From mehmet at akcin.net Thu Jun 1 04:15:05 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 01 Jun 2017 04:15:05 +0000 Subject: Help evaluate CDN Message-ID: Hey there I have written few blog posts about dns performance in the past comparing public resolver performance and root server performance using tools like thousandeyes. I am now working on a new blog post independently and voluntarily comparing cdn performance. I wanted to reach out to experts in the community ask feedback on what they wanted to see in such comparison. What are some of the important things like cache-hit-ratio etc. you look for when evaluating CDN performance? What categories would you like to see? Such as video performance, static images, etc. Appreciate any feedback you can share, and will make sure to thank you for your help in my post(s). I might even buy you guys beer @ nanog :) i will be in Bellevue next week if anybody prefers to talk face to face Mehmet From vikash_sorout at yahoo.com Thu Jun 1 01:47:53 2017 From: vikash_sorout at yahoo.com (Vikash Sorout) Date: Thu, 1 Jun 2017 01:47:53 +0000 (UTC) Subject: ospf suppress-fa References: <118392368.218778.1496281673773.ref@mail.yahoo.com> Message-ID: <118392368.218778.1496281673773@mail.yahoo.com> blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; } What is the purpose of suppressing FA when Type 7 is translated to Type 5 and injected to backbone area by ABR. I don't see any reason other than hiding the NSSA ASBR details .Guys please suggest . Sent from Yahoo Mail for iPhone From nanog at ics-il.net Thu Jun 1 12:56:26 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 1 Jun 2017 07:56:26 -0500 (CDT) Subject: Internet connectivity in Ghana In-Reply-To: References: Message-ID: <1676164459.2045.1496321786279.JavaMail.mhammett@ThunderFuck> These cable systems land in Ghana. Look to see who rides those cable systems to see who is at least capable of serving your client. Then you have to figure out how to get from your client to the coast. SAT-3 WACS GLO1 ACE MainOne ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Rishi Singh" To: nanog at nanog.org Sent: Wednesday, May 31, 2017 9:40:29 AM Subject: Internet connectivity in Ghana Has anyone dealt with getting internet connectivity in Ghana? I've been doing a lot of research and saw some peering plans with Nigeria but nothing solid there yet. Currently a financial client of mine is paying quite a bit every quarter on satellite up link fees. Do any of the major carriers have any direct connectivity into Ghana? Thank you, From rod.beck at unitedcablecompany.com Thu Jun 1 13:45:50 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 1 Jun 2017 13:45:50 +0000 Subject: Internet connectivity in Ghana In-Reply-To: <1676164459.2045.1496321786279.JavaMail.mhammett@ThunderFuck> References: , <1676164459.2045.1496321786279.JavaMail.mhammett@ThunderFuck> Message-ID: I would recommend PCCW because they own capacity on many these systems and have experience in delivering service. I have contacts I can recommend. - R. ________________________________ From: NANOG on behalf of Mike Hammett Sent: Thursday, June 1, 2017 2:56 PM To: Rishi Singh Cc: nanog at nanog.org Subject: Re: Internet connectivity in Ghana These cable systems land in Ghana. Look to see who rides those cable systems to see who is at least capable of serving your client. Then you have to figure out how to get from your client to the coast. SAT-3 WACS GLO1 ACE MainOne ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Rishi Singh" To: nanog at nanog.org Sent: Wednesday, May 31, 2017 9:40:29 AM Subject: Internet connectivity in Ghana Has anyone dealt with getting internet connectivity in Ghana? I've been doing a lot of research and saw some peering plans with Nigeria but nothing solid there yet. Currently a financial client of mine is paying quite a bit every quarter on satellite up link fees. Do any of the major carriers have any direct connectivity into Ghana? Thank you, From aaron1 at gvtc.com Thu Jun 1 13:52:44 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 1 Jun 2017 08:52:44 -0500 Subject: Leasing /22 blocks In-Reply-To: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> References: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> Message-ID: <002c01d2dade$58a0e520$09e2af60$@gvtc.com> Someone recently reached out to me and asked me about this same thing... to which I responded by asking them how much they would pay me to lease my address space... here was their response...I'm pretty sure they are U.S.-based company. I'd rather not say who they are... since I'm not sure I'm at liberty to do so. ************************************************************** Please see below pricing (per month with 6 months commitment) : /19 - 2000$ /20 - 1200$ /21 - 600$ /22 - 400$ /23 - 200$ /24 - 100$ ************************************************************** - Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Security Admin (NetSec) Sent: Friday, May 26, 2017 11:45 AM To: 'nanog at nanog.org' Subject: Leasing /22 blocks Recently had someone offer to lease some IPv4 address space from me. Have never done that before. I thought I would ask the group what a reasonable monthly rate for a /22 in the United States might be. Thanks in advance! Ed(ward) Ray From aaron1 at gvtc.com Thu Jun 1 13:55:16 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 1 Jun 2017 08:55:16 -0500 Subject: RFC2544 Testing Equipment In-Reply-To: <829bff2b-8054-104a-5042-7deb9aac2568@talkunafraid.co.uk> References: <829bff2b-8054-104a-5042-7deb9aac2568@talkunafraid.co.uk> Message-ID: <002e01d2dade$b348e720$19dab560$@gvtc.com> We used VeEX for a while and had our CO Techs run around with hand-held VeEx testers and run tests from them to a VeEx loopback device.... I config'd mpls pw's between them. We don't really do this anymore... we now role out Accedian MetroNid's and MetroNode's which have a lot of this RFC2544 and Y.1731 (accedian paa) built-in... -Aaron From lguillory at reservetele.com Thu Jun 1 13:57:07 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Thu, 1 Jun 2017 13:57:07 +0000 Subject: Leasing /22 blocks In-Reply-To: <002c01d2dade$58a0e520$09e2af60$@gvtc.com> References: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> <002c01d2dade$58a0e520$09e2af60$@gvtc.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1B42C0@RTC-EXCH01.RESERVE.LDS> LogicWeb leases IPs, their pricing is below. /21 -1600$ /22 - 800$ /23 - 400$ /24 - 200$ Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould Sent: Thursday, June 01, 2017 8:53 AM To: 'Security Admin (NetSec)'; nanog at nanog.org Subject: RE: Leasing /22 blocks Someone recently reached out to me and asked me about this same thing... to which I responded by asking them how much they would pay me to lease my address space... here was their response...I'm pretty sure they are U.S.-based company. I'd rather not say who they are... since I'm not sure I'm at liberty to do so. ************************************************************** Please see below pricing (per month with 6 months commitment) : /19 - 2000$ /20 - 1200$ /21 - 600$ /22 - 400$ /23 - 200$ /24 - 100$ ************************************************************** - Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Security Admin (NetSec) Sent: Friday, May 26, 2017 11:45 AM To: 'nanog at nanog.org' Subject: Leasing /22 blocks Recently had someone offer to lease some IPv4 address space from me. Have never done that before. I thought I would ask the group what a reasonable monthly rate for a /22 in the United States might be. Thanks in advance! Ed(ward) Ray From josh at imaginenetworksllc.com Thu Jun 1 13:58:29 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 1 Jun 2017 09:58:29 -0400 Subject: Leasing /22 blocks In-Reply-To: <002c01d2dade$58a0e520$09e2af60$@gvtc.com> References: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> <002c01d2dade$58a0e520$09e2af60$@gvtc.com> Message-ID: For purchase price I've seen a lot of recommendation for https://www.ipv4auctions.com/ Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Jun 1, 2017 9:53 AM, "Aaron Gould" wrote: > Someone recently reached out to me and asked me about this same thing... to > which I responded by asking them how much they would pay me to lease my > address space... here was their response...I'm pretty sure they are > U.S.-based company. I'd rather not say who they are... since I'm not sure > I'm at liberty to do so. > > ************************************************************** > Please see below pricing (per month with 6 months commitment) : > > /19 - 2000$ > /20 - 1200$ > /21 - 600$ > /22 - 400$ > /23 - 200$ > /24 - 100$ > ************************************************************** > > - Aaron > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Security Admin > (NetSec) > Sent: Friday, May 26, 2017 11:45 AM > To: 'nanog at nanog.org' > Subject: Leasing /22 blocks > > Recently had someone offer to lease some IPv4 address space from me. Have > never done that before. > > I thought I would ask the group what a reasonable monthly rate for a /22 in > the United States might be. > > Thanks in advance! > > Ed(ward) Ray > > From math at sizone.org Thu Jun 1 14:04:35 2017 From: math at sizone.org (Ken Chase) Date: Thu, 1 Jun 2017 10:04:35 -0400 Subject: Leasing /22 blocks In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1B42C0@RTC-EXCH01.RESERVE.LDS> References: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> <002c01d2dade$58a0e520$09e2af60$@gvtc.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1B42C0@RTC-EXCH01.RESERVE.LDS> Message-ID: <20170601140434.GY25240@sizone.org> Almost attractive pricing, but then we assume those IPs are trashed for life, and attract blowback scan/hack traffic? I would think that permanent sale is the only option, once one has removed all traces of one's name from all records (irr and robtex and mxtoolbox and and and) before one does. /kc On Thu, Jun 01, 2017 at 01:57:07PM +0000, Luke Guillory said: >LogicWeb leases IPs, their pricing is below. > >/21 -1600$ >/22 - 800$ >/23 - 400$ >/24 - 200$ > > > > >Luke Guillory >Network Operations Manager > >Tel: 985.536.1212 >Fax: 985.536.0300 >Email: lguillory at reservetele.com > >Reserve Telecommunications >100 RTC Dr >Reserve, LA 70084 > >_________________________________________________________________________________________________ > >Disclaimer: >The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould >Sent: Thursday, June 01, 2017 8:53 AM >To: 'Security Admin (NetSec)'; nanog at nanog.org >Subject: RE: Leasing /22 blocks > >Someone recently reached out to me and asked me about this same thing... to which I responded by asking them how much they would pay me to lease my address space... here was their response...I'm pretty sure they are U.S.-based company. I'd rather not say who they are... since I'm not sure I'm at liberty to do so. > >************************************************************** >Please see below pricing (per month with 6 months commitment) : > >/19 - 2000$ >/20 - 1200$ >/21 - 600$ >/22 - 400$ >/23 - 200$ >/24 - 100$ >************************************************************** > >- Aaron > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Security Admin >(NetSec) >Sent: Friday, May 26, 2017 11:45 AM >To: 'nanog at nanog.org' >Subject: Leasing /22 blocks > >Recently had someone offer to lease some IPv4 address space from me. Have never done that before. > >I thought I would ask the group what a reasonable monthly rate for a /22 in the United States might be. > >Thanks in advance! > >Ed(ward) Ray > Ken Chase - math at sizone.org Guelph Canada From aaron1 at gvtc.com Thu Jun 1 14:24:40 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 1 Jun 2017 09:24:40 -0500 Subject: Leasing /22 blocks In-Reply-To: References: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> <002c01d2dade$58a0e520$09e2af60$@gvtc.com> Message-ID: <003301d2dae2$ce9fd110$6bdf7330$@gvtc.com> Yeah, I was looking at ipv4auctions.com a while back and recall seeing $10/per ip? now it seems that $12.50/per ip is the lowest -Aaron From lguillory at reservetele.com Thu Jun 1 15:02:17 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Thu, 1 Jun 2017 15:02:17 +0000 Subject: Leasing /22 blocks In-Reply-To: <003301d2dae2$ce9fd110$6bdf7330$@gvtc.com> References: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> <002c01d2dade$58a0e520$09e2af60$@gvtc.com> <003301d2dae2$ce9fd110$6bdf7330$@gvtc.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1B456C@RTC-EXCH01.RESERVE.LDS> While that is true, it does still require ARIN approval in the US and will need to be justified. Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould Sent: Thursday, June 01, 2017 9:25 AM To: 'Josh Luthman' Cc: 'NANOG list' Subject: RE: Leasing /22 blocks Yeah, I was looking at ipv4auctions.com a while back and recall seeing $10/per ip? now it seems that $12.50/per ip is the lowest -Aaron From izaac at setec.org Thu Jun 1 15:04:09 2017 From: izaac at setec.org (Izaac) Date: Thu, 1 Jun 2017 11:04:09 -0400 Subject: Leasing /22 blocks In-Reply-To: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> References: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> Message-ID: <20170601T145729Z@localhost> On Fri, May 26, 2017 at 04:44:52PM +0000, Security Admin (NetSec) wrote: > Recently had someone offer to lease some IPv4 address space from me. > Have never done that before. > > I thought I would ask the group what a reasonable monthly rate for a > /22 in the United States might be. Let me just set up my crystal ball. Perhaps I can divine the future of your address space. Hmmm. It's a little cloudy. A lot of retransmits. What if I adjust this here -- nope, that's upping the packet loss. Maybe ...? Ahh, yes. It's starting to take shape. I see ... I see your IP space being used for abuse. It's appearing on every blacklist imaginable. Whole segments of the Network null route it. Hmmm. It's being returned to you by the spamm--clients. About a week later. You're sitting there with a couple hundred dollars. And a letter from ARIN. You look .. sad. Yes, definitely sad. I'd recommend not doing that. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From alexis.letessier at gmail.com Thu Jun 1 12:41:03 2017 From: alexis.letessier at gmail.com (Alexis Letessier) Date: Thu, 1 Jun 2017 14:41:03 +0200 Subject: Lille, France In-Reply-To: References: Message-ID: <7B1BBFD0-7D15-478B-B8C7-1FCBF6430076@sfr.com> Hello Rod, Altice France can sell you optical links or optical transport or IPv4/v6 transit from any to any point in France. Lille to Paris should be OK. For last mile networks we should be able to help you since we have the biggest optical network in France (we have approximately 2 million fiber optic customers). If you can provide with the exact GPS points you wish to connect we could try to estimate the price with you. Do you want black fiber or MPLS transport ? Last time i did that for one of our backbones, i ended up using optical transmission which is based on 100g links. Quick and easy. Regards, Alexis Letessier > On 24 May 2017, at 21:03, Rod Beck wrote: > > Hi, > > > I am looking for insight into which carriers have metropolitan or last mile networks in this city. Preferably connected to Paris. > > > Roderick Beck > > Director of Global Sales > > United Cable Company > > www.unitedcablecompany.com > > 85 Kir?ly utca, 1077 Budapest > > rod.beck at unitedcablecompany.com > > 36-30-859-5144 > > > [1467221477350_image005.png] From beatrice at wiredscore.com Thu Jun 1 12:41:29 2017 From: beatrice at wiredscore.com (Beatrice Ghorra) Date: Thu, 1 Jun 2017 14:41:29 +0200 Subject: Lille, France In-Reply-To: <1495791721.2910018.989274112.6BC43DB2@webmail.messagingengine.com> References: <1495791721.2910018.989274112.6BC43DB2@webmail.messagingengine.com> Message-ID: Hi all, I beg to differ Scott, the SFR Group owned by Altice lays its own Fiber Optic networks and are present in all major cities in France. Each company that has been part of the group has a solid knowledge of fiber deployments for B2C and B2B clients. The mergers and acquisitions has helped the group consolidate many networks and add more capillarity nationwide. Regards, -- Beatrice Ghorra On Fri, May 26, 2017 at 11:42 AM, Scott Christopher wrote: > Rod Beck wrote: > > > Altice is in the States and going public soon. They have been producing > > superior financial results. Appears to know how to run these cable > > networks better than the standard American management. > > They don't actually lay any cable though, nor do they build their own > network. They have been acquiring other telecoms at a brisk pace for 15 > years as the industry consolidates. (They are debt heavy, especially for > a European company, and this upcoming IPO is a 20% sale to grab more > capital, riding the wave of recent market bullishness for U.S. > telecoms.) > > Not sure if any of us network engineers will like them in 2 - 4 years - > but you're a business consultant seeing this from a different > perspective. ;) > > -- > Regards, > S.C. > ? From nbakker at me.com Thu Jun 1 15:00:19 2017 From: nbakker at me.com (Nick Bakker) Date: Thu, 01 Jun 2017 15:00:19 +0000 (GMT) Subject: XO SIP in Chicago Message-ID: Is anyone else having issues with XO SIP service in the Chicago area?? We?re seeing poor audio quality on outbound calls and inbound calls may or may not work. ? ? Thanks! From kvicknair at reservetele.com Thu Jun 1 15:27:37 2017 From: kvicknair at reservetele.com (Kody Vicknair) Date: Thu, 1 Jun 2017 15:27:37 +0000 Subject: XO SIP in Chicago In-Reply-To: References: Message-ID: <3979AE529B56AB47942E2423B707F16E64C07036@RTC-EXCH01.RESERVE.LDS> Quoted: > Having issues starting at 8:31AM CST with call quality on XO SIP. Inbound calls goes from the number is not available message, to calls completing but very choppy voice quality. Outbound calls seems to work but voice quality is poor. Opened a ticket with XO no call back or engineer picked up the ticket. Anyone else having issues with XO SIP? Judah Sameth | Director of Information Technology Judah.Sameth at xsportfitness.com p: 630.318.3470 Kody Vicknair Network Engineer Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Bakker Sent: Thursday, June 01, 2017 10:00 AM To: nanog at nanog.org Subject: XO SIP in Chicago Is anyone else having issues with XO SIP service in the Chicago area? We?re seeing poor audio quality on outbound calls and inbound calls may or may not work. Thanks! From eric.kuhnke at gmail.com Thu Jun 1 15:30:54 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 1 Jun 2017 08:30:54 -0700 Subject: Internet connectivity in Ghana In-Reply-To: References: Message-ID: All of the licensed mobile phone network operators in Ghana are also ISPs and can reach enterprise customers. Within Accra or a few other major coastal cities, either by microwave rooftop/tower based links or their terrestrial fiber. Should definitely be much faster and more economical than satellite. Interestingly if you look at BGP tables and AS-adjacencies for the major Ghanian ISPs and telecoms, it is logically a suburb of London, which is where most of the traffic in the recently built West African submarine cables goes. On Wed, May 31, 2017 at 7:40 AM, Rishi Singh wrote: > Has anyone dealt with getting internet connectivity in Ghana? I've been > doing a lot of research and saw some peering plans with Nigeria but nothing > solid there yet. Currently a financial client of mine is paying quite a bit > every quarter on satellite up link fees. > > Do any of the major carriers have any direct connectivity into Ghana? > > Thank you, > From bob at FiberInternetCenter.com Thu Jun 1 15:54:15 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 1 Jun 2017 08:54:15 -0700 Subject: Leasing /22 blocks In-Reply-To: <20170601T145729Z@localhost> References: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> <20170601T145729Z@localhost> Message-ID: <2e3c16f6ebc725674c471bb74e05f55d.squirrel@66.201.44.180> You must look deeply into the company you lease IPs too. Have a contract - there is one on RentIPv4.com you can download, copy and modify. (I created it, I say you can do that if you need one.) But the contract is a small part....Because companies come and go. You must be able to verify many things about the company - how long in business - explore previous IPs they utilized... what they plan to do with them, will thier customers spam with them, etc. If not you run a greater risk of getting back IPs that are on international black lists. Many of those will require you to pay a ransom fees to be removed blocks. Thank You Bob Evans CTO > On Fri, May 26, 2017 at 04:44:52PM +0000, Security Admin (NetSec) wrote: >> Recently had someone offer to lease some IPv4 address space from me. >> Have never done that before. >> >> I thought I would ask the group what a reasonable monthly rate for a >> /22 in the United States might be. > > Let me just set up my crystal ball. Perhaps I can divine the future of > your address space. Hmmm. It's a little cloudy. A lot of retransmits. > What if I adjust this here -- nope, that's upping the packet loss. > Maybe ...? Ahh, yes. It's starting to take shape. I see ... > > I see your IP space being used for abuse. It's appearing on every > blacklist imaginable. Whole segments of the Network null route it. > Hmmm. It's being returned to you by the spamm--clients. About a week > later. You're sitting there with a couple hundred dollars. And a > letter from ARIN. You look .. sad. Yes, definitely sad. > > I'd recommend not doing that. > > -- > . ___ ___ . . ___ > . \ / |\ |\ \ > . _\_ /__ |-\ |-\ \__ > From pkranz at unwiredltd.com Thu Jun 1 17:50:04 2017 From: pkranz at unwiredltd.com (Peter Kranz) Date: Thu, 1 Jun 2017 10:50:04 -0700 Subject: Anyone using Arista 7280R as edge router? In-Reply-To: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> References: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> Message-ID: <032d01d2daff$8004a770$800df650$@unwiredltd.com> > Arista?s specs say the 7500R / 7280R can handle 1M ipv4+ipv6 routes in hardware (FIB): I'm using these as edge routers facing multiple peering networks and several full table feeds. No problems so far, very cost effective platform in my mind. Here is what it looks like with about 100 peers and several full table feeds: Forwarding Resources Usage Table Feature Chip Used Used Free Committed Best Case High Entries (%) Entries Entries Max Watermark Entries -------- ----------- --------- -------- ----- --------- ----------- ----------- --------- LEM 559529 71% 226903 0 786432 560163 LEM MAC 242 0% 226903 0 786432 290 Routing Resource1 874 42% 1174 0 2048 880 Routing Resource2 543 53% 481 0 1024 548 Routing Resource3 16038 48% 16730 0 32768 16060 Routing V4Hosts 0 0% 81920 0 81920 0 Routing V4Routes 541905 70% 226903 0 786432 542491 Routing V6Hosts 0 0% 81920 0 81920 0 Routing V6Routes 17382 7% 226903 0 786432 17481 From sean at donelan.com Thu Jun 1 18:02:46 2017 From: sean at donelan.com (Sean Donelan) Date: Thu, 1 Jun 2017 14:02:46 -0400 (EDT) Subject: Russian diplomats lingering near fiber optic cables Message-ID: There must be a perfectly logical explanation.... Yes, people in the industry know where the choke points are. But the choke points aren't always the most obvious places. Its kinda a weird for diplomats to show up there. On the other hand, I've been a fiber optic tourist. I've visited many critical choke points in the USA and other countries, and even took selfies :-) http://www.politico.com/story/2017/06/01/russia-spies-espionage-trump-239003 In the throes of the 2016 campaign, the FBI found itself with an escalating problem: Russian diplomats, whose travel was supposed to be tracked by the State Department, were going missing. The diplomats, widely assumed to be intelligence operatives, would eventually turn up in odd places, often in middle-of-nowhere USA. One was found on a beach, nowhere near where he was supposed to be. In one particularly bizarre case, relayed by a U.S. intelligence official, another turned up wandering around in the middle of the desert. Interestingly, both seemed to be lingering where underground fiber-optic cables tend to run. According to another U.S. intelligence official, ?They find these guys driving around in circles in Kansas. It?s a pretty aggressive effort.? It?s a trend that has led intelligence officials to conclude that the Kremlin is waging a quiet effort to map the United States? telecommunications infrastructure, perhaps preparing for an opportunity to disrupt it. From jared at puck.nether.net Thu Jun 1 18:05:42 2017 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 1 Jun 2017 14:05:42 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: > On Jun 1, 2017, at 2:02 PM, Sean Donelan wrote: > > > There must be a perfectly logical explanation.... Yes, people in the industry know where the choke points are. But the choke points aren't always the most obvious places. Its kinda a weird for diplomats to show up there. > > On the other hand, I've been a fiber optic tourist. I've visited many critical choke points in the USA and other countries, and even took selfies :-) > > > http://www.politico.com/story/2017/06/01/russia-spies-espionage-trump-239003 > > In the throes of the 2016 campaign, the FBI found itself with an escalating problem: Russian diplomats, whose travel was supposed to be tracked by the State Department, were going missing. > > The diplomats, widely assumed to be intelligence operatives, would eventually turn up in odd places, often in middle-of-nowhere USA. One was found on a beach, nowhere near where he was supposed to be. In one particularly bizarre case, relayed by a U.S. intelligence official, another turned up wandering around in the middle of the desert. Interestingly, both seemed to be lingering where underground fiber-optic cables tend to run. > > According to another U.S. intelligence official, ?They find these guys driving around in circles in Kansas. It?s a pretty aggressive effort.? > > It?s a trend that has led intelligence officials to conclude that the Kremlin is waging a quiet effort to map the United States? telecommunications infrastructure, perhaps preparing for an opportunity to disrupt it. Seems it would be easier to just pay for a subscription to a service like FiberLocator or similar. They could just dial 811 as well and request the locates happen. - Jared From Brandon.Vincent at asu.edu Thu Jun 1 18:32:28 2017 From: Brandon.Vincent at asu.edu (Brandon Vincent) Date: Thu, 1 Jun 2017 11:32:28 -0700 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: DO NOT ANCHOR OR DREDGE is a pretty good indicator. On Thu, Jun 1, 2017 at 11:05 AM, Jared Mauch wrote: > >> On Jun 1, 2017, at 2:02 PM, Sean Donelan wrote: >> >> >> There must be a perfectly logical explanation.... Yes, people in the industry know where the choke points are. But the choke points aren't always the most obvious places. Its kinda a weird for diplomats to show up there. >> >> On the other hand, I've been a fiber optic tourist. I've visited many critical choke points in the USA and other countries, and even took selfies :-) >> >> >> http://www.politico.com/story/2017/06/01/russia-spies-espionage-trump-239003 >> >> In the throes of the 2016 campaign, the FBI found itself with an escalating problem: Russian diplomats, whose travel was supposed to be tracked by the State Department, were going missing. >> >> The diplomats, widely assumed to be intelligence operatives, would eventually turn up in odd places, often in middle-of-nowhere USA. One was found on a beach, nowhere near where he was supposed to be. In one particularly bizarre case, relayed by a U.S. intelligence official, another turned up wandering around in the middle of the desert. Interestingly, both seemed to be lingering where underground fiber-optic cables tend to run. >> >> According to another U.S. intelligence official, ?They find these guys driving around in circles in Kansas. It?s a pretty aggressive effort.? >> >> It?s a trend that has led intelligence officials to conclude that the Kremlin is waging a quiet effort to map the United States? telecommunications infrastructure, perhaps preparing for an opportunity to disrupt it. > > Seems it would be easier to just pay for a subscription to a service like FiberLocator or similar. > > They could just dial 811 as well and request the locates happen. > > - Jared From valdis.kletnieks at vt.edu Thu Jun 1 18:56:37 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 01 Jun 2017 14:56:37 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: <21710.1496343397@turing-police.cc.vt.edu> On Thu, 01 Jun 2017 11:32:28 -0700, Brandon Vincent said: > DO NOT ANCHOR OR DREDGE is a pretty good indicator. In Kansas? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From mel at beckman.org Thu Jun 1 18:56:45 2017 From: mel at beckman.org (Mel Beckman) Date: Thu, 1 Jun 2017 18:56:45 +0000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: , Message-ID: <61591C57-2582-4926-9D42-DA350BF10230@beckman.org> That's how we found the Russian's fiber cables: "According to ?Blind Man?s Bluff,? Bradley, in his predawn stupor, recalled from his youth written signs that had been posted along the Mississippi River to mark undersea cables. The signs, posted along the shore, were meant to prevent passing from hooking the cables with their anchors. With this in mind, Bradley reasoned that there had to be similar signs near the shallower points on the Sea of Okhotsk." https://www.washingtonpost.com/news/checkpoint/wp/2015/10/26/as-russia-scopes-undersea-cables-a-shadow-of-the-united-states-cold-war-past/?utm_term=.48dbf7c289af -mel beckman > On Jun 1, 2017, at 11:33 AM, Brandon Vincent wrote: > > DO NOT ANCHOR OR DREDGE is a pretty good indicator. > >> On Thu, Jun 1, 2017 at 11:05 AM, Jared Mauch wrote: >> >>> On Jun 1, 2017, at 2:02 PM, Sean Donelan wrote: >>> >>> >>> There must be a perfectly logical explanation.... Yes, people in the industry know where the choke points are. But the choke points aren't always the most obvious places. Its kinda a weird for diplomats to show up there. >>> >>> On the other hand, I've been a fiber optic tourist. I've visited many critical choke points in the USA and other countries, and even took selfies :-) >>> >>> >>> http://www.politico.com/story/2017/06/01/russia-spies-espionage-trump-239003 >>> >>> In the throes of the 2016 campaign, the FBI found itself with an escalating problem: Russian diplomats, whose travel was supposed to be tracked by the State Department, were going missing. >>> >>> The diplomats, widely assumed to be intelligence operatives, would eventually turn up in odd places, often in middle-of-nowhere USA. One was found on a beach, nowhere near where he was supposed to be. In one particularly bizarre case, relayed by a U.S. intelligence official, another turned up wandering around in the middle of the desert. Interestingly, both seemed to be lingering where underground fiber-optic cables tend to run. >>> >>> According to another U.S. intelligence official, ?They find these guys driving around in circles in Kansas. It?s a pretty aggressive effort.? >>> >>> It?s a trend that has led intelligence officials to conclude that the Kremlin is waging a quiet effort to map the United States? telecommunications infrastructure, perhaps preparing for an opportunity to disrupt it. >> >> Seems it would be easier to just pay for a subscription to a service like FiberLocator or similar. >> >> They could just dial 811 as well and request the locates happen. >> >> - Jared From eric.kuhnke at gmail.com Thu Jun 1 19:20:54 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 1 Jun 2017 12:20:54 -0700 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: It's not like the locations of any of the transatlantic or transpacific cable landing stations are a big secret. They're published in the FCC's digest reports for international authorization and whenever ownership of a cable changes hands or is restructured. Additionally it is pretty hard to hide from modern imagery intelligence analysis any sort of building that has 1+1 or N+1 200kW diesel generators and the cooling required for a medium sized telecom facility. Locations of cables are published specifically for the purpose of helping trawlers and ships avoid damaging them, for example: http://bandoncable.org/cables.asp That said, a pretty quick way to get on some homeland security watch lists would be to hang around a cable landing station beach location with a big DSLR camera, and appear uninterested in the beach... On Thu, Jun 1, 2017 at 11:02 AM, Sean Donelan wrote: > > There must be a perfectly logical explanation.... Yes, people in the > industry know where the choke points are. But the choke points aren't > always the most obvious places. Its kinda a weird for diplomats to show up > there. > > On the other hand, I've been a fiber optic tourist. I've visited many > critical choke points in the USA and other countries, and even took selfies > :-) > > > http://www.politico.com/story/2017/06/01/russia-spies-espion > age-trump-239003 > > In the throes of the 2016 campaign, the FBI found itself with an > escalating problem: Russian diplomats, whose travel was supposed to be > tracked by the State Department, were going missing. > > The diplomats, widely assumed to be intelligence operatives, would > eventually turn up in odd places, often in middle-of-nowhere USA. One was > found on a beach, nowhere near where he was supposed to be. In one > particularly bizarre case, relayed by a U.S. intelligence official, another > turned up wandering around in the middle of the desert. Interestingly, both > seemed to be lingering where underground fiber-optic cables tend to run. > > According to another U.S. intelligence official, ?They find these guys > driving around in circles in Kansas. It?s a pretty aggressive effort.? > > It?s a trend that has led intelligence officials to conclude that the > Kremlin is waging a quiet effort to map the United States? > telecommunications infrastructure, perhaps preparing for an opportunity to > disrupt it. > From rod.beck at unitedcablecompany.com Thu Jun 1 19:44:12 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 1 Jun 2017 19:44:12 +0000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: , Message-ID: As someone who has sold a lot of capacity on Hibernia Atlantic, I must concur. There is a website showing where most of the Trans-Atlantic cables land on the West Coast of Britain at towns like Bude in Wales. Hiding is not an option. http://www.kis-orca.eu/ Regards, Roderick. ________________________________ From: NANOG on behalf of Eric Kuhnke Sent: Thursday, June 1, 2017 9:20 PM To: nanog at nanog.org list Subject: Re: Russian diplomats lingering near fiber optic cables It's not like the locations of any of the transatlantic or transpacific cable landing stations are a big secret. They're published in the FCC's digest reports for international authorization and whenever ownership of a cable changes hands or is restructured. Additionally it is pretty hard to hide from modern imagery intelligence analysis any sort of building that has 1+1 or N+1 200kW diesel generators and the cooling required for a medium sized telecom facility. Locations of cables are published specifically for the purpose of helping trawlers and ships avoid damaging them, for example: http://bandoncable.org/cables.asp [http://bandoncable.org/images/cable01.jpg] Bandon Submarine Cable Council - Cable Locations bandoncable.org Be advised of the location if two submarine cables in the North Pacific located off the coast of Bandon, Oregon. The TPC-5 cable system consists of ... That said, a pretty quick way to get on some homeland security watch lists would be to hang around a cable landing station beach location with a big DSLR camera, and appear uninterested in the beach... On Thu, Jun 1, 2017 at 11:02 AM, Sean Donelan wrote: > > There must be a perfectly logical explanation.... Yes, people in the > industry know where the choke points are. But the choke points aren't > always the most obvious places. Its kinda a weird for diplomats to show up > there. > > On the other hand, I've been a fiber optic tourist. I've visited many > critical choke points in the USA and other countries, and even took selfies > :-) > > > http://www.politico.com/story/2017/06/01/russia-spies-espion > age-trump-239003 > > In the throes of the 2016 campaign, the FBI found itself with an > escalating problem: Russian diplomats, whose travel was supposed to be > tracked by the State Department, were going missing. > > The diplomats, widely assumed to be intelligence operatives, would > eventually turn up in odd places, often in middle-of-nowhere USA. One was > found on a beach, nowhere near where he was supposed to be. In one > particularly bizarre case, relayed by a U.S. intelligence official, another > turned up wandering around in the middle of the desert. Interestingly, both > seemed to be lingering where underground fiber-optic cables tend to run. > > According to another U.S. intelligence official, ?They find these guys > driving around in circles in Kansas. It?s a pretty aggressive effort.? > > It?s a trend that has led intelligence officials to conclude that the > Kremlin is waging a quiet effort to map the United States? > telecommunications infrastructure, perhaps preparing for an opportunity to > disrupt it. > From sean at donelan.com Thu Jun 1 19:54:32 2017 From: sean at donelan.com (Sean Donelan) Date: Thu, 1 Jun 2017 15:54:32 -0400 (EDT) Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: , Message-ID: On Thu, 1 Jun 2017, Rod Beck wrote: > As someone who has sold a lot of capacity on Hibernia Atlantic, I must > concur. There is a website showing where most of the Trans-Atlantic > cables land on the West Coast of Britain at towns like Bude in Wales. > Hiding is not an option. As far as I know, there are no cable landing stations in Kansas. Has US geography changed recently? From rod.beck at unitedcablecompany.com Thu Jun 1 19:57:42 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 1 Jun 2017 19:57:42 +0000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: , , Message-ID: Last time I checked satellite imagery, existing fiber maps, as well as signs saying "Fiber Optic Cables" lead to the same outcome: Very little can be hidden. Nice try, Sean. You can try out next year. ________________________________ From: Sean Donelan Sent: Thursday, June 1, 2017 9:54 PM To: Rod Beck Cc: Eric Kuhnke; nanog at nanog.org list Subject: Re: Russian diplomats lingering near fiber optic cables On Thu, 1 Jun 2017, Rod Beck wrote: > As someone who has sold a lot of capacity on Hibernia Atlantic, I must > concur. There is a website showing where most of the Trans-Atlantic > cables land on the West Coast of Britain at towns like Bude in Wales. > Hiding is not an option. As far as I know, there are no cable landing stations in Kansas. Has US geography changed recently? From clinton.mielke at gmail.com Thu Jun 1 20:00:49 2017 From: clinton.mielke at gmail.com (clinton mielke) Date: Thu, 1 Jun 2017 13:00:49 -0700 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: Sea levels rose pretty quickly On Thu, Jun 1, 2017 at 12:54 PM, Sean Donelan wrote: > On Thu, 1 Jun 2017, Rod Beck wrote: > >> As someone who has sold a lot of capacity on Hibernia Atlantic, I must >> concur. There is a website showing where most of the Trans-Atlantic cables >> land on the West Coast of Britain at towns like Bude in Wales. Hiding is >> not an option. >> > > As far as I know, there are no cable landing stations in Kansas. > > Has US geography changed recently? > > > From jlmcgraw at gmail.com Thu Jun 1 20:02:05 2017 From: jlmcgraw at gmail.com (Jesse McGraw) Date: Thu, 1 Jun 2017 16:02:05 -0400 Subject: Solarwinds Orion/NPM business hours 95th percentile query Message-ID: <507e1449-64af-4f92-159d-b8400d276660@gmail.com> ( I'm not sure if this will be generally useful, but I needed it so I thought I'd share in case others may too ) I have a system that uses Solarwinds NPM/Orion to collect interface utilization data from devices scattered around the globe and I found myself needing to calculate 95th percentile values from it that only takes into account local business hours (i.e. no weekends or nights). After much googling and banging around on the keyboard this is the query that I came up with. As it stands you have to manually adjust the query for the timezones of the SQL database itself and the various devices you're querying, it would be smarter to add a custom field for each device representing its UTC offset and use that value in the query but I haven't made that happen yet I am certainly no SQL maestro so I've also put it into a github repository in case anyone has ideas on how to improve it or fix any silly mistakes I've made https://github.com/jlmcgraw/sql_queries_for_solarwinds_orion/blob/master/solarwinds_orion_95th_percentile_business_hours_sql_query.sql --Jesse -- This is a query to calculate 95th percentile statistics for bits in, bits out, -- and a new column that is the max of bits in vs. bits out for each sample -- only for business hours (i.e. excluding weekends and hours before / after work -- hours) -- -- Edit the "WHERE" statement in the "InterfaceTraffic_Detail_BusinessHours" CTE -- to choose which devices you're querying -- -- Developed/tested with -- Microsoft SQL server 2014 -- Orion Platform 2017.1, NPM 12.1 -- Uses the detailed last 30 days view of interface statistics -- [swnpm].[dbo].[InterfaceTraffic_Detail] -- you may wish to use different input data -- -- Issues -- You currently must adjust the timezone setting manually and be sure to query -- only devices that are all in the same timezone -- Surely performance can be improved -- To Do -- Document adding a custom column with a UTC offset for each device and modify -- this query to use that value instead -- Account for standard vs. daylight savings time DECLARE @SampleOffset Float DECLARE @TargetDeviceOffset Float DECLARE @TargetPercentile Float DECLARE @StartBusinessHours Float DECLARE @EndBusinessHours Float -- The UTC offset of the timezone the samples are stored in -- (i.e. where the database is) SET @SampleOffset = -4.0 -- The UTC offset of the timezone where the target devices are SET @TargetDeviceOffset = -4.0 -- Target percentile as a decimal SET @TargetPercentile = 0.95 -- When do business hours start ( 0700 = 7am ) SET @StartBusinessHours = 7 -- When do business hours end ( 1800 = 6pm ) SET @EndBusinessHours = 18 ; WITH InterfaceTraffic_Detail_BusinessHours AS ( -- Create a CTE showing only business hours data -- Also adding a MaxBps column SELECT i.DateTime ,i.interfaceid ,i.[In_Maxbps] ,i.[out_Maxbps] ,MaxBps = CASE --Use whichever is greater of IN vs. OUT WHEN Out_Maxbps > In_Maxbps THEN Out_Maxbps ELSE In_Maxbps END FROM [swnpm].[dbo].[InterfaceTraffic_Detail] as I INNER JOIN [swnpm].[dbo].[Nodes] as N ON (n.NodeID = [i].NodeID ) WHERE (n.SysName LIKE '%pattern1%' -- or n.SysName LIKE '%pattern1%' -- or n.SysName LIKE '%pattern2%' -- or n.SysName LIKE '%pattern3%' -- or n.SysName LIKE '%pattern4%' ) AND ( -- This adjusts for both the timezone of the samples and the target device -- Not Saturday or Sunday after adjusting for timezones (DATEPART(dw,DATEADD(hh,- at SampleOffset+@TargetDeviceOffset,DateTime)) <> 1 AND (DATEPART(dw,DATEADD(hh,- at SampleOffset+@TargetDeviceOffset,DateTime)) <> 7) ) AND -- Between @StartBusinessHours and @EndBusinessHours after adjusting for timezones (DATEPART(Hour,DATEADD(hh,- at SampleOffset+@TargetDeviceOffset,DateTime)) >= @StartBusinessHours AND (DATEPART(Hour,DATEADD(hh,- at SampleOffset+@TargetDeviceOffset,DateTime)) <= @EndBusinessHours)) ) ) , Percentile_IN as ( -- A CTE that builds on InterfaceTraffic_Detail_BusinessHours for calculating -- the chosen percentile value for each interfaceId SELECT t.InterfaceID, -- The smallest value in the chosen percentile -- http://www.dummies.com/education/math/statistics/how-to-calculate-percentiles-in-statistics/ Min(CASE WHEN seqnum >= @TargetPercentile * cnt THEN [In_Maxbps] END) AS percentile FROM ( SELECT t.*, ROW_NUMBER() OVER (PARTITION BY t.InterfaceID ORDER BY [In_Maxbps]) AS seqnum, COUNT(*) OVER (PARTITION BY t.InterfaceID) AS cnt FROM InterfaceTraffic_Detail_BusinessHours t ) t GROUP BY t.InterfaceID ) , Percentile_out as ( -- A CTE that builds on InterfaceTraffic_Detail_BusinessHours for calculating -- the chosen percentile value for each interfaceId SELECT o.InterfaceID, -- The smallest value in the chosen percentile -- http://www.dummies.com/education/math/statistics/how-to-calculate-percentiles-in-statistics/ Min(CASE WHEN seqnum >= @TargetPercentile * cnt THEN [out_Maxbps] END) AS percentile FROM ( SELECT o.*, ROW_NUMBER() OVER (PARTITION BY o.InterfaceID ORDER BY [Out_Maxbps]) AS seqnum, COUNT(*) OVER (PARTITION BY o.InterfaceID) AS cnt FROM InterfaceTraffic_Detail_BusinessHours o ) o GROUP BY o.InterfaceID ) ,Percentile_max as ( -- A CTE that builds on InterfaceTraffic_Detail_BusinessHours for calculating -- the chosen percentile value for each interfaceId SELECT m.InterfaceID, -- The smallest value in the chosen percentile -- http://www.dummies.com/education/math/statistics/how-to-calculate-percentiles-in-statistics/ Min(CASE WHEN seqnum >= @TargetPercentile * cnt THEN MaxBps END) AS percentile FROM ( SELECT m.*, ROW_NUMBER() OVER (PARTITION BY m.InterfaceID ORDER BY MaxBps) AS seqnum, COUNT(*) OVER (PARTITION BY m.InterfaceID) AS cnt FROM InterfaceTraffic_Detail_BusinessHours m ) m GROUP BY m.InterfaceID ) SELECT Nodes.NodeID ,Interfaces.InterfaceId ,Nodes.SysName ,Interfaces.Caption AS Interface_Caption ,InterfaceSpeed ,Percentile_in.percentile AS in_percentile ,Percentile_out.percentile AS out_percentile ,Percentile_max.percentile AS max_percentile , UTC_offset = @TargetDeviceOffset , SYSDATETIMEOFFSET () as Date FROM [swnpm].[dbo].[Nodes] INNER JOIN [swnpm].[dbo].[Interfaces] ON (Nodes.NodeID = Interfaces.NodeID ) INNER JOIN Percentile_in ON (Interfaces.InterfaceId = Percentile_in.InterfaceId) INNER JOIN Percentile_out ON (Interfaces.InterfaceId = Percentile_out.InterfaceId) INNER JOIN Percentile_max ON (Interfaces.InterfaceId = Percentile_max.InterfaceId) ORDER BY SysName, Interface_Caption From rod.beck at unitedcablecompany.com Thu Jun 1 20:04:42 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 1 Jun 2017 20:04:42 +0000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: , , Message-ID: And even in Kansas most fiber optic cables are probably next to roads, gas pipelines, and railways. Pretty easy to find. ________________________________ From: Sean Donelan Sent: Thursday, June 1, 2017 9:54:32 PM To: Rod Beck Cc: Eric Kuhnke; nanog at nanog.org list Subject: Re: Russian diplomats lingering near fiber optic cables On Thu, 1 Jun 2017, Rod Beck wrote: > As someone who has sold a lot of capacity on Hibernia Atlantic, I must > concur. There is a website showing where most of the Trans-Atlantic > cables land on the West Coast of Britain at towns like Bude in Wales. > Hiding is not an option. As far as I know, there are no cable landing stations in Kansas. Has US geography changed recently? From bhm at ufl.edu Thu Jun 1 20:18:16 2017 From: bhm at ufl.edu (Bruce H McIntosh) Date: Thu, 1 Jun 2017 16:18:16 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: <7793cc42-5c11-a68c-9703-d8dfa32e4e93@ufl.edu> On 2017-06-01 16:04, Rod Beck wrote: > And even in Kansas most fiber optic cables are probably next to roads, gas pipelines, and railways. Pretty easy to find. Yep, with those orange-and-white plastic pipe markers sticking up that say "CAUTION! Buried Fiber Optic Cable!" on 'em. -- ---------------------------------------------------------------------- Bruce H. McIntosh Senior Network Engineer University of Florida IT ICT Networking and Telecommunication Services bhm at ufl.edu 352-273-1066 From sean at donelan.com Thu Jun 1 20:57:54 2017 From: sean at donelan.com (Sean Donelan) Date: Thu, 1 Jun 2017 16:57:54 -0400 (EDT) Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: , , Message-ID: On Thu, 1 Jun 2017, Rod Beck wrote: > And even in Kansas most fiber optic cables are probably next to roads, gas > pipelines, and railways. Pretty easy to find. Unlike cable landing stations and satellite earth stations, which are documented in public FCC licenses, usually to 6 decimal points of longitude & latitude; and and included in navigation maps.... Finding the exact cable routes in the middle of the country requires on the ground surveying and locating cable markers. Piecemeal maps exist at the local level, and high-level maps are available from various providers. But as anyone familar with cable accidents or network planning knows, those marketing maps are aspirational. I had real estate people try to convince me that "fiber was available" at specific sites because there was a railroad across the road, and everyone "knew" that fiber was always next to railroads. Yes, its fairly simple to find a cable marker, if you put people (i.e. diplomats) on the ground in remote areas across the country. But, its odd to send diplomats to remote areas of the country, if you are not trying to survey geographic infrastructure in the middle of the country. From lists at mtin.net Thu Jun 1 23:21:08 2017 From: lists at mtin.net (Justin Wilson) Date: Thu, 1 Jun 2017 19:21:08 -0400 Subject: Leasing /22 blocks In-Reply-To: <003301d2dae2$ce9fd110$6bdf7330$@gvtc.com> References: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> <002c01d2dade$58a0e520$09e2af60$@gvtc.com> <003301d2dae2$ce9fd110$6bdf7330$@gvtc.com> Message-ID: We have done several transactions with ipv4auctions. You do ARIN pre-approval first and then you are golden. Did a purchase just yesterday for $3900 for a /24. Justin Justin Wilson j2sw at mtin.net skype:j2swmtin --- http://www.mtin.net xISP Solutions ? Consulting ? Data Centers ? Bandwidth http://www.midwest-ix.com Internet Exchange ? Peering ? Distributed Fabric > On Jun 1, 2017, at 10:24 AM, Aaron Gould wrote: > > Yeah, I was looking at ipv4auctions.com a while back and recall seeing $10/per ip? now it seems that $12.50/per ip is the lowest > > > > -Aaron > > > From mpalmer at hezmatt.org Fri Jun 2 01:07:10 2017 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 2 Jun 2017 11:07:10 +1000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: <20170602010710.GS28511@hezmatt.org> On Thu, Jun 01, 2017 at 12:20:54PM -0700, Eric Kuhnke wrote: > That said, a pretty quick way to get on some homeland security watch lists > would be to hang around a cable landing station beach location with a big > DSLR camera, and appear uninterested in the beach... I think regardless of what you appear to be interested in, hanging around a beach with a big DSLR is likely to get you on one list or another. - Matt From mpalmer at hezmatt.org Fri Jun 2 01:08:19 2017 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 2 Jun 2017 11:08:19 +1000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: <20170602010819.GT28511@hezmatt.org> On Thu, Jun 01, 2017 at 02:02:46PM -0400, Sean Donelan wrote: > There must be a perfectly logical explanation.... Yes, people in the > industry know where the choke points are. But the choke points aren't always > the most obvious places. Its kinda a weird for diplomats to show up there. Maybe they're not *actually* Russian diplomats, but instead undercover backhoes using Russian diplomatic credentials. - Matt From Brandon.Vincent at asu.edu Fri Jun 2 01:08:47 2017 From: Brandon.Vincent at asu.edu (Brandon Vincent) Date: Thu, 1 Jun 2017 18:08:47 -0700 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <20170602010710.GS28511@hezmatt.org> References: <20170602010710.GS28511@hezmatt.org> Message-ID: On Thu, Jun 1, 2017 at 6:07 PM, Matt Palmer wrote: > I think regardless of what you appear to be interested in, hanging around a > beach with a big DSLR is likely to get you on one list or another. "Excuse me, sir! Can you direct us to the naval base in Alameda? It's where they keep the nuclear wessels." From pbmarcos at inf.ufrgs.br Thu Jun 1 17:23:05 2017 From: pbmarcos at inf.ufrgs.br (Pedro de Botelho Marcos) Date: Thu, 1 Jun 2017 14:23:05 -0300 Subject: Survey on Internet agreement ecosystem Message-ID: Dear NANOG community, We are conducting a survey about Internet agreements, with a focus on dynamism, economics, and service level agreements aspects. Can you please help us by answering a set of objective questions reflecting your views (<10min)? Feel free to drop any comment on how to improve the survey in the future. Survey URL: http://bit.ly/2rfoQ3E Thank you very much, Cheers, -- Pedro de Botelho Marcos PhD Student Computer Networks Research Group Federal University of Rio Grande do Sul - UFRGS From s at xopher.net Thu Jun 1 21:43:07 2017 From: s at xopher.net (Scott Christopher) Date: Fri, 02 Jun 2017 00:43:07 +0300 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: <1496353387.1103281.995939536.7A01693E@webmail.messagingengine.com> Sean Donelan wrote: > But, its odd to send diplomats to remote areas of the country, if you are > not trying to survey geographic infrastructure in the middle of the > country. It's just "for show." If they really wanted to be invisible, they could do so without using diplomats - a group that is always assumed to be under location surveillance. -- Regards, S.C. From joe at nethead.com Fri Jun 2 02:15:12 2017 From: joe at nethead.com (Joe Hamelin) Date: Thu, 1 Jun 2017 19:15:12 -0700 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: <20170602010710.GS28511@hezmatt.org> Message-ID: The Seattle Russian Embassy is in the Westin Building just 4 floors above the fiber meet-me-room and five floors above the NRO tap room. They use to come ask us (an ISP) for IT help back in '96 when they would drag an icon too far off the screen in Windows 3.11. We were on the same floor. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 On Thu, Jun 1, 2017 at 6:08 PM, Brandon Vincent wrote: > On Thu, Jun 1, 2017 at 6:07 PM, Matt Palmer wrote: > > I think regardless of what you appear to be interested in, hanging > around a > > beach with a big DSLR is likely to get you on one list or another. > > "Excuse me, sir! Can you direct us to the naval base in Alameda? It's > where they keep the nuclear wessels." > From joe at nethead.com Fri Jun 2 02:17:37 2017 From: joe at nethead.com (Joe Hamelin) Date: Thu, 1 Jun 2017 19:17:37 -0700 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: Sean said: "Unlike cable landing stations and satellite earth stations, which are documented in public FCC licenses, usually to 6 decimal points of longitude & latitude; and and included in navigation maps...." Or you just follow the manhole covers that say Global Crossings. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 On Thu, Jun 1, 2017 at 1:57 PM, Sean Donelan wrote: > On Thu, 1 Jun 2017, Rod Beck wrote: > >> And even in Kansas most fiber optic cables are probably next to roads, gas >> pipelines, and railways. Pretty easy to find. >> > > Unlike cable landing stations and satellite earth stations, which are > documented in public FCC licenses, usually to 6 decimal points of longitude > & latitude; and and included in navigation maps.... > > Finding the exact cable routes in the middle of the country requires on > the ground surveying and locating cable markers. Piecemeal maps exist at > the local level, and high-level maps are available from various providers. > But as anyone familar with cable accidents or network planning knows, those > marketing maps are aspirational. I had real estate people try to convince > me that "fiber was available" at specific sites because there was a > railroad across the road, and everyone "knew" that fiber was always next to > railroads. > > Yes, its fairly simple to find a cable marker, if you put people (i.e. > diplomats) on the ground in remote areas across the country. > > But, its odd to send diplomats to remote areas of the country, if you are > not trying to survey geographic infrastructure in the middle of the country. > From ben at adversary.org Fri Jun 2 02:42:55 2017 From: ben at adversary.org (Ben McGinnes) Date: Fri, 2 Jun 2017 12:42:55 +1000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: <20170602010710.GS28511@hezmatt.org> Message-ID: <20170602024255.p73wmvsy5dshsjae@adversary.org> On Thu, Jun 01, 2017 at 07:15:12PM -0700, Joe Hamelin wrote: > > The Seattle Russian Embassy is in the Westin Building just 4 floors > above the fiber meet-me-room and five floors above the NRO tap room. > They use to come ask us (an ISP) for IT help back in '96 when they > would drag an icon too far off the screen in Windows 3.11. We were > on the same floor. So when Flynn & Friends in the Trump Transition Team were trying to establish that back channel link to Vladimir Putin they should've just wandered into the nearest colo facility ... okay, then. I guess they did it the other way because they wanted the trench coats. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From sean at donelan.com Fri Jun 2 03:35:26 2017 From: sean at donelan.com (Sean Donelan) Date: Thu, 1 Jun 2017 23:35:26 -0400 (EDT) Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <1496353387.1103281.995939536.7A01693E@webmail.messagingengine.com> References: <1496353387.1103281.995939536.7A01693E@webmail.messagingengine.com> Message-ID: On Fri, 2 Jun 2017, Scott Christopher wrote: >> But, its odd to send diplomats to remote areas of the country, if you are >> not trying to survey geographic infrastructure in the middle of the >> country. > > It's just "for show." > > If they really wanted to be invisible, they could do so without using > diplomats - a group that is always assumed to be under location > surveillance. Yep, which is why its odd. It would be much easier to hire one of the construction companies which lay fiber routes to prepare a nation-wide survey for them. Or hack their computer servers containing GIS maps. Maybe diplomats get bored, and like yanking the FBI's chain for sport. They have diplomatic immunity, so the risk is very low. I'll admit, I did visit the Geographic Center of the U.S. (lower 48-states) in Lebanon, Kansas. It was very nerdy, but something to check off the list. I only have 6 U.S. states left to visit for another item to check off the list. Maybe Russian diplomats have a bucket list too? From mis at seiden.com Fri Jun 2 04:24:41 2017 From: mis at seiden.com (mark seiden) Date: Fri, 2 Jun 2017 00:24:41 -0400 Subject: need to talk with a comcast noc engineer rather urgently Message-ID: at the internet archive we have a strange problem at the moment. a slightly upstream device looks like it's returning icmp administratively unreachable for our main load balancer's ip address (which serves archive.org). comcast has interpreted this to remove or (maybe blackhole) connections to archive.org somewhere pretty close to the edge. but it is routing and completing connections perfectly to other ip addresses on the same /24. no other providers than comcast are behaving similarly. can someone supply me with a contact phone number of someone at the real comcast NOC who can help talk us out of this? (obviously we want to fix the device and have opened a ticket with the upstream provider but in the meantime we're hoping to talk with a comcast noc engineer about other options for getting back on the air for comcast customers). thanks a lot. From morrowc.lists at gmail.com Fri Jun 2 04:46:48 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Jun 2017 00:46:48 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: <20170602010710.GS28511@hezmatt.org> Message-ID: On Thu, Jun 1, 2017 at 10:15 PM, Joe Hamelin wrote: > > the fiber meet-me-room and five floors above the NRO tap room. They use to > 'nro tap room' ... what's the expansion of NRO here? From main at kipsang.com Fri Jun 2 06:04:05 2017 From: main at kipsang.com (Michael Bullut) Date: Fri, 2 Jun 2017 09:04:05 +0300 Subject: Internet connectivity in Ghana In-Reply-To: References: Message-ID: I would definitely recommend *Internet Solutions Ghana. * ? On 31 May 2017 at 17:40, Rishi Singh wrote: > Has anyone dealt with getting internet connectivity in Ghana? I've been > doing a lot of research and saw some peering plans with Nigeria but nothing > solid there yet. Currently a financial client of mine is paying quite a bit > every quarter on satellite up link fees. > > Do any of the major carriers have any direct connectivity into Ghana? > > Thank you, > From denys at visp.net.lb Fri Jun 2 07:28:38 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 02 Jun 2017 10:28:38 +0300 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <20170602024255.p73wmvsy5dshsjae@adversary.org> References: <20170602010710.GS28511@hezmatt.org> <20170602024255.p73wmvsy5dshsjae@adversary.org> Message-ID: On 2017-06-02 05:42, Ben McGinnes wrote: > On Thu, Jun 01, 2017 at 07:15:12PM -0700, Joe Hamelin wrote: >> >> The Seattle Russian Embassy is in the Westin Building just 4 floors >> above the fiber meet-me-room and five floors above the NRO tap room. >> They use to come ask us (an ISP) for IT help back in '96 when they >> would drag an icon too far off the screen in Windows 3.11. We were >> on the same floor. > > So when Flynn & Friends in the Trump Transition Team were trying to > establish that back channel link to Vladimir Putin they should've just > wandered into the nearest colo facility ... okay, then. I guess they > did it the other way because they wanted the trench coats. > > > Regards, > Ben American diplomats are doing also all sort of nasty stuff in Russia(and not only), but that's a concern of the equivalent of FBI/NSA/etc, not operators public discussion places, unless it really affect operators anyhow. Just amazing, how NANOG slipped into pure politics. From jwbensley at gmail.com Fri Jun 2 08:50:10 2017 From: jwbensley at gmail.com (James Bensley) Date: Fri, 2 Jun 2017 09:50:10 +0100 Subject: RFC2544 Testing Equipment In-Reply-To: <829bff2b-8054-104a-5042-7deb9aac2568@talkunafraid.co.uk> References: <829bff2b-8054-104a-5042-7deb9aac2568@talkunafraid.co.uk> Message-ID: On 30 May 2017 at 16:41, James Harrison wrote: > On 30/05/17 16:22, Nick Olsen wrote: >> Looking to test up to 1Gb/s at various packet sizes, Measure Packet loss, >> Jitter..etc. Primarily Copper, But if it had some form of optical port, I >> wouldn't complain. Outputting a report that we can provide to the customer >> would be useful, But isn't mandatory. Doesn't need anything fancy, Like >> MPLS awareness, VLAN ID's..etc. ... > if > you have a VPLS setup then probably you'd go from a 1U box next to your > VPLS box through the VPLS pipe through to the endpoint. If you are using VPLS then you need to send 1Gbs of broadcast traffic and see how that cripples your network and send 1Gbps of BPDUs and ARP requests/responses etc. to see how that ruins everything, as your customer will loop it at some point. Also to check how your PEs work and if storm-control or similar is working. We had an issue with a VPLS instance where different model edge PEs had their core facing interfaces built in different ways; some had a physical interface configured facing the core, some a sub-interface, some an SVI/BVI/BDI etc, it turned out that device X won't tunnel PPP packets over VPLS/pseudowires when the core facing interface is an SVI, model Y will but not when using EVCs etc. People usually test TCP/UDP over IPv4 which doesn't tell you much about what your equipment/service can or can't do and how it will fail. Cheers, James. From ben at adversary.org Fri Jun 2 09:19:14 2017 From: ben at adversary.org (Ben McGinnes) Date: Fri, 2 Jun 2017 19:19:14 +1000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: <20170602010710.GS28511@hezmatt.org> <20170602024255.p73wmvsy5dshsjae@adversary.org> Message-ID: <20170602091914.n7h72yszlmzmj54c@adversary.org> On Fri, Jun 02, 2017 at 10:28:38AM +0300, Denys Fedoryshchenko wrote: > > American diplomats are doing also all sort of nasty stuff in > Russia(and not only), Yes they have and for a very long time. > but that's a concern of the equivalent of FBI/NSA/etc, not operators > public discussion places, unless it really affect operators anyhow. > Just amazing, how NANOG slipped into pure politics. The network(s) have been political for a very long time and will only become more so as time passes. Remember, the engineers wishing for the purity of technical discussion are usually the same ones crying that, "information wants to be free." Well, no matter. You want purely technical, okay, let's start with authorised mail hosts. You need to add 144.76.183.226/32 to the SPF record for visp.net.lb, which is currently triggering softfails everywhere. It might be wise to explicitly state whether or not it is just 144.76.183.226/32 in the SPF record for nuclearcat.com given the deny all instruction for that domain. Regards, Ben -- | GPG Made Easy (GPGME) Python 3 API Maintainer, GNU Privacy Guard | | GPG key: 0x321E4E2373590E5D http://www.adversary.org/ben-key.asc | | GPG key fpr: DB47 24E6 FA42 86C9 2B4E 55C4 321E 4E23 7359 0E5D | | https://www.gnupg.org/ https://securetheinternet.org/ | | ----------------------------------------------------------------- | -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From joe at nethead.com Fri Jun 2 04:49:33 2017 From: joe at nethead.com (Joe Hamelin) Date: Thu, 1 Jun 2017 21:49:33 -0700 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: <20170602010710.GS28511@hezmatt.org> Message-ID: Christopher asks: 'nro tap room' ... what's the expansion of NRO here? https://en.wikipedia.org/wiki/National_Reconnaissance_Office -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 From d3e3e3 at gmail.com Fri Jun 2 13:54:40 2017 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 2 Jun 2017 09:54:40 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: <20170602010710.GS28511@hezmatt.org> Message-ID: On Thu, Jun 1, 2017 at 10:15 PM, Joe Hamelin wrote: > > The Seattle Russian Embassy is in the Westin Building just 4 floors above > the fiber meet-me-room ... The only real Russian Embassy in the US is in Washington where their Ambassador is stationed, although arguably their UN Office in NYC has the status of am Embassy. Embassies have to do with international diplomacy. Their Seattle office is a consulate, which is what most people deal with for passports, visas, import/export permits, and similar personal/commercial stuff rather than diplomatic stuff. Commonly the Embassy of a country is also a consulate or, as it is sometimes described, has a consular affairs branch. See http://www.russianembassy.org/page/russian-consulates-in-the-u-s Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com > -- > Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 From ahebert at pubnix.net Fri Jun 2 14:14:12 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 2 Jun 2017 10:14:12 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: It will if the Ocean level change drastically. Which with this week news cycle... might not be that far fetched =D> ----- 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 06/01/17 15:54, Sean Donelan wrote: > On Thu, 1 Jun 2017, Rod Beck wrote: >> As someone who has sold a lot of capacity on Hibernia Atlantic, I >> must concur. There is a website showing where most of the >> Trans-Atlantic cables land on the West Coast of Britain at towns like >> Bude in Wales. Hiding is not an option. > > As far as I know, there are no cable landing stations in Kansas. > > Has US geography changed recently? > > > From denys at visp.net.lb Fri Jun 2 14:52:43 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 02 Jun 2017 17:52:43 +0300 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <20170602091914.n7h72yszlmzmj54c@adversary.org> References: <20170602010710.GS28511@hezmatt.org> <20170602024255.p73wmvsy5dshsjae@adversary.org> <20170602091914.n7h72yszlmzmj54c@adversary.org> Message-ID: <38c4e9c00a96d8094003e0c64e8f2900@visp.net.lb> On 2017-06-02 12:19, Ben McGinnes wrote: > On Fri, Jun 02, 2017 at 10:28:38AM +0300, Denys Fedoryshchenko wrote: >> >> American diplomats are doing also all sort of nasty stuff in >> Russia(and not only), > > Yes they have and for a very long time. > >> but that's a concern of the equivalent of FBI/NSA/etc, not operators >> public discussion places, unless it really affect operators anyhow. >> Just amazing, how NANOG slipped into pure politics. > > The network(s) have been political for a very long time and will only > become more so as time passes. Remember, the engineers wishing for > the purity of technical discussion are usually the same ones crying > that, "information wants to be free." https://www.nanog.org/list 6. Postings of political, philosophical, and legal nature are prohibited. It is quite clear. I do not deny networks sometimes are deeply affected by political factors, but current discussion is pure FUD, based on very questionable MSM source. IMHO any sane person wont like to receive this trash in his mailbox in list, that supposed to be politics-free, as there is enough of this garbage in internet. I do discuss such things too, when i have mood for that, but in designated places only. > > Well, no matter. You want purely technical, okay, let's start with > authorised mail hosts. > > You need to add 144.76.183.226/32 to the SPF record for visp.net.lb, > which is currently triggering softfails everywhere. It might be wise > to explicitly state whether or not it is just 144.76.183.226/32 in the > SPF record for nuclearcat.com given the deny all instruction for that > domain. Thanks for the hint, fixed, i use this domain only for old maillist subscriptions, so i missed that, after i migrated SMTP to my private server. From valdis.kletnieks at vt.edu Fri Jun 2 15:04:39 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 02 Jun 2017 11:04:39 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: <68977.1496415879@turing-police.cc.vt.edu> On Fri, 02 Jun 2017 10:14:12 -0400, Alain Hebert said: > It will if the Ocean level change drastically. Raising the question - how well protected against sea level rise *is* the average cable landing/termination station, given that most landing stations in particular are probably fairly near the beach and not very high above sea level? Are there any in particular that we need to worry if another Hurricane Sandy or local equivalent wanders by? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From rod.beck at unitedcablecompany.com Fri Jun 2 15:11:36 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 2 Jun 2017 15:11:36 +0000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <68977.1496415879@turing-police.cc.vt.edu> References: , <68977.1496415879@turing-police.cc.vt.edu> Message-ID: Landing stations can be 10 to 30 kilometers from the beach manhole. I don't think it is big concern. Hibernia Atlantic dublin landing station is a good example. ________________________________ From: NANOG on behalf of valdis.kletnieks at vt.edu Sent: Friday, June 2, 2017 5:04 PM To: ahebert at pubnix.net Cc: nanog at nanog.org Subject: Re: Russian diplomats lingering near fiber optic cables On Fri, 02 Jun 2017 10:14:12 -0400, Alain Hebert said: > It will if the Ocean level change drastically. Raising the question - how well protected against sea level rise *is* the average cable landing/termination station, given that most landing stations in particular are probably fairly near the beach and not very high above sea level? Are there any in particular that we need to worry if another Hurricane Sandy or local equivalent wanders by? From valdis.kletnieks at vt.edu Fri Jun 2 16:46:31 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 02 Jun 2017 12:46:31 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: , <68977.1496415879@turing-police.cc.vt.edu> Message-ID: <7782.1496421991@turing-police.cc.vt.edu> On Fri, 02 Jun 2017 15:11:36 -0000, Rod Beck said: > Landing stations can be 10 to 30 kilometers from the beach manhole. I don't > think it is big concern. Hibernia Atlantic dublin landing station is a good > example. So 100% of those beach manholes are watertight and safe from flooding, and don't contain any gear that will get upset if it does in fact end up with salt water in there? This listing for landing points in Japan seems to call out a hell of a lot of specific buildings that are nowhere near 10 to 30 km inland: https://www.google.com/maps/d/viewer?mid=1Siy5qBMoFyBUlSFNHdHDpGAkIR0 Singapore: Right on the water. http://www.streetdirectory.com/sg/singapore-cable-landing-station/1-changi-north-rise-498817/8118_79569.html Hong Kong: More of same (though with its hills, some of the 8 sites may actually be a bit above sea level even though they're 2 blocks from water) http://www.ofca.gov.hk/en/industry_focus/telecommunications/facility_based/infrastructures/submarine_cables/index.html Cryptome has a bunch of older images that tend to indicate that a lot of buildings right on the water in New Jersey and Long Island are involved: https://cryptome.org/eyeball/cable/cable-eyeball.htm And that's just in the first 3 pages returned by Google for "cable landing station map". The experience of the Manhattan phone system when the conduits and basements flooded during Sandy tends to indicate that we *are* in for similar surprises over the coming decades. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From morrowc.lists at gmail.com Fri Jun 2 17:20:57 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Jun 2017 13:20:57 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: <20170602010710.GS28511@hezmatt.org> Message-ID: On Fri, Jun 2, 2017 at 12:49 AM, Joe Hamelin wrote: > Christopher asks: 'nro tap room' ... what's the expansion of NRO here? > > https://en.wikipedia.org/wiki/National_Reconnaissance_Office > > I'm unsure why the NRO would have a room doing tap things in anyone's network. that is not their remit. Certianly we can FUD all day long about black helicopters, but in this case the NRO is a red herring. perhaps you meant NSA? and something akin to the ATT SF room-2 thing? -chris From morrowc.lists at gmail.com Fri Jun 2 17:23:26 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Jun 2017 13:23:26 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <7782.1496421991@turing-police.cc.vt.edu> References: <68977.1496415879@turing-police.cc.vt.edu> <7782.1496421991@turing-police.cc.vt.edu> Message-ID: On Fri, Jun 2, 2017 at 12:46 PM, wrote: > On Fri, 02 Jun 2017 15:11:36 -0000, Rod Beck said: > > > Landing stations can be 10 to 30 kilometers from the beach manhole. I > don't > > think it is big concern. Hibernia Atlantic dublin landing station is a > good > > example. > > So 100% of those beach manholes are watertight and safe from flooding, and > don't contain any gear that will get upset if it does in fact end up with > salt water in there? > > This listing for landing points in Japan seems to call out a hell of a lot > of > specific buildings that are nowhere near 10 to 30 km inland: > https://www.google.com/maps/d/viewer?mid=1Siy5qBMoFyBUlSFNHdHDpGAkIR0 > > Singapore: Right on the water. > http://www.streetdirectory.com/sg/singapore-cable- > landing-station/1-changi-north-rise-498817/8118_79569.html > > Hong Kong: More of same (though with its hills, some of the 8 sites may > actually be a bit above sea level even though they're 2 blocks from water) > http://www.ofca.gov.hk/en/industry_focus/telecommunications/facility_ > based/infrastructures/submarine_cables/index.html > > Cryptome has a bunch of older images that tend to indicate that a lot of > buildings right on the water in New Jersey and Long Island are involved: > https://cryptome.org/eyeball/cable/cable-eyeball.htm > > is this a case of 'wherer the cable gets dry' vs 'where the electronics doing cable things lives' ? aren't (normally) the dry equipment locations a bit inland and then have last-mile services from the consortium members headed inland to their respective network pops? > And that's just in the first 3 pages returned by Google for "cable landing > station > map". > > The experience of the Manhattan phone system when the conduits and > basements > flooded during Sandy tends to indicate that we *are* in for similar > surprises over the coming decades. > From ben at adversary.org Fri Jun 2 17:25:22 2017 From: ben at adversary.org (Ben McGinnes) Date: Sat, 3 Jun 2017 03:25:22 +1000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <38c4e9c00a96d8094003e0c64e8f2900@visp.net.lb> References: <20170602010710.GS28511@hezmatt.org> <20170602024255.p73wmvsy5dshsjae@adversary.org> <20170602091914.n7h72yszlmzmj54c@adversary.org> <38c4e9c00a96d8094003e0c64e8f2900@visp.net.lb> Message-ID: <20170602172522.mqev2yfykxhs75gx@adversary.org> On Fri, Jun 02, 2017 at 05:52:43PM +0300, Denys Fedoryshchenko wrote: > > https://www.nanog.org/list > 6. Postings of political, philosophical, and legal nature are prohibited. > It is quite clear. That's a fair point. The crypto dev world does have a tendency to veer into two of those three (political and legal) with a little more regularity, usually by necessity. So I do tend to weave in and out of those "off" topics without getting too hung up on the creeping FUD in some quarters. At times they'll even have practical requirements which need addressing; which is why somewhere in one of my GPGME branches there's a completed ITAR questionairre - definitely political, very legal and absolutely required in order to continue the technical work at all. I'd be surprised if there were not similar types of issues affecting some aspects of various networks. Most likely pertaining to international routes and even more likely subject to confidentiality agreements of various types (not just everyone's favourite bugbear of national security). > I do not deny networks sometimes are deeply affected by political > factors, but current discussion is pure FUD, based on very > questionable MSM source. IMHO any sane person wont like to receive > this trash in his mailbox in list, that supposed to be > politics-free, as there is enough of this garbage in internet. And it's the role of NANOG to make sure all that FUD gets where the conspiracists intended it to go. Isn't it great ... :) > Thanks for the hint, fixed, i use this domain only for old maillist > subscriptions, > so i missed that, after i migrated SMTP to my private server. I entirely understand, I've been tweaking mine a fair bit recently, weighing up the local Postfix instance vs. not having as great a control over the network as I'd like and ultimately deciding to run it all through the MX. I noticed it because I was double-checking return headers to be sure my own systems are doing, more or less, what they're supposed to. Especially since the current MX is set the way it is for technical, legal and political reasons (basically the mail server is in a jurisdiction with *far* greater privacy protections than my own country). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From cscora at apnic.net Fri Jun 2 18:02:45 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Jun 2017 04:02:45 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170602180245.EDF83C44B5@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 03 Jun, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 650075 Prefixes after maximum aggregation (per Origin AS): 253371 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 313766 Total ASes present in the Internet Routing Table: 57397 Prefixes per ASN: 11.33 Origin-only ASes present in the Internet Routing Table: 49676 Origin ASes announcing only one prefix: 21966 Transit ASes present in the Internet Routing Table: 7721 Transit-only ASes present in the Internet Routing Table: 223 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 45 Max AS path prepend of ASN ( 55644) 41 Prefixes from unregistered ASNs in the Routing Table: 75 Numnber of instances of unregistered ASNs: 79 Number of 32-bit ASNs allocated by the RIRs: 18845 Number of 32-bit ASNs visible in the Routing Table: 14651 Prefixes from 32-bit ASNs in the Routing Table: 59470 Number of bogon 32-bit ASNs visible in the Routing Table: 62 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 371 Number of addresses announced to Internet: 2848498020 Equivalent to 169 /8s, 200 /16s and 161 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.6 Total number of prefixes smaller than registry allocations: 216741 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 178319 Total APNIC prefixes after maximum aggregation: 51254 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 177534 Unique aggregates announced from the APNIC address blocks: 73377 APNIC Region origin ASes present in the Internet Routing Table: 8157 APNIC Prefixes per ASN: 21.76 APNIC Region origin ASes announcing only one prefix: 2280 APNIC Region transit ASes present in the Internet Routing Table: 1158 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 45 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2982 Number of APNIC addresses announced to Internet: 763338596 Equivalent to 45 /8s, 127 /16s and 159 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 197726 Total ARIN prefixes after maximum aggregation: 94486 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 199729 Unique aggregates announced from the ARIN address blocks: 91822 ARIN Region origin ASes present in the Internet Routing Table: 17896 ARIN Prefixes per ASN: 11.16 ARIN Region origin ASes announcing only one prefix: 6624 ARIN Region transit ASes present in the Internet Routing Table: 1776 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1998 Number of ARIN addresses announced to Internet: 1110645408 Equivalent to 66 /8s, 51 /16s and 26 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 175068 Total RIPE prefixes after maximum aggregation: 85454 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 170673 Unique aggregates announced from the RIPE address blocks: 102684 RIPE Region origin ASes present in the Internet Routing Table: 24083 RIPE Prefixes per ASN: 7.09 RIPE Region origin ASes announcing only one prefix: 11105 RIPE Region transit ASes present in the Internet Routing Table: 3395 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5875 Number of RIPE addresses announced to Internet: 711601280 Equivalent to 42 /8s, 106 /16s and 44 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 81723 Total LACNIC prefixes after maximum aggregation: 18302 LACNIC Deaggregation factor: 4.47 Prefixes being announced from the LACNIC address blocks: 82998 Unique aggregates announced from the LACNIC address blocks: 38686 LACNIC Region origin ASes present in the Internet Routing Table: 5963 LACNIC Prefixes per ASN: 13.92 LACNIC Region origin ASes announcing only one prefix: 1636 LACNIC Region transit ASes present in the Internet Routing Table: 1096 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3481 Number of LACNIC addresses announced to Internet: 170738656 Equivalent to 10 /8s, 45 /16s and 67 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 17121 Total AfriNIC prefixes after maximum aggregation: 3825 AfriNIC Deaggregation factor: 4.48 Prefixes being announced from the AfriNIC address blocks: 18770 Unique aggregates announced from the AfriNIC address blocks: 6865 AfriNIC Region origin ASes present in the Internet Routing Table: 1047 AfriNIC Prefixes per ASN: 17.93 AfriNIC Region origin ASes announcing only one prefix: 320 AfriNIC Region transit ASes present in the Internet Routing Table: 205 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 315 Number of AfriNIC addresses announced to Internet: 91747328 Equivalent to 5 /8s, 119 /16s and 244 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5566 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3935 402 370 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2999 903 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2781 11137 759 KIXS-AS-KR Korea Telecom, KR 9829 2733 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2215 8699 34 CMNET-GD Guangdong Mobile Communication 4755 2089 422 222 TATACOMM-AS TATA Communications formerl 45899 1987 1392 108 VNPT-AS-VN VNPT Corp, VN 7552 1616 1100 66 VIETEL-AS-AP Viettel Corporation, VN 9498 1579 361 138 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3726 2968 153 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3410 1333 80 SHAW - Shaw Communications Inc., CA 18566 2181 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2066 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2006 2166 417 CHARTER-NET-HKY-NC - Charter Communicat 209 1815 5069 638 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1805 3440 585 AMAZON-02 - Amazon.com, Inc., US 30036 1778 324 316 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1696 854 232 ITCDELTA - Earthlink, Inc., US 701 1559 10578 636 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3187 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2866 985 2058 AKAMAI-ASN1, US 34984 2014 328 387 TELLCOM-AS, TR 9121 1981 1691 17 TTNET, TR 12479 1612 1044 52 UNI2-AS, ES 13188 1595 99 62 TRIOLAN, UA 12389 1507 1398 620 ROSTELECOM-AS, RU 9198 1324 352 25 KAZTELECOM-AS, KZ 6849 1225 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3538 544 173 Telmex Colombia S.A., CO 8151 2516 3400 573 Uninet S.A. de C.V., MX 11830 2084 369 57 Instituto Costarricense de Electricidad 7303 1566 1009 249 Telecom Argentina S.A., AR 6503 1540 437 53 Axtel, S.A.B. de C.V., MX 6147 1293 377 27 Telefonica del Peru S.A.A., PE 3816 1012 494 186 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1010 2300 176 CLARO S.A., BR 11172 906 126 81 Alestra, S. de R.L. de C.V., MX 18881 895 1052 23 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1260 398 48 LINKdotNET-AS, EG 36903 713 358 123 MT-MPLS, MA 37611 713 67 7 Afrihost, ZA 36992 627 1375 26 ETISALAT-MISR, EG 24835 495 850 15 RAYA-AS, EG 29571 419 36 10 CITelecom-AS, CI 37492 407 320 75 ORANGE-, TN 8452 402 1730 17 TE-AS TE-AS, EG 15399 353 35 7 WANANCHI-, KE 2018 297 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5566 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3935 402 370 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3726 2968 153 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3538 544 173 Telmex Colombia S.A., CO 6327 3410 1333 80 SHAW - Shaw Communications Inc., CA 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3187 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 17974 2999 903 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2866 985 2058 AKAMAI-ASN1, US 4766 2781 11137 759 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3726 3573 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3935 3565 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3538 3365 Telmex Colombia S.A., CO 6327 3410 3330 SHAW - Shaw Communications Inc., CA 39891 3338 3316 ALJAWWALSTC-AS, SA 8551 3187 3147 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2999 2927 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9829 2733 2193 BSNL-NIB National Internet Backbone, IN 9808 2215 2181 CMNET-GD Guangdong Mobile Communication Co.Ltd. 18566 2181 2072 MEGAPATH5-US - MegaPath Corporation, 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 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 66255 UNALLOCATED 45.6.244.0/22 16735 ALGAR TELECOM S/A, BR Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.15.0/24 55427 BROADLINK-AS-AP Broadlink Nepal, NP 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 36.255.248.0/24 64091 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:280 /13:546 /14:1047 /15:1849 /16:13483 /17:7616 /18:13409 /19:24727 /20:38578 /21:41118 /22:76987 /23:63986 /24:364065 /25:832 /26:613 /27:639 /28:43 /29:32 /30:26 /31:3 /32:28 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3204 3410 SHAW - Shaw Communications Inc., CA 39891 2898 3338 ALJAWWALSTC-AS, SA 22773 2878 3726 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2652 3187 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2074 2181 MEGAPATH5-US - MegaPath Corporation, US 30036 1574 1778 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1474 2084 Instituto Costarricense de Electricidad y Telec 10620 1468 3538 Telmex Colombia S.A., CO 6389 1373 2066 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 9121 1373 1981 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1603 2:842 4:27 5:2426 6:34 8:1095 12:1826 13:122 14:1772 15:27 16:2 17:123 18:121 20:57 23:2295 24:1823 25:2 27:2445 31:1903 32:83 33:9 35:20 36:407 37:2594 38:1331 39:43 40:97 41:3007 42:468 43:1923 44:72 45:2696 46:2769 47:121 49:1207 50:985 51:19 52:819 54:361 55:3 56:4 57:42 58:1599 59:1043 60:390 61:1944 62:1552 63:1908 64:4578 65:2208 66:4529 67:2252 68:1217 69:3368 70:1147 71:582 72:2167 74:2683 75:387 76:430 77:1472 78:1441 79:2441 80:1390 81:1386 82:976 83:723 84:871 85:1754 86:481 87:1155 88:766 89:2063 90:176 91:6198 92:1022 93:2391 94:2371 95:2756 96:622 97:352 98:1031 99:90 100:155 101:1307 103:14912 104:2907 105:188 106:486 107:1646 108:816 109:3003 110:1411 111:1744 112:1185 113:1232 114:1036 115:1730 116:1787 117:1715 118:2156 119:1574 120:1029 121:1110 122:2278 123:1811 124:1523 125:1891 128:746 129:645 130:440 131:1386 132:518 133:191 134:643 135:226 136:455 137:439 138:1968 139:483 140:377 141:571 142:748 143:927 144:787 145:182 146:1031 147:676 148:1430 149:579 150:710 151:971 152:797 153:288 154:832 155:743 156:592 157:640 158:449 159:1460 160:663 161:746 162:2515 163:530 164:794 165:1211 166:385 167:1245 168:2653 169:779 170:3322 171:318 172:1018 173:1915 174:804 175:749 176:1845 177:4088 178:2498 179:1151 180:2204 181:1895 182:2362 183:996 184:860 185:9786 186:3117 187:2184 188:2705 189:1807 190:8202 191:1333 192:9422 193:5788 194:4655 195:3880 196:2125 197:1222 198:5510 199:5897 200:7458 201:4325 202:10406 203:9979 204:4481 205:2813 206:3016 207:3166 208:3977 209:4022 210:3963 211:2147 212:2842 213:2481 214:881 215:67 216:5736 217:2077 218:848 219:600 220:1653 221:912 222:757 223:1180 End of report From eric.kuhnke at gmail.com Fri Jun 2 18:22:51 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 2 Jun 2017 11:22:51 -0700 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: <20170602010710.GS28511@hezmatt.org> Message-ID: It is no longer in the Westin, or if they've kept an office space it is not the public facing consulate. The security desk at the lobby frequently has to deal with confused Russian consular-service seeking people who don't want to take "no" for an answer when they're told that the consulate has moved. new address: 600 University St #2510, Seattle, WA 98101 On Thu, Jun 1, 2017 at 7:15 PM, Joe Hamelin wrote: > The Seattle Russian Embassy is in the Westin Building just 4 floors above > the fiber meet-me-room and five floors above the NRO tap room. They use to > come ask us (an ISP) for IT help back in '96 when they would drag an icon > too far off the screen in Windows 3.11. We were on the same floor. > > -- > Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 > > On Thu, Jun 1, 2017 at 6:08 PM, Brandon Vincent > wrote: > > > On Thu, Jun 1, 2017 at 6:07 PM, Matt Palmer wrote: > > > I think regardless of what you appear to be interested in, hanging > > around a > > > beach with a big DSLR is likely to get you on one list or another. > > > > "Excuse me, sir! Can you direct us to the naval base in Alameda? It's > > where they keep the nuclear wessels." > > > From valdis.kletnieks at vt.edu Fri Jun 2 18:40:35 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 02 Jun 2017 14:40:35 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: <68977.1496415879@turing-police.cc.vt.edu> <7782.1496421991@turing-police.cc.vt.edu> Message-ID: <16678.1496428835@turing-police.cc.vt.edu> On Fri, 02 Jun 2017 13:23:26 -0400, Christopher Morrow said: > is this a case of 'wherer the cable gets dry' vs 'where the electronics > doing cable things lives' ? > aren't (normally) the dry equipment locations a bit inland and then have > last-mile services from the consortium members headed inland to their > respective network pops? Well, I'd be willing to buy that logic, except the specific buildings called out look pretty damned big for just drying off a cable. For example, this is claimed to be the US landing point for TAT-14 - looks around 4K square feet? http://virtualglobetrotting.com/map/tuckerton-cable-landing-station/view/google/ Though I admit I'm foggy on how much gear is needed to stuff however many amps at 4,000 volts down the cable core to power the repeaters. But again - if there's gear stuffing that many amps at that many volts down a cable, salt water could be the start of a bad day... (And note - I'm not saying that *everybody* who built a cable landing station managed to get it wrong. I'm saying that with the number of landing stations in existence, the chance that *somebody* got it wrong is probably scarily high. Telco and internet experiences in New Orleans during Katrina and NYC during Sandy suggest there's a lot of infrastructure built with "we never had storm surge in this building before so it can't happen" planning....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From eric.kuhnke at gmail.com Fri Jun 2 18:43:05 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 2 Jun 2017 11:43:05 -0700 Subject: NANOG 70 network diagram and upstream Message-ID: Just a small thing, but as one of the folks who used to work on the core network gear of AS11404, the network diagram has something in it that might confuse attendees as to who is really sponsoring the upstream: https://www.nanog.org/meetings/nanog70/diagram AS11404 was formerly known as Spectrum Networks, acquired in 2013 by Wavedivision Holdings LLC (Wave Broadband) and became the backbone of the Wave network. It's a totally different thing than the Charter service which is trademarked as as Spectrum. https://www.peeringdb.com/asn/11404 The logo in the right side bubble there shouldn't be the Charter/Spectrum trademarked font, but rather should be Wave, who built the dark fiber into the hotel and are providing the upstream. The last mile fiber into the hotel is Wave. -Eric From rod.beck at unitedcablecompany.com Fri Jun 2 18:55:55 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 2 Jun 2017 18:55:55 +0000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <16678.1496428835@turing-police.cc.vt.edu> References: <68977.1496415879@turing-police.cc.vt.edu> <7782.1496421991@turing-police.cc.vt.edu> , <16678.1496428835@turing-police.cc.vt.edu> Message-ID: The plan is to decommission TAT-14 in 2024. That is long before the next Biblical Flood due the ice caps melting. The Trans-Atlantic systems have a life span at best of 30 years. When the next set of systems is built rising waters will be taken into account. ________________________________ From: Valdis Kletnieks on behalf of valdis.kletnieks at vt.edu Sent: Friday, June 2, 2017 8:40 PM To: Christopher Morrow Cc: Rod Beck; nanog at nanog.org Subject: Re: Russian diplomats lingering near fiber optic cables On Fri, 02 Jun 2017 13:23:26 -0400, Christopher Morrow said: > is this a case of 'wherer the cable gets dry' vs 'where the electronics > doing cable things lives' ? > aren't (normally) the dry equipment locations a bit inland and then have > last-mile services from the consortium members headed inland to their > respective network pops? Well, I'd be willing to buy that logic, except the specific buildings called out look pretty damned big for just drying off a cable. For example, this is claimed to be the US landing point for TAT-14 - looks around 4K square feet? http://virtualglobetrotting.com/map/tuckerton-cable-landing-station/view/google/ [http://khm0.googleapis.com/kh?v=726&hl=en-US&x=307790&y=398428&z=20] Tuckerton Cable Landing Station in Tuckerton, NJ (Google ... virtualglobetrotting.com Tuckerton Cable Landing Station (Google Maps). Tuckerton Cable Landing Station hosts the TAT-14 fibre cable which runs 15,000km to... Though I admit I'm foggy on how much gear is needed to stuff however many amps at 4,000 volts down the cable core to power the repeaters. But again - if there's gear stuffing that many amps at that many volts down a cable, salt water could be the start of a bad day... (And note - I'm not saying that *everybody* who built a cable landing station managed to get it wrong. I'm saying that with the number of landing stations in existence, the chance that *somebody* got it wrong is probably scarily high. Telco and internet experiences in New Orleans during Katrina and NYC during Sandy suggest there's a lot of infrastructure built with "we never had storm surge in this building before so it can't happen" planning....) From aaron1 at gvtc.com Fri Jun 2 20:54:38 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 2 Jun 2017 15:54:38 -0500 Subject: NANOG 70 network diagram and upstream In-Reply-To: References: Message-ID: <001401d2dbe2$73248230$596d8690$@gvtc.com> Btw.... Wow, a ~2 million dollar boundary (dual PTX1000's) for the NANOG 70 conference.... geez -aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke Sent: Friday, June 2, 2017 1:43 PM To: nanog at nanog.org list Subject: NANOG 70 network diagram and upstream Just a small thing, but as one of the folks who used to work on the core network gear of AS11404, the network diagram has something in it that might confuse attendees as to who is really sponsoring the upstream: https://www.nanog.org/meetings/nanog70/diagram AS11404 was formerly known as Spectrum Networks, acquired in 2013 by Wavedivision Holdings LLC (Wave Broadband) and became the backbone of the Wave network. It's a totally different thing than the Charter service which is trademarked as as Spectrum. https://www.peeringdb.com/asn/11404 The logo in the right side bubble there shouldn't be the Charter/Spectrum trademarked font, but rather should be Wave, who built the dark fiber into the hotel and are providing the upstream. The last mile fiber into the hotel is Wave. -Eric From edugas at unknowndevice.ca Fri Jun 2 21:34:44 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Fri, 2 Jun 2017 17:34:44 -0400 Subject: NANOG 70 network diagram and upstream In-Reply-To: <001401d2dbe2$73248230$596d8690$@gvtc.com> References: <001401d2dbe2$73248230$596d8690$@gvtc.com> Message-ID: And the 4x100G. That's four times the capacity of the network I work for. ~100k subs. On Jun 2, 2017 16:54, "Aaron Gould" wrote: > Btw.... > > Wow, a ~2 million dollar boundary (dual PTX1000's) for the NANOG 70 > conference.... geez > > -aaron > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke > Sent: Friday, June 2, 2017 1:43 PM > To: nanog at nanog.org list > Subject: NANOG 70 network diagram and upstream > > Just a small thing, but as one of the folks who used to work on the core > network gear of AS11404, the network diagram has something in it that might > confuse attendees as to who is really sponsoring the upstream: > > https://www.nanog.org/meetings/nanog70/diagram > > AS11404 was formerly known as Spectrum Networks, acquired in 2013 by > Wavedivision Holdings LLC (Wave Broadband) and became the backbone of the > Wave network. It's a totally different thing than the Charter service which > is trademarked as as Spectrum. > > https://www.peeringdb.com/asn/11404 > > The logo in the right side bubble there shouldn't be the Charter/Spectrum > trademarked font, but rather should be Wave, who built the dark fiber into > the hotel and are providing the upstream. The last mile fiber into the > hotel is Wave. > > > -Eric > > From jared at puck.nether.net Sat Jun 3 01:08:51 2017 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 2 Jun 2017 21:08:51 -0400 Subject: NANOG 70 network diagram and upstream In-Reply-To: References: <001401d2dbe2$73248230$596d8690$@gvtc.com> Message-ID: > On Jun 2, 2017, at 5:34 PM, Eric Dugas wrote: > > And the 4x100G. That's four times the capacity of the network I work for. > ~100k subs. Disclaimer: Not an employee of NTT, but I was last Bellevue NANOG. Last time in Bellevue with the Comcast (dark) and Wave (dim) fiber we had 220G with diverse building entrances. Many people made fun of me for the overkill. It peaked at 1.1Gb/s as WWDC was at the same time and at least one person plugged in to the wired station to download the latest developer tools. WWDC overlaps this time as well, and I believe there will be some additional wired ports available, so bring your thunderbolt and USB to Ethernet adapters. :-) - Jared From hank at efes.iucc.ac.il Sat Jun 3 18:13:35 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 3 Jun 2017 21:13:35 +0300 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <7782.1496421991@turing-police.cc.vt.edu> References: <68977.1496415879@turing-police.cc.vt.edu> <7782.1496421991@turing-police.cc.vt.edu> Message-ID: <92c5f7bc-1b60-7533-1a3c-a856f712f380@efes.iucc.ac.il> On 02/06/2017 19:46, valdis.kletnieks at vt.edu wrote: > On Fri, 02 Jun 2017 15:11:36 -0000, Rod Beck said: > >> Landing stations can be 10 to 30 kilometers from the beach manhole. I don't >> think it is big concern. Hibernia Atlantic dublin landing station is a good >> example. > So 100% of those beach manholes are watertight and safe from flooding, and > don't contain any gear that will get upset if it does in fact end up with > salt water in there? > > This listing for landing points in Japan seems to call out a hell of a lot of > specific buildings that are nowhere near 10 to 30 km inland: > https://www.google.com/maps/d/viewer?mid=1Siy5qBMoFyBUlSFNHdHDpGAkIR0 > > Singapore: Right on the water. > http://www.streetdirectory.com/sg/singapore-cable-landing-station/1-changi-north-rise-498817/8118_79569.html > > Hong Kong: More of same (though with its hills, some of the 8 sites may > actually be a bit above sea level even though they're 2 blocks from water) > http://www.ofca.gov.hk/en/industry_focus/telecommunications/facility_based/infrastructures/submarine_cables/index.html > > Cryptome has a bunch of older images that tend to indicate that a lot of > buildings right on the water in New Jersey and Long Island are involved: > https://cryptome.org/eyeball/cable/cable-eyeball.htm > > And that's just in the first 3 pages returned by Google for "cable landing station > map". > > The experience of the Manhattan phone system when the conduits and basements > flooded during Sandy tends to indicate that we *are* in for similar > surprises over the coming decades. I think you are missing the point. The issue is not the actual landing station but the actual *exact *path the cable takes from 100meter out at sea to the landing station. For that you need GPS coordinates down to a 3' level as the fiber snakes its way from shore into the city. I do not believe that is available on the Internet and is only available to the actual company that laid the cable. One can try to deduce the path by looking for manhole covers but that would require opening and physically inspecting. -Hank From rod.beck at unitedcablecompany.com Sat Jun 3 18:54:18 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Sat, 3 Jun 2017 18:54:18 +0000 Subject: SEA-ME-WE5 Cable Message-ID: Anyone who is familiar with network performance on this system such as shunt faults. Please contact me. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Kir?ly utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From mpetach at netflight.com Sat Jun 3 19:13:14 2017 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 3 Jun 2017 12:13:14 -0700 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <16678.1496428835@turing-police.cc.vt.edu> References: <68977.1496415879@turing-police.cc.vt.edu> <7782.1496421991@turing-police.cc.vt.edu> <16678.1496428835@turing-police.cc.vt.edu> Message-ID: On Fri, Jun 2, 2017 at 11:40 AM, wrote: [...] > > Well, I'd be willing to buy that logic, except the specific buildings called > out look pretty damned big for just drying off a cable. For example, this > is claimed to be the US landing point for TAT-14 - looks around 4K square feet? I think you might be off by an order of magnitude or two on that. 4,000 sq ft is about the size of the guest bathroom in Snowhorn's new house, isn't it? (well, OK, maybe a slight exaggeration... ;) Matt From martijnschmidt at i3d.net Sun Jun 4 13:03:51 2017 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Sun, 4 Jun 2017 15:03:51 +0200 Subject: Internet connectivity in Ghana In-Reply-To: References: Message-ID: <78376e93-d734-d661-5016-ecbc998f1167@i3d.net> TISparkle/Seabone also has an IP transit PoP in Accra, plus they have a partnership with Dolphin Telecom. On 06/01/2017 05:30 PM, Eric Kuhnke wrote: > All of the licensed mobile phone network operators in Ghana are also ISPs > and can reach enterprise customers. Within Accra or a few other major > coastal cities, either by microwave rooftop/tower based links or their > terrestrial fiber. Should definitely be much faster and more economical > than satellite. > > Interestingly if you look at BGP tables and AS-adjacencies for the major > Ghanian ISPs and telecoms, it is logically a suburb of London, which is > where most of the traffic in the recently built West African submarine > cables goes. > > > On Wed, May 31, 2017 at 7:40 AM, Rishi Singh wrote: > >> Has anyone dealt with getting internet connectivity in Ghana? I've been >> doing a lot of research and saw some peering plans with Nigeria but nothing >> solid there yet. Currently a financial client of mine is paying quite a bit >> every quarter on satellite up link fees. >> >> Do any of the major carriers have any direct connectivity into Ghana? >> >> Thank you, >> From tom at ninjabadger.net Sun Jun 4 22:22:54 2017 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 4 Jun 2017 23:22:54 +0100 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: On 01/06/17 20:44, Rod Beck wrote: > There is a website showing where most of the Trans-Atlantic cables land on the West Coast of Britain at towns like Bude in Wales. Hiding is not an option. Bude is in Cornwall, a county of England. It's not in Wales. -- Tom From rod.beck at unitedcablecompany.com Sun Jun 4 22:26:56 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Sun, 4 Jun 2017 22:26:56 +0000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: , Message-ID: Perfectly irrelevant, Tom. ? ________________________________ From: NANOG on behalf of Tom Hill Sent: Monday, June 5, 2017 12:22:54 AM To: nanog at nanog.org Subject: Re: Russian diplomats lingering near fiber optic cables On 01/06/17 20:44, Rod Beck wrote: > There is a website showing where most of the Trans-Atlantic cables land on the West Coast of Britain at towns like Bude in Wales. Hiding is not an option. Bude is in Cornwall, a county of England. It's not in Wales. -- Tom From rod.beck at unitedcablecompany.com Sun Jun 4 22:32:40 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Sun, 4 Jun 2017 22:32:40 +0000 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: , Message-ID: And when you get over trying to score cheap points, you can view the map: http://www.kis-orca.eu/map#.WTSKGG4lHIU. ________________________________ From: NANOG on behalf of Tom Hill Sent: Monday, June 5, 2017 12:22:54 AM To: nanog at nanog.org Subject: Re: Russian diplomats lingering near fiber optic cables On 01/06/17 20:44, Rod Beck wrote: > There is a website showing where most of the Trans-Atlantic cables land on the West Coast of Britain at towns like Bude in Wales. Hiding is not an option. Bude is in Cornwall, a county of England. It's not in Wales. -- Tom From tom at ninjabadger.net Sun Jun 4 22:49:47 2017 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 4 Jun 2017 23:49:47 +0100 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: On 04/06/17 23:32, Rod Beck wrote: > And when you get over trying to score cheap points, you can view the map I'm not the one that needs to look at a map ;) -- Tom From James at arenalgroup.co Sun Jun 4 23:02:27 2017 From: James at arenalgroup.co (James Breeden) Date: Sun, 4 Jun 2017 23:02:27 +0000 Subject: NANOG 70 network diagram and upstream In-Reply-To: References: <001401d2dbe2$73248230$596d8690$@gvtc.com> Message-ID: Yeah, I was wondering about that 4x100G. is that a necessity or a "because we can" move? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas Sent: Friday, June 2, 2017 4:35 PM To: Aaron Gould Cc: NANOG Subject: RE: NANOG 70 network diagram and upstream And the 4x100G. That's four times the capacity of the network I work for. ~100k subs. On Jun 2, 2017 16:54, "Aaron Gould" wrote: > Btw.... > > Wow, a ~2 million dollar boundary (dual PTX1000's) for the NANOG 70 > conference.... geez > > -aaron > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke > Sent: Friday, June 2, 2017 1:43 PM > To: nanog at nanog.org list > Subject: NANOG 70 network diagram and upstream > > Just a small thing, but as one of the folks who used to work on the > core network gear of AS11404, the network diagram has something in it > that might confuse attendees as to who is really sponsoring the upstream: > > https://www.nanog.org/meetings/nanog70/diagram > > AS11404 was formerly known as Spectrum Networks, acquired in 2013 by > Wavedivision Holdings LLC (Wave Broadband) and became the backbone of > the Wave network. It's a totally different thing than the Charter > service which is trademarked as as Spectrum. > > https://www.peeringdb.com/asn/11404 > > The logo in the right side bubble there shouldn't be the > Charter/Spectrum trademarked font, but rather should be Wave, who > built the dark fiber into the hotel and are providing the upstream. > The last mile fiber into the hotel is Wave. > > > -Eric > > From mpetach at netflight.com Sun Jun 4 23:55:20 2017 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 4 Jun 2017 16:55:20 -0700 Subject: NANOG70 tee shirt mystery Message-ID: So, I've been staring at the NANOG70 tee shirt for a bit now: https://flic.kr/p/VejX5y and I have to admit, I'm a bit stymied. Usually, the tee-shirts are somewhat referential to the location or to a particular event; but this one is leaving me scratching my head. Is it perhaps a shot of the network engineering "Ooops (I broke the network again)" concert tour? Or is there some other cultural reference at play that I'm not aware of? Enquiring minds want to know!(tm). :) Matt From tom at ninjabadger.net Mon Jun 5 00:06:02 2017 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 5 Jun 2017 01:06:02 +0100 Subject: NANOG70 tee shirt mystery In-Reply-To: References: Message-ID: <406364f7-007a-64b2-89e2-89182f9fb817@ninjabadger.net> On 05/06/17 00:55, Matthew Petach wrote: > Or is there some other cultural reference at > play that I'm not aware of? It could be this: https://en.wikipedia.org/wiki/Music_of_Washington_(state)#Grunge Nirvana & Pearl Jam (amongst others) came out of Seattle, it seems. TIL! -- Tom From thegameiam at yahoo.com Mon Jun 5 00:06:51 2017 From: thegameiam at yahoo.com (David Barak) Date: Sun, 4 Jun 2017 17:06:51 -0700 Subject: NANOG70 tee shirt mystery In-Reply-To: References: Message-ID: <7F2D923B-A55D-4D22-AECB-FEDFBF925DC7@yahoo.com> https://en.m.wikipedia.org/wiki/Ten_(Pearl_Jam_album) Pearl Jam are from Seattle... David Barak Sent from mobile device, please excuse autocorrection artifacts > On Jun 4, 2017, at 4:55 PM, Matthew Petach wrote: > > So, I've been staring at the NANOG70 tee shirt for > a bit now: > > https://flic.kr/p/VejX5y > > and I have to admit, I'm a bit stymied. > > Usually, the tee-shirts are somewhat referential > to the location or to a particular event; but this > one is leaving me scratching my head. > > Is it perhaps a shot of the network engineering > "Ooops (I broke the network again)" concert > tour? > > Or is there some other cultural reference at > play that I'm not aware of? > > Enquiring minds want to know!(tm). :) > > Matt From eric.kuhnke at gmail.com Mon Jun 5 00:28:26 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Sun, 4 Jun 2017 17:28:26 -0700 Subject: NANOG70 tee shirt mystery In-Reply-To: <7F2D923B-A55D-4D22-AECB-FEDFBF925DC7@yahoo.com> References: <7F2D923B-A55D-4D22-AECB-FEDFBF925DC7@yahoo.com> Message-ID: However, a Hyatt Regency hotel in Bellevue is about as far from grunge as one can get. For those not familiar with Bellevue it is roughly similar to Crystal City in Arlington, VA. On Jun 4, 2017 5:10 PM, "David Barak via NANOG" wrote: > https://en.m.wikipedia.org/wiki/Ten_(Pearl_Jam_album) > > Pearl Jam are from Seattle... > > David Barak > Sent from mobile device, please excuse autocorrection artifacts > > > On Jun 4, 2017, at 4:55 PM, Matthew Petach > wrote: > > > > So, I've been staring at the NANOG70 tee shirt for > > a bit now: > > > > https://flic.kr/p/VejX5y > > > > and I have to admit, I'm a bit stymied. > > > > Usually, the tee-shirts are somewhat referential > > to the location or to a particular event; but this > > one is leaving me scratching my head. > > > > Is it perhaps a shot of the network engineering > > "Ooops (I broke the network again)" concert > > tour? > > > > Or is there some other cultural reference at > > play that I'm not aware of? > > > > Enquiring minds want to know!(tm). :) > > > > Matt > From eric.kuhnke at gmail.com Mon Jun 5 00:30:38 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Sun, 4 Jun 2017 17:30:38 -0700 Subject: NANOG 70 network diagram and upstream In-Reply-To: References: <001401d2dbe2$73248230$596d8690$@gvtc.com> Message-ID: Doesn't cost a lot to use the regional shelf spares stocked by Juniper for a couple of days... On Jun 4, 2017 4:03 PM, "James Breeden" wrote: > Yeah, I was wondering about that 4x100G. is that a necessity or a "because > we can" move? > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas > Sent: Friday, June 2, 2017 4:35 PM > To: Aaron Gould > Cc: NANOG > Subject: RE: NANOG 70 network diagram and upstream > > And the 4x100G. That's four times the capacity of the network I work for. > ~100k subs. > > On Jun 2, 2017 16:54, "Aaron Gould" wrote: > > > Btw.... > > > > Wow, a ~2 million dollar boundary (dual PTX1000's) for the NANOG 70 > > conference.... geez > > > > -aaron > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke > > Sent: Friday, June 2, 2017 1:43 PM > > To: nanog at nanog.org list > > Subject: NANOG 70 network diagram and upstream > > > > Just a small thing, but as one of the folks who used to work on the > > core network gear of AS11404, the network diagram has something in it > > that might confuse attendees as to who is really sponsoring the upstream: > > > > https://www.nanog.org/meetings/nanog70/diagram > > > > AS11404 was formerly known as Spectrum Networks, acquired in 2013 by > > Wavedivision Holdings LLC (Wave Broadband) and became the backbone of > > the Wave network. It's a totally different thing than the Charter > > service which is trademarked as as Spectrum. > > > > https://www.peeringdb.com/asn/11404 > > > > The logo in the right side bubble there shouldn't be the > > Charter/Spectrum trademarked font, but rather should be Wave, who > > built the dark fiber into the hotel and are providing the upstream. > > The last mile fiber into the hotel is Wave. > > > > > > -Eric > > > > > From eric.kuhnke at gmail.com Mon Jun 5 00:31:31 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Sun, 4 Jun 2017 17:31:31 -0700 Subject: Internet connectivity in Ghana In-Reply-To: <78376e93-d734-d661-5016-ecbc998f1167@i3d.net> References: <78376e93-d734-d661-5016-ecbc998f1167@i3d.net> Message-ID: Another good choice for a major international carrier with a pop in Accra would be opentransit/France Telecom. On Jun 4, 2017 6:04 AM, "i3D.net - Martijn Schmidt" wrote: > TISparkle/Seabone also has an IP transit PoP in Accra, plus they have a > partnership with Dolphin Telecom. > > On 06/01/2017 05:30 PM, Eric Kuhnke wrote: > > All of the licensed mobile phone network operators in Ghana are also ISPs > > and can reach enterprise customers. Within Accra or a few other major > > coastal cities, either by microwave rooftop/tower based links or their > > terrestrial fiber. Should definitely be much faster and more economical > > than satellite. > > > > Interestingly if you look at BGP tables and AS-adjacencies for the major > > Ghanian ISPs and telecoms, it is logically a suburb of London, which is > > where most of the traffic in the recently built West African submarine > > cables goes. > > > > > > On Wed, May 31, 2017 at 7:40 AM, Rishi Singh > wrote: > > > >> Has anyone dealt with getting internet connectivity in Ghana? I've been > >> doing a lot of research and saw some peering plans with Nigeria but > nothing > >> solid there yet. Currently a financial client of mine is paying quite a > bit > >> every quarter on satellite up link fees. > >> > >> Do any of the major carriers have any direct connectivity into Ghana? > >> > >> Thank you, > >> > > > From rfg at tristatelogic.com Mon Jun 5 10:56:14 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 05 Jun 2017 03:56:14 -0700 Subject: IPv4 Hijacking For Idiots Message-ID: <88661.1496660174@segfault.tristatelogic.com> The more I know, the less I understand. Maybe some of you kind folks can help. Please explain for me the following scenario, and how this all actually works in practice. Let's say that you're a malevolent Bad Actor and all you want to do is to get hold of some ASN that nobody is watching too closely, and then use that to announce some routes to some IPv4 space that nobody is watching too closely, so that you can then parcel out that IP space to your snowshoe spammer pals... at least until somebody gets wise. OK, so you pull down a copy of, say, the RIPE WHOIS database, and you programatically walk your way through it, looking for contact email addresses on ASN records where the domain of the contact email address has become unregistered. Say for example the one for AS34991. So then you re-register that contact domain, fresh, and then you start telling all of your friends and enemies that you -are- AS34991. That part seems simple enough, and indeed, I've seen -this- part of the movie several times before. However once you have stepped into the identity of the former owners of the ASN, if you then want to actually proceed to -announce- some routes, and actually ave those routes make it out onto the Internet generally, then you still have to -peer- with somebody, right? So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.) But see, this is where I get lost. I mean how do you push your route announcements to these guys? (I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to? And if you are going to push your route announcements out to, say, the specific routers that are run by AS206776 and AS57344, i.e. the ones that will send your desired route announcements out to the rest of the Internet... well.. how do you find out the IP addresses of those routers on those other networks? Do you call up the NOCs at those other networks and do a bit of social engineering on them to find out the IP addresses you need to send to? And can you just send BGP messages to the routers on those other networks without -any- authentication or anything and have those routers just blindly accept them -and- relay them on to the whole rest of the Internet?? I've read article after article after article bemoanging the fact that "BGP isn't secure", but now I'm starting to wonder just how massively and unbelieveably unsecure it actually is. I mean would these routers being run by AS206776 and AS57344 just blindly accept -any- route announcements sent to them from literally -any- IP address? (That seems positively looney tunes to me! I mean things can't really be THAT colossally and unbelievably stupid, can they?) Thanks in advance for any enlightenment. Regards, rfg P.S. It would appear to be the case that since some time in April of this year the "Bulgarian" network, AS34991, had evinced a rather sudden and pronounced affinity for various portion of the IPv4 address space nominally associated with the nation of Columbia, including at least five /24 blocks within 168.176.0.0/16 which, from where I am sitting, would appear to belong to the National University of Columbia. Oh well. They apparently haven't been missing those five gaping holes in their /16 since the time the more specifics started showing up in April. And anyway, so far it looks like the new owners of AS34991 haven't actually sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24 block seems to be filled, wall-to-all, with snowshoe spammers so far. From rod.beck at unitedcablecompany.com Mon Jun 5 11:03:12 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Mon, 5 Jun 2017 11:03:12 +0000 Subject: Northern Ireland Message-ID: Who are the main competitive local providers in Belfast? Regards, Roderick. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Kir?ly utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From mel at beckman.org Mon Jun 5 11:05:21 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 5 Jun 2017 11:05:21 +0000 Subject: IPv4 Hijacking For Idiots In-Reply-To: <88661.1496660174@segfault.tristatelogic.com> References: <88661.1496660174@segfault.tristatelogic.com> Message-ID: One way is for the hijacker to simply peer with himself. The hijacker has an existing peering arrangement with, say, AT&T. He then tells AT&T that he will be transit for ASxxxx advertising XYZ routes, by dint of a cheerfully forged LOA. Once filters have been updated, the hijacker advertises the space to himself, and then from thence to AT&T. It's no great trick getting peering set up. Just fill out a ten-question BGP app and pay a one-time fee of maybe $100, and you're done. -mel beckman > On Jun 5, 2017, at 3:56 AM, Ronald F. Guilmette wrote: > > > The more I know, the less I understand. > > Maybe some of you kind folks can help. > > Please explain for me the following scenario, and how this all actually > works in practice. > > Let's say that you're a malevolent Bad Actor and all you want to do is > to get hold of some ASN that nobody is watching too closely, and then > use that to announce some routes to some IPv4 space that nobody is > watching too closely, so that you can then parcel out that IP space > to your snowshoe spammer pals... at least until somebody gets wise. > > OK, so you pull down a copy of, say, the RIPE WHOIS database, and you > programatically walk your way through it, looking for contact email > addresses on ASN records where the domain of the contact email address > has become unregistered. Say for example the one for AS34991. So > then you re-register that contact domain, fresh, and then you start > telling all of your friends and enemies that you -are- AS34991. > > That part seems simple enough, and indeed, I've seen -this- part of the > movie several times before. However once you have stepped into the > identity of the former owners of the ASN, if you then want to actually > proceed to -announce- some routes, and actually ave those routes make > it out onto the Internet generally, then you still have to -peer- with > somebody, right? > > So, I guess then, if you're clever, you look and see who the ASN you've > just successfully hijacked has historically peered with, and then you > somehow arrange to send route announcements to those guys, right? > (I'm talking about AS206776 and AS57344 here, BTW.) > > But see, this is where I get lost. I mean how do you push your route > announcements to these guys? (I don't actually know that much about > how BGP actually works in practice, so please bear with me.) How do > you know what IP address to send your announcements to? And if you are > going to push your route announcements out to, say, the specific routers > that are run by AS206776 and AS57344, i.e. the ones that will send your > desired route announcements out to the rest of the Internet... well.. > how do you find out the IP addresses of those routers on those other > networks? Do you call up the NOCs at those other networks and do a bit > of social engineering on them to find out the IP addresses you need to > send to? And can you just send BGP messages to the routers on those > other networks without -any- authentication or anything and have those > routers just blindly accept them -and- relay them on to the whole rest > of the Internet?? > > I've read article after article after article bemoanging the fact that > "BGP isn't secure", but now I'm starting to wonder just how massively > and unbelieveably unsecure it actually is. I mean would these routers > being run by AS206776 and AS57344 just blindly accept -any- route > announcements sent to them from literally -any- IP address? (That seems > positively looney tunes to me! I mean things can't really be THAT > colossally and unbelievably stupid, can they?) > > Thanks in advance for any enlightenment. > > > Regards, > rfg > > > P.S. It would appear to be the case that since some time in April of this > year the "Bulgarian" network, AS34991, had evinced a rather sudden and > pronounced affinity for various portion of the IPv4 address space nominally > associated with the nation of Columbia, including at least five /24 blocks > within 168.176.0.0/16 which, from where I am sitting, would appear to belong > to the National University of Columbia. > > Oh well. They apparently haven't been missing those five gaping holes in > their /16 since the time the more specifics started showing up in April. > > And anyway, so far it looks like the new owners of AS34991 haven't actually > sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24 > block seems to be filled, wall-to-all, with snowshoe spammers so far. > > From morrowc.lists at gmail.com Mon Jun 5 16:03:18 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 5 Jun 2017 12:03:18 -0400 Subject: IPv4 Hijacking For Idiots In-Reply-To: References: <88661.1496660174@segfault.tristatelogic.com> Message-ID: On Mon, Jun 5, 2017 at 7:05 AM, Mel Beckman wrote: > One way is for the hijacker to simply peer with himself. The hijacker has > an existing peering arrangement with, say, AT&T. He then tells AT&T that he > will be transit for ASxxxx advertising XYZ routes, by dint of a cheerfully > forged LOA. Once filters have been updated, the hijacker advertises the > space to himself, and then from thence to AT&T. > that doesn't seem to be what's happening in ron's example though... it looks, to me, like the example ron has is more a case of: 1) register contacts for lost asn (AS34991) 2) setup equipment/etc at an IX (bulgaria-ix it seems, at least) with another shill/lost-child asn (AS206776) 3) start doing the bgps with the IX fabric's route-server 4) profit (or something) so here the IXP operator (balkans ix actually?) http://lg.bix.bg/?query=summary&addr=&router=rs1.bix.bg+%28IPv4%29 (search for 206776 -> http://lg.bix.bg/?query=bgp&addr=neighbors+193.169.198.191&router=rs1.bix.bg+(IPv4) ) should probably look more than just side-eyes at their customer... > > It's no great trick getting peering set up. Just fill out a ten-question > BGP app and pay a one-time fee of maybe $100, and you're done. > err, you'll have to better explain this I think. Are you saying: "get an ASN from RIR that costs 100USD" (might, probably does) this doesn't get you a peering/transit contract though... -chris > > -mel beckman > > > On Jun 5, 2017, at 3:56 AM, Ronald F. Guilmette > wrote: > > > > > > The more I know, the less I understand. > > > > Maybe some of you kind folks can help. > > > > Please explain for me the following scenario, and how this all actually > > works in practice. > > > > Let's say that you're a malevolent Bad Actor and all you want to do is > > to get hold of some ASN that nobody is watching too closely, and then > > use that to announce some routes to some IPv4 space that nobody is > > watching too closely, so that you can then parcel out that IP space > > to your snowshoe spammer pals... at least until somebody gets wise. > > > > OK, so you pull down a copy of, say, the RIPE WHOIS database, and you > > programatically walk your way through it, looking for contact email > > addresses on ASN records where the domain of the contact email address > > has become unregistered. Say for example the one for AS34991. So > > then you re-register that contact domain, fresh, and then you start > > telling all of your friends and enemies that you -are- AS34991. > > > > That part seems simple enough, and indeed, I've seen -this- part of the > > movie several times before. However once you have stepped into the > > identity of the former owners of the ASN, if you then want to actually > > proceed to -announce- some routes, and actually ave those routes make > > it out onto the Internet generally, then you still have to -peer- with > > somebody, right? > > > > So, I guess then, if you're clever, you look and see who the ASN you've > > just successfully hijacked has historically peered with, and then you > > somehow arrange to send route announcements to those guys, right? > > (I'm talking about AS206776 and AS57344 here, BTW.) > > > > But see, this is where I get lost. I mean how do you push your route > > announcements to these guys? (I don't actually know that much about > > how BGP actually works in practice, so please bear with me.) How do > > you know what IP address to send your announcements to? And if you are > > going to push your route announcements out to, say, the specific routers > > that are run by AS206776 and AS57344, i.e. the ones that will send your > > desired route announcements out to the rest of the Internet... well.. > > how do you find out the IP addresses of those routers on those other > > networks? Do you call up the NOCs at those other networks and do a bit > > of social engineering on them to find out the IP addresses you need to > > send to? And can you just send BGP messages to the routers on those > > other networks without -any- authentication or anything and have those > > routers just blindly accept them -and- relay them on to the whole rest > > of the Internet?? > > > > I've read article after article after article bemoanging the fact that > > "BGP isn't secure", but now I'm starting to wonder just how massively > > and unbelieveably unsecure it actually is. I mean would these routers > > being run by AS206776 and AS57344 just blindly accept -any- route > > announcements sent to them from literally -any- IP address? (That seems > > positively looney tunes to me! I mean things can't really be THAT > > colossally and unbelievably stupid, can they?) > > > > Thanks in advance for any enlightenment. > > > > > > Regards, > > rfg > > > > > > P.S. It would appear to be the case that since some time in April of > this > > year the "Bulgarian" network, AS34991, had evinced a rather sudden and > > pronounced affinity for various portion of the IPv4 address space > nominally > > associated with the nation of Columbia, including at least five /24 > blocks > > within 168.176.0.0/16 which, from where I am sitting, would appear to > belong > > to the National University of Columbia. > > > > Oh well. They apparently haven't been missing those five gaping holes in > > their /16 since the time the more specifics started showing up in April. > > > > And anyway, so far it looks like the new owners of AS34991 haven't > actually > > sub-leased any of those /24s to any spammers yet. Only the > 190.90.88.0/24 > > block seems to be filled, wall-to-all, with snowshoe spammers so far. > > > > > From mel at beckman.org Mon Jun 5 16:28:11 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 5 Jun 2017 16:28:11 +0000 Subject: IPv4 Hijacking For Idiots In-Reply-To: References: <88661.1496660174@segfault.tristatelogic.com> Message-ID: Chris, I didn?t research Ron?s specific example. I was speaking in generalities. I?m assuming any BGP hijacker already has two or more DIA connections. It only costs $100 to add BGP peering to that setup. Yes, they will need an ASN. I was only talking about the cost of adding an upstream BGP session. -mel On Jun 5, 2017, at 9:03 AM, Christopher Morrow > wrote: On Mon, Jun 5, 2017 at 7:05 AM, Mel Beckman > wrote: One way is for the hijacker to simply peer with himself. The hijacker has an existing peering arrangement with, say, AT&T. He then tells AT&T that he will be transit for ASxxxx advertising XYZ routes, by dint of a cheerfully forged LOA. Once filters have been updated, the hijacker advertises the space to himself, and then from thence to AT&T. that doesn't seem to be what's happening in ron's example though... it looks, to me, like the example ron has is more a case of: 1) register contacts for lost asn (AS34991) 2) setup equipment/etc at an IX (bulgaria-ix it seems, at least) with another shill/lost-child asn (AS206776) 3) start doing the bgps with the IX fabric's route-server 4) profit (or something) so here the IXP operator (balkans ix actually?) http://lg.bix.bg/?query=summary&addr=&router=rs1.bix.bg+%28IPv4%29 (search for 206776 -> http://lg.bix.bg/?query=bgp&addr=neighbors+193.169.198.191&router=rs1.bix.bg+(IPv4)) should probably look more than just side-eyes at their customer... It's no great trick getting peering set up. Just fill out a ten-question BGP app and pay a one-time fee of maybe $100, and you're done. err, you'll have to better explain this I think. Are you saying: "get an ASN from RIR that costs 100USD" (might, probably does) this doesn't get you a peering/transit contract though... -chris -mel beckman > On Jun 5, 2017, at 3:56 AM, Ronald F. Guilmette > wrote: > > > The more I know, the less I understand. > > Maybe some of you kind folks can help. > > Please explain for me the following scenario, and how this all actually > works in practice. > > Let's say that you're a malevolent Bad Actor and all you want to do is > to get hold of some ASN that nobody is watching too closely, and then > use that to announce some routes to some IPv4 space that nobody is > watching too closely, so that you can then parcel out that IP space > to your snowshoe spammer pals... at least until somebody gets wise. > > OK, so you pull down a copy of, say, the RIPE WHOIS database, and you > programatically walk your way through it, looking for contact email > addresses on ASN records where the domain of the contact email address > has become unregistered. Say for example the one for AS34991. So > then you re-register that contact domain, fresh, and then you start > telling all of your friends and enemies that you -are- AS34991. > > That part seems simple enough, and indeed, I've seen -this- part of the > movie several times before. However once you have stepped into the > identity of the former owners of the ASN, if you then want to actually > proceed to -announce- some routes, and actually ave those routes make > it out onto the Internet generally, then you still have to -peer- with > somebody, right? > > So, I guess then, if you're clever, you look and see who the ASN you've > just successfully hijacked has historically peered with, and then you > somehow arrange to send route announcements to those guys, right? > (I'm talking about AS206776 and AS57344 here, BTW.) > > But see, this is where I get lost. I mean how do you push your route > announcements to these guys? (I don't actually know that much about > how BGP actually works in practice, so please bear with me.) How do > you know what IP address to send your announcements to? And if you are > going to push your route announcements out to, say, the specific routers > that are run by AS206776 and AS57344, i.e. the ones that will send your > desired route announcements out to the rest of the Internet... well.. > how do you find out the IP addresses of those routers on those other > networks? Do you call up the NOCs at those other networks and do a bit > of social engineering on them to find out the IP addresses you need to > send to? And can you just send BGP messages to the routers on those > other networks without -any- authentication or anything and have those > routers just blindly accept them -and- relay them on to the whole rest > of the Internet?? > > I've read article after article after article bemoanging the fact that > "BGP isn't secure", but now I'm starting to wonder just how massively > and unbelieveably unsecure it actually is. I mean would these routers > being run by AS206776 and AS57344 just blindly accept -any- route > announcements sent to them from literally -any- IP address? (That seems > positively looney tunes to me! I mean things can't really be THAT > colossally and unbelievably stupid, can they?) > > Thanks in advance for any enlightenment. > > > Regards, > rfg > > > P.S. It would appear to be the case that since some time in April of this > year the "Bulgarian" network, AS34991, had evinced a rather sudden and > pronounced affinity for various portion of the IPv4 address space nominally > associated with the nation of Columbia, including at least five /24 blocks > within 168.176.0.0/16 which, from where I am sitting, would appear to belong > to the National University of Columbia. > > Oh well. They apparently haven't been missing those five gaping holes in > their /16 since the time the more specifics started showing up in April. > > And anyway, so far it looks like the new owners of AS34991 haven't actually > sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24 > block seems to be filled, wall-to-all, with snowshoe spammers so far. > > From morrowc.lists at gmail.com Mon Jun 5 17:09:37 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 5 Jun 2017 13:09:37 -0400 Subject: IPv4 Hijacking For Idiots In-Reply-To: References: <88661.1496660174@segfault.tristatelogic.com> Message-ID: On Mon, Jun 5, 2017 at 12:28 PM, Mel Beckman wrote: > Chris, > > I didn?t research Ron?s specific example. I was speaking in generalities. > I?m assuming any BGP hijacker already has two or more DIA connections. It > only costs $100 to add BGP peering to that setup. Yes, they will need an > ASN. I was only > most times i've seen isp DIA links bgp was 'free' or had been.. > talking about the cost of adding an upstream BGP session. > ok. so either free or some up-charge by the isp. > > -mel > > > On Jun 5, 2017, at 9:03 AM, Christopher Morrow > wrote: > > > > On Mon, Jun 5, 2017 at 7:05 AM, Mel Beckman wrote: > >> One way is for the hijacker to simply peer with himself. The hijacker has >> an existing peering arrangement with, say, AT&T. He then tells AT&T that he >> will be transit for ASxxxx advertising XYZ routes, by dint of a cheerfully >> forged LOA. Once filters have been updated, the hijacker advertises the >> space to himself, and then from thence to AT&T. >> > > that doesn't seem to be what's happening in ron's example though... > > it looks, to me, like the example ron has is more a case of: > 1) register contacts for lost asn (AS34991) > 2) setup equipment/etc at an IX (bulgaria-ix it seems, at least) with > another shill/lost-child asn (AS206776) > 3) start doing the bgps with the IX fabric's route-server > 4) profit (or something) > > so here the IXP operator (balkans ix actually?) > http://lg.bix.bg/?query=summary&addr=&router=rs1.bix.bg+%28IPv4%29 > (search for 206776 -> http://lg.bix.bg/?query= > bgp&addr=neighbors+193.169.198.191&router=rs1.bix.bg+(IPv4)) > > should probably look more than just side-eyes at their customer... > > >> >> It's no great trick getting peering set up. Just fill out a ten-question >> BGP app and pay a one-time fee of maybe $100, and you're done. >> > > err, you'll have to better explain this I think. > > Are you saying: "get an ASN from RIR that costs 100USD" (might, probably > does) > > this doesn't get you a peering/transit contract though... > > -chris > > >> >> -mel beckman >> >> > On Jun 5, 2017, at 3:56 AM, Ronald F. Guilmette >> wrote: >> > >> > >> > The more I know, the less I understand. >> > >> > Maybe some of you kind folks can help. >> > >> > Please explain for me the following scenario, and how this all actually >> > works in practice. >> > >> > Let's say that you're a malevolent Bad Actor and all you want to do is >> > to get hold of some ASN that nobody is watching too closely, and then >> > use that to announce some routes to some IPv4 space that nobody is >> > watching too closely, so that you can then parcel out that IP space >> > to your snowshoe spammer pals... at least until somebody gets wise. >> > >> > OK, so you pull down a copy of, say, the RIPE WHOIS database, and you >> > programatically walk your way through it, looking for contact email >> > addresses on ASN records where the domain of the contact email address >> > has become unregistered. Say for example the one for AS34991. So >> > then you re-register that contact domain, fresh, and then you start >> > telling all of your friends and enemies that you -are- AS34991. >> > >> > That part seems simple enough, and indeed, I've seen -this- part of the >> > movie several times before. However once you have stepped into the >> > identity of the former owners of the ASN, if you then want to actually >> > proceed to -announce- some routes, and actually ave those routes make >> > it out onto the Internet generally, then you still have to -peer- with >> > somebody, right? >> > >> > So, I guess then, if you're clever, you look and see who the ASN you've >> > just successfully hijacked has historically peered with, and then you >> > somehow arrange to send route announcements to those guys, right? >> > (I'm talking about AS206776 and AS57344 here, BTW.) >> > >> > But see, this is where I get lost. I mean how do you push your route >> > announcements to these guys? (I don't actually know that much about >> > how BGP actually works in practice, so please bear with me.) How do >> > you know what IP address to send your announcements to? And if you are >> > going to push your route announcements out to, say, the specific routers >> > that are run by AS206776 and AS57344, i.e. the ones that will send your >> > desired route announcements out to the rest of the Internet... well.. >> > how do you find out the IP addresses of those routers on those other >> > networks? Do you call up the NOCs at those other networks and do a bit >> > of social engineering on them to find out the IP addresses you need to >> > send to? And can you just send BGP messages to the routers on those >> > other networks without -any- authentication or anything and have those >> > routers just blindly accept them -and- relay them on to the whole rest >> > of the Internet?? >> > >> > I've read article after article after article bemoanging the fact that >> > "BGP isn't secure", but now I'm starting to wonder just how massively >> > and unbelieveably unsecure it actually is. I mean would these routers >> > being run by AS206776 and AS57344 just blindly accept -any- route >> > announcements sent to them from literally -any- IP address? (That seems >> > positively looney tunes to me! I mean things can't really be THAT >> > colossally and unbelievably stupid, can they?) >> > >> > Thanks in advance for any enlightenment. >> > >> > >> > Regards, >> > rfg >> > >> > >> > P.S. It would appear to be the case that since some time in April of >> this >> > year the "Bulgarian" network, AS34991, had evinced a rather sudden and >> > pronounced affinity for various portion of the IPv4 address space >> nominally >> > associated with the nation of Columbia, including at least five /24 >> blocks >> > within 168.176.0.0/16 which, from where I am sitting, would appear to >> belong >> > to the National University of Columbia. >> > >> > Oh well. They apparently haven't been missing those five gaping holes >> in >> > their /16 since the time the more specifics started showing up in April. >> > >> > And anyway, so far it looks like the new owners of AS34991 haven't >> actually >> > sub-leased any of those /24s to any spammers yet. Only the >> 190.90.88.0/24 >> > block seems to be filled, wall-to-all, with snowshoe spammers so far. >> > >> > >> > > > From gabe at rtegroup.com Sat Jun 3 15:16:19 2017 From: gabe at rtegroup.com (Gabe Cole) Date: Sat, 3 Jun 2017 11:16:19 -0400 Subject: India Data Center Contacts Message-ID: I am trying to track down contacts at the following data centers in India if anyone can help. 1. Net4 2. NetMagic 3. Ricoh -- G. Gabriel Cole *RTE Group, Inc.* *Strategic Consulting for Mission Critical Infrastructure* 56 Woodridge Rd Wellesley, MA 02482 US +1-617-303-8707 fax +1-781-209-5577 www.rtegroup.com gabe at rtegroup.com skype: ggabrielcole Twitter: @DataCenterGuru Linked In: http://www.linkedin.com/in/gabecole Blog: http://datacenterguru.blogspot.com/ The information contained herein is confidential and proprietary to RTE Group, Inc. It is intended for presentation to and permitted use solely by those person(s) to whom it has been transmitted by RTE Group, Inc. and it is transmitted to such person(s) solely for, conditional upon, and only to the extent necessary for use by such person(s) as part of their business relationship with RTE Group, Inc. or to further their respective evaluation(s) of a potential business relationship with RTE Group, Inc., and no other use, release, or reproduction of this information is permitted. From jon.p.sevier at gmail.com Mon Jun 5 00:10:24 2017 From: jon.p.sevier at gmail.com (Jon Sevier) Date: Sun, 4 Jun 2017 17:10:24 -0700 Subject: NANOG70 tee shirt mystery In-Reply-To: References: Message-ID: It's a play on Pearl Jam's "Ten" album cover as best as I can tell. -Jon On Jun 4, 2017 16:57, "Matthew Petach" wrote: > So, I've been staring at the NANOG70 tee shirt for > a bit now: > > https://flic.kr/p/VejX5y > > and I have to admit, I'm a bit stymied. > > Usually, the tee-shirts are somewhat referential > to the location or to a particular event; but this > one is leaving me scratching my head. > > Is it perhaps a shot of the network engineering > "Ooops (I broke the network again)" concert > tour? > > Or is there some other cultural reference at > play that I'm not aware of? > > Enquiring minds want to know!(tm). :) > > Matt > From nickdwhite at gmail.com Sat Jun 3 23:32:56 2017 From: nickdwhite at gmail.com (Nick W) Date: Sat, 3 Jun 2017 19:32:56 -0400 Subject: Anyone Competent within ATT ASE (On Demand)? Message-ID: I have an ASEOD change order (disconnect from EVC, then add to new EVC) that is effectively stuck and has taken 4 of my circuits down. I'm unable to initiate new changes to the affected circuits. I've got 2 tickets open, escalated to level 6, spoken with 2 different ENOC people, and no one seems to be able to do anything or help me, and no one knows how to get a hold of anyone that can actually work on On Demand circuits. Been at this for 12 hours now... This network automation stuff is fun, eh? Except when you outsource the people that fix it, and they apparently don't work on weekends... or don't exist at all. Thanks, Nick From vaibhav.bajpai at tum.de Mon Jun 5 12:51:35 2017 From: vaibhav.bajpai at tum.de (Bajpai, Vaibhav) Date: Mon, 5 Jun 2017 12:51:35 +0000 Subject: IPv6 traffic percentages? Message-ID: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> Hello, > nanog-isp at mail.com nanog-isp at mail.com > Wed Jan 20 12:14:42 UTC 2016 > > Hello all, > > Would those with IPv6 deployments kindly share some statistics on their percentage of IPv6 traffic? > Bonus points for sharing top IPv6 sources. Anything else than the usual suspects, Google/YouTube, Netflix and Facebook? > > Some public information I've found so far: > - Comcast around 25% IPv6 traffic (http://www.lightreading.com/ethernet-ip/ip-protocols-software/facebook-ipv6-is-a-real-world-big-deal/a/d-id/718395) > - Comcast has over 1 Tb/s (of mostly YouTube traffic) over IPv6 (http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-in-launch-of-ipv6-broadband-network) > - Swisscom 26% IPv6 traffic, 60% YouTube (http://www.swinog.ch/meetings/swinog27/p/01_Martin_Gysi.pdf) > > I'd be very much interested in hearing from smaller ISPs, especially those having a very limited number of IPv4 addresses and/or running out. > > Thanks, > Jared The v6 numbers from ^ NANOG post are now more than 1 year old. Thought to re-bump this thread. Would it be possible to share updated numbers of v6 traffic share within your network and % contribution by top apps. Thanks a bunch! -- Vaibhav -------------------------- Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Researcher TU Munich, Germany -------------------------- From rfg at tristatelogic.com Mon Jun 5 23:17:24 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 05 Jun 2017 16:17:24 -0700 Subject: IPv4 Hijacking For Idiots In-Reply-To: Message-ID: <91062.1496704644@segfault.tristatelogic.com> In message Christopher Morrow wrote: >that doesn't seem to be what's happening in ron's example though... > >it looks, to me, like the example ron has is more a case of: > 1) register contacts for lost asn (AS34991) > 2) setup equipment/etc at an IX (bulgaria-ix it seems, at least) with >another shill/lost-child asn (AS206776) I'm perplexed at why you would call AS206776 a "lost child", so perhaps you could explain that. From where I'm sitting, it does look rather entirely dodgy... being (allegedly) located as it is in the British Virgin Islands, and having only been created (manufactured?) circa 2016-11-04. But bpg.he.net is showing that it has 35 peers, and that it is peering even with the likes of big boys like HE.net and Level3, just to name a few. > 3) start doing the bgps with the IX fabric's route-server Yeabut again, I personally would like to be enlightened about the basic mechanics of how one causes this to happen. If I am Joe Blow criminal and I somehow manage to finnagle my way into having a machine which is physically present within some IX at some locale, somewhere on planet earth, then does that mean that, by definition, I know -where- to inject bogus routes and -how- to inject bogus routes and that I have the -capability- in inject bogus routes into the kind of "fabric route server" you speak of? And by the way, I see now that I botched the Subject: for this thread that I started. I meant to say "IP Hijacking for Dummies". Obviously, this activity has become so popular that it is high time that somebody wrote one of those "XYZ for Dummies" books, you know, with the yellow and black covers, so that aspiring but ignorant criminals don't have to always start from scratch and learn how to do this stuff from the ground up, based just on piecing together little scraps and fragments of information scattered all over the Internet. > 4) profit (or something) Yea. I don't think that hijackers are doing this stuff just for fun. But they've already figured out how to MAKE MONEY FAST from the purloined IP space, so that part probably doesn't even need to go in the book. >err, you'll have to better explain this I think. > >Are you saying: "get an ASN from RIR that costs 100USD" (might, probably >does) > >this doesn't get you a peering/transit contract though... Yea, this is a part of what I'm still mystified about. Have AS206776 and AS57344 been paid to pass the routes given to them by AS34991 ? And have they been paid an extra premium, above and beyond the normal fee for this service, you know, to look the other way and do the old Muhammad Ali rope-a-dope and act stupid/innocent when and if anybody ever calls them out for this rather entirely blatant and brazen bogosity? I've seen this movie before, and not that long ago. And it's just not nearly as entertaining the second time around. The upstreams shrug and offer the lame excuse of "Oh... well... the routes are all properly registered in the RIPE route registry, so, you know, how could we have possibly known that anything was amiss?" But as I learned last time this lame excuse was used, any baboon with a keyboard and a pulse can get himself a RIPE account and then create all of the bogus route objects he or she desires. And since it took me less than a day to find out this ludicrous but true fact last time, I have to wonder if network operators, and particularly those in the RIPE region, are in some cases being -willfully ignorant- of the fact that a route object's presence within the RIPE data base has a reliability value roughly equal to that of a three dollar bill. Regards, rfg P.S. I'll be more than happy to take it upon myself... even being the basically unknown nobody and non-network-operator that I am... to send polite emails to both AS206776 and AS57344, asking them, as politely as I can manage, to please explain just WTF they think they are doing. But if past experience from the last such event is any guide, these emails will have no effect whatsoever. So that leads me to ask the obvious next question: Is it at all likely that anybody at, say, HE.net and/or Level3 might give enough of a damn about any of this ludicrous and clearly malevolent bogosity so that they mught actually be inclined to have a friendly word with the folks at AS206776 and AS57344? And if so, how might I get in touch with any such people (at HE and/or Level3)? From rfg at tristatelogic.com Mon Jun 5 23:46:04 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 05 Jun 2017 16:46:04 -0700 Subject: IP Hijacking For Dummies Message-ID: <91149.1496706364@segfault.tristatelogic.com> Late last night, I put together the following simple annotated listing of the routes being announced by AS34991. Beyond the quite apparent fact that this "Bulgarian" network is announcing a bunch of routes for blocks of IPv4 space allocated to various parties within the nation of Columbia (including the National University thereof) the other thing that struck me about this was the apparent relevance of a company called "host-offshore.com". Looking at the web site for that, it provides only a single contact phone number which is unambiguously a -Pakistani- phone number. But of course, that makes perfect sense, because Pakistan is just down the street from Bulgaria (NOT!) It did also strike me as passing strange that this company has apparently elected to not actually put its own web server, name servers, or mail server anywhere within its own duly allocated IPv4 blocks. Things got even a bit more interesting when I tried to actually order a server from this company. Apparently, all of their virtual servers are "sold out". However... and please, somebody check me on this... I guess that all of the browsers on all of the platforms I have ready access to are broken or something, because try as I might, I could never quite succeed at reaching any page on this company's web site where I could order up -any- kind of server, virtual, dedicated, or otherwise. So, you know, this hosting company appears somewhat unique and unusual, at least from where I am sitting, in the sense that it is perhaps the only such "hosting" company that I've ever run across in my travels that doesn't actually have -anything- for sale. Personally, I don't really give a rat's ass if this site is just a cover for some inept criminals, or for Panstani ISI, or for the FSB, or for some of Putin's patriots, or even if it belongs to the NSA. But I cannot help but bemoan the fact that here we are, and it is 2017 already, and yet, whichever bunch of lame-ass jerks are in fact behind this thing, apparently aren't even capable of slapping together a cover web site that is more than just some entirely shallow and not very effective false front. As a researcher and student of such things, I just think that by now, in 2017, we should have a somewhat more skilled class of frauds, rogues, criminals and spies on the Internet. I mean this is just baby stuff, and it only takes a couple of minutes and few clicks to see past such transparent gibberish. So c'mon all ye criminals, rogues and spys! You need to up your game fer cryin' out loud! At least present us with something a bit more challenging than -this- kind of very superflous crap. I mean, have you no self-respect? Geeeessshhh! Regards, rfg ======================================================================= 79.124.77.0/24 -- Bulgaria -- host-offshore.com 82.118.233.0/24 -- Blugaria -- wirelessnetbg.info 91.92.144.0/24 -- Bulgaria -- host-offshore.com 130.185.254.0/24 -- Belize? -- host-offshore.com - formerly routed by Verdina) 152.204.132.0/24 -- Columbia 152.204.133.0/24 -- Columbia 152.231.25.0/24 -- Columbia 152.231.28.0/24 -- Columbia 168.176.187.0/24 -- Columbia, National University of 168.176.192.0/24 -- Columbia, National University of 168.176.194.0/24 -- Columbia, National University of 168.176.218.0/24 -- Columbia, National University of 168.176.219.0/24 -- Columbia, National University of 179.1.71.0/24 -- Columbia 181.57.40.0/24 -- Columbia 186.113.13.0/24 -- Columbia 186.113.15.0/24 -- Columbia 186.147.230.0/24 -- Columbia 190.90.31.0/24 -- Columbia 190.90.88.0/24 -- Columbia 200.1.65.0/24 -- Columbia 200.14.44.0/24 -- Columbia 200.24.3.0/24 -- Columbia 200.24.5.0/24 -- Columbia From bill at herrin.us Tue Jun 6 00:20:53 2017 From: bill at herrin.us (William Herrin) Date: Mon, 5 Jun 2017 20:20:53 -0400 Subject: IPv4 Hijacking For Idiots In-Reply-To: <88661.1496660174@segfault.tristatelogic.com> References: <88661.1496660174@segfault.tristatelogic.com> Message-ID: On Mon, Jun 5, 2017 at 6:56 AM, Ronald F. Guilmette wrote: > So, I guess then, if you're clever, you look and see who the ASN you've > just successfully hijacked has historically peered with, and then you > somehow arrange to send route announcements to those guys, right? > (I'm talking about AS206776 and AS57344 here, BTW.) > > But see, this is where I get lost. I mean how do you push your route > announcements to these guys? Hi Ron, You actually got lost a couple steps back. First, you want to control the POC emails for the IP addresses. Controlling just the POC emails for the AS number won't do you any good. Let's say you have gained control of the POC emails for the IP address block. Stay completely away from the historical BGP peers. They might know the real registrant and get suspicious when you show up. Go to somebody else, dummy up some letterhead for the purported registrant and write yourself a letter authorizing the ISP to whom the letter is presented to route those IP addresses. Explain that you're a networking contractor working for the organization holding the registration and give them adequate contact information for yourself: postal address, email, phone. Not "1234 Main, box 30" but "1234 Main, Suite 30". Paid for with the cash-bought debit card. You get the idea. Then you pay the ISP to connect you to the Internet and present your letter. Until the inevitable complaints roll it, that's it: you have control of those IP addresses. > (I don't actually know that much about > how BGP actually works in practice, so please bear with me.) How do > you know what IP address to send your announcements to? You don't. Even if the session wasn't disabled when the customer stopped paying, you're not physically connected to the same network interface where it was configured. This reasoning path is a dead end. I've read article after article after article bemoanging the fact that > "BGP isn't secure", They're talking about a different problem: ISPs are supposed to configure end-user BGP sessions per BCP38 which limits which BGP announcements the customer can make. Some ISPs are sloppy and incompetent and don't do this. Unfortunately, once you're a level or two upstream the backbone ISP actually can't do much to limit the BGP announcements because it's often impractical to determine whether a block of IP addresses can legitimately be announced from a given peer. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From rfg at tristatelogic.com Tue Jun 6 01:04:54 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 05 Jun 2017 18:04:54 -0700 Subject: IPv4 Hijacking For Idiots In-Reply-To: Message-ID: <91401.1496711094@segfault.tristatelogic.com> In message Christopher Morrow wrote: >most times i've seen isp DIA links bgp was 'free' or had been.. > >> talking about the cost of adding an upstream BGP session. > >ok. so either free or some up-charge by the isp. Wait a minute. I just wanna make sure that I am getting this. So you're saying that whichever criminal is behind this stuff, that he maybe could have pulled it all off for the astounding and impressive sum of zero dollars and zero cents ($0.00) ? (Well, I guess that's not quite accurate. I guess that he at least had to pay for the cost of re-registering the wirelessnetbg.info domain name. I don't know what .info domains cost anymore, but the last time I looked you could get one of those for less than ten bucks. I suppose that Internet criminals everwhere will be greatly heartened by the low cost of entry into this game. I'm guessing that it probably costs much much more to become an Amway distributor, for example. Even second-story men have to invest more than this for a set of appropriate tools.) Regards, rfg From aftab.siddiqui at gmail.com Tue Jun 6 02:03:06 2017 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 06 Jun 2017 02:03:06 +0000 Subject: IP Hijacking For Dummies In-Reply-To: <91149.1496706364@segfault.tristatelogic.com> References: <91149.1496706364@segfault.tristatelogic.com> Message-ID: Same mobile number (+92-304-4000736 <+92%20304%204000736>) and address are listed here for Blue Angel Hosting with only 1 peer AS206776. aut-num: AS206349 as-name: blueangelhost org: ORG-BPL5-RIPE sponsoring-org: ORG-HGC2-RIPE import: from AS206776 accept ANY export: to AS206776 announce AS206349 import: from AS57344 accept ANY export: to AS57344 announce AS206349 admin-c: SS30461-RIPE tech-c: SS30461-RIPE remarks: For information on "status:" attribute read https://www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources status: ASSIGNED mnt-by: RIPE-NCC-END-MNT mnt-by: blueangelhost mnt-routes: blueangelhost created: 2017-02-08T10:44:15Z last-modified: 2017-02-08T10:44:15Z source: RIPE organisation: ORG-BPL5-RIPE org-name: BlueAngelHost Pvt. Ltd org-type: OTHER address: HOUSE NO 173 STREET NO 4 BLOCK E YOHANA ABAD, FEROZ PUR ROAD, LAHORE, PAKISTAN abuse-c: ACRO1320-RIPE mnt-ref: MNT-NETERRA mnt-ref: AZ39139-MNT mnt-ref: MNT-LIR-BG mnt-by: blueangelhost created: 2016-10-21T17:23:02Z last-modified: 2016-11-01T21:03:31Z source: RIPE # Filtered person: Sunil Shahzad address: HOUSE NO 173 STREET NO 4 BLOCK E YOHANA ABAD, FEROZ PUR ROAD, LAHORE, PAKISTAN phone: +92-304-4000736 nic-hdl: SS30461-RIPE mnt-by: blueangelhost created: 2016-10-21T17:19:19Z last-modified: 2016-10-21T17:19:19Z source: RIPE On Tue, 6 Jun 2017 at 09:48 Ronald F. Guilmette wrote: > > Late last night, I put together the following simple annotated listing of > the routes being announced by AS34991. > > Beyond the quite apparent fact that this "Bulgarian" network is announcing > a bunch of routes for blocks of IPv4 space allocated to various parties > within the nation of Columbia (including the National University thereof) > the other thing that struck me about this was the apparent relevance of > a company called "host-offshore.com". > > Looking at the web site for that, it provides only a single contact > phone number which is unambiguously a -Pakistani- phone number. But > of course, that makes perfect sense, because Pakistan is just down the > street from Bulgaria (NOT!) > > It did also strike me as passing strange that this company has apparently > elected to not actually put its own web server, name servers, or mail > server anywhere within its own duly allocated IPv4 blocks. > > Things got even a bit more interesting when I tried to actually order a > server from this company. Apparently, all of their virtual servers > are "sold out". However... and please, somebody check me on this... > I guess that all of the browsers on all of the platforms I have ready > access to are broken or something, because try as I might, I could never > quite succeed at reaching any page on this company's web site where I > could order up -any- kind of server, virtual, dedicated, or otherwise. > > So, you know, this hosting company appears somewhat unique and unusual, > at least from where I am sitting, in the sense that it is perhaps the > only such "hosting" company that I've ever run across in my travels that > doesn't actually have -anything- for sale. > > Personally, I don't really give a rat's ass if this site is just a cover > for some inept criminals, or for Panstani ISI, or for the FSB, or for > some of Putin's patriots, or even if it belongs to the NSA. But I cannot > help but bemoan the fact that here we are, and it is 2017 already, and > yet, whichever bunch of lame-ass jerks are in fact behind this thing, > apparently aren't even capable of slapping together a cover web site > that is more than just some entirely shallow and not very effective false > front. > > As a researcher and student of such things, I just think that by now, > in 2017, we should have a somewhat more skilled class of frauds, rogues, > criminals and spies on the Internet. I mean this is just baby stuff, > and it only takes a couple of minutes and few clicks to see past such > transparent gibberish. > > So c'mon all ye criminals, rogues and spys! You need to up your game > fer cryin' out loud! At least present us with something a bit more > challenging than -this- kind of very superflous crap. I mean, have you > no self-respect? > > Geeeessshhh! > > > Regards, > rfg > > > > ======================================================================= > 79.124.77.0/24 -- Bulgaria -- host-offshore.com > 82.118.233.0/24 -- Blugaria -- wirelessnetbg.info > 91.92.144.0/24 -- Bulgaria -- host-offshore.com > 130.185.254.0/24 -- Belize? -- host-offshore.com - formerly routed by > Verdina) > 152.204.132.0/24 -- Columbia > 152.204.133.0/24 -- Columbia > 152.231.25.0/24 -- Columbia > 152.231.28.0/24 -- Columbia > 168.176.187.0/24 -- Columbia, National University of > 168.176.192.0/24 -- Columbia, National University of > 168.176.194.0/24 -- Columbia, National University of > 168.176.218.0/24 -- Columbia, National University of > 168.176.219.0/24 -- Columbia, National University of > 179.1.71.0/24 -- Columbia > 181.57.40.0/24 -- Columbia > 186.113.13.0/24 -- Columbia > 186.113.15.0/24 -- Columbia > 186.147.230.0/24 -- Columbia > 190.90.31.0/24 -- Columbia > 190.90.88.0/24 -- Columbia > 200.1.65.0/24 -- Columbia > 200.14.44.0/24 -- Columbia > 200.24.3.0/24 -- Columbia > 200.24.5.0/24 -- Columbia > > -- Best Wishes, Aftab A. Siddiqui From rfg at tristatelogic.com Tue Jun 6 02:16:38 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 05 Jun 2017 19:16:38 -0700 Subject: IPv4 Hijacking For Idiots In-Reply-To: Message-ID: <91773.1496715398@segfault.tristatelogic.com> In message William Herrin wrote: >You actually got lost a couple steps back. > >First, you want to control the POC emails for the IP addresses. Controlling >just the POC emails for the AS number won't do you any good. Ummm... in this case there doesn't seem to be any reason to believe that the hijacker(s) have gotten anywhere near to controlling the POC emails for any, let alone -all- of the relevant (Columbian) IP blocks... only the POC emails for the ASN. But you are suggesting that they -did- get control of those, all essentially simultaneously (or anyway sometime during the past 2 months), for all of about five or six or seven separate and different Columbian entities. That theory would seem to fail the Occam's razor test. It just doesn't seem at all liklely. >Let's say you have gained control of the POC emails for the IP address >block. Stay completely away from the historical BGP peers. They might know >the real registrant and get suspicious when you show up. Good point! I'll have to remember to put that in the book. :-) >Go to somebody >else, dummy up some letterhead for the purported registrant and write >yourself a letter authorizing the ISP to whom the letter is presented to >route those IP addresses. Explain that you're a networking contractor >working for the organization holding the registration and give them >adequate contact information for yourself: postal address, email, phone. >Not "1234 Main, box 30" but "1234 Main, Suite 30". Paid for with the >cash-bought debit card. You get the idea. Yes. The whole general identity theft ruse isn't that complicated to understand. I still don't get how these crooks managed to get past that occular biometric scan, but I guess the check cleared, so maybe that goes a long way towards explaining -that- mystery. :-) >Then you pay the ISP to connect you to the Internet and present your >letter. Until the inevitable complaints roll it, that's it: you have >control of those IP addresses. I guess that I must be hoplessly naive to believe that the likes of either Hurricane or Level3 might employ some warm body, at least part time, to actually look for this kind of blatant gibberish, and flag it for further inquiry when it arises. I would volunteer to do the job for them if they would just keep me in Cheetos. (Cheetos are my new favorite snack ever since last November's election. :-) >I've read article after article after article bemoanging the fact that >> "BGP isn't secure", > >They're talking about a different problem: ISPs are supposed to configure >end-user BGP sessions per BCP38 which limits which BGP announcements the >customer can make. Some ISPs are sloppy and incompetent and don't do this. Yea. I kinda thought that most or all of the very public hand-wringing over the "insecurity" of BGP was indeed about this other aspect of the problem. But I just wanted to be sure that I was clear in my own mind about this. The insecurity -isn't- that any Joe Blow can just willy nilly connect up to any router on the Internet and push bogus routes into it. The insecurity is only that people/entities you know, trust, and have actual business relationships with can (and apparently do), in many cases, pass goofy stuff to you, and if you are not fastidious enough about washing up after such contacts, then you pass those bits of nonsense along to everybody else who you have relationships with... sort-of like chlamydia. Regards, rfg From valdis.kletnieks at vt.edu Tue Jun 6 03:59:45 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 05 Jun 2017 23:59:45 -0400 Subject: IPv4 Hijacking For Idiots In-Reply-To: <91401.1496711094@segfault.tristatelogic.com> References: <91401.1496711094@segfault.tristatelogic.com> Message-ID: <14702.1496721585@turing-police.cc.vt.edu> On Mon, 05 Jun 2017 18:04:54 -0700, "Ronald F. Guilmette" said: > So you're saying that whichever criminal is behind this stuff, that he > maybe could have pulled it all off for the astounding and impressive > sum of zero dollars and zero cents ($0.00) ? > > (Well, I guess that's not quite accurate. I guess that he at least had > to pay for the cost of re-registering the wirelessnetbg.info domain name. Anybody who didn't just fall out of a tree will use a stolen but still functional credit card for that. So yeah, it's zero money out of their own pocket. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From rfg at tristatelogic.com Tue Jun 6 04:37:19 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 05 Jun 2017 21:37:19 -0700 Subject: IP Hijacking For Dummies In-Reply-To: Message-ID: <92211.1496723839@segfault.tristatelogic.com> In message Aftab Siddiqui wrote: >Same mobile number (+92-304-4000736 <+92%20304%204000736>) and address are >listed here for Blue Angel Hosting with only 1 peer AS206776. I noticed Blue Angel. I -didn't- notice that it had the same phone number as the other thing, host-offshore.com, which looks to me like a paper-mache mock up of a false front of a sham of a mockery of travesty of a sham. I am terrifically tempted, right at this moment, to engage in at least a couple of noteworthy feats of unbridled cultural disparagement, directed pointedly at the owners/operators of blueangelhost.com/host-offshore.com, but I am restrained by the knowledge that any such would serve only to sully my own already dubious reputation, such as it is. So I simply ask readers to imagine the kinds of verbal venom that I would point in that direction if the better angels of my nature did not, on this occaasion, prevail. Regards, rfg From hank at efes.iucc.ac.il Tue Jun 6 06:25:56 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 6 Jun 2017 09:25:56 +0300 Subject: IPv4 Hijacking For Idiots In-Reply-To: References: <88661.1496660174@segfault.tristatelogic.com> Message-ID: <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> On 06/06/2017 03:20, William Herrin wrote: Ronald, Here is how I would do it: 1. As you noted in your first email in this thread, find an abandoned ASN, lets call it AS12345, with a POC of support at acme.com 2. Create a domain called acme-corp.com and a user called peering 3. Contact an IX, preferably not one in a Westernized, clueful area: https://en.wikipedia.org/wiki/List_of_Internet_exchange_points 4. Using peering at acme-corp.com, state that you are AS12345 and you wish to join their wonderful IXP and to bring you router to their IXP for peering purposes and to pay full membership dues. 5. In general, not much due diligence will be done, since all Acme is requesting is to colo their router in the same room/floor/building as the IX and the IX is always trying to increase membership. Not every IX in the world is as diligent as LINX (example): https://www.linx.net/join-linx/joining-procedure 6. In the event the IX does ask for some documentation, create a logo, forge a few documents, create a nice corporate landing page with the logo, etc. Remember, the ASN hijacker will have done their homework and shy away from clueful IXs. 7. Pay your membership, bring your router to the IX and install it 8. IX announces to all members about the existence of a new IX member. 9. Major/large peers will shy away from small unknown ASNs, but there are always many smaller IX members who are willing to peer with you simply by sending them an email. 10. Of the 56 IX members at clueless IX, 18 have peered with you within a week and you have established your bona-fides. You are now in your way to growing your business :-) Regards, Hank > On Mon, Jun 5, 2017 at 6:56 AM, Ronald F. Guilmette > wrote: > >> So, I guess then, if you're clever, you look and see who the ASN you've >> just successfully hijacked has historically peered with, and then you >> somehow arrange to send route announcements to those guys, right? >> (I'm talking about AS206776 and AS57344 here, BTW.) >> >> But see, this is where I get lost. I mean how do you push your route >> announcements to these guys? > > Hi Ron, > > You actually got lost a couple steps back. > > First, you want to control the POC emails for the IP addresses. Controlling > just the POC emails for the AS number won't do you any good. > > Let's say you have gained control of the POC emails for the IP address > block. Stay completely away from the historical BGP peers. They might know > the real registrant and get suspicious when you show up. Go to somebody > else, dummy up some letterhead for the purported registrant and write > yourself a letter authorizing the ISP to whom the letter is presented to > route those IP addresses. Explain that you're a networking contractor > working for the organization holding the registration and give them > adequate contact information for yourself: postal address, email, phone. > Not "1234 Main, box 30" but "1234 Main, Suite 30". Paid for with the > cash-bought debit card. You get the idea. > > Then you pay the ISP to connect you to the Internet and present your > letter. Until the inevitable complaints roll it, that's it: you have > control of those IP addresses. > > > >> (I don't actually know that much about >> how BGP actually works in practice, so please bear with me.) How do >> you know what IP address to send your announcements to? > > You don't. Even if the session wasn't disabled when the customer stopped > paying, you're not physically connected to the same network interface where > it was configured. This reasoning path is a dead end. > > > I've read article after article after article bemoanging the fact that >> "BGP isn't secure", > > They're talking about a different problem: ISPs are supposed to configure > end-user BGP sessions per BCP38 which limits which BGP announcements the > customer can make. Some ISPs are sloppy and incompetent and don't do this. > Unfortunately, once you're a level or two upstream the backbone ISP > actually can't do much to limit the BGP announcements because it's often > impractical to determine whether a block of IP addresses can legitimately > be announced from a given peer. > > Regards, > Bill Herrin > > > > From johnstong at westmancom.com Tue Jun 6 13:22:59 2017 From: johnstong at westmancom.com (Graham Johnston) Date: Tue, 6 Jun 2017 13:22:59 +0000 Subject: Templating/automating configuration Message-ID: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> Short of complete SDN, for those of you that have some degree of configuration templating and/or automation tools what is it that you run? I'm envisioning some sort of tool that let's me define template snippets of configuration and aids in their deployment to devices. I'm okay doing the heaving lifting in defining everything, I'm just looking for the tool that stitches it together and hopefully makes things a little less error prone for those who aren't as adept. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com From email at edylie.net Tue Jun 6 13:27:00 2017 From: email at edylie.net (Pui Edylie) Date: Tue, 6 Jun 2017 21:27:00 +0800 Subject: Templating/automating configuration In-Reply-To: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> Message-ID: <3f6cec0b-f904-141a-d535-4fd7cf0df76c@edylie.net> Hi, Take a look at Ansible https://www.ansible.com/ Our whole infra is automated using it and it is great! Regards, Edy On 6/6/2017 9:22 PM, Graham Johnston wrote: > Short of complete SDN, for those of you that have some degree of configuration templating and/or automation tools what is it that you run? I'm envisioning some sort of tool that let's me define template snippets of configuration and aids in their deployment to devices. I'm okay doing the heaving lifting in defining everything, I'm just looking for the tool that stitches it together and hopefully makes things a little less error prone for those who aren't as adept. > > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > > From nick at foobar.org Tue Jun 6 14:09:56 2017 From: nick at foobar.org (Nick Hilliard) Date: Tue, 06 Jun 2017 15:09:56 +0100 Subject: Templating/automating configuration In-Reply-To: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> Message-ID: <5936B7B4.8010508@foobar.org> Graham Johnston wrote: > Short of complete SDN, for those of you that have some degree of > configuration templating and/or automation tools what is it that you > run? I'm envisioning some sort of tool that let's me define template > snippets of configuration and aids in their deployment to devices. > I'm okay doing the heaving lifting in defining everything, I'm just > looking for the tool that stitches it together and hopefully makes > things a little less error prone for those who aren't as adept. you would probably want to look at napalm for something like this. It will back-end into ansible or more recently, salt stack. Nick From netfortius at gmail.com Tue Jun 6 14:23:36 2017 From: netfortius at gmail.com (Stefan) Date: Tue, 6 Jun 2017 09:23:36 -0500 Subject: Templating/automating configuration In-Reply-To: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> Message-ID: http://ipspace.net - search on everything ref network automation, under webinars. Ivan is among the best in analysis and consolidation of such info, and in documenting all options you may have. Once you see what he has to offer, and definitely not only in the network automation space, you may want to subscribe to all his webinars repository access. Regards, ***Stefan On Jun 6, 2017 8:24 AM, "Graham Johnston" wrote: > Short of complete SDN, for those of you that have some degree of > configuration templating and/or automation tools what is it that you run? > I'm envisioning some sort of tool that let's me define template snippets of > configuration and aids in their deployment to devices. I'm okay doing the > heaving lifting in defining everything, I'm just looking for the tool that > stitches it together and hopefully makes things a little less error prone > for those who aren't as adept. > > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > > From ESundberg at nitelusa.com Tue Jun 6 14:34:15 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Tue, 6 Jun 2017 14:34:15 +0000 Subject: Looking for Cisco ASR9000v feedback Message-ID: <495D0934DA46854A9CA758393724D5907557AEB7@NI-MAIL02.nii.ads> Does anyone have any experience with the Cisco 9000v? Looking for the pro's, con's, and the gotcha's of moving our 1G ports to the 9000V. ________________________________ 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. From tom at ninjabadger.net Tue Jun 6 14:53:17 2017 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 6 Jun 2017 15:53:17 +0100 Subject: Looking for Cisco ASR9000v feedback In-Reply-To: <495D0934DA46854A9CA758393724D5907557AEB7@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5907557AEB7@NI-MAIL02.nii.ads> Message-ID: On 06/06/17 15:34, Erik Sundberg wrote: > Looking for the pro's, con's, and the gotcha's of moving our 1G ports to the 9000V. The nV licenses for one. Talk about printing money. -- Tom From morrowc.lists at gmail.com Tue Jun 6 16:09:08 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Jun 2017 12:09:08 -0400 Subject: IPv4 Hijacking For Idiots In-Reply-To: <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> Message-ID: On Tue, Jun 6, 2017 at 2:25 AM, Hank Nussbacher wrote: (I think this is really Ron and Bill chatting, but some of the linkage got lost on the tubes) > > > > I've read article after article after article bemoanging the fact that > >> "BGP isn't secure", > > > > They're talking about a different problem: ISPs are supposed to configure > > end-user BGP sessions per BCP38 which limits which BGP announcements the > > customer can make. Some ISPs are sloppy and incompetent and don't do > this. > > Unfortunately, once you're a level or two upstream the backbone ISP > > actually can't do much to limit the BGP announcements because it's often > > impractical to determine whether a block of IP addresses can legitimately > > be announced from a given peer. > just a clarifying note: I don't think bcp38 talks about BGP at all, actually... I think bill is actually saying: "ISPs are supposed to configure bcp38 to filter TRAFFIC from their customers/peers and BGP filters to limit the scope of the customer routes sent/received" I don't think the filtering of customer prefixes/announcements is actually covered in a BCP though. From rsk at gsp.org Tue Jun 6 17:26:45 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 6 Jun 2017 13:26:45 -0400 Subject: IP Hijacking For Dummies In-Reply-To: <91149.1496706364@segfault.tristatelogic.com> References: <91149.1496706364@segfault.tristatelogic.com> Message-ID: <20170606172645.GA23015@gsp.org> On Mon, Jun 05, 2017 at 04:46:04PM -0700, Ronald F. Guilmette wrote: > It did also strike me as passing strange that this company has apparently > elected to not actually put its own web server, name servers, or mail > server anywhere within its own duly allocated IPv4 blocks. Out of curiosity, I ran a DNS scan against all of the /24's that you enumerated (thank you, by the way). I am also perplexed that a hosting company which has "sold out" of virtual servers seems to have precious few servers -- of any type -- represented in its DNS records. To save everyone else the trouble, I'm appending below all the results (1023) that did not result in NXDOMAIN or SERVFAIL (5121). Note in re the last dozen on the list: I believe "correo" translates to "post", in the sense of "mail", so those may well be (customer?) mail servers. ---rsk 168.176.194.11 palmi19411.palmira.unal.edu.co 168.176.194.12 palmi19412.palmira.unal.edu.co 168.176.194.13 palmi19413.palmira.unal.edu.co 168.176.194.14 palmi19414.palmira.unal.edu.co 168.176.194.15 palmi19415.palmira.unal.edu.co 168.176.194.16 palmi19416.palmira.unal.edu.co 168.176.194.17 palmi19417.palmira.unal.edu.co 168.176.194.18 palmi19418.palmira.unal.edu.co 168.176.194.19 palmi19419.palmira.unal.edu.co 168.176.194.20 palmi19420.palmira.unal.edu.co 168.176.194.21 palmi19421.palmira.unal.edu.co 168.176.194.22 palmi19422.palmira.unal.edu.co 168.176.194.23 palmi19423.palmira.unal.edu.co 168.176.194.24 palmi19424.palmira.unal.edu.co 168.176.194.25 palmi19425.palmira.unal.edu.co 168.176.194.26 palmi19426.palmira.unal.edu.co 168.176.194.27 palmi19427.palmira.unal.edu.co 168.176.194.28 palmi19428.palmira.unal.edu.co 168.176.194.29 palmi19429.palmira.unal.edu.co 168.176.194.30 palmi19430.palmira.unal.edu.co 168.176.194.31 palmi19431.palmira.unal.edu.co 168.176.194.32 palmi19432.palmira.unal.edu.co 168.176.194.33 palmi19433.palmira.unal.edu.co 168.176.194.34 palmi19434.palmira.unal.edu.co 168.176.194.35 palmi19435.palmira.unal.edu.co 168.176.194.36 palmi19436.palmira.unal.edu.co 168.176.194.37 palmi19437.palmira.unal.edu.co 168.176.194.38 palmi19438.palmira.unal.edu.co 168.176.194.39 palmi19439.palmira.unal.edu.co 168.176.194.40 palmi19440.palmira.unal.edu.co 168.176.194.41 palmi19441.palmira.unal.edu.co 168.176.194.42 palmi19442.palmira.unal.edu.co 168.176.194.43 palmi19443.palmira.unal.edu.co 168.176.194.44 palmi19444.palmira.unal.edu.co 168.176.194.45 palmi19445.palmira.unal.edu.co 168.176.194.46 palmi19446.palmira.unal.edu.co 168.176.194.47 palmi19447.palmira.unal.edu.co 168.176.194.48 palmi19448.palmira.unal.edu.co 168.176.194.49 palmi19449.palmira.unal.edu.co 168.176.194.50 palmi19450.palmira.unal.edu.co 168.176.194.51 palmi19451.palmira.unal.edu.co 168.176.194.52 palmi19452.palmira.unal.edu.co 168.176.194.53 palmi19453.palmira.unal.edu.co 168.176.194.54 palmi19454.palmira.unal.edu.co 168.176.194.55 palmi19455.palmira.unal.edu.co 168.176.194.56 palmi19456.palmira.unal.edu.co 168.176.194.57 palmi19457.palmira.unal.edu.co 168.176.194.58 palmi19458.palmira.unal.edu.co 168.176.194.59 palmi19459.palmira.unal.edu.co 168.176.194.60 palmi19460.palmira.unal.edu.co 168.176.194.61 palmi19461.palmira.unal.edu.co 168.176.194.62 palmi19462.palmira.unal.edu.co 168.176.194.63 palmi19463.palmira.unal.edu.co 168.176.194.64 palmi19464.palmira.unal.edu.co 168.176.194.65 palmi19465.palmira.unal.edu.co 168.176.194.66 palmi19466.palmira.unal.edu.co 168.176.194.67 palmi19467.palmira.unal.edu.co 168.176.194.68 palmi19468.palmira.unal.edu.co 168.176.194.69 palmi19469.palmira.unal.edu.co 168.176.194.70 palmi19470.palmira.unal.edu.co 168.176.194.71 palmi19471.palmira.unal.edu.co 168.176.194.72 palmi19472.palmira.unal.edu.co 168.176.194.73 palmi19473.palmira.unal.edu.co 168.176.194.74 palmi19474.palmira.unal.edu.co 168.176.194.75 palmi19475.palmira.unal.edu.co 168.176.194.76 palmi19476.palmira.unal.edu.co 168.176.194.77 palmi19477.palmira.unal.edu.co 168.176.194.78 palmi19478.palmira.unal.edu.co 168.176.194.79 palmi19479.palmira.unal.edu.co 168.176.194.80 palmi19480.palmira.unal.edu.co 168.176.194.81 palmi19481.palmira.unal.edu.co 168.176.194.82 palmi19482.palmira.unal.edu.co 168.176.194.83 palmi19483.palmira.unal.edu.co 168.176.194.84 palmi19484.palmira.unal.edu.co 168.176.194.85 palmi19485.palmira.unal.edu.co 168.176.194.86 palmi19486.palmira.unal.edu.co 168.176.194.87 palmi19487.palmira.unal.edu.co 168.176.194.88 palmi19488.palmira.unal.edu.co 168.176.194.89 palmi19489.palmira.unal.edu.co 168.176.194.90 palmi19490.palmira.unal.edu.co 168.176.194.91 palmi19491.palmira.unal.edu.co 168.176.194.92 palmi19492.palmira.unal.edu.co 168.176.194.93 palmi19493.palmira.unal.edu.co 168.176.194.94 palmi19494.palmira.unal.edu.co 168.176.194.95 palmi19495.palmira.unal.edu.co 168.176.194.96 palmi19496.palmira.unal.edu.co 168.176.194.97 palmi19497.palmira.unal.edu.co 168.176.194.98 palmi19498.palmira.unal.edu.co 168.176.194.99 palmi19499.palmira.unal.edu.co 168.176.194.100 palmi194100.palmira.unal.edu.co 168.176.194.101 palmi194101.palmira.unal.edu.co 168.176.194.102 palmi194102.palmira.unal.edu.co 168.176.194.103 palmi194103.palmira.unal.edu.co 168.176.194.104 palmi194104.palmira.unal.edu.co 168.176.194.105 palmi194105.palmira.unal.edu.co 168.176.194.106 palmi194106.palmira.unal.edu.co 168.176.194.107 palmi194107.palmira.unal.edu.co 168.176.194.108 palmi194108.palmira.unal.edu.co 168.176.194.109 palmi194109.palmira.unal.edu.co 168.176.194.110 palmi194110.palmira.unal.edu.co 168.176.194.111 palmi194111.palmira.unal.edu.co 168.176.194.112 palmi194112.palmira.unal.edu.co 168.176.194.113 palmi194113.palmira.unal.edu.co 168.176.194.114 palmi194114.palmira.unal.edu.co 168.176.194.115 palmi194115.palmira.unal.edu.co 168.176.194.116 palmi194116.palmira.unal.edu.co 168.176.194.117 palmi194117.palmira.unal.edu.co 168.176.194.118 palmi194118.palmira.unal.edu.co 168.176.194.119 palmi194119.palmira.unal.edu.co 168.176.194.120 palmi194120.palmira.unal.edu.co 168.176.194.121 palmi194121.palmira.unal.edu.co 168.176.194.122 palmi194122.palmira.unal.edu.co 168.176.194.123 palmi194123.palmira.unal.edu.co 168.176.194.124 palmi194124.palmira.unal.edu.co 168.176.194.125 palmi194125.palmira.unal.edu.co 168.176.194.126 palmi194126.palmira.unal.edu.co 168.176.194.127 palmi194127.palmira.unal.edu.co 168.176.194.128 palmi194128.palmira.unal.edu.co 168.176.194.129 palmi194129.palmira.unal.edu.co 168.176.194.130 palmi194130.palmira.unal.edu.co 168.176.194.131 palmi194131.palmira.unal.edu.co 168.176.194.132 palmi194132.palmira.unal.edu.co 168.176.194.133 palmi194133.palmira.unal.edu.co 168.176.194.134 palmi194134.palmira.unal.edu.co 168.176.194.135 palmi194135.palmira.unal.edu.co 168.176.194.136 palmi194136.palmira.unal.edu.co 168.176.194.137 palmi194137.palmira.unal.edu.co 168.176.194.138 palmi194138.palmira.unal.edu.co 168.176.194.139 palmi194139.palmira.unal.edu.co 168.176.194.140 palmi194140.palmira.unal.edu.co 168.176.194.141 palmi194141.palmira.unal.edu.co 168.176.194.142 palmi194142.palmira.unal.edu.co 168.176.194.143 palmi194143.palmira.unal.edu.co 168.176.194.144 palmi194144.palmira.unal.edu.co 168.176.194.145 palmi194145.palmira.unal.edu.co 168.176.194.146 palmi194146.palmira.unal.edu.co 168.176.194.147 palmi194147.palmira.unal.edu.co 168.176.194.148 palmi194148.palmira.unal.edu.co 168.176.194.149 palmi194149.palmira.unal.edu.co 168.176.194.150 palmi194150.palmira.unal.edu.co 168.176.194.151 palmi194151.palmira.unal.edu.co 168.176.194.152 palmi194152.palmira.unal.edu.co 168.176.194.153 palmi194153.palmira.unal.edu.co 168.176.194.154 palmi194154.palmira.unal.edu.co 168.176.194.155 palmi194155.palmira.unal.edu.co 168.176.194.156 palmi194156.palmira.unal.edu.co 168.176.194.157 palmi194157.palmira.unal.edu.co 168.176.194.158 palmi194158.palmira.unal.edu.co 168.176.194.159 palmi194159.palmira.unal.edu.co 168.176.194.160 palmi194160.palmira.unal.edu.co 168.176.194.161 palmi194161.palmira.unal.edu.co 168.176.194.162 palmi194162.palmira.unal.edu.co 168.176.194.163 palmi194163.palmira.unal.edu.co 168.176.194.164 palmi194164.palmira.unal.edu.co 168.176.194.165 palmi194165.palmira.unal.edu.co 168.176.194.166 palmi194166.palmira.unal.edu.co 168.176.194.167 palmi194167.palmira.unal.edu.co 168.176.194.168 palmi194168.palmira.unal.edu.co 168.176.194.169 palmi194169.palmira.unal.edu.co 168.176.194.170 palmi194170.palmira.unal.edu.co 168.176.194.171 palmi194171.palmira.unal.edu.co 168.176.194.172 palmi194172.palmira.unal.edu.co 168.176.194.173 palmi194173.palmira.unal.edu.co 168.176.194.174 palmi194174.palmira.unal.edu.co 168.176.194.175 palmi194175.palmira.unal.edu.co 168.176.194.176 palmi194176.palmira.unal.edu.co 168.176.194.177 palmi194177.palmira.unal.edu.co 168.176.194.178 palmi194178.palmira.unal.edu.co 168.176.194.179 palmi194179.palmira.unal.edu.co 168.176.194.180 palmi194180.palmira.unal.edu.co 168.176.194.181 palmi194181.palmira.unal.edu.co 168.176.194.182 palmi194182.palmira.unal.edu.co 168.176.194.183 palmi194183.palmira.unal.edu.co 168.176.194.184 palmi194184.palmira.unal.edu.co 168.176.194.185 palmi194185.palmira.unal.edu.co 168.176.194.186 palmi194186.palmira.unal.edu.co 168.176.194.187 palmi194187.palmira.unal.edu.co 168.176.194.188 palmi194188.palmira.unal.edu.co 168.176.194.189 palmi194189.palmira.unal.edu.co 168.176.194.190 palmi194190.palmira.unal.edu.co 168.176.194.191 palmi194191.palmira.unal.edu.co 168.176.194.192 palmi194192.palmira.unal.edu.co 168.176.194.193 palmi194193.palmira.unal.edu.co 168.176.194.194 palmi194194.palmira.unal.edu.co 168.176.194.195 palmi194195.palmira.unal.edu.co 168.176.194.196 palmi194196.palmira.unal.edu.co 168.176.194.197 palmi194197.palmira.unal.edu.co 168.176.194.198 palmi194198.palmira.unal.edu.co 168.176.194.199 palmi194199.palmira.unal.edu.co 168.176.194.200 palmi194200.palmira.unal.edu.co 168.176.194.201 palmi194201.palmira.unal.edu.co 168.176.194.202 palmi194202.palmira.unal.edu.co 168.176.194.203 palmi194203.palmira.unal.edu.co 168.176.194.204 palmi194204.palmira.unal.edu.co 168.176.194.205 palmi194205.palmira.unal.edu.co 168.176.194.206 palmi194206.palmira.unal.edu.co 168.176.194.207 palmi194207.palmira.unal.edu.co 168.176.194.208 palmi194208.palmira.unal.edu.co 168.176.194.209 palmi194209.palmira.unal.edu.co 168.176.194.210 palmi194210.palmira.unal.edu.co 168.176.194.211 palmi194211.palmira.unal.edu.co 168.176.194.212 palmi194212.palmira.unal.edu.co 168.176.194.213 palmi194213.palmira.unal.edu.co 168.176.194.214 palmi194214.palmira.unal.edu.co 168.176.194.215 palmi194215.palmira.unal.edu.co 168.176.194.216 palmi194216.palmira.unal.edu.co 168.176.194.217 palmi194217.palmira.unal.edu.co 168.176.194.218 palmi194218.palmira.unal.edu.co 168.176.194.219 palmi194219.palmira.unal.edu.co 168.176.194.220 palmi194220.palmira.unal.edu.co 168.176.194.221 palmi194221.palmira.unal.edu.co 168.176.194.222 palmi194222.palmira.unal.edu.co 168.176.194.223 palmi194223.palmira.unal.edu.co 168.176.194.224 palmi194224.palmira.unal.edu.co 168.176.194.225 palmi194225.palmira.unal.edu.co 168.176.194.226 palmi194226.palmira.unal.edu.co 168.176.194.227 palmi194227.palmira.unal.edu.co 168.176.194.228 palmi194228.palmira.unal.edu.co 168.176.194.229 palmi194229.palmira.unal.edu.co 168.176.194.230 palmi194230.palmira.unal.edu.co 168.176.194.231 palmi194231.palmira.unal.edu.co 168.176.194.232 palmi194232.palmira.unal.edu.co 168.176.194.233 palmi194233.palmira.unal.edu.co 168.176.194.234 palmi194234.palmira.unal.edu.co 168.176.194.235 palmi194235.palmira.unal.edu.co 168.176.194.236 palmi194236.palmira.unal.edu.co 168.176.194.237 palmi194237.palmira.unal.edu.co 168.176.194.238 palmi194238.palmira.unal.edu.co 168.176.194.239 palmi194239.palmira.unal.edu.co 168.176.194.240 palmi194240.palmira.unal.edu.co 168.176.194.241 palmi194241.palmira.unal.edu.co 168.176.194.242 palmi194242.palmira.unal.edu.co 168.176.194.243 palmi194243.palmira.unal.edu.co 168.176.194.244 palmi194244.palmira.unal.edu.co 168.176.194.245 palmi194245.palmira.unal.edu.co 168.176.194.246 palmi194246.palmira.unal.edu.co 168.176.194.247 palmi194247.palmira.unal.edu.co 168.176.194.248 palmi194248.palmira.unal.edu.co 168.176.194.249 palmi194249.palmira.unal.edu.co 168.176.194.250 palmi194250.palmira.unal.edu.co 168.176.194.251 palmi194251.palmira.unal.edu.co 168.176.194.252 palmi194252.palmira.unal.edu.co 168.176.194.253 palmi194253.palmira.unal.edu.co 168.176.194.254 palmi194254.palmira.unal.edu.co 181.57.40.0 static-ip-18157400.cable.net.co 181.57.40.1 static-ip-18157401.cable.net.co 181.57.40.2 static-ip-18157402.cable.net.co 181.57.40.3 static-ip-18157403.cable.net.co 181.57.40.4 static-ip-18157404.cable.net.co 181.57.40.5 static-ip-18157405.cable.net.co 181.57.40.6 static-ip-18157406.cable.net.co 181.57.40.7 static-ip-18157407.cable.net.co 181.57.40.8 static-ip-18157408.cable.net.co 181.57.40.9 static-ip-18157409.cable.net.co 181.57.40.10 static-ip-181574010.cable.net.co 181.57.40.11 static-ip-181574011.cable.net.co 181.57.40.12 static-ip-181574012.cable.net.co 181.57.40.13 static-ip-181574013.cable.net.co 181.57.40.14 static-ip-181574014.cable.net.co 181.57.40.15 static-ip-181574015.cable.net.co 181.57.40.16 static-ip-181574016.cable.net.co 181.57.40.17 static-ip-181574017.cable.net.co 181.57.40.18 static-ip-181574018.cable.net.co 181.57.40.19 static-ip-181574019.cable.net.co 181.57.40.20 static-ip-181574020.cable.net.co 181.57.40.21 static-ip-181574021.cable.net.co 181.57.40.22 static-ip-181574022.cable.net.co 181.57.40.23 static-ip-181574023.cable.net.co 181.57.40.24 static-ip-181574024.cable.net.co 181.57.40.25 static-ip-181574025.cable.net.co 181.57.40.26 static-ip-181574026.cable.net.co 181.57.40.27 static-ip-181574027.cable.net.co 181.57.40.28 static-ip-181574028.cable.net.co 181.57.40.29 static-ip-181574029.cable.net.co 181.57.40.30 static-ip-181574030.cable.net.co 181.57.40.31 static-ip-181574031.cable.net.co 181.57.40.32 static-ip-181574032.cable.net.co 181.57.40.33 static-ip-181574033.cable.net.co 181.57.40.34 static-ip-181574034.cable.net.co 181.57.40.35 static-ip-181574035.cable.net.co 181.57.40.36 static-ip-181574036.cable.net.co 181.57.40.37 static-ip-181574037.cable.net.co 181.57.40.38 static-ip-181574038.cable.net.co 181.57.40.39 static-ip-181574039.cable.net.co 181.57.40.40 static-ip-181574040.cable.net.co 181.57.40.41 static-ip-181574041.cable.net.co 181.57.40.42 static-ip-181574042.cable.net.co 181.57.40.43 static-ip-181574043.cable.net.co 181.57.40.44 static-ip-181574044.cable.net.co 181.57.40.45 static-ip-181574045.cable.net.co 181.57.40.46 static-ip-181574046.cable.net.co 181.57.40.47 static-ip-181574047.cable.net.co 181.57.40.48 static-ip-181574048.cable.net.co 181.57.40.49 static-ip-181574049.cable.net.co 181.57.40.50 static-ip-181574050.cable.net.co 181.57.40.51 static-ip-181574051.cable.net.co 181.57.40.52 static-ip-181574052.cable.net.co 181.57.40.53 static-ip-181574053.cable.net.co 181.57.40.54 static-ip-181574054.cable.net.co 181.57.40.55 static-ip-181574055.cable.net.co 181.57.40.56 static-ip-181574056.cable.net.co 181.57.40.57 static-ip-181574057.cable.net.co 181.57.40.58 static-ip-181574058.cable.net.co 181.57.40.59 static-ip-181574059.cable.net.co 181.57.40.60 static-ip-181574060.cable.net.co 181.57.40.61 static-ip-181574061.cable.net.co 181.57.40.62 static-ip-181574062.cable.net.co 181.57.40.63 static-ip-181574063.cable.net.co 181.57.40.64 static-ip-181574064.cable.net.co 181.57.40.65 static-ip-181574065.cable.net.co 181.57.40.66 static-ip-181574066.cable.net.co 181.57.40.67 static-ip-181574067.cable.net.co 181.57.40.68 static-ip-181574068.cable.net.co 181.57.40.69 static-ip-181574069.cable.net.co 181.57.40.70 static-ip-181574070.cable.net.co 181.57.40.71 static-ip-181574071.cable.net.co 181.57.40.72 static-ip-181574072.cable.net.co 181.57.40.73 static-ip-181574073.cable.net.co 181.57.40.74 static-ip-181574074.cable.net.co 181.57.40.75 static-ip-181574075.cable.net.co 181.57.40.76 static-ip-181574076.cable.net.co 181.57.40.77 static-ip-181574077.cable.net.co 181.57.40.78 static-ip-181574078.cable.net.co 181.57.40.79 static-ip-181574079.cable.net.co 181.57.40.80 static-ip-181574080.cable.net.co 181.57.40.81 static-ip-181574081.cable.net.co 181.57.40.82 static-ip-181574082.cable.net.co 181.57.40.83 static-ip-181574083.cable.net.co 181.57.40.84 static-ip-181574084.cable.net.co 181.57.40.85 static-ip-181574085.cable.net.co 181.57.40.86 static-ip-181574086.cable.net.co 181.57.40.87 static-ip-181574087.cable.net.co 181.57.40.88 static-ip-181574088.cable.net.co 181.57.40.89 static-ip-181574089.cable.net.co 181.57.40.90 static-ip-181574090.cable.net.co 181.57.40.91 static-ip-181574091.cable.net.co 181.57.40.92 static-ip-181574092.cable.net.co 181.57.40.93 static-ip-181574093.cable.net.co 181.57.40.94 static-ip-181574094.cable.net.co 181.57.40.95 static-ip-181574095.cable.net.co 181.57.40.96 static-ip-181574096.cable.net.co 181.57.40.97 static-ip-181574097.cable.net.co 181.57.40.98 static-ip-181574098.cable.net.co 181.57.40.99 static-ip-181574099.cable.net.co 181.57.40.100 static-ip-1815740100.cable.net.co 181.57.40.101 static-ip-1815740101.cable.net.co 181.57.40.102 static-ip-1815740102.cable.net.co 181.57.40.103 static-ip-1815740103.cable.net.co 181.57.40.104 static-ip-1815740104.cable.net.co 181.57.40.105 static-ip-1815740105.cable.net.co 181.57.40.106 static-ip-1815740106.cable.net.co 181.57.40.107 static-ip-1815740107.cable.net.co 181.57.40.108 static-ip-1815740108.cable.net.co 181.57.40.109 static-ip-1815740109.cable.net.co 181.57.40.110 static-ip-1815740110.cable.net.co 181.57.40.111 static-ip-1815740111.cable.net.co 181.57.40.112 static-ip-1815740112.cable.net.co 181.57.40.113 static-ip-1815740113.cable.net.co 181.57.40.114 static-ip-1815740114.cable.net.co 181.57.40.115 static-ip-1815740115.cable.net.co 181.57.40.116 static-ip-1815740116.cable.net.co 181.57.40.117 static-ip-1815740117.cable.net.co 181.57.40.118 static-ip-1815740118.cable.net.co 181.57.40.119 static-ip-1815740119.cable.net.co 181.57.40.120 static-ip-1815740120.cable.net.co 181.57.40.121 static-ip-1815740121.cable.net.co 181.57.40.122 static-ip-1815740122.cable.net.co 181.57.40.123 static-ip-1815740123.cable.net.co 181.57.40.124 static-ip-1815740124.cable.net.co 181.57.40.125 static-ip-1815740125.cable.net.co 181.57.40.126 static-ip-1815740126.cable.net.co 181.57.40.127 static-ip-1815740127.cable.net.co 181.57.40.128 static-ip-1815740128.cable.net.co 181.57.40.129 static-ip-1815740129.cable.net.co 181.57.40.130 static-ip-1815740130.cable.net.co 181.57.40.131 static-ip-1815740131.cable.net.co 181.57.40.132 static-ip-1815740132.cable.net.co 181.57.40.133 static-ip-1815740133.cable.net.co 181.57.40.134 static-ip-1815740134.cable.net.co 181.57.40.135 static-ip-1815740135.cable.net.co 181.57.40.136 static-ip-1815740136.cable.net.co 181.57.40.137 static-ip-1815740137.cable.net.co 181.57.40.138 static-ip-1815740138.cable.net.co 181.57.40.139 static-ip-1815740139.cable.net.co 181.57.40.140 static-ip-1815740140.cable.net.co 181.57.40.141 static-ip-1815740141.cable.net.co 181.57.40.142 static-ip-1815740142.cable.net.co 181.57.40.143 static-ip-1815740143.cable.net.co 181.57.40.144 static-ip-1815740144.cable.net.co 181.57.40.145 static-ip-1815740145.cable.net.co 181.57.40.146 static-ip-1815740146.cable.net.co 181.57.40.147 static-ip-1815740147.cable.net.co 181.57.40.148 static-ip-1815740148.cable.net.co 181.57.40.149 static-ip-1815740149.cable.net.co 181.57.40.150 static-ip-1815740150.cable.net.co 181.57.40.151 static-ip-1815740151.cable.net.co 181.57.40.152 static-ip-1815740152.cable.net.co 181.57.40.153 static-ip-1815740153.cable.net.co 181.57.40.154 static-ip-1815740154.cable.net.co 181.57.40.155 static-ip-1815740155.cable.net.co 181.57.40.156 static-ip-1815740156.cable.net.co 181.57.40.157 static-ip-1815740157.cable.net.co 181.57.40.158 static-ip-1815740158.cable.net.co 181.57.40.159 static-ip-1815740159.cable.net.co 181.57.40.160 static-ip-1815740160.cable.net.co 181.57.40.161 static-ip-1815740161.cable.net.co 181.57.40.162 static-ip-1815740162.cable.net.co 181.57.40.163 static-ip-1815740163.cable.net.co 181.57.40.164 static-ip-1815740164.cable.net.co 181.57.40.165 static-ip-1815740165.cable.net.co 181.57.40.166 static-ip-1815740166.cable.net.co 181.57.40.167 static-ip-1815740167.cable.net.co 181.57.40.168 static-ip-1815740168.cable.net.co 181.57.40.169 static-ip-1815740169.cable.net.co 181.57.40.170 static-ip-1815740170.cable.net.co 181.57.40.171 static-ip-1815740171.cable.net.co 181.57.40.172 static-ip-1815740172.cable.net.co 181.57.40.173 static-ip-1815740173.cable.net.co 181.57.40.174 static-ip-1815740174.cable.net.co 181.57.40.175 static-ip-1815740175.cable.net.co 181.57.40.176 static-ip-1815740176.cable.net.co 181.57.40.177 static-ip-1815740177.cable.net.co 181.57.40.178 static-ip-1815740178.cable.net.co 181.57.40.179 static-ip-1815740179.cable.net.co 181.57.40.180 static-ip-1815740180.cable.net.co 181.57.40.181 static-ip-1815740181.cable.net.co 181.57.40.182 static-ip-1815740182.cable.net.co 181.57.40.183 static-ip-1815740183.cable.net.co 181.57.40.184 static-ip-1815740184.cable.net.co 181.57.40.185 static-ip-1815740185.cable.net.co 181.57.40.186 static-ip-1815740186.cable.net.co 181.57.40.187 static-ip-1815740187.cable.net.co 181.57.40.188 static-ip-1815740188.cable.net.co 181.57.40.189 static-ip-1815740189.cable.net.co 181.57.40.190 static-ip-1815740190.cable.net.co 181.57.40.191 static-ip-1815740191.cable.net.co 181.57.40.192 static-ip-1815740192.cable.net.co 181.57.40.193 static-ip-1815740193.cable.net.co 181.57.40.194 static-ip-1815740194.cable.net.co 181.57.40.195 static-ip-1815740195.cable.net.co 181.57.40.196 static-ip-1815740196.cable.net.co 181.57.40.197 static-ip-1815740197.cable.net.co 181.57.40.198 static-ip-1815740198.cable.net.co 181.57.40.199 static-ip-1815740199.cable.net.co 181.57.40.200 static-ip-1815740200.cable.net.co 181.57.40.201 static-ip-1815740201.cable.net.co 181.57.40.202 static-ip-1815740202.cable.net.co 181.57.40.203 static-ip-1815740203.cable.net.co 181.57.40.204 static-ip-1815740204.cable.net.co 181.57.40.205 static-ip-1815740205.cable.net.co 181.57.40.206 static-ip-1815740206.cable.net.co 181.57.40.207 static-ip-1815740207.cable.net.co 181.57.40.208 static-ip-1815740208.cable.net.co 181.57.40.209 static-ip-1815740209.cable.net.co 181.57.40.210 static-ip-1815740210.cable.net.co 181.57.40.211 static-ip-1815740211.cable.net.co 181.57.40.212 static-ip-1815740212.cable.net.co 181.57.40.213 static-ip-1815740213.cable.net.co 181.57.40.214 static-ip-1815740214.cable.net.co 181.57.40.215 static-ip-1815740215.cable.net.co 181.57.40.216 static-ip-1815740216.cable.net.co 181.57.40.217 static-ip-1815740217.cable.net.co 181.57.40.218 static-ip-1815740218.cable.net.co 181.57.40.219 static-ip-1815740219.cable.net.co 181.57.40.220 static-ip-1815740220.cable.net.co 181.57.40.221 static-ip-1815740221.cable.net.co 181.57.40.222 static-ip-1815740222.cable.net.co 181.57.40.223 static-ip-1815740223.cable.net.co 181.57.40.224 static-ip-1815740224.cable.net.co 181.57.40.225 static-ip-1815740225.cable.net.co 181.57.40.226 static-ip-1815740226.cable.net.co 181.57.40.227 static-ip-1815740227.cable.net.co 181.57.40.228 static-ip-1815740228.cable.net.co 181.57.40.229 static-ip-1815740229.cable.net.co 181.57.40.230 static-ip-1815740230.cable.net.co 181.57.40.231 static-ip-1815740231.cable.net.co 181.57.40.232 static-ip-1815740232.cable.net.co 181.57.40.233 static-ip-1815740233.cable.net.co 181.57.40.234 static-ip-1815740234.cable.net.co 181.57.40.235 static-ip-1815740235.cable.net.co 181.57.40.236 static-ip-1815740236.cable.net.co 181.57.40.237 static-ip-1815740237.cable.net.co 181.57.40.238 static-ip-1815740238.cable.net.co 181.57.40.239 static-ip-1815740239.cable.net.co 181.57.40.240 static-ip-1815740240.cable.net.co 181.57.40.241 static-ip-1815740241.cable.net.co 181.57.40.242 static-ip-1815740242.cable.net.co 181.57.40.243 static-ip-1815740243.cable.net.co 181.57.40.244 static-ip-1815740244.cable.net.co 181.57.40.245 static-ip-1815740245.cable.net.co 181.57.40.246 static-ip-1815740246.cable.net.co 181.57.40.247 static-ip-1815740247.cable.net.co 181.57.40.248 static-ip-1815740248.cable.net.co 181.57.40.249 static-ip-1815740249.cable.net.co 181.57.40.250 static-ip-1815740250.cable.net.co 181.57.40.251 static-ip-1815740251.cable.net.co 181.57.40.252 static-ip-1815740252.cable.net.co 181.57.40.253 static-ip-1815740253.cable.net.co 181.57.40.254 static-ip-1815740254.cable.net.co 181.57.40.255 static-ip-1815740255.cable.net.co 186.147.230.0 static-ip-1861472300.cable.net.co 186.147.230.1 static-ip-1861472301.cable.net.co 186.147.230.2 static-ip-1861472302.cable.net.co 186.147.230.3 static-ip-1861472303.cable.net.co 186.147.230.4 static-ip-1861472304.cable.net.co 186.147.230.5 static-ip-1861472305.cable.net.co 186.147.230.6 static-ip-1861472306.cable.net.co 186.147.230.7 static-ip-1861472307.cable.net.co 186.147.230.8 static-ip-1861472308.cable.net.co 186.147.230.9 static-ip-1861472309.cable.net.co 186.147.230.10 static-ip-18614723010.cable.net.co 186.147.230.11 static-ip-18614723011.cable.net.co 186.147.230.12 static-ip-18614723012.cable.net.co 186.147.230.13 static-ip-18614723013.cable.net.co 186.147.230.14 static-ip-18614723014.cable.net.co 186.147.230.15 static-ip-18614723015.cable.net.co 186.147.230.16 static-ip-18614723016.cable.net.co 186.147.230.17 static-ip-18614723017.cable.net.co 186.147.230.18 static-ip-18614723018.cable.net.co 186.147.230.19 static-ip-18614723019.cable.net.co 186.147.230.20 static-ip-18614723020.cable.net.co 186.147.230.21 static-ip-18614723021.cable.net.co 186.147.230.22 static-ip-18614723022.cable.net.co 186.147.230.23 static-ip-18614723023.cable.net.co 186.147.230.24 static-ip-18614723024.cable.net.co 186.147.230.25 static-ip-18614723025.cable.net.co 186.147.230.26 static-ip-18614723026.cable.net.co 186.147.230.27 static-ip-18614723027.cable.net.co 186.147.230.28 static-ip-18614723028.cable.net.co 186.147.230.29 static-ip-18614723029.cable.net.co 186.147.230.30 static-ip-18614723030.cable.net.co 186.147.230.31 static-ip-18614723031.cable.net.co 186.147.230.32 static-ip-18614723032.cable.net.co 186.147.230.33 static-ip-18614723033.cable.net.co 186.147.230.34 static-ip-18614723034.cable.net.co 186.147.230.35 static-ip-18614723035.cable.net.co 186.147.230.36 static-ip-18614723036.cable.net.co 186.147.230.37 static-ip-18614723037.cable.net.co 186.147.230.38 static-ip-18614723038.cable.net.co 186.147.230.39 static-ip-18614723039.cable.net.co 186.147.230.40 static-ip-18614723040.cable.net.co 186.147.230.41 static-ip-18614723041.cable.net.co 186.147.230.42 static-ip-18614723042.cable.net.co 186.147.230.43 static-ip-18614723043.cable.net.co 186.147.230.44 static-ip-18614723044.cable.net.co 186.147.230.45 static-ip-18614723045.cable.net.co 186.147.230.46 static-ip-18614723046.cable.net.co 186.147.230.47 static-ip-18614723047.cable.net.co 186.147.230.48 static-ip-18614723048.cable.net.co 186.147.230.49 static-ip-18614723049.cable.net.co 186.147.230.50 static-ip-18614723050.cable.net.co 186.147.230.51 static-ip-18614723051.cable.net.co 186.147.230.52 static-ip-18614723052.cable.net.co 186.147.230.53 static-ip-18614723053.cable.net.co 186.147.230.54 static-ip-18614723054.cable.net.co 186.147.230.55 static-ip-18614723055.cable.net.co 186.147.230.56 static-ip-18614723056.cable.net.co 186.147.230.57 static-ip-18614723057.cable.net.co 186.147.230.58 static-ip-18614723058.cable.net.co 186.147.230.59 static-ip-18614723059.cable.net.co 186.147.230.60 static-ip-18614723060.cable.net.co 186.147.230.61 static-ip-18614723061.cable.net.co 186.147.230.62 static-ip-18614723062.cable.net.co 186.147.230.63 static-ip-18614723063.cable.net.co 186.147.230.64 static-ip-18614723064.cable.net.co 186.147.230.65 static-ip-18614723065.cable.net.co 186.147.230.66 static-ip-18614723066.cable.net.co 186.147.230.67 static-ip-18614723067.cable.net.co 186.147.230.68 static-ip-18614723068.cable.net.co 186.147.230.69 static-ip-18614723069.cable.net.co 186.147.230.70 static-ip-18614723070.cable.net.co 186.147.230.71 static-ip-18614723071.cable.net.co 186.147.230.72 static-ip-18614723072.cable.net.co 186.147.230.73 static-ip-18614723073.cable.net.co 186.147.230.74 static-ip-18614723074.cable.net.co 186.147.230.75 static-ip-18614723075.cable.net.co 186.147.230.76 static-ip-18614723076.cable.net.co 186.147.230.77 static-ip-18614723077.cable.net.co 186.147.230.78 static-ip-18614723078.cable.net.co 186.147.230.79 static-ip-18614723079.cable.net.co 186.147.230.80 static-ip-18614723080.cable.net.co 186.147.230.81 static-ip-18614723081.cable.net.co 186.147.230.82 static-ip-18614723082.cable.net.co 186.147.230.83 static-ip-18614723083.cable.net.co 186.147.230.84 static-ip-18614723084.cable.net.co 186.147.230.85 static-ip-18614723085.cable.net.co 186.147.230.86 static-ip-18614723086.cable.net.co 186.147.230.87 static-ip-18614723087.cable.net.co 186.147.230.88 static-ip-18614723088.cable.net.co 186.147.230.89 static-ip-18614723089.cable.net.co 186.147.230.90 static-ip-18614723090.cable.net.co 186.147.230.91 static-ip-18614723091.cable.net.co 186.147.230.92 static-ip-18614723092.cable.net.co 186.147.230.93 static-ip-18614723093.cable.net.co 186.147.230.94 static-ip-18614723094.cable.net.co 186.147.230.95 static-ip-18614723095.cable.net.co 186.147.230.96 static-ip-18614723096.cable.net.co 186.147.230.97 static-ip-18614723097.cable.net.co 186.147.230.98 static-ip-18614723098.cable.net.co 186.147.230.99 static-ip-18614723099.cable.net.co 186.147.230.100 static-ip-186147230100.cable.net.co 186.147.230.101 static-ip-186147230101.cable.net.co 186.147.230.102 static-ip-186147230102.cable.net.co 186.147.230.103 static-ip-186147230103.cable.net.co 186.147.230.104 static-ip-186147230104.cable.net.co 186.147.230.105 static-ip-186147230105.cable.net.co 186.147.230.106 static-ip-186147230106.cable.net.co 186.147.230.107 static-ip-186147230107.cable.net.co 186.147.230.108 static-ip-186147230108.cable.net.co 186.147.230.109 static-ip-186147230109.cable.net.co 186.147.230.110 static-ip-186147230110.cable.net.co 186.147.230.111 static-ip-186147230111.cable.net.co 186.147.230.112 static-ip-186147230112.cable.net.co 186.147.230.113 static-ip-186147230113.cable.net.co 186.147.230.114 static-ip-186147230114.cable.net.co 186.147.230.115 static-ip-186147230115.cable.net.co 186.147.230.116 static-ip-186147230116.cable.net.co 186.147.230.117 static-ip-186147230117.cable.net.co 186.147.230.118 static-ip-186147230118.cable.net.co 186.147.230.119 static-ip-186147230119.cable.net.co 186.147.230.120 static-ip-186147230120.cable.net.co 186.147.230.121 static-ip-186147230121.cable.net.co 186.147.230.122 static-ip-186147230122.cable.net.co 186.147.230.123 static-ip-186147230123.cable.net.co 186.147.230.124 static-ip-186147230124.cable.net.co 186.147.230.125 static-ip-186147230125.cable.net.co 186.147.230.126 static-ip-186147230126.cable.net.co 186.147.230.127 static-ip-186147230127.cable.net.co 186.147.230.128 static-ip-186147230128.cable.net.co 186.147.230.129 static-ip-186147230129.cable.net.co 186.147.230.130 static-ip-186147230130.cable.net.co 186.147.230.131 static-ip-186147230131.cable.net.co 186.147.230.132 static-ip-186147230132.cable.net.co 186.147.230.133 static-ip-186147230133.cable.net.co 186.147.230.134 static-ip-186147230134.cable.net.co 186.147.230.135 static-ip-186147230135.cable.net.co 186.147.230.136 static-ip-186147230136.cable.net.co 186.147.230.137 static-ip-186147230137.cable.net.co 186.147.230.138 static-ip-186147230138.cable.net.co 186.147.230.139 static-ip-186147230139.cable.net.co 186.147.230.140 static-ip-186147230140.cable.net.co 186.147.230.141 static-ip-186147230141.cable.net.co 186.147.230.142 static-ip-186147230142.cable.net.co 186.147.230.143 static-ip-186147230143.cable.net.co 186.147.230.144 static-ip-186147230144.cable.net.co 186.147.230.145 static-ip-186147230145.cable.net.co 186.147.230.146 static-ip-186147230146.cable.net.co 186.147.230.147 static-ip-186147230147.cable.net.co 186.147.230.148 static-ip-186147230148.cable.net.co 186.147.230.149 static-ip-186147230149.cable.net.co 186.147.230.150 static-ip-186147230150.cable.net.co 186.147.230.151 static-ip-186147230151.cable.net.co 186.147.230.152 static-ip-186147230152.cable.net.co 186.147.230.153 static-ip-186147230153.cable.net.co 186.147.230.154 static-ip-186147230154.cable.net.co 186.147.230.155 static-ip-186147230155.cable.net.co 186.147.230.156 static-ip-186147230156.cable.net.co 186.147.230.157 static-ip-186147230157.cable.net.co 186.147.230.158 static-ip-186147230158.cable.net.co 186.147.230.159 static-ip-186147230159.cable.net.co 186.147.230.160 static-ip-186147230160.cable.net.co 186.147.230.161 static-ip-186147230161.cable.net.co 186.147.230.162 static-ip-186147230162.cable.net.co 186.147.230.163 static-ip-186147230163.cable.net.co 186.147.230.164 static-ip-186147230164.cable.net.co 186.147.230.165 static-ip-186147230165.cable.net.co 186.147.230.166 static-ip-186147230166.cable.net.co 186.147.230.167 static-ip-186147230167.cable.net.co 186.147.230.168 static-ip-186147230168.cable.net.co 186.147.230.169 static-ip-186147230169.cable.net.co 186.147.230.170 static-ip-186147230170.cable.net.co 186.147.230.171 static-ip-186147230171.cable.net.co 186.147.230.172 static-ip-186147230172.cable.net.co 186.147.230.173 static-ip-186147230173.cable.net.co 186.147.230.174 static-ip-186147230174.cable.net.co 186.147.230.175 static-ip-186147230175.cable.net.co 186.147.230.176 static-ip-186147230176.cable.net.co 186.147.230.177 static-ip-186147230177.cable.net.co 186.147.230.178 static-ip-186147230178.cable.net.co 186.147.230.179 static-ip-186147230179.cable.net.co 186.147.230.180 static-ip-186147230180.cable.net.co 186.147.230.181 static-ip-186147230181.cable.net.co 186.147.230.182 static-ip-186147230182.cable.net.co 186.147.230.183 static-ip-186147230183.cable.net.co 186.147.230.184 static-ip-186147230184.cable.net.co 186.147.230.185 static-ip-186147230185.cable.net.co 186.147.230.186 static-ip-186147230186.cable.net.co 186.147.230.187 static-ip-186147230187.cable.net.co 186.147.230.188 static-ip-186147230188.cable.net.co 186.147.230.189 static-ip-186147230189.cable.net.co 186.147.230.190 static-ip-186147230190.cable.net.co 186.147.230.191 static-ip-186147230191.cable.net.co 186.147.230.192 static-ip-186147230192.cable.net.co 186.147.230.193 static-ip-186147230193.cable.net.co 186.147.230.194 static-ip-186147230194.cable.net.co 186.147.230.195 static-ip-186147230195.cable.net.co 186.147.230.196 static-ip-186147230196.cable.net.co 186.147.230.197 static-ip-186147230197.cable.net.co 186.147.230.198 static-ip-186147230198.cable.net.co 186.147.230.199 static-ip-186147230199.cable.net.co 186.147.230.200 static-ip-186147230200.cable.net.co 186.147.230.201 static-ip-186147230201.cable.net.co 186.147.230.202 static-ip-186147230202.cable.net.co 186.147.230.203 static-ip-186147230203.cable.net.co 186.147.230.204 static-ip-186147230204.cable.net.co 186.147.230.205 static-ip-186147230205.cable.net.co 186.147.230.206 static-ip-186147230206.cable.net.co 186.147.230.207 static-ip-186147230207.cable.net.co 186.147.230.208 static-ip-186147230208.cable.net.co 186.147.230.209 static-ip-186147230209.cable.net.co 186.147.230.210 static-ip-186147230210.cable.net.co 186.147.230.211 static-ip-186147230211.cable.net.co 186.147.230.212 static-ip-186147230212.cable.net.co 186.147.230.213 static-ip-186147230213.cable.net.co 186.147.230.214 static-ip-186147230214.cable.net.co 186.147.230.215 static-ip-186147230215.cable.net.co 186.147.230.216 static-ip-186147230216.cable.net.co 186.147.230.217 static-ip-186147230217.cable.net.co 186.147.230.218 static-ip-186147230218.cable.net.co 186.147.230.219 static-ip-186147230219.cable.net.co 186.147.230.220 static-ip-186147230220.cable.net.co 186.147.230.221 static-ip-186147230221.cable.net.co 186.147.230.222 static-ip-186147230222.cable.net.co 186.147.230.223 static-ip-186147230223.cable.net.co 186.147.230.224 static-ip-186147230224.cable.net.co 186.147.230.225 static-ip-186147230225.cable.net.co 186.147.230.226 static-ip-186147230226.cable.net.co 186.147.230.227 static-ip-186147230227.cable.net.co 186.147.230.228 static-ip-186147230228.cable.net.co 186.147.230.229 static-ip-186147230229.cable.net.co 186.147.230.230 static-ip-186147230230.cable.net.co 186.147.230.231 static-ip-186147230231.cable.net.co 186.147.230.232 static-ip-186147230232.cable.net.co 186.147.230.233 static-ip-186147230233.cable.net.co 186.147.230.234 static-ip-186147230234.cable.net.co 186.147.230.235 static-ip-186147230235.cable.net.co 186.147.230.236 static-ip-186147230236.cable.net.co 186.147.230.237 static-ip-186147230237.cable.net.co 186.147.230.238 static-ip-186147230238.cable.net.co 186.147.230.239 static-ip-186147230239.cable.net.co 186.147.230.240 static-ip-186147230240.cable.net.co 186.147.230.241 static-ip-186147230241.cable.net.co 186.147.230.242 static-ip-186147230242.cable.net.co 186.147.230.243 static-ip-186147230243.cable.net.co 186.147.230.244 static-ip-186147230244.cable.net.co 186.147.230.245 static-ip-186147230245.cable.net.co 186.147.230.246 static-ip-186147230246.cable.net.co 186.147.230.247 static-ip-186147230247.cable.net.co 186.147.230.248 static-ip-186147230248.cable.net.co 186.147.230.249 static-ip-186147230249.cable.net.co 186.147.230.250 static-ip-186147230250.cable.net.co 186.147.230.251 static-ip-186147230251.cable.net.co 186.147.230.252 static-ip-186147230252.cable.net.co 186.147.230.253 static-ip-186147230253.cable.net.co 186.147.230.254 static-ip-186147230254.cable.net.co 186.147.230.255 static-ip-186147230255.cable.net.co 190.90.88.3 smtp.tvnet.com.ec 200.14.44.1 host-200.14.44.1.merca.net.co 200.14.44.2 host-200.14.44.2.merca.net.co 200.14.44.3 host-200.14.44.3.merca.net.co 200.14.44.4 host-200.14.44.4.merca.net.co 200.14.44.5 host-200.14.44.5.merca.net.co 200.14.44.6 host-200.14.44.6.merca.net.co 200.14.44.7 host-200.14.44.7.merca.net.co 200.14.44.8 host-200.14.44.8.merca.net.co 200.14.44.9 host-200.14.44.9.merca.net.co 200.14.44.10 host-200.14.44.10.merca.net.co 200.14.44.11 host-200.14.44.11.merca.net.co 200.14.44.12 host-200.14.44.12.merca.net.co 200.14.44.13 host-200.14.44.13.merca.net.co 200.14.44.14 host-200.14.44.14.merca.net.co 200.14.44.15 host-200.14.44.15.merca.net.co 200.14.44.16 host-200.14.44.16.merca.net.co 200.14.44.17 host-200.14.44.17.merca.net.co 200.14.44.18 host-200.14.44.18.merca.net.co 200.14.44.19 host-200.14.44.19.merca.net.co 200.14.44.20 host-200.14.44.20.merca.net.co 200.14.44.21 host-200.14.44.21.merca.net.co 200.14.44.22 host-200.14.44.22.merca.net.co 200.14.44.23 host-200.14.44.23.merca.net.co 200.14.44.24 host-200.14.44.24.merca.net.co 200.14.44.25 host-200.14.44.25.merca.net.co 200.14.44.26 host-200.14.44.26.merca.net.co 200.14.44.27 host-200.14.44.27.merca.net.co 200.14.44.28 host-200.14.44.28.merca.net.co 200.14.44.29 host-200.14.44.29.merca.net.co 200.14.44.30 host-200.14.44.30.merca.net.co 200.14.44.31 host-200.14.44.31.merca.net.co 200.14.44.32 host-200.14.44.32.merca.net.co 200.14.44.33 host-200.14.44.33.merca.net.co 200.14.44.34 host-200.14.44.34.merca.net.co 200.14.44.35 host-200.14.44.35.merca.net.co 200.14.44.36 host-200.14.44.36.merca.net.co 200.14.44.37 host-200.14.44.37.merca.net.co 200.14.44.38 host-200.14.44.38.merca.net.co 200.14.44.39 host-200.14.44.39.merca.net.co 200.14.44.40 host-200.14.44.40.merca.net.co 200.14.44.41 host-200.14.44.41.merca.net.co 200.14.44.42 host-200.14.44.42.merca.net.co 200.14.44.43 host-200.14.44.43.merca.net.co 200.14.44.44 host-200.14.44.44.merca.net.co 200.14.44.45 host-200.14.44.45.merca.net.co 200.14.44.46 host-200.14.44.46.merca.net.co 200.14.44.47 host-200.14.44.47.merca.net.co 200.14.44.48 host-200.14.44.48.merca.net.co 200.14.44.49 host-200.14.44.49.merca.net.co 200.14.44.50 host-200.14.44.50.merca.net.co 200.14.44.51 host-200.14.44.51.merca.net.co 200.14.44.52 host-200.14.44.52.merca.net.co 200.14.44.53 host-200.14.44.53.merca.net.co 200.14.44.54 host-200.14.44.54.merca.net.co 200.14.44.55 host-200.14.44.55.merca.net.co 200.14.44.56 host-200.14.44.56.merca.net.co 200.14.44.57 host-200.14.44.57.merca.net.co 200.14.44.58 host-200.14.44.58.merca.net.co 200.14.44.59 host-200.14.44.59.merca.net.co 200.14.44.60 host-200.14.44.60.merca.net.co 200.14.44.61 host-200.14.44.61.merca.net.co 200.14.44.62 host-200.14.44.62.merca.net.co 200.14.44.63 host-200.14.44.63.merca.net.co 200.14.44.64 host-200.14.44.64.merca.net.co 200.14.44.65 host-200.14.44.65.merca.net.co 200.14.44.66 host-200.14.44.66.merca.net.co 200.14.44.67 host-200.14.44.67.merca.net.co 200.14.44.68 host-200.14.44.68.merca.net.co 200.14.44.69 host-200.14.44.69.merca.net.co 200.14.44.70 host-200.14.44.70.merca.net.co 200.14.44.71 host-200.14.44.71.merca.net.co 200.14.44.72 host-200.14.44.72.merca.net.co 200.14.44.73 host-200.14.44.73.merca.net.co 200.14.44.74 host-200.14.44.74.merca.net.co 200.14.44.75 host-200.14.44.75.merca.net.co 200.14.44.76 host-200.14.44.76.merca.net.co 200.14.44.77 host-200.14.44.77.merca.net.co 200.14.44.78 host-200.14.44.78.merca.net.co 200.14.44.79 host-200.14.44.79.merca.net.co 200.14.44.80 host-200.14.44.80.merca.net.co 200.14.44.81 host-200.14.44.81.merca.net.co 200.14.44.82 host-200.14.44.82.merca.net.co 200.14.44.83 host-200.14.44.83.merca.net.co 200.14.44.84 host-200.14.44.84.merca.net.co 200.14.44.85 host-200.14.44.85.merca.net.co 200.14.44.86 host-200.14.44.86.merca.net.co 200.14.44.87 host-200.14.44.87.merca.net.co 200.14.44.88 host-200.14.44.88.merca.net.co 200.14.44.89 host-200.14.44.89.merca.net.co 200.14.44.90 host-200.14.44.90.merca.net.co 200.14.44.91 host-200.14.44.91.merca.net.co 200.14.44.92 host-200.14.44.92.merca.net.co 200.14.44.93 host-200.14.44.93.merca.net.co 200.14.44.94 host-200.14.44.94.merca.net.co 200.14.44.95 host-200.14.44.95.merca.net.co 200.14.44.96 host-200.14.44.96.merca.net.co 200.14.44.97 host-200.14.44.97.merca.net.co 200.14.44.98 host-200.14.44.98.merca.net.co 200.14.44.99 host-200.14.44.99.merca.net.co 200.14.44.100 host-200.14.44.100.merca.net.co 200.14.44.101 host-200.14.44.101.merca.net.co 200.14.44.102 host-200.14.44.102.merca.net.co 200.14.44.103 host-200.14.44.103.merca.net.co 200.14.44.104 host-200.14.44.104.merca.net.co 200.14.44.105 host-200.14.44.105.merca.net.co 200.14.44.106 host-200.14.44.106.merca.net.co 200.14.44.107 host-200.14.44.107.merca.net.co 200.14.44.108 host-200.14.44.108.merca.net.co 200.14.44.109 host-200.14.44.109.merca.net.co 200.14.44.110 host-200.14.44.110.merca.net.co 200.14.44.111 host-200.14.44.111.merca.net.co 200.14.44.112 host-200.14.44.112.merca.net.co 200.14.44.113 host-200.14.44.113.merca.net.co 200.14.44.114 host-200.14.44.114.merca.net.co 200.14.44.115 host-200.14.44.115.merca.net.co 200.14.44.116 host-200.14.44.116.merca.net.co 200.14.44.117 host-200.14.44.117.merca.net.co 200.14.44.118 host-200.14.44.118.merca.net.co 200.14.44.119 host-200.14.44.119.merca.net.co 200.14.44.120 host-200.14.44.120.merca.net.co 200.14.44.121 host-200.14.44.121.merca.net.co 200.14.44.122 host-200.14.44.122.merca.net.co 200.14.44.123 host-200.14.44.123.merca.net.co 200.14.44.124 host-200.14.44.124.merca.net.co 200.14.44.125 host-200.14.44.125.merca.net.co 200.14.44.126 host-200.14.44.126.merca.net.co 200.14.44.127 host-200.14.44.127.merca.net.co 200.14.44.128 host-200.14.44.128.merca.net.co 200.14.44.129 host-200.14.44.129.merca.net.co 200.14.44.130 host-200.14.44.130.merca.net.co 200.14.44.131 host-200.14.44.131.merca.net.co 200.14.44.132 host-200.14.44.132.merca.net.co 200.14.44.133 host-200.14.44.133.merca.net.co 200.14.44.134 host-200.14.44.134.merca.net.co 200.14.44.135 host-200.14.44.135.merca.net.co 200.14.44.136 host-200.14.44.136.merca.net.co 200.14.44.137 host-200.14.44.137.merca.net.co 200.14.44.138 host-200.14.44.138.merca.net.co 200.14.44.139 host-200.14.44.139.merca.net.co 200.14.44.140 host-200.14.44.140.merca.net.co 200.14.44.141 host-200.14.44.141.merca.net.co 200.14.44.142 host-200.14.44.142.merca.net.co 200.14.44.143 host-200.14.44.143.merca.net.co 200.14.44.144 host-200.14.44.144.merca.net.co 200.14.44.145 host-200.14.44.145.merca.net.co 200.14.44.146 host-200.14.44.146.merca.net.co 200.14.44.147 host-200.14.44.147.merca.net.co 200.14.44.148 host-200.14.44.148.merca.net.co 200.14.44.149 host-200.14.44.149.merca.net.co 200.14.44.150 host-200.14.44.150.merca.net.co 200.14.44.151 host-200.14.44.151.merca.net.co 200.14.44.152 host-200.14.44.152.merca.net.co 200.14.44.153 host-200.14.44.153.merca.net.co 200.14.44.154 host-200.14.44.154.merca.net.co 200.14.44.155 host-200.14.44.155.merca.net.co 200.14.44.156 host-200.14.44.156.merca.net.co 200.14.44.157 host-200.14.44.157.merca.net.co 200.14.44.158 host-200.14.44.158.merca.net.co 200.14.44.159 host-200.14.44.159.merca.net.co 200.14.44.160 host-200.14.44.160.merca.net.co 200.14.44.161 host-200.14.44.161.merca.net.co 200.14.44.162 host-200.14.44.162.merca.net.co 200.14.44.163 host-200.14.44.163.merca.net.co 200.14.44.164 host-200.14.44.164.merca.net.co 200.14.44.165 host-200.14.44.165.merca.net.co 200.14.44.166 host-200.14.44.166.merca.net.co 200.14.44.167 host-200.14.44.167.merca.net.co 200.14.44.168 host-200.14.44.168.merca.net.co 200.14.44.169 host-200.14.44.169.merca.net.co 200.14.44.170 host-200.14.44.170.merca.net.co 200.14.44.171 host-200.14.44.171.merca.net.co 200.14.44.172 host-200.14.44.172.merca.net.co 200.14.44.173 host-200.14.44.173.merca.net.co 200.14.44.174 host-200.14.44.174.merca.net.co 200.14.44.175 host-200.14.44.175.merca.net.co 200.14.44.176 host-200.14.44.176.merca.net.co 200.14.44.177 host-200.14.44.177.merca.net.co 200.14.44.178 host-200.14.44.178.merca.net.co 200.14.44.179 host-200.14.44.179.merca.net.co 200.14.44.180 host-200.14.44.180.merca.net.co 200.14.44.181 host-200.14.44.181.merca.net.co 200.14.44.182 host-200.14.44.182.merca.net.co 200.14.44.183 host-200.14.44.183.merca.net.co 200.14.44.184 host-200.14.44.184.merca.net.co 200.14.44.185 host-200.14.44.185.merca.net.co 200.14.44.186 host-200.14.44.186.merca.net.co 200.14.44.187 host-200.14.44.187.merca.net.co 200.14.44.188 host-200.14.44.188.merca.net.co 200.14.44.189 host-200.14.44.189.merca.net.co 200.14.44.190 host-200.14.44.190.merca.net.co 200.14.44.191 host-200.14.44.191.merca.net.co 200.14.44.192 host-200.14.44.192.merca.net.co 200.14.44.193 host-200.14.44.193.merca.net.co 200.14.44.194 host-200.14.44.194.merca.net.co 200.14.44.195 host-200.14.44.195.merca.net.co 200.14.44.196 host-200.14.44.196.merca.net.co 200.14.44.197 host-200.14.44.197.merca.net.co 200.14.44.198 host-200.14.44.198.merca.net.co 200.14.44.199 host-200.14.44.199.merca.net.co 200.14.44.200 host-200.14.44.200.merca.net.co 200.14.44.201 host-200.14.44.201.merca.net.co 200.14.44.202 host-200.14.44.202.merca.net.co 200.14.44.203 host-200.14.44.203.merca.net.co 200.14.44.204 host-200.14.44.204.merca.net.co 200.14.44.205 host-200.14.44.205.merca.net.co 200.14.44.206 host-200.14.44.206.merca.net.co 200.14.44.207 host-200.14.44.207.merca.net.co 200.14.44.208 host-200.14.44.208.merca.net.co 200.14.44.209 host-200.14.44.209.merca.net.co 200.14.44.210 host-200.14.44.210.merca.net.co 200.14.44.211 host-200.14.44.211.merca.net.co 200.14.44.212 host-200.14.44.212.merca.net.co 200.14.44.213 host-200.14.44.213.merca.net.co 200.14.44.214 host-200.14.44.214.merca.net.co 200.14.44.215 host-200.14.44.215.merca.net.co 200.14.44.216 host-200.14.44.216.merca.net.co 200.14.44.217 host-200.14.44.217.merca.net.co 200.14.44.218 host-200.14.44.218.merca.net.co 200.14.44.219 host-200.14.44.219.merca.net.co 200.14.44.220 host-200.14.44.220.merca.net.co 200.14.44.221 host-200.14.44.221.merca.net.co 200.14.44.222 host-200.14.44.222.merca.net.co 200.14.44.223 host-200.14.44.223.merca.net.co 200.14.44.224 host-200.14.44.224.merca.net.co 200.14.44.225 host-200.14.44.225.merca.net.co 200.14.44.226 host-200.14.44.226.merca.net.co 200.14.44.227 host-200.14.44.227.merca.net.co 200.14.44.228 host-200.14.44.228.merca.net.co 200.14.44.229 host-200.14.44.229.merca.net.co 200.14.44.230 host-200.14.44.230.merca.net.co 200.14.44.231 host-200.14.44.231.merca.net.co 200.14.44.232 host-200.14.44.232.merca.net.co 200.14.44.233 host-200.14.44.233.merca.net.co 200.14.44.234 host-200.14.44.234.merca.net.co 200.14.44.235 host-200.14.44.235.merca.net.co 200.14.44.236 host-200.14.44.236.merca.net.co 200.14.44.237 host-200.14.44.237.merca.net.co 200.14.44.238 host-200.14.44.238.merca.net.co 200.14.44.239 host-200.14.44.239.merca.net.co 200.14.44.240 host-200.14.44.240.merca.net.co 200.14.44.241 host-200.14.44.241.merca.net.co 200.14.44.242 host-200.14.44.242.merca.net.co 200.14.44.243 host-200.14.44.243.merca.net.co 200.14.44.244 host-200.14.44.244.merca.net.co 200.14.44.245 host-200.14.44.245.merca.net.co 200.14.44.246 host-200.14.44.246.merca.net.co 200.14.44.247 host-200.14.44.247.merca.net.co 200.14.44.248 host-200.14.44.248.merca.net.co 200.14.44.249 host-200.14.44.249.merca.net.co 200.14.44.250 host-200.14.44.250.merca.net.co 200.14.44.251 host-200.14.44.251.merca.net.co 200.14.44.252 host-200.14.44.252.merca.net.co 200.14.44.253 host-200.14.44.253.merca.net.co 200.14.44.254 host-200.14.44.254.merca.net.co 200.24.5.37 mail.cecep.edu.co 200.24.5.51 correo.isagen.com.co 200.24.5.51 gfiserver.isagen.com.co 200.24.5.90 mail.hptu.org.co 200.24.5.126 correo.sonoco.com.co 200.24.5.133 correo.fibrexa.com.co 200.24.5.185 dns.datawareltda.com 200.24.5.185 webserver.datawareltda.com 200.24.5.187 dnsdw.datawareltda.com 200.24.5.189 correo.datawareltda.com 200.24.5.210 mail.globalmanagement.com.co 200.24.5.250 mail.araujoibarra.com From andrew.fried at gmail.com Tue Jun 6 18:18:55 2017 From: andrew.fried at gmail.com (Andrew Fried) Date: Tue, 6 Jun 2017 14:18:55 -0400 Subject: IP Hijacking For Dummies In-Reply-To: <20170606172645.GA23015@gsp.org> References: <91149.1496706364@segfault.tristatelogic.com> <20170606172645.GA23015@gsp.org> Message-ID: <3d1d8a99-6a62-3d08-451e-80998ab4fb03@gmail.com> PTR records rarely paint an accurate picture. Looking at passive dns for the past week, I see a slightly different view of those subnets: 2017-06-05 16:41:45,amasonsuper.com,A,168.176.194.132 2017-06-03 17:09:42,amztodai.com,A,168.176.194.4 2017-06-06 17:45:13,asianbabee.com,A,168.176.194.73 2017-06-05 16:40:29,asianbabez.com,A,168.176.194.197 2017-06-03 19:32:13,aydsleep.com,A,168.176.194.67 2017-06-05 19:56:30,becomedriverz.com,A,168.176.194.133 2017-06-05 23:31:07,bestkidbookz.com,A,168.176.194.71 2017-06-04 18:50:58,besttransforms.com,A,168.176.194.196 2017-06-03 21:03:57,brainkares.com,A,168.176.194.195 2017-06-06 14:28:15,cannabizmoney.com,A,168.176.194.10 2017-06-06 14:26:51,cvstodai.com,A,168.176.194.72 2017-06-03 20:07:48,extragiftz.com,A,168.176.194.130 2017-06-04 18:50:36,foxlivescand.com,A,168.176.194.68 2017-06-02 20:34:16,foxtodaylive.com,A,168.176.194.194 2017-06-02 18:20:10,funguzcured.com,A,168.176.194.193 2017-06-04 18:51:51,healthydiscoverz.com,A,168.176.194.131 2017-06-05 16:11:20,helpsavelifes.com,A,168.176.194.69 2017-06-05 16:15:25,kellyscandals.com,A,168.176.194.7 2017-06-06 17:45:43,kohlmaster.com,A,168.176.194.11 2017-06-05 19:44:34,luckireward.com,A,168.176.194.70 2017-06-05 16:41:35,mail.amasonsuper.com,A,168.176.194.132 2017-06-03 17:09:41,mail.amztodai.com,A,168.176.194.4 2017-06-06 17:45:56,mail.asianbabee.com,A,168.176.194.73 2017-06-05 16:40:28,mail.asianbabez.com,A,168.176.194.197 2017-06-03 19:32:12,mail.aydsleep.com,A,168.176.194.67 2017-06-05 19:56:30,mail.becomedriverz.com,A,168.176.194.133 2017-06-05 23:31:07,mail.bestkidbookz.com,A,168.176.194.71 2017-06-04 18:50:58,mail.besttransforms.com,A,168.176.194.196 2017-06-03 21:03:56,mail.brainkares.com,A,168.176.194.195 2017-06-06 14:28:15,mail.cannabizmoney.com,A,168.176.194.10 2017-06-06 14:26:57,mail.cvstodai.com,A,168.176.194.72 2017-06-03 20:07:55,mail.extragiftz.com,A,168.176.194.130 2017-06-04 18:50:40,mail.foxlivescand.com,A,168.176.194.68 2017-06-02 20:34:16,mail.foxtodaylive.com,A,168.176.194.194 2017-06-02 18:20:21,mail.funguzcured.com,A,168.176.194.193 2017-06-04 18:51:53,mail.healthydiscoverz.com,A,168.176.194.131 2017-06-05 16:11:03,mail.helpsavelifes.com,A,168.176.194.69 2017-06-05 16:15:25,mail.kellyscandals.com,A,168.176.194.7 2017-06-06 17:45:43,mail.kohlmaster.com,A,168.176.194.11 2017-06-05 19:44:34,mail.luckireward.com,A,168.176.194.70 2017-06-05 19:56:09,mail.navylighting.com,A,168.176.194.8 2017-06-05 19:42:38,mail.pharmacyalertz.com,A,168.176.194.198 2017-06-05 23:38:35,mail.prettyrussianz.com,A,168.176.194.134 2017-06-06 14:51:55,mail.primemazons.com,A,168.176.194.135 2017-06-05 21:20:18,mail.secretpotz.com,A,168.176.194.9 2017-06-04 19:06:59,mail.supersundayamz.com,A,168.176.194.5 2017-06-06 15:24:58,mail.todaymedications.com,A,168.176.194.199 2017-06-06 18:06:51,mail.wehelpbrains.com,A,168.176.194.136 2017-06-05 19:56:09,navylighting.com,A,168.176.194.8 2017-06-05 19:42:38,pharmacyalertz.com,A,168.176.194.198 2017-06-05 23:38:40,prettyrussianz.com,A,168.176.194.134 2017-06-06 14:51:55,primemazons.com,A,168.176.194.135 2017-06-05 21:20:18,secretpotz.com,A,168.176.194.9 2017-06-04 19:06:56,supersundayamz.com,A,168.176.194.5 2017-06-06 15:24:59,todaymedications.com,A,168.176.194.199 2017-06-06 18:06:51,wehelpbrains.com,A,168.176.194.136 2017-06-05 19:53:34,alertcvs.com,A,181.57.40.195 2017-06-06 14:48:56,amasonprimes.com,A,181.57.40.133 2017-06-03 17:20:21,amasuperprime.com,A,181.57.40.5 2017-06-06 00:27:57,amazinstorez.com,A,181.57.40.196 2017-06-05 16:32:57,amzntodaygift.com,A,181.57.40.131 2017-06-05 16:12:11,bloodlifesaver.com,A,181.57.40.69 2017-06-06 17:58:56,brainupdatez.com,A,181.57.40.134 2017-06-05 23:16:15,disneyfavz.com,A,181.57.40.9 2017-06-04 19:07:35,hbpsos.com,A,181.57.40.130 2017-06-05 19:41:29,kohlsupdatez.com,A,181.57.40.70 2017-06-02 20:34:52,livefoxscandal.com,A,181.57.40.4 2017-06-05 16:42:43,lovelyazian.com,A,181.57.40.194 2017-06-06 17:54:40,lovethisasian.com,A,181.57.40.73 2017-06-05 19:43:53,lyftdrivez.com,A,181.57.40.132 2017-06-05 19:53:34,mail.alertcvs.com,A,181.57.40.195 2017-06-06 14:48:55,mail.amasonprimes.com,A,181.57.40.133 2017-06-03 17:20:23,mail.amasuperprime.com,A,181.57.40.5 2017-06-06 00:27:50,mail.amazinstorez.com,A,181.57.40.196 2017-06-05 16:32:39,mail.amzntodaygift.com,A,181.57.40.131 2017-06-05 16:12:14,mail.bloodlifesaver.com,A,181.57.40.69 2017-06-06 17:59:14,mail.brainupdatez.com,A,181.57.40.134 2017-06-05 23:16:23,mail.disneyfavz.com,A,181.57.40.9 2017-06-04 19:07:34,mail.hbpsos.com,A,181.57.40.130 2017-06-05 19:41:25,mail.kohlsupdatez.com,A,181.57.40.70 2017-06-02 20:34:52,mail.livefoxscandal.com,A,181.57.40.4 2017-06-05 16:42:40,mail.lovelyazian.com,A,181.57.40.194 2017-06-06 17:54:40,mail.lovethisasian.com,A,181.57.40.73 2017-06-05 19:43:58,mail.lyftdrivez.com,A,181.57.40.132 2017-06-06 14:52:27,mail.medicationalertz.com,A,181.57.40.197 2017-06-05 16:09:55,mail.megynkelupdate.com,A,181.57.40.7 2017-06-05 19:58:32,mail.militaryequipz.com,A,181.57.40.8 2017-06-04 19:08:49,mail.momshocker.com,A,181.57.40.193 2017-06-03 17:14:54,mail.mycvscardz.com,A,181.57.40.68 2017-06-06 14:24:21,mail.pharmascvs.com,A,181.57.40.72 2017-06-06 14:22:58,mail.potstockk.com,A,181.57.40.10 2017-06-05 23:17:38,mail.russiancute.com,A,181.57.40.71 2017-06-06 17:49:46,mail.specialkohlz.com,A,181.57.40.11 2017-06-04 19:41:51,mail.sundaireward.com,A,181.57.40.6 2017-06-04 19:08:44,mail.toniteshowfox.com,A,181.57.40.67 2017-06-06 14:52:27,medicationalertz.com,A,181.57.40.197 2017-06-05 16:09:55,megynkelupdate.com,A,181.57.40.7 2017-06-05 19:58:20,militaryequipz.com,A,181.57.40.8 2017-06-04 19:08:00,momshocker.com,A,181.57.40.193 2017-06-03 17:14:50,mycvscardz.com,A,181.57.40.68 2017-06-06 14:24:35,pharmascvs.com,A,181.57.40.72 2017-06-06 14:25:56,potstockk.com,A,181.57.40.10 2017-06-05 23:17:38,russiancute.com,A,181.57.40.71 2017-06-06 17:49:42,specialkohlz.com,A,181.57.40.11 2017-06-04 19:41:51,sundaireward.com,A,181.57.40.6 2017-06-04 19:08:44,toniteshowfox.com,A,181.57.40.67 2017-06-03 17:16:40,amasonikusa.com,A,186.147.230.5 2017-06-06 14:51:56,amazntoda.com,A,186.147.230.139 2017-06-02 14:16:59,bizawardz.com,A,186.147.230.132 2017-06-06 18:00:51,bloodpressurealertz.com,A,186.147.230.140 2017-06-04 18:54:38,botoxkills.com,A,186.147.230.199 2017-06-01 22:46:46,bpmedz.com,A,186.147.230.68 2017-06-02 20:53:55,byesnorings.com,A,186.147.230.71 2017-06-06 14:27:48,cannabissal.com,A,186.147.230.10 2017-06-01 18:53:21,cvsextracares.com,A,186.147.230.67 2017-06-06 00:19:30,dizneyrewardz.com,A,186.147.230.202 2017-06-06 14:26:31,extracaregift.com,A,186.147.230.77 2017-06-01 18:50:40,extracarelight.com,A,186.147.230.130 2017-06-05 19:44:58,freebiezsibies.com,A,186.147.230.75 2017-06-02 19:33:35,fullnightsleepz.com,A,186.147.230.70 2017-06-02 14:19:21,giftamaazon.com,A,186.147.230.195 2017-06-06 17:46:46,giftcerttoday.com,A,186.147.230.11 2017-06-03 19:34:00,healthsleepz.com,A,186.147.230.72 2017-06-02 22:21:58,healthytypz.com,A,186.147.230.134 2017-06-05 23:30:41,heartallert.com,A,186.147.230.76 2017-06-04 19:07:49,hellpyourheart.com,A,186.147.230.136 2017-06-01 21:33:05,helpwbloodpressure.com,A,186.147.230.193 2017-06-05 16:12:57,highbloodpressurekill.com,A,186.147.230.74 2017-06-02 13:26:59,hollywoodlifez.com,A,186.147.230.69 2017-06-04 18:53:48,hollywudscandal.com,A,186.147.230.73 2017-06-02 16:35:59,importantfunds.com,A,186.147.230.133 2017-06-05 23:17:57,inzurancehealth.com,A,186.147.230.9 2017-06-03 17:16:32,kohlstodai.com,A,186.147.230.198 2017-06-03 21:40:59,kohlstodais.com,A,186.147.230.135 2017-06-05 16:26:52,livecandidacy.com,A,186.147.230.200 2017-06-05 16:15:53,livefoxtvusa.com,A,186.147.230.7 2017-06-01 22:52:15,livescandals.com,A,186.147.230.131 2017-06-03 17:16:40,mail.amasonikusa.com,A,186.147.230.5 2017-06-06 14:51:39,mail.amazntoda.com,A,186.147.230.139 2017-06-02 14:17:44,mail.bizawardz.com,A,186.147.230.132 2017-06-06 18:00:47,mail.bloodpressurealertz.com,A,186.147.230.140 2017-06-04 18:54:17,mail.botoxkills.com,A,186.147.230.199 2017-06-01 22:46:50,mail.bpmedz.com,A,186.147.230.68 2017-06-02 20:53:54,mail.byesnorings.com,A,186.147.230.71 2017-06-06 14:27:47,mail.cannabissal.com,A,186.147.230.10 2017-06-01 18:53:21,mail.cvsextracares.com,A,186.147.230.67 2017-06-06 00:19:38,mail.dizneyrewardz.com,A,186.147.230.202 2017-06-06 14:26:31,mail.extracaregift.com,A,186.147.230.77 2017-06-01 18:52:35,mail.extracarelight.com,A,186.147.230.130 2017-06-05 19:45:30,mail.freebiezsibies.com,A,186.147.230.75 2017-06-02 19:33:35,mail.fullnightsleepz.com,A,186.147.230.70 2017-06-02 14:19:21,mail.giftamaazon.com,A,186.147.230.195 2017-06-06 17:46:58,mail.giftcerttoday.com,A,186.147.230.11 2017-06-03 19:34:24,mail.healthsleepz.com,A,186.147.230.72 2017-06-02 22:18:33,mail.healthytypz.com,A,186.147.230.134 2017-06-05 23:30:30,mail.heartallert.com,A,186.147.230.76 2017-06-04 19:07:58,mail.hellpyourheart.com,A,186.147.230.136 2017-06-01 21:33:07,mail.helpwbloodpressure.com,A,186.147.230.193 2017-06-05 16:12:57,mail.highbloodpressurekill.com,A,186.147.230.74 2017-06-02 13:26:57,mail.hollywoodlifez.com,A,186.147.230.69 2017-06-04 18:53:48,mail.hollywudscandal.com,A,186.147.230.73 2017-06-02 16:35:58,mail.importantfunds.com,A,186.147.230.133 2017-06-05 23:17:56,mail.inzurancehealth.com,A,186.147.230.9 2017-06-03 17:16:43,mail.kohlstodai.com,A,186.147.230.198 2017-06-03 21:40:54,mail.kohlstodais.com,A,186.147.230.135 2017-06-05 16:26:52,mail.livecandidacy.com,A,186.147.230.200 2017-06-05 16:15:53,mail.livefoxtvusa.com,A,186.147.230.7 2017-06-01 22:52:27,mail.livescandals.com,A,186.147.230.131 2017-06-06 14:48:58,mail.medicinekillz.com,A,186.147.230.203 2017-06-05 21:13:42,mail.moneyofbud.com,A,186.147.230.8 2017-06-06 17:47:21,mail.sheishottoday.com,A,186.147.230.78 2017-06-02 16:35:52,mail.skinscareusa.com,A,186.147.230.196 2017-06-01 22:46:41,mail.snoringkillz.com,A,186.147.230.194 2017-06-04 18:57:47,mail.sundaygiveawayz.com,A,186.147.230.4 2017-06-02 20:57:25,mail.supergiveawayz.com,A,186.147.230.197 2017-06-05 19:53:42,mail.todaycvspharma.com,A,186.147.230.201 2017-06-05 16:34:14,mail.todayweamazn.com,A,186.147.230.137 2017-06-05 21:13:26,mail.zippygives.com,A,186.147.230.138 2017-06-06 14:48:45,medicinekillz.com,A,186.147.230.203 2017-06-05 21:13:44,moneyofbud.com,A,186.147.230.8 2017-06-06 17:47:21,sheishottoday.com,A,186.147.230.78 2017-06-02 16:35:58,skinscareusa.com,A,186.147.230.196 2017-06-01 22:46:12,snoringkillz.com,A,186.147.230.194 2017-06-04 18:57:47,sundaygiveawayz.com,A,186.147.230.4 2017-06-02 20:57:26,supergiveawayz.com,A,186.147.230.197 2017-06-05 19:53:42,todaycvspharma.com,A,186.147.230.201 2017-06-05 16:34:01,todayweamazn.com,A,186.147.230.137 2017-06-05 21:13:36,zippygives.com,A,186.147.230.138 Andrew Fried andrew.fried at gmail.com On 6/6/17 1:26 PM, Rich Kulawiec wrote: > On Mon, Jun 05, 2017 at 04:46:04PM -0700, Ronald F. Guilmette wrote: >> It did also strike me as passing strange that this company has apparently >> elected to not actually put its own web server, name servers, or mail >> server anywhere within its own duly allocated IPv4 blocks. > > Out of curiosity, I ran a DNS scan against all of the /24's that you > enumerated (thank you, by the way). I am also perplexed that a hosting > company which has "sold out" of virtual servers seems to have precious > few servers -- of any type -- represented in its DNS records. To save > everyone else the trouble, I'm appending below all the results (1023) > that did not result in NXDOMAIN or SERVFAIL (5121). Note in re the > last dozen on the list: I believe "correo" translates to "post", in > the sense of "mail", so those may well be (customer?) mail servers. > > ---rsk > > 168.176.194.11 palmi19411.palmira.unal.edu.co > 168.176.194.12 palmi19412.palmira.unal.edu.co > 168.176.194.13 palmi19413.palmira.unal.edu.co > 168.176.194.14 palmi19414.palmira.unal.edu.co > 168.176.194.15 palmi19415.palmira.unal.edu.co > 168.176.194.16 palmi19416.palmira.unal.edu.co > 168.176.194.17 palmi19417.palmira.unal.edu.co > 168.176.194.18 palmi19418.palmira.unal.edu.co > 168.176.194.19 palmi19419.palmira.unal.edu.co > 168.176.194.20 palmi19420.palmira.unal.edu.co > 168.176.194.21 palmi19421.palmira.unal.edu.co > 168.176.194.22 palmi19422.palmira.unal.edu.co > 168.176.194.23 palmi19423.palmira.unal.edu.co > 168.176.194.24 palmi19424.palmira.unal.edu.co > 168.176.194.25 palmi19425.palmira.unal.edu.co > 168.176.194.26 palmi19426.palmira.unal.edu.co > 168.176.194.27 palmi19427.palmira.unal.edu.co > 168.176.194.28 palmi19428.palmira.unal.edu.co > 168.176.194.29 palmi19429.palmira.unal.edu.co > 168.176.194.30 palmi19430.palmira.unal.edu.co > 168.176.194.31 palmi19431.palmira.unal.edu.co > 168.176.194.32 palmi19432.palmira.unal.edu.co > 168.176.194.33 palmi19433.palmira.unal.edu.co > 168.176.194.34 palmi19434.palmira.unal.edu.co > 168.176.194.35 palmi19435.palmira.unal.edu.co > 168.176.194.36 palmi19436.palmira.unal.edu.co > 168.176.194.37 palmi19437.palmira.unal.edu.co > 168.176.194.38 palmi19438.palmira.unal.edu.co > 168.176.194.39 palmi19439.palmira.unal.edu.co > 168.176.194.40 palmi19440.palmira.unal.edu.co > 168.176.194.41 palmi19441.palmira.unal.edu.co > 168.176.194.42 palmi19442.palmira.unal.edu.co > 168.176.194.43 palmi19443.palmira.unal.edu.co > 168.176.194.44 palmi19444.palmira.unal.edu.co > 168.176.194.45 palmi19445.palmira.unal.edu.co > 168.176.194.46 palmi19446.palmira.unal.edu.co > 168.176.194.47 palmi19447.palmira.unal.edu.co > 168.176.194.48 palmi19448.palmira.unal.edu.co > 168.176.194.49 palmi19449.palmira.unal.edu.co > 168.176.194.50 palmi19450.palmira.unal.edu.co > 168.176.194.51 palmi19451.palmira.unal.edu.co > 168.176.194.52 palmi19452.palmira.unal.edu.co > 168.176.194.53 palmi19453.palmira.unal.edu.co > 168.176.194.54 palmi19454.palmira.unal.edu.co > 168.176.194.55 palmi19455.palmira.unal.edu.co > 168.176.194.56 palmi19456.palmira.unal.edu.co > 168.176.194.57 palmi19457.palmira.unal.edu.co > 168.176.194.58 palmi19458.palmira.unal.edu.co > 168.176.194.59 palmi19459.palmira.unal.edu.co > 168.176.194.60 palmi19460.palmira.unal.edu.co > 168.176.194.61 palmi19461.palmira.unal.edu.co > 168.176.194.62 palmi19462.palmira.unal.edu.co > 168.176.194.63 palmi19463.palmira.unal.edu.co > 168.176.194.64 palmi19464.palmira.unal.edu.co > 168.176.194.65 palmi19465.palmira.unal.edu.co > 168.176.194.66 palmi19466.palmira.unal.edu.co > 168.176.194.67 palmi19467.palmira.unal.edu.co > 168.176.194.68 palmi19468.palmira.unal.edu.co > 168.176.194.69 palmi19469.palmira.unal.edu.co > 168.176.194.70 palmi19470.palmira.unal.edu.co > 168.176.194.71 palmi19471.palmira.unal.edu.co > 168.176.194.72 palmi19472.palmira.unal.edu.co > 168.176.194.73 palmi19473.palmira.unal.edu.co > 168.176.194.74 palmi19474.palmira.unal.edu.co > 168.176.194.75 palmi19475.palmira.unal.edu.co > 168.176.194.76 palmi19476.palmira.unal.edu.co > 168.176.194.77 palmi19477.palmira.unal.edu.co > 168.176.194.78 palmi19478.palmira.unal.edu.co > 168.176.194.79 palmi19479.palmira.unal.edu.co > 168.176.194.80 palmi19480.palmira.unal.edu.co > 168.176.194.81 palmi19481.palmira.unal.edu.co > 168.176.194.82 palmi19482.palmira.unal.edu.co > 168.176.194.83 palmi19483.palmira.unal.edu.co > 168.176.194.84 palmi19484.palmira.unal.edu.co > 168.176.194.85 palmi19485.palmira.unal.edu.co > 168.176.194.86 palmi19486.palmira.unal.edu.co > 168.176.194.87 palmi19487.palmira.unal.edu.co > 168.176.194.88 palmi19488.palmira.unal.edu.co > 168.176.194.89 palmi19489.palmira.unal.edu.co > 168.176.194.90 palmi19490.palmira.unal.edu.co > 168.176.194.91 palmi19491.palmira.unal.edu.co > 168.176.194.92 palmi19492.palmira.unal.edu.co > 168.176.194.93 palmi19493.palmira.unal.edu.co > 168.176.194.94 palmi19494.palmira.unal.edu.co > 168.176.194.95 palmi19495.palmira.unal.edu.co > 168.176.194.96 palmi19496.palmira.unal.edu.co > 168.176.194.97 palmi19497.palmira.unal.edu.co > 168.176.194.98 palmi19498.palmira.unal.edu.co > 168.176.194.99 palmi19499.palmira.unal.edu.co > 168.176.194.100 palmi194100.palmira.unal.edu.co > 168.176.194.101 palmi194101.palmira.unal.edu.co > 168.176.194.102 palmi194102.palmira.unal.edu.co > 168.176.194.103 palmi194103.palmira.unal.edu.co > 168.176.194.104 palmi194104.palmira.unal.edu.co > 168.176.194.105 palmi194105.palmira.unal.edu.co > 168.176.194.106 palmi194106.palmira.unal.edu.co > 168.176.194.107 palmi194107.palmira.unal.edu.co > 168.176.194.108 palmi194108.palmira.unal.edu.co > 168.176.194.109 palmi194109.palmira.unal.edu.co > 168.176.194.110 palmi194110.palmira.unal.edu.co > 168.176.194.111 palmi194111.palmira.unal.edu.co > 168.176.194.112 palmi194112.palmira.unal.edu.co > 168.176.194.113 palmi194113.palmira.unal.edu.co > 168.176.194.114 palmi194114.palmira.unal.edu.co > 168.176.194.115 palmi194115.palmira.unal.edu.co > 168.176.194.116 palmi194116.palmira.unal.edu.co > 168.176.194.117 palmi194117.palmira.unal.edu.co > 168.176.194.118 palmi194118.palmira.unal.edu.co > 168.176.194.119 palmi194119.palmira.unal.edu.co > 168.176.194.120 palmi194120.palmira.unal.edu.co > 168.176.194.121 palmi194121.palmira.unal.edu.co > 168.176.194.122 palmi194122.palmira.unal.edu.co > 168.176.194.123 palmi194123.palmira.unal.edu.co > 168.176.194.124 palmi194124.palmira.unal.edu.co > 168.176.194.125 palmi194125.palmira.unal.edu.co > 168.176.194.126 palmi194126.palmira.unal.edu.co > 168.176.194.127 palmi194127.palmira.unal.edu.co > 168.176.194.128 palmi194128.palmira.unal.edu.co > 168.176.194.129 palmi194129.palmira.unal.edu.co > 168.176.194.130 palmi194130.palmira.unal.edu.co > 168.176.194.131 palmi194131.palmira.unal.edu.co > 168.176.194.132 palmi194132.palmira.unal.edu.co > 168.176.194.133 palmi194133.palmira.unal.edu.co > 168.176.194.134 palmi194134.palmira.unal.edu.co > 168.176.194.135 palmi194135.palmira.unal.edu.co > 168.176.194.136 palmi194136.palmira.unal.edu.co > 168.176.194.137 palmi194137.palmira.unal.edu.co > 168.176.194.138 palmi194138.palmira.unal.edu.co > 168.176.194.139 palmi194139.palmira.unal.edu.co > 168.176.194.140 palmi194140.palmira.unal.edu.co > 168.176.194.141 palmi194141.palmira.unal.edu.co > 168.176.194.142 palmi194142.palmira.unal.edu.co > 168.176.194.143 palmi194143.palmira.unal.edu.co > 168.176.194.144 palmi194144.palmira.unal.edu.co > 168.176.194.145 palmi194145.palmira.unal.edu.co > 168.176.194.146 palmi194146.palmira.unal.edu.co > 168.176.194.147 palmi194147.palmira.unal.edu.co > 168.176.194.148 palmi194148.palmira.unal.edu.co > 168.176.194.149 palmi194149.palmira.unal.edu.co > 168.176.194.150 palmi194150.palmira.unal.edu.co > 168.176.194.151 palmi194151.palmira.unal.edu.co > 168.176.194.152 palmi194152.palmira.unal.edu.co > 168.176.194.153 palmi194153.palmira.unal.edu.co > 168.176.194.154 palmi194154.palmira.unal.edu.co > 168.176.194.155 palmi194155.palmira.unal.edu.co > 168.176.194.156 palmi194156.palmira.unal.edu.co > 168.176.194.157 palmi194157.palmira.unal.edu.co > 168.176.194.158 palmi194158.palmira.unal.edu.co > 168.176.194.159 palmi194159.palmira.unal.edu.co > 168.176.194.160 palmi194160.palmira.unal.edu.co > 168.176.194.161 palmi194161.palmira.unal.edu.co > 168.176.194.162 palmi194162.palmira.unal.edu.co > 168.176.194.163 palmi194163.palmira.unal.edu.co > 168.176.194.164 palmi194164.palmira.unal.edu.co > 168.176.194.165 palmi194165.palmira.unal.edu.co > 168.176.194.166 palmi194166.palmira.unal.edu.co > 168.176.194.167 palmi194167.palmira.unal.edu.co > 168.176.194.168 palmi194168.palmira.unal.edu.co > 168.176.194.169 palmi194169.palmira.unal.edu.co > 168.176.194.170 palmi194170.palmira.unal.edu.co > 168.176.194.171 palmi194171.palmira.unal.edu.co > 168.176.194.172 palmi194172.palmira.unal.edu.co > 168.176.194.173 palmi194173.palmira.unal.edu.co > 168.176.194.174 palmi194174.palmira.unal.edu.co > 168.176.194.175 palmi194175.palmira.unal.edu.co > 168.176.194.176 palmi194176.palmira.unal.edu.co > 168.176.194.177 palmi194177.palmira.unal.edu.co > 168.176.194.178 palmi194178.palmira.unal.edu.co > 168.176.194.179 palmi194179.palmira.unal.edu.co > 168.176.194.180 palmi194180.palmira.unal.edu.co > 168.176.194.181 palmi194181.palmira.unal.edu.co > 168.176.194.182 palmi194182.palmira.unal.edu.co > 168.176.194.183 palmi194183.palmira.unal.edu.co > 168.176.194.184 palmi194184.palmira.unal.edu.co > 168.176.194.185 palmi194185.palmira.unal.edu.co > 168.176.194.186 palmi194186.palmira.unal.edu.co > 168.176.194.187 palmi194187.palmira.unal.edu.co > 168.176.194.188 palmi194188.palmira.unal.edu.co > 168.176.194.189 palmi194189.palmira.unal.edu.co > 168.176.194.190 palmi194190.palmira.unal.edu.co > 168.176.194.191 palmi194191.palmira.unal.edu.co > 168.176.194.192 palmi194192.palmira.unal.edu.co > 168.176.194.193 palmi194193.palmira.unal.edu.co > 168.176.194.194 palmi194194.palmira.unal.edu.co > 168.176.194.195 palmi194195.palmira.unal.edu.co > 168.176.194.196 palmi194196.palmira.unal.edu.co > 168.176.194.197 palmi194197.palmira.unal.edu.co > 168.176.194.198 palmi194198.palmira.unal.edu.co > 168.176.194.199 palmi194199.palmira.unal.edu.co > 168.176.194.200 palmi194200.palmira.unal.edu.co > 168.176.194.201 palmi194201.palmira.unal.edu.co > 168.176.194.202 palmi194202.palmira.unal.edu.co > 168.176.194.203 palmi194203.palmira.unal.edu.co > 168.176.194.204 palmi194204.palmira.unal.edu.co > 168.176.194.205 palmi194205.palmira.unal.edu.co > 168.176.194.206 palmi194206.palmira.unal.edu.co > 168.176.194.207 palmi194207.palmira.unal.edu.co > 168.176.194.208 palmi194208.palmira.unal.edu.co > 168.176.194.209 palmi194209.palmira.unal.edu.co > 168.176.194.210 palmi194210.palmira.unal.edu.co > 168.176.194.211 palmi194211.palmira.unal.edu.co > 168.176.194.212 palmi194212.palmira.unal.edu.co > 168.176.194.213 palmi194213.palmira.unal.edu.co > 168.176.194.214 palmi194214.palmira.unal.edu.co > 168.176.194.215 palmi194215.palmira.unal.edu.co > 168.176.194.216 palmi194216.palmira.unal.edu.co > 168.176.194.217 palmi194217.palmira.unal.edu.co > 168.176.194.218 palmi194218.palmira.unal.edu.co > 168.176.194.219 palmi194219.palmira.unal.edu.co > 168.176.194.220 palmi194220.palmira.unal.edu.co > 168.176.194.221 palmi194221.palmira.unal.edu.co > 168.176.194.222 palmi194222.palmira.unal.edu.co > 168.176.194.223 palmi194223.palmira.unal.edu.co > 168.176.194.224 palmi194224.palmira.unal.edu.co > 168.176.194.225 palmi194225.palmira.unal.edu.co > 168.176.194.226 palmi194226.palmira.unal.edu.co > 168.176.194.227 palmi194227.palmira.unal.edu.co > 168.176.194.228 palmi194228.palmira.unal.edu.co > 168.176.194.229 palmi194229.palmira.unal.edu.co > 168.176.194.230 palmi194230.palmira.unal.edu.co > 168.176.194.231 palmi194231.palmira.unal.edu.co > 168.176.194.232 palmi194232.palmira.unal.edu.co > 168.176.194.233 palmi194233.palmira.unal.edu.co > 168.176.194.234 palmi194234.palmira.unal.edu.co > 168.176.194.235 palmi194235.palmira.unal.edu.co > 168.176.194.236 palmi194236.palmira.unal.edu.co > 168.176.194.237 palmi194237.palmira.unal.edu.co > 168.176.194.238 palmi194238.palmira.unal.edu.co > 168.176.194.239 palmi194239.palmira.unal.edu.co > 168.176.194.240 palmi194240.palmira.unal.edu.co > 168.176.194.241 palmi194241.palmira.unal.edu.co > 168.176.194.242 palmi194242.palmira.unal.edu.co > 168.176.194.243 palmi194243.palmira.unal.edu.co > 168.176.194.244 palmi194244.palmira.unal.edu.co > 168.176.194.245 palmi194245.palmira.unal.edu.co > 168.176.194.246 palmi194246.palmira.unal.edu.co > 168.176.194.247 palmi194247.palmira.unal.edu.co > 168.176.194.248 palmi194248.palmira.unal.edu.co > 168.176.194.249 palmi194249.palmira.unal.edu.co > 168.176.194.250 palmi194250.palmira.unal.edu.co > 168.176.194.251 palmi194251.palmira.unal.edu.co > 168.176.194.252 palmi194252.palmira.unal.edu.co > 168.176.194.253 palmi194253.palmira.unal.edu.co > 168.176.194.254 palmi194254.palmira.unal.edu.co > 181.57.40.0 static-ip-18157400.cable.net.co > 181.57.40.1 static-ip-18157401.cable.net.co > 181.57.40.2 static-ip-18157402.cable.net.co > 181.57.40.3 static-ip-18157403.cable.net.co > 181.57.40.4 static-ip-18157404.cable.net.co > 181.57.40.5 static-ip-18157405.cable.net.co > 181.57.40.6 static-ip-18157406.cable.net.co > 181.57.40.7 static-ip-18157407.cable.net.co > 181.57.40.8 static-ip-18157408.cable.net.co > 181.57.40.9 static-ip-18157409.cable.net.co > 181.57.40.10 static-ip-181574010.cable.net.co > 181.57.40.11 static-ip-181574011.cable.net.co > 181.57.40.12 static-ip-181574012.cable.net.co > 181.57.40.13 static-ip-181574013.cable.net.co > 181.57.40.14 static-ip-181574014.cable.net.co > 181.57.40.15 static-ip-181574015.cable.net.co > 181.57.40.16 static-ip-181574016.cable.net.co > 181.57.40.17 static-ip-181574017.cable.net.co > 181.57.40.18 static-ip-181574018.cable.net.co > 181.57.40.19 static-ip-181574019.cable.net.co > 181.57.40.20 static-ip-181574020.cable.net.co > 181.57.40.21 static-ip-181574021.cable.net.co > 181.57.40.22 static-ip-181574022.cable.net.co > 181.57.40.23 static-ip-181574023.cable.net.co > 181.57.40.24 static-ip-181574024.cable.net.co > 181.57.40.25 static-ip-181574025.cable.net.co > 181.57.40.26 static-ip-181574026.cable.net.co > 181.57.40.27 static-ip-181574027.cable.net.co > 181.57.40.28 static-ip-181574028.cable.net.co > 181.57.40.29 static-ip-181574029.cable.net.co > 181.57.40.30 static-ip-181574030.cable.net.co > 181.57.40.31 static-ip-181574031.cable.net.co > 181.57.40.32 static-ip-181574032.cable.net.co > 181.57.40.33 static-ip-181574033.cable.net.co > 181.57.40.34 static-ip-181574034.cable.net.co > 181.57.40.35 static-ip-181574035.cable.net.co > 181.57.40.36 static-ip-181574036.cable.net.co > 181.57.40.37 static-ip-181574037.cable.net.co > 181.57.40.38 static-ip-181574038.cable.net.co > 181.57.40.39 static-ip-181574039.cable.net.co > 181.57.40.40 static-ip-181574040.cable.net.co > 181.57.40.41 static-ip-181574041.cable.net.co > 181.57.40.42 static-ip-181574042.cable.net.co > 181.57.40.43 static-ip-181574043.cable.net.co > 181.57.40.44 static-ip-181574044.cable.net.co > 181.57.40.45 static-ip-181574045.cable.net.co > 181.57.40.46 static-ip-181574046.cable.net.co > 181.57.40.47 static-ip-181574047.cable.net.co > 181.57.40.48 static-ip-181574048.cable.net.co > 181.57.40.49 static-ip-181574049.cable.net.co > 181.57.40.50 static-ip-181574050.cable.net.co > 181.57.40.51 static-ip-181574051.cable.net.co > 181.57.40.52 static-ip-181574052.cable.net.co > 181.57.40.53 static-ip-181574053.cable.net.co > 181.57.40.54 static-ip-181574054.cable.net.co > 181.57.40.55 static-ip-181574055.cable.net.co > 181.57.40.56 static-ip-181574056.cable.net.co > 181.57.40.57 static-ip-181574057.cable.net.co > 181.57.40.58 static-ip-181574058.cable.net.co > 181.57.40.59 static-ip-181574059.cable.net.co > 181.57.40.60 static-ip-181574060.cable.net.co > 181.57.40.61 static-ip-181574061.cable.net.co > 181.57.40.62 static-ip-181574062.cable.net.co > 181.57.40.63 static-ip-181574063.cable.net.co > 181.57.40.64 static-ip-181574064.cable.net.co > 181.57.40.65 static-ip-181574065.cable.net.co > 181.57.40.66 static-ip-181574066.cable.net.co > 181.57.40.67 static-ip-181574067.cable.net.co > 181.57.40.68 static-ip-181574068.cable.net.co > 181.57.40.69 static-ip-181574069.cable.net.co > 181.57.40.70 static-ip-181574070.cable.net.co > 181.57.40.71 static-ip-181574071.cable.net.co > 181.57.40.72 static-ip-181574072.cable.net.co > 181.57.40.73 static-ip-181574073.cable.net.co > 181.57.40.74 static-ip-181574074.cable.net.co > 181.57.40.75 static-ip-181574075.cable.net.co > 181.57.40.76 static-ip-181574076.cable.net.co > 181.57.40.77 static-ip-181574077.cable.net.co > 181.57.40.78 static-ip-181574078.cable.net.co > 181.57.40.79 static-ip-181574079.cable.net.co > 181.57.40.80 static-ip-181574080.cable.net.co > 181.57.40.81 static-ip-181574081.cable.net.co > 181.57.40.82 static-ip-181574082.cable.net.co > 181.57.40.83 static-ip-181574083.cable.net.co > 181.57.40.84 static-ip-181574084.cable.net.co > 181.57.40.85 static-ip-181574085.cable.net.co > 181.57.40.86 static-ip-181574086.cable.net.co > 181.57.40.87 static-ip-181574087.cable.net.co > 181.57.40.88 static-ip-181574088.cable.net.co > 181.57.40.89 static-ip-181574089.cable.net.co > 181.57.40.90 static-ip-181574090.cable.net.co > 181.57.40.91 static-ip-181574091.cable.net.co > 181.57.40.92 static-ip-181574092.cable.net.co > 181.57.40.93 static-ip-181574093.cable.net.co > 181.57.40.94 static-ip-181574094.cable.net.co > 181.57.40.95 static-ip-181574095.cable.net.co > 181.57.40.96 static-ip-181574096.cable.net.co > 181.57.40.97 static-ip-181574097.cable.net.co > 181.57.40.98 static-ip-181574098.cable.net.co > 181.57.40.99 static-ip-181574099.cable.net.co > 181.57.40.100 static-ip-1815740100.cable.net.co > 181.57.40.101 static-ip-1815740101.cable.net.co > 181.57.40.102 static-ip-1815740102.cable.net.co > 181.57.40.103 static-ip-1815740103.cable.net.co > 181.57.40.104 static-ip-1815740104.cable.net.co > 181.57.40.105 static-ip-1815740105.cable.net.co > 181.57.40.106 static-ip-1815740106.cable.net.co > 181.57.40.107 static-ip-1815740107.cable.net.co > 181.57.40.108 static-ip-1815740108.cable.net.co > 181.57.40.109 static-ip-1815740109.cable.net.co > 181.57.40.110 static-ip-1815740110.cable.net.co > 181.57.40.111 static-ip-1815740111.cable.net.co > 181.57.40.112 static-ip-1815740112.cable.net.co > 181.57.40.113 static-ip-1815740113.cable.net.co > 181.57.40.114 static-ip-1815740114.cable.net.co > 181.57.40.115 static-ip-1815740115.cable.net.co > 181.57.40.116 static-ip-1815740116.cable.net.co > 181.57.40.117 static-ip-1815740117.cable.net.co > 181.57.40.118 static-ip-1815740118.cable.net.co > 181.57.40.119 static-ip-1815740119.cable.net.co > 181.57.40.120 static-ip-1815740120.cable.net.co > 181.57.40.121 static-ip-1815740121.cable.net.co > 181.57.40.122 static-ip-1815740122.cable.net.co > 181.57.40.123 static-ip-1815740123.cable.net.co > 181.57.40.124 static-ip-1815740124.cable.net.co > 181.57.40.125 static-ip-1815740125.cable.net.co > 181.57.40.126 static-ip-1815740126.cable.net.co > 181.57.40.127 static-ip-1815740127.cable.net.co > 181.57.40.128 static-ip-1815740128.cable.net.co > 181.57.40.129 static-ip-1815740129.cable.net.co > 181.57.40.130 static-ip-1815740130.cable.net.co > 181.57.40.131 static-ip-1815740131.cable.net.co > 181.57.40.132 static-ip-1815740132.cable.net.co > 181.57.40.133 static-ip-1815740133.cable.net.co > 181.57.40.134 static-ip-1815740134.cable.net.co > 181.57.40.135 static-ip-1815740135.cable.net.co > 181.57.40.136 static-ip-1815740136.cable.net.co > 181.57.40.137 static-ip-1815740137.cable.net.co > 181.57.40.138 static-ip-1815740138.cable.net.co > 181.57.40.139 static-ip-1815740139.cable.net.co > 181.57.40.140 static-ip-1815740140.cable.net.co > 181.57.40.141 static-ip-1815740141.cable.net.co > 181.57.40.142 static-ip-1815740142.cable.net.co > 181.57.40.143 static-ip-1815740143.cable.net.co > 181.57.40.144 static-ip-1815740144.cable.net.co > 181.57.40.145 static-ip-1815740145.cable.net.co > 181.57.40.146 static-ip-1815740146.cable.net.co > 181.57.40.147 static-ip-1815740147.cable.net.co > 181.57.40.148 static-ip-1815740148.cable.net.co > 181.57.40.149 static-ip-1815740149.cable.net.co > 181.57.40.150 static-ip-1815740150.cable.net.co > 181.57.40.151 static-ip-1815740151.cable.net.co > 181.57.40.152 static-ip-1815740152.cable.net.co > 181.57.40.153 static-ip-1815740153.cable.net.co > 181.57.40.154 static-ip-1815740154.cable.net.co > 181.57.40.155 static-ip-1815740155.cable.net.co > 181.57.40.156 static-ip-1815740156.cable.net.co > 181.57.40.157 static-ip-1815740157.cable.net.co > 181.57.40.158 static-ip-1815740158.cable.net.co > 181.57.40.159 static-ip-1815740159.cable.net.co > 181.57.40.160 static-ip-1815740160.cable.net.co > 181.57.40.161 static-ip-1815740161.cable.net.co > 181.57.40.162 static-ip-1815740162.cable.net.co > 181.57.40.163 static-ip-1815740163.cable.net.co > 181.57.40.164 static-ip-1815740164.cable.net.co > 181.57.40.165 static-ip-1815740165.cable.net.co > 181.57.40.166 static-ip-1815740166.cable.net.co > 181.57.40.167 static-ip-1815740167.cable.net.co > 181.57.40.168 static-ip-1815740168.cable.net.co > 181.57.40.169 static-ip-1815740169.cable.net.co > 181.57.40.170 static-ip-1815740170.cable.net.co > 181.57.40.171 static-ip-1815740171.cable.net.co > 181.57.40.172 static-ip-1815740172.cable.net.co > 181.57.40.173 static-ip-1815740173.cable.net.co > 181.57.40.174 static-ip-1815740174.cable.net.co > 181.57.40.175 static-ip-1815740175.cable.net.co > 181.57.40.176 static-ip-1815740176.cable.net.co > 181.57.40.177 static-ip-1815740177.cable.net.co > 181.57.40.178 static-ip-1815740178.cable.net.co > 181.57.40.179 static-ip-1815740179.cable.net.co > 181.57.40.180 static-ip-1815740180.cable.net.co > 181.57.40.181 static-ip-1815740181.cable.net.co > 181.57.40.182 static-ip-1815740182.cable.net.co > 181.57.40.183 static-ip-1815740183.cable.net.co > 181.57.40.184 static-ip-1815740184.cable.net.co > 181.57.40.185 static-ip-1815740185.cable.net.co > 181.57.40.186 static-ip-1815740186.cable.net.co > 181.57.40.187 static-ip-1815740187.cable.net.co > 181.57.40.188 static-ip-1815740188.cable.net.co > 181.57.40.189 static-ip-1815740189.cable.net.co > 181.57.40.190 static-ip-1815740190.cable.net.co > 181.57.40.191 static-ip-1815740191.cable.net.co > 181.57.40.192 static-ip-1815740192.cable.net.co > 181.57.40.193 static-ip-1815740193.cable.net.co > 181.57.40.194 static-ip-1815740194.cable.net.co > 181.57.40.195 static-ip-1815740195.cable.net.co > 181.57.40.196 static-ip-1815740196.cable.net.co > 181.57.40.197 static-ip-1815740197.cable.net.co > 181.57.40.198 static-ip-1815740198.cable.net.co > 181.57.40.199 static-ip-1815740199.cable.net.co > 181.57.40.200 static-ip-1815740200.cable.net.co > 181.57.40.201 static-ip-1815740201.cable.net.co > 181.57.40.202 static-ip-1815740202.cable.net.co > 181.57.40.203 static-ip-1815740203.cable.net.co > 181.57.40.204 static-ip-1815740204.cable.net.co > 181.57.40.205 static-ip-1815740205.cable.net.co > 181.57.40.206 static-ip-1815740206.cable.net.co > 181.57.40.207 static-ip-1815740207.cable.net.co > 181.57.40.208 static-ip-1815740208.cable.net.co > 181.57.40.209 static-ip-1815740209.cable.net.co > 181.57.40.210 static-ip-1815740210.cable.net.co > 181.57.40.211 static-ip-1815740211.cable.net.co > 181.57.40.212 static-ip-1815740212.cable.net.co > 181.57.40.213 static-ip-1815740213.cable.net.co > 181.57.40.214 static-ip-1815740214.cable.net.co > 181.57.40.215 static-ip-1815740215.cable.net.co > 181.57.40.216 static-ip-1815740216.cable.net.co > 181.57.40.217 static-ip-1815740217.cable.net.co > 181.57.40.218 static-ip-1815740218.cable.net.co > 181.57.40.219 static-ip-1815740219.cable.net.co > 181.57.40.220 static-ip-1815740220.cable.net.co > 181.57.40.221 static-ip-1815740221.cable.net.co > 181.57.40.222 static-ip-1815740222.cable.net.co > 181.57.40.223 static-ip-1815740223.cable.net.co > 181.57.40.224 static-ip-1815740224.cable.net.co > 181.57.40.225 static-ip-1815740225.cable.net.co > 181.57.40.226 static-ip-1815740226.cable.net.co > 181.57.40.227 static-ip-1815740227.cable.net.co > 181.57.40.228 static-ip-1815740228.cable.net.co > 181.57.40.229 static-ip-1815740229.cable.net.co > 181.57.40.230 static-ip-1815740230.cable.net.co > 181.57.40.231 static-ip-1815740231.cable.net.co > 181.57.40.232 static-ip-1815740232.cable.net.co > 181.57.40.233 static-ip-1815740233.cable.net.co > 181.57.40.234 static-ip-1815740234.cable.net.co > 181.57.40.235 static-ip-1815740235.cable.net.co > 181.57.40.236 static-ip-1815740236.cable.net.co > 181.57.40.237 static-ip-1815740237.cable.net.co > 181.57.40.238 static-ip-1815740238.cable.net.co > 181.57.40.239 static-ip-1815740239.cable.net.co > 181.57.40.240 static-ip-1815740240.cable.net.co > 181.57.40.241 static-ip-1815740241.cable.net.co > 181.57.40.242 static-ip-1815740242.cable.net.co > 181.57.40.243 static-ip-1815740243.cable.net.co > 181.57.40.244 static-ip-1815740244.cable.net.co > 181.57.40.245 static-ip-1815740245.cable.net.co > 181.57.40.246 static-ip-1815740246.cable.net.co > 181.57.40.247 static-ip-1815740247.cable.net.co > 181.57.40.248 static-ip-1815740248.cable.net.co > 181.57.40.249 static-ip-1815740249.cable.net.co > 181.57.40.250 static-ip-1815740250.cable.net.co > 181.57.40.251 static-ip-1815740251.cable.net.co > 181.57.40.252 static-ip-1815740252.cable.net.co > 181.57.40.253 static-ip-1815740253.cable.net.co > 181.57.40.254 static-ip-1815740254.cable.net.co > 181.57.40.255 static-ip-1815740255.cable.net.co > 186.147.230.0 static-ip-1861472300.cable.net.co > 186.147.230.1 static-ip-1861472301.cable.net.co > 186.147.230.2 static-ip-1861472302.cable.net.co > 186.147.230.3 static-ip-1861472303.cable.net.co > 186.147.230.4 static-ip-1861472304.cable.net.co > 186.147.230.5 static-ip-1861472305.cable.net.co > 186.147.230.6 static-ip-1861472306.cable.net.co > 186.147.230.7 static-ip-1861472307.cable.net.co > 186.147.230.8 static-ip-1861472308.cable.net.co > 186.147.230.9 static-ip-1861472309.cable.net.co > 186.147.230.10 static-ip-18614723010.cable.net.co > 186.147.230.11 static-ip-18614723011.cable.net.co > 186.147.230.12 static-ip-18614723012.cable.net.co > 186.147.230.13 static-ip-18614723013.cable.net.co > 186.147.230.14 static-ip-18614723014.cable.net.co > 186.147.230.15 static-ip-18614723015.cable.net.co > 186.147.230.16 static-ip-18614723016.cable.net.co > 186.147.230.17 static-ip-18614723017.cable.net.co > 186.147.230.18 static-ip-18614723018.cable.net.co > 186.147.230.19 static-ip-18614723019.cable.net.co > 186.147.230.20 static-ip-18614723020.cable.net.co > 186.147.230.21 static-ip-18614723021.cable.net.co > 186.147.230.22 static-ip-18614723022.cable.net.co > 186.147.230.23 static-ip-18614723023.cable.net.co > 186.147.230.24 static-ip-18614723024.cable.net.co > 186.147.230.25 static-ip-18614723025.cable.net.co > 186.147.230.26 static-ip-18614723026.cable.net.co > 186.147.230.27 static-ip-18614723027.cable.net.co > 186.147.230.28 static-ip-18614723028.cable.net.co > 186.147.230.29 static-ip-18614723029.cable.net.co > 186.147.230.30 static-ip-18614723030.cable.net.co > 186.147.230.31 static-ip-18614723031.cable.net.co > 186.147.230.32 static-ip-18614723032.cable.net.co > 186.147.230.33 static-ip-18614723033.cable.net.co > 186.147.230.34 static-ip-18614723034.cable.net.co > 186.147.230.35 static-ip-18614723035.cable.net.co > 186.147.230.36 static-ip-18614723036.cable.net.co > 186.147.230.37 static-ip-18614723037.cable.net.co > 186.147.230.38 static-ip-18614723038.cable.net.co > 186.147.230.39 static-ip-18614723039.cable.net.co > 186.147.230.40 static-ip-18614723040.cable.net.co > 186.147.230.41 static-ip-18614723041.cable.net.co > 186.147.230.42 static-ip-18614723042.cable.net.co > 186.147.230.43 static-ip-18614723043.cable.net.co > 186.147.230.44 static-ip-18614723044.cable.net.co > 186.147.230.45 static-ip-18614723045.cable.net.co > 186.147.230.46 static-ip-18614723046.cable.net.co > 186.147.230.47 static-ip-18614723047.cable.net.co > 186.147.230.48 static-ip-18614723048.cable.net.co > 186.147.230.49 static-ip-18614723049.cable.net.co > 186.147.230.50 static-ip-18614723050.cable.net.co > 186.147.230.51 static-ip-18614723051.cable.net.co > 186.147.230.52 static-ip-18614723052.cable.net.co > 186.147.230.53 static-ip-18614723053.cable.net.co > 186.147.230.54 static-ip-18614723054.cable.net.co > 186.147.230.55 static-ip-18614723055.cable.net.co > 186.147.230.56 static-ip-18614723056.cable.net.co > 186.147.230.57 static-ip-18614723057.cable.net.co > 186.147.230.58 static-ip-18614723058.cable.net.co > 186.147.230.59 static-ip-18614723059.cable.net.co > 186.147.230.60 static-ip-18614723060.cable.net.co > 186.147.230.61 static-ip-18614723061.cable.net.co > 186.147.230.62 static-ip-18614723062.cable.net.co > 186.147.230.63 static-ip-18614723063.cable.net.co > 186.147.230.64 static-ip-18614723064.cable.net.co > 186.147.230.65 static-ip-18614723065.cable.net.co > 186.147.230.66 static-ip-18614723066.cable.net.co > 186.147.230.67 static-ip-18614723067.cable.net.co > 186.147.230.68 static-ip-18614723068.cable.net.co > 186.147.230.69 static-ip-18614723069.cable.net.co > 186.147.230.70 static-ip-18614723070.cable.net.co > 186.147.230.71 static-ip-18614723071.cable.net.co > 186.147.230.72 static-ip-18614723072.cable.net.co > 186.147.230.73 static-ip-18614723073.cable.net.co > 186.147.230.74 static-ip-18614723074.cable.net.co > 186.147.230.75 static-ip-18614723075.cable.net.co > 186.147.230.76 static-ip-18614723076.cable.net.co > 186.147.230.77 static-ip-18614723077.cable.net.co > 186.147.230.78 static-ip-18614723078.cable.net.co > 186.147.230.79 static-ip-18614723079.cable.net.co > 186.147.230.80 static-ip-18614723080.cable.net.co > 186.147.230.81 static-ip-18614723081.cable.net.co > 186.147.230.82 static-ip-18614723082.cable.net.co > 186.147.230.83 static-ip-18614723083.cable.net.co > 186.147.230.84 static-ip-18614723084.cable.net.co > 186.147.230.85 static-ip-18614723085.cable.net.co > 186.147.230.86 static-ip-18614723086.cable.net.co > 186.147.230.87 static-ip-18614723087.cable.net.co > 186.147.230.88 static-ip-18614723088.cable.net.co > 186.147.230.89 static-ip-18614723089.cable.net.co > 186.147.230.90 static-ip-18614723090.cable.net.co > 186.147.230.91 static-ip-18614723091.cable.net.co > 186.147.230.92 static-ip-18614723092.cable.net.co > 186.147.230.93 static-ip-18614723093.cable.net.co > 186.147.230.94 static-ip-18614723094.cable.net.co > 186.147.230.95 static-ip-18614723095.cable.net.co > 186.147.230.96 static-ip-18614723096.cable.net.co > 186.147.230.97 static-ip-18614723097.cable.net.co > 186.147.230.98 static-ip-18614723098.cable.net.co > 186.147.230.99 static-ip-18614723099.cable.net.co > 186.147.230.100 static-ip-186147230100.cable.net.co > 186.147.230.101 static-ip-186147230101.cable.net.co > 186.147.230.102 static-ip-186147230102.cable.net.co > 186.147.230.103 static-ip-186147230103.cable.net.co > 186.147.230.104 static-ip-186147230104.cable.net.co > 186.147.230.105 static-ip-186147230105.cable.net.co > 186.147.230.106 static-ip-186147230106.cable.net.co > 186.147.230.107 static-ip-186147230107.cable.net.co > 186.147.230.108 static-ip-186147230108.cable.net.co > 186.147.230.109 static-ip-186147230109.cable.net.co > 186.147.230.110 static-ip-186147230110.cable.net.co > 186.147.230.111 static-ip-186147230111.cable.net.co > 186.147.230.112 static-ip-186147230112.cable.net.co > 186.147.230.113 static-ip-186147230113.cable.net.co > 186.147.230.114 static-ip-186147230114.cable.net.co > 186.147.230.115 static-ip-186147230115.cable.net.co > 186.147.230.116 static-ip-186147230116.cable.net.co > 186.147.230.117 static-ip-186147230117.cable.net.co > 186.147.230.118 static-ip-186147230118.cable.net.co > 186.147.230.119 static-ip-186147230119.cable.net.co > 186.147.230.120 static-ip-186147230120.cable.net.co > 186.147.230.121 static-ip-186147230121.cable.net.co > 186.147.230.122 static-ip-186147230122.cable.net.co > 186.147.230.123 static-ip-186147230123.cable.net.co > 186.147.230.124 static-ip-186147230124.cable.net.co > 186.147.230.125 static-ip-186147230125.cable.net.co > 186.147.230.126 static-ip-186147230126.cable.net.co > 186.147.230.127 static-ip-186147230127.cable.net.co > 186.147.230.128 static-ip-186147230128.cable.net.co > 186.147.230.129 static-ip-186147230129.cable.net.co > 186.147.230.130 static-ip-186147230130.cable.net.co > 186.147.230.131 static-ip-186147230131.cable.net.co > 186.147.230.132 static-ip-186147230132.cable.net.co > 186.147.230.133 static-ip-186147230133.cable.net.co > 186.147.230.134 static-ip-186147230134.cable.net.co > 186.147.230.135 static-ip-186147230135.cable.net.co > 186.147.230.136 static-ip-186147230136.cable.net.co > 186.147.230.137 static-ip-186147230137.cable.net.co > 186.147.230.138 static-ip-186147230138.cable.net.co > 186.147.230.139 static-ip-186147230139.cable.net.co > 186.147.230.140 static-ip-186147230140.cable.net.co > 186.147.230.141 static-ip-186147230141.cable.net.co > 186.147.230.142 static-ip-186147230142.cable.net.co > 186.147.230.143 static-ip-186147230143.cable.net.co > 186.147.230.144 static-ip-186147230144.cable.net.co > 186.147.230.145 static-ip-186147230145.cable.net.co > 186.147.230.146 static-ip-186147230146.cable.net.co > 186.147.230.147 static-ip-186147230147.cable.net.co > 186.147.230.148 static-ip-186147230148.cable.net.co > 186.147.230.149 static-ip-186147230149.cable.net.co > 186.147.230.150 static-ip-186147230150.cable.net.co > 186.147.230.151 static-ip-186147230151.cable.net.co > 186.147.230.152 static-ip-186147230152.cable.net.co > 186.147.230.153 static-ip-186147230153.cable.net.co > 186.147.230.154 static-ip-186147230154.cable.net.co > 186.147.230.155 static-ip-186147230155.cable.net.co > 186.147.230.156 static-ip-186147230156.cable.net.co > 186.147.230.157 static-ip-186147230157.cable.net.co > 186.147.230.158 static-ip-186147230158.cable.net.co > 186.147.230.159 static-ip-186147230159.cable.net.co > 186.147.230.160 static-ip-186147230160.cable.net.co > 186.147.230.161 static-ip-186147230161.cable.net.co > 186.147.230.162 static-ip-186147230162.cable.net.co > 186.147.230.163 static-ip-186147230163.cable.net.co > 186.147.230.164 static-ip-186147230164.cable.net.co > 186.147.230.165 static-ip-186147230165.cable.net.co > 186.147.230.166 static-ip-186147230166.cable.net.co > 186.147.230.167 static-ip-186147230167.cable.net.co > 186.147.230.168 static-ip-186147230168.cable.net.co > 186.147.230.169 static-ip-186147230169.cable.net.co > 186.147.230.170 static-ip-186147230170.cable.net.co > 186.147.230.171 static-ip-186147230171.cable.net.co > 186.147.230.172 static-ip-186147230172.cable.net.co > 186.147.230.173 static-ip-186147230173.cable.net.co > 186.147.230.174 static-ip-186147230174.cable.net.co > 186.147.230.175 static-ip-186147230175.cable.net.co > 186.147.230.176 static-ip-186147230176.cable.net.co > 186.147.230.177 static-ip-186147230177.cable.net.co > 186.147.230.178 static-ip-186147230178.cable.net.co > 186.147.230.179 static-ip-186147230179.cable.net.co > 186.147.230.180 static-ip-186147230180.cable.net.co > 186.147.230.181 static-ip-186147230181.cable.net.co > 186.147.230.182 static-ip-186147230182.cable.net.co > 186.147.230.183 static-ip-186147230183.cable.net.co > 186.147.230.184 static-ip-186147230184.cable.net.co > 186.147.230.185 static-ip-186147230185.cable.net.co > 186.147.230.186 static-ip-186147230186.cable.net.co > 186.147.230.187 static-ip-186147230187.cable.net.co > 186.147.230.188 static-ip-186147230188.cable.net.co > 186.147.230.189 static-ip-186147230189.cable.net.co > 186.147.230.190 static-ip-186147230190.cable.net.co > 186.147.230.191 static-ip-186147230191.cable.net.co > 186.147.230.192 static-ip-186147230192.cable.net.co > 186.147.230.193 static-ip-186147230193.cable.net.co > 186.147.230.194 static-ip-186147230194.cable.net.co > 186.147.230.195 static-ip-186147230195.cable.net.co > 186.147.230.196 static-ip-186147230196.cable.net.co > 186.147.230.197 static-ip-186147230197.cable.net.co > 186.147.230.198 static-ip-186147230198.cable.net.co > 186.147.230.199 static-ip-186147230199.cable.net.co > 186.147.230.200 static-ip-186147230200.cable.net.co > 186.147.230.201 static-ip-186147230201.cable.net.co > 186.147.230.202 static-ip-186147230202.cable.net.co > 186.147.230.203 static-ip-186147230203.cable.net.co > 186.147.230.204 static-ip-186147230204.cable.net.co > 186.147.230.205 static-ip-186147230205.cable.net.co > 186.147.230.206 static-ip-186147230206.cable.net.co > 186.147.230.207 static-ip-186147230207.cable.net.co > 186.147.230.208 static-ip-186147230208.cable.net.co > 186.147.230.209 static-ip-186147230209.cable.net.co > 186.147.230.210 static-ip-186147230210.cable.net.co > 186.147.230.211 static-ip-186147230211.cable.net.co > 186.147.230.212 static-ip-186147230212.cable.net.co > 186.147.230.213 static-ip-186147230213.cable.net.co > 186.147.230.214 static-ip-186147230214.cable.net.co > 186.147.230.215 static-ip-186147230215.cable.net.co > 186.147.230.216 static-ip-186147230216.cable.net.co > 186.147.230.217 static-ip-186147230217.cable.net.co > 186.147.230.218 static-ip-186147230218.cable.net.co > 186.147.230.219 static-ip-186147230219.cable.net.co > 186.147.230.220 static-ip-186147230220.cable.net.co > 186.147.230.221 static-ip-186147230221.cable.net.co > 186.147.230.222 static-ip-186147230222.cable.net.co > 186.147.230.223 static-ip-186147230223.cable.net.co > 186.147.230.224 static-ip-186147230224.cable.net.co > 186.147.230.225 static-ip-186147230225.cable.net.co > 186.147.230.226 static-ip-186147230226.cable.net.co > 186.147.230.227 static-ip-186147230227.cable.net.co > 186.147.230.228 static-ip-186147230228.cable.net.co > 186.147.230.229 static-ip-186147230229.cable.net.co > 186.147.230.230 static-ip-186147230230.cable.net.co > 186.147.230.231 static-ip-186147230231.cable.net.co > 186.147.230.232 static-ip-186147230232.cable.net.co > 186.147.230.233 static-ip-186147230233.cable.net.co > 186.147.230.234 static-ip-186147230234.cable.net.co > 186.147.230.235 static-ip-186147230235.cable.net.co > 186.147.230.236 static-ip-186147230236.cable.net.co > 186.147.230.237 static-ip-186147230237.cable.net.co > 186.147.230.238 static-ip-186147230238.cable.net.co > 186.147.230.239 static-ip-186147230239.cable.net.co > 186.147.230.240 static-ip-186147230240.cable.net.co > 186.147.230.241 static-ip-186147230241.cable.net.co > 186.147.230.242 static-ip-186147230242.cable.net.co > 186.147.230.243 static-ip-186147230243.cable.net.co > 186.147.230.244 static-ip-186147230244.cable.net.co > 186.147.230.245 static-ip-186147230245.cable.net.co > 186.147.230.246 static-ip-186147230246.cable.net.co > 186.147.230.247 static-ip-186147230247.cable.net.co > 186.147.230.248 static-ip-186147230248.cable.net.co > 186.147.230.249 static-ip-186147230249.cable.net.co > 186.147.230.250 static-ip-186147230250.cable.net.co > 186.147.230.251 static-ip-186147230251.cable.net.co > 186.147.230.252 static-ip-186147230252.cable.net.co > 186.147.230.253 static-ip-186147230253.cable.net.co > 186.147.230.254 static-ip-186147230254.cable.net.co > 186.147.230.255 static-ip-186147230255.cable.net.co > 190.90.88.3 smtp.tvnet.com.ec > 200.14.44.1 host-200.14.44.1.merca.net.co > 200.14.44.2 host-200.14.44.2.merca.net.co > 200.14.44.3 host-200.14.44.3.merca.net.co > 200.14.44.4 host-200.14.44.4.merca.net.co > 200.14.44.5 host-200.14.44.5.merca.net.co > 200.14.44.6 host-200.14.44.6.merca.net.co > 200.14.44.7 host-200.14.44.7.merca.net.co > 200.14.44.8 host-200.14.44.8.merca.net.co > 200.14.44.9 host-200.14.44.9.merca.net.co > 200.14.44.10 host-200.14.44.10.merca.net.co > 200.14.44.11 host-200.14.44.11.merca.net.co > 200.14.44.12 host-200.14.44.12.merca.net.co > 200.14.44.13 host-200.14.44.13.merca.net.co > 200.14.44.14 host-200.14.44.14.merca.net.co > 200.14.44.15 host-200.14.44.15.merca.net.co > 200.14.44.16 host-200.14.44.16.merca.net.co > 200.14.44.17 host-200.14.44.17.merca.net.co > 200.14.44.18 host-200.14.44.18.merca.net.co > 200.14.44.19 host-200.14.44.19.merca.net.co > 200.14.44.20 host-200.14.44.20.merca.net.co > 200.14.44.21 host-200.14.44.21.merca.net.co > 200.14.44.22 host-200.14.44.22.merca.net.co > 200.14.44.23 host-200.14.44.23.merca.net.co > 200.14.44.24 host-200.14.44.24.merca.net.co > 200.14.44.25 host-200.14.44.25.merca.net.co > 200.14.44.26 host-200.14.44.26.merca.net.co > 200.14.44.27 host-200.14.44.27.merca.net.co > 200.14.44.28 host-200.14.44.28.merca.net.co > 200.14.44.29 host-200.14.44.29.merca.net.co > 200.14.44.30 host-200.14.44.30.merca.net.co > 200.14.44.31 host-200.14.44.31.merca.net.co > 200.14.44.32 host-200.14.44.32.merca.net.co > 200.14.44.33 host-200.14.44.33.merca.net.co > 200.14.44.34 host-200.14.44.34.merca.net.co > 200.14.44.35 host-200.14.44.35.merca.net.co > 200.14.44.36 host-200.14.44.36.merca.net.co > 200.14.44.37 host-200.14.44.37.merca.net.co > 200.14.44.38 host-200.14.44.38.merca.net.co > 200.14.44.39 host-200.14.44.39.merca.net.co > 200.14.44.40 host-200.14.44.40.merca.net.co > 200.14.44.41 host-200.14.44.41.merca.net.co > 200.14.44.42 host-200.14.44.42.merca.net.co > 200.14.44.43 host-200.14.44.43.merca.net.co > 200.14.44.44 host-200.14.44.44.merca.net.co > 200.14.44.45 host-200.14.44.45.merca.net.co > 200.14.44.46 host-200.14.44.46.merca.net.co > 200.14.44.47 host-200.14.44.47.merca.net.co > 200.14.44.48 host-200.14.44.48.merca.net.co > 200.14.44.49 host-200.14.44.49.merca.net.co > 200.14.44.50 host-200.14.44.50.merca.net.co > 200.14.44.51 host-200.14.44.51.merca.net.co > 200.14.44.52 host-200.14.44.52.merca.net.co > 200.14.44.53 host-200.14.44.53.merca.net.co > 200.14.44.54 host-200.14.44.54.merca.net.co > 200.14.44.55 host-200.14.44.55.merca.net.co > 200.14.44.56 host-200.14.44.56.merca.net.co > 200.14.44.57 host-200.14.44.57.merca.net.co > 200.14.44.58 host-200.14.44.58.merca.net.co > 200.14.44.59 host-200.14.44.59.merca.net.co > 200.14.44.60 host-200.14.44.60.merca.net.co > 200.14.44.61 host-200.14.44.61.merca.net.co > 200.14.44.62 host-200.14.44.62.merca.net.co > 200.14.44.63 host-200.14.44.63.merca.net.co > 200.14.44.64 host-200.14.44.64.merca.net.co > 200.14.44.65 host-200.14.44.65.merca.net.co > 200.14.44.66 host-200.14.44.66.merca.net.co > 200.14.44.67 host-200.14.44.67.merca.net.co > 200.14.44.68 host-200.14.44.68.merca.net.co > 200.14.44.69 host-200.14.44.69.merca.net.co > 200.14.44.70 host-200.14.44.70.merca.net.co > 200.14.44.71 host-200.14.44.71.merca.net.co > 200.14.44.72 host-200.14.44.72.merca.net.co > 200.14.44.73 host-200.14.44.73.merca.net.co > 200.14.44.74 host-200.14.44.74.merca.net.co > 200.14.44.75 host-200.14.44.75.merca.net.co > 200.14.44.76 host-200.14.44.76.merca.net.co > 200.14.44.77 host-200.14.44.77.merca.net.co > 200.14.44.78 host-200.14.44.78.merca.net.co > 200.14.44.79 host-200.14.44.79.merca.net.co > 200.14.44.80 host-200.14.44.80.merca.net.co > 200.14.44.81 host-200.14.44.81.merca.net.co > 200.14.44.82 host-200.14.44.82.merca.net.co > 200.14.44.83 host-200.14.44.83.merca.net.co > 200.14.44.84 host-200.14.44.84.merca.net.co > 200.14.44.85 host-200.14.44.85.merca.net.co > 200.14.44.86 host-200.14.44.86.merca.net.co > 200.14.44.87 host-200.14.44.87.merca.net.co > 200.14.44.88 host-200.14.44.88.merca.net.co > 200.14.44.89 host-200.14.44.89.merca.net.co > 200.14.44.90 host-200.14.44.90.merca.net.co > 200.14.44.91 host-200.14.44.91.merca.net.co > 200.14.44.92 host-200.14.44.92.merca.net.co > 200.14.44.93 host-200.14.44.93.merca.net.co > 200.14.44.94 host-200.14.44.94.merca.net.co > 200.14.44.95 host-200.14.44.95.merca.net.co > 200.14.44.96 host-200.14.44.96.merca.net.co > 200.14.44.97 host-200.14.44.97.merca.net.co > 200.14.44.98 host-200.14.44.98.merca.net.co > 200.14.44.99 host-200.14.44.99.merca.net.co > 200.14.44.100 host-200.14.44.100.merca.net.co > 200.14.44.101 host-200.14.44.101.merca.net.co > 200.14.44.102 host-200.14.44.102.merca.net.co > 200.14.44.103 host-200.14.44.103.merca.net.co > 200.14.44.104 host-200.14.44.104.merca.net.co > 200.14.44.105 host-200.14.44.105.merca.net.co > 200.14.44.106 host-200.14.44.106.merca.net.co > 200.14.44.107 host-200.14.44.107.merca.net.co > 200.14.44.108 host-200.14.44.108.merca.net.co > 200.14.44.109 host-200.14.44.109.merca.net.co > 200.14.44.110 host-200.14.44.110.merca.net.co > 200.14.44.111 host-200.14.44.111.merca.net.co > 200.14.44.112 host-200.14.44.112.merca.net.co > 200.14.44.113 host-200.14.44.113.merca.net.co > 200.14.44.114 host-200.14.44.114.merca.net.co > 200.14.44.115 host-200.14.44.115.merca.net.co > 200.14.44.116 host-200.14.44.116.merca.net.co > 200.14.44.117 host-200.14.44.117.merca.net.co > 200.14.44.118 host-200.14.44.118.merca.net.co > 200.14.44.119 host-200.14.44.119.merca.net.co > 200.14.44.120 host-200.14.44.120.merca.net.co > 200.14.44.121 host-200.14.44.121.merca.net.co > 200.14.44.122 host-200.14.44.122.merca.net.co > 200.14.44.123 host-200.14.44.123.merca.net.co > 200.14.44.124 host-200.14.44.124.merca.net.co > 200.14.44.125 host-200.14.44.125.merca.net.co > 200.14.44.126 host-200.14.44.126.merca.net.co > 200.14.44.127 host-200.14.44.127.merca.net.co > 200.14.44.128 host-200.14.44.128.merca.net.co > 200.14.44.129 host-200.14.44.129.merca.net.co > 200.14.44.130 host-200.14.44.130.merca.net.co > 200.14.44.131 host-200.14.44.131.merca.net.co > 200.14.44.132 host-200.14.44.132.merca.net.co > 200.14.44.133 host-200.14.44.133.merca.net.co > 200.14.44.134 host-200.14.44.134.merca.net.co > 200.14.44.135 host-200.14.44.135.merca.net.co > 200.14.44.136 host-200.14.44.136.merca.net.co > 200.14.44.137 host-200.14.44.137.merca.net.co > 200.14.44.138 host-200.14.44.138.merca.net.co > 200.14.44.139 host-200.14.44.139.merca.net.co > 200.14.44.140 host-200.14.44.140.merca.net.co > 200.14.44.141 host-200.14.44.141.merca.net.co > 200.14.44.142 host-200.14.44.142.merca.net.co > 200.14.44.143 host-200.14.44.143.merca.net.co > 200.14.44.144 host-200.14.44.144.merca.net.co > 200.14.44.145 host-200.14.44.145.merca.net.co > 200.14.44.146 host-200.14.44.146.merca.net.co > 200.14.44.147 host-200.14.44.147.merca.net.co > 200.14.44.148 host-200.14.44.148.merca.net.co > 200.14.44.149 host-200.14.44.149.merca.net.co > 200.14.44.150 host-200.14.44.150.merca.net.co > 200.14.44.151 host-200.14.44.151.merca.net.co > 200.14.44.152 host-200.14.44.152.merca.net.co > 200.14.44.153 host-200.14.44.153.merca.net.co > 200.14.44.154 host-200.14.44.154.merca.net.co > 200.14.44.155 host-200.14.44.155.merca.net.co > 200.14.44.156 host-200.14.44.156.merca.net.co > 200.14.44.157 host-200.14.44.157.merca.net.co > 200.14.44.158 host-200.14.44.158.merca.net.co > 200.14.44.159 host-200.14.44.159.merca.net.co > 200.14.44.160 host-200.14.44.160.merca.net.co > 200.14.44.161 host-200.14.44.161.merca.net.co > 200.14.44.162 host-200.14.44.162.merca.net.co > 200.14.44.163 host-200.14.44.163.merca.net.co > 200.14.44.164 host-200.14.44.164.merca.net.co > 200.14.44.165 host-200.14.44.165.merca.net.co > 200.14.44.166 host-200.14.44.166.merca.net.co > 200.14.44.167 host-200.14.44.167.merca.net.co > 200.14.44.168 host-200.14.44.168.merca.net.co > 200.14.44.169 host-200.14.44.169.merca.net.co > 200.14.44.170 host-200.14.44.170.merca.net.co > 200.14.44.171 host-200.14.44.171.merca.net.co > 200.14.44.172 host-200.14.44.172.merca.net.co > 200.14.44.173 host-200.14.44.173.merca.net.co > 200.14.44.174 host-200.14.44.174.merca.net.co > 200.14.44.175 host-200.14.44.175.merca.net.co > 200.14.44.176 host-200.14.44.176.merca.net.co > 200.14.44.177 host-200.14.44.177.merca.net.co > 200.14.44.178 host-200.14.44.178.merca.net.co > 200.14.44.179 host-200.14.44.179.merca.net.co > 200.14.44.180 host-200.14.44.180.merca.net.co > 200.14.44.181 host-200.14.44.181.merca.net.co > 200.14.44.182 host-200.14.44.182.merca.net.co > 200.14.44.183 host-200.14.44.183.merca.net.co > 200.14.44.184 host-200.14.44.184.merca.net.co > 200.14.44.185 host-200.14.44.185.merca.net.co > 200.14.44.186 host-200.14.44.186.merca.net.co > 200.14.44.187 host-200.14.44.187.merca.net.co > 200.14.44.188 host-200.14.44.188.merca.net.co > 200.14.44.189 host-200.14.44.189.merca.net.co > 200.14.44.190 host-200.14.44.190.merca.net.co > 200.14.44.191 host-200.14.44.191.merca.net.co > 200.14.44.192 host-200.14.44.192.merca.net.co > 200.14.44.193 host-200.14.44.193.merca.net.co > 200.14.44.194 host-200.14.44.194.merca.net.co > 200.14.44.195 host-200.14.44.195.merca.net.co > 200.14.44.196 host-200.14.44.196.merca.net.co > 200.14.44.197 host-200.14.44.197.merca.net.co > 200.14.44.198 host-200.14.44.198.merca.net.co > 200.14.44.199 host-200.14.44.199.merca.net.co > 200.14.44.200 host-200.14.44.200.merca.net.co > 200.14.44.201 host-200.14.44.201.merca.net.co > 200.14.44.202 host-200.14.44.202.merca.net.co > 200.14.44.203 host-200.14.44.203.merca.net.co > 200.14.44.204 host-200.14.44.204.merca.net.co > 200.14.44.205 host-200.14.44.205.merca.net.co > 200.14.44.206 host-200.14.44.206.merca.net.co > 200.14.44.207 host-200.14.44.207.merca.net.co > 200.14.44.208 host-200.14.44.208.merca.net.co > 200.14.44.209 host-200.14.44.209.merca.net.co > 200.14.44.210 host-200.14.44.210.merca.net.co > 200.14.44.211 host-200.14.44.211.merca.net.co > 200.14.44.212 host-200.14.44.212.merca.net.co > 200.14.44.213 host-200.14.44.213.merca.net.co > 200.14.44.214 host-200.14.44.214.merca.net.co > 200.14.44.215 host-200.14.44.215.merca.net.co > 200.14.44.216 host-200.14.44.216.merca.net.co > 200.14.44.217 host-200.14.44.217.merca.net.co > 200.14.44.218 host-200.14.44.218.merca.net.co > 200.14.44.219 host-200.14.44.219.merca.net.co > 200.14.44.220 host-200.14.44.220.merca.net.co > 200.14.44.221 host-200.14.44.221.merca.net.co > 200.14.44.222 host-200.14.44.222.merca.net.co > 200.14.44.223 host-200.14.44.223.merca.net.co > 200.14.44.224 host-200.14.44.224.merca.net.co > 200.14.44.225 host-200.14.44.225.merca.net.co > 200.14.44.226 host-200.14.44.226.merca.net.co > 200.14.44.227 host-200.14.44.227.merca.net.co > 200.14.44.228 host-200.14.44.228.merca.net.co > 200.14.44.229 host-200.14.44.229.merca.net.co > 200.14.44.230 host-200.14.44.230.merca.net.co > 200.14.44.231 host-200.14.44.231.merca.net.co > 200.14.44.232 host-200.14.44.232.merca.net.co > 200.14.44.233 host-200.14.44.233.merca.net.co > 200.14.44.234 host-200.14.44.234.merca.net.co > 200.14.44.235 host-200.14.44.235.merca.net.co > 200.14.44.236 host-200.14.44.236.merca.net.co > 200.14.44.237 host-200.14.44.237.merca.net.co > 200.14.44.238 host-200.14.44.238.merca.net.co > 200.14.44.239 host-200.14.44.239.merca.net.co > 200.14.44.240 host-200.14.44.240.merca.net.co > 200.14.44.241 host-200.14.44.241.merca.net.co > 200.14.44.242 host-200.14.44.242.merca.net.co > 200.14.44.243 host-200.14.44.243.merca.net.co > 200.14.44.244 host-200.14.44.244.merca.net.co > 200.14.44.245 host-200.14.44.245.merca.net.co > 200.14.44.246 host-200.14.44.246.merca.net.co > 200.14.44.247 host-200.14.44.247.merca.net.co > 200.14.44.248 host-200.14.44.248.merca.net.co > 200.14.44.249 host-200.14.44.249.merca.net.co > 200.14.44.250 host-200.14.44.250.merca.net.co > 200.14.44.251 host-200.14.44.251.merca.net.co > 200.14.44.252 host-200.14.44.252.merca.net.co > 200.14.44.253 host-200.14.44.253.merca.net.co > 200.14.44.254 host-200.14.44.254.merca.net.co > 200.24.5.37 mail.cecep.edu.co > 200.24.5.51 correo.isagen.com.co > 200.24.5.51 gfiserver.isagen.com.co > 200.24.5.90 mail.hptu.org.co > 200.24.5.126 correo.sonoco.com.co > 200.24.5.133 correo.fibrexa.com.co > 200.24.5.185 dns.datawareltda.com > 200.24.5.185 webserver.datawareltda.com > 200.24.5.187 dnsdw.datawareltda.com > 200.24.5.189 correo.datawareltda.com > 200.24.5.210 mail.globalmanagement.com.co > 200.24.5.250 mail.araujoibarra.com > From morrowc.lists at gmail.com Tue Jun 6 19:26:46 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Jun 2017 15:26:46 -0400 Subject: Templating/automating configuration In-Reply-To: <5936B7B4.8010508@foobar.org> References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> <5936B7B4.8010508@foobar.org> Message-ID: https://youtu.be/ltqXgtLWXFo and the assocaited pdf https://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf On Tue, Jun 6, 2017 at 10:09 AM, Nick Hilliard wrote: > Graham Johnston wrote: > > Short of complete SDN, for those of you that have some degree of > > configuration templating and/or automation tools what is it that you > > run? I'm envisioning some sort of tool that let's me define template > > snippets of configuration and aids in their deployment to devices. > > I'm okay doing the heaving lifting in defining everything, I'm just > > looking for the tool that stitches it together and hopefully makes > > things a little less error prone for those who aren't as adept. > > you would probably want to look at napalm for something like this. It > will back-end into ansible or more recently, salt stack. > > Nick > From ml at knight-networks.com Tue Jun 6 20:48:20 2017 From: ml at knight-networks.com (Brian Knight) Date: Tue, 06 Jun 2017 15:48:20 -0500 Subject: Templating/automating configuration Message-ID: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> Because we had different sources of truth which were written in-house, we wound up rolling our own template engine in Python. It took about 3 weeks to write the engine and adapt existing templates. Given a circuit ID, it generates the full config for copy and paste into a terminal session. It also hooks into a configuration parser tool, written in-house, that tracks configured interfaces, so it is easy to see whether the template would overwrite an existing interface. I used the Jinja2 template engine, along with pyodbc/unixODBC/FreeTDS for access to a Microsoft SQL backend. The keys for us are: * extracting information from a source of truth * validating the information for correctness * making sure you don't overwrite existing config * outputting the right templates for the circuit features It made more sense to write a tool than it did to try to adapt something for our environment. If I had a free hand and unlimited budget, I would find a single app that functions as a source of truth for all circuits and products, which includes a templating engine that hooks in easily. -Brian ---- On Tue, 06 Jun 2017 08:22:59 -0500 Graham Johnston <johnstong at westmancom.com> wrote ---- Short of complete SDN, for those of you that have some degree of configuration templating and/or automation tools what is it that you run? I'm envisioning some sort of tool that let's me define template snippets of configuration and aids in their deployment to devices. I'm okay doing the heaving lifting in defining everything, I'm just looking for the tool that stitches it together and hopefully makes things a little less error prone for those who aren't as adept. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com<mailto:johnstong at westmancom.com> From job at ntt.net Tue Jun 6 21:02:38 2017 From: job at ntt.net (Job Snijders) Date: Tue, 06 Jun 2017 21:02:38 +0000 Subject: Templating/automating configuration In-Reply-To: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> References: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> Message-ID: Hi, Here are some extra pointers: https://youtube.com/watch?v=C7pkab8n7ys https://www.nanog.org/sites/default/files/dosdontsnetworkautomation.pdf https://github.com/coloclue/kees Kind regards, Job On Tue, 6 Jun 2017 at 13:49, Brian Knight wrote: > Because we had different sources of truth which were written in-house, we > wound up rolling our own template engine in Python. It took about 3 weeks > to write the engine and adapt existing templates. Given a circuit ID, it > generates the full config for copy and paste into a terminal session. It > also hooks into a configuration parser tool, written in-house, that tracks > configured interfaces, so it is easy to see whether the template would > overwrite an existing interface. > > > > I used the Jinja2 template engine, along with pyodbc/unixODBC/FreeTDS for > access to a Microsoft SQL backend. > > > > The keys for us are: > > > > * extracting information from a source of truth > > * validating the information for correctness > > * making sure you don't overwrite existing config > > * outputting the right templates for the circuit features > > > > It made more sense to write a tool than it did to try to adapt something > for our environment. > > > > If I had a free hand and unlimited budget, I would find a single app that > functions as a source of truth for all circuits and products, which > includes a templating engine that hooks in easily. > > > > -Brian > > > > > > ---- On Tue, 06 Jun 2017 08:22:59 -0500 Graham Johnston & > lt;johnstong at westmancom.com> wrote ---- > > > > > > > > > > > > Short of complete SDN, for those of you that have some degree of > configuration templating and/or automation tools what is it that you run? > I'm envisioning some sort of tool that let's me define template snippets of > configuration and aids in their deployment to devices. I'm okay doing the > heaving lifting in defining everything, I'm just looking for the tool that > stitches it together and hopefully makes things a little less error prone > for those who aren't as adept. > > > > Graham Johnston > > Network Planner > > Westman Communications Group > > 204.717.2829 > > johnstong at westmancom.com<mailto:johnstong at westmancom.com> > > > > > > From spedersen.lists at gmail.com Tue Jun 6 21:10:12 2017 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Tue, 6 Jun 2017 14:10:12 -0700 Subject: Looking for Cisco ASR9000v feedback In-Reply-To: References: <495D0934DA46854A9CA758393724D5907557AEB7@NI-MAIL02.nii.ads> Message-ID: <001d01d2df09$49a73400$dcf59c00$@gmail.com> Yeah - look for bundles if possible. I know it cut about 3/4 of the cost off of an NCS5K that we were looking at in a ASR9K satellite config. Also, if you're doing satellite on the 9000V, I believe support for that feature is going away in a future version of IOS-XR. Double-check w/ your account team. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tom Hill Sent: Tuesday, June 6, 2017 7:53 AM To: nanog at nanog.org Subject: Re: Looking for Cisco ASR9000v feedback On 06/06/17 15:34, Erik Sundberg wrote: > Looking for the pro's, con's, and the gotcha's of moving our 1G ports to the 9000V. The nV licenses for one. Talk about printing money. -- Tom From dave at temk.in Tue Jun 6 21:24:05 2017 From: dave at temk.in (Dave Temkin) Date: Tue, 6 Jun 2017 14:24:05 -0700 Subject: NANOG 70 network diagram and upstream In-Reply-To: References: <001401d2dbe2$73248230$596d8690$@gvtc.com> Message-ID: Yes, frankly, it doesn't cost us (NANOG) anything - the sponsors like to do it for the "cool" factor, and so long as it's not an undue burden on us, they can throw as much bandwidth at us as they'd like. -Dave On Sun, Jun 4, 2017 at 4:02 PM, James Breeden wrote: > Yeah, I was wondering about that 4x100G. is that a necessity or a "because > we can" move? > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas > Sent: Friday, June 2, 2017 4:35 PM > To: Aaron Gould > Cc: NANOG > Subject: RE: NANOG 70 network diagram and upstream > > And the 4x100G. That's four times the capacity of the network I work for. > ~100k subs. > > On Jun 2, 2017 16:54, "Aaron Gould" wrote: > > > Btw.... > > > > Wow, a ~2 million dollar boundary (dual PTX1000's) for the NANOG 70 > > conference.... geez > > > > -aaron > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke > > Sent: Friday, June 2, 2017 1:43 PM > > To: nanog at nanog.org list > > Subject: NANOG 70 network diagram and upstream > > > > Just a small thing, but as one of the folks who used to work on the > > core network gear of AS11404, the network diagram has something in it > > that might confuse attendees as to who is really sponsoring the upstream: > > > > https://www.nanog.org/meetings/nanog70/diagram > > > > AS11404 was formerly known as Spectrum Networks, acquired in 2013 by > > Wavedivision Holdings LLC (Wave Broadband) and became the backbone of > > the Wave network. It's a totally different thing than the Charter > > service which is trademarked as as Spectrum. > > > > https://www.peeringdb.com/asn/11404 > > > > The logo in the right side bubble there shouldn't be the > > Charter/Spectrum trademarked font, but rather should be Wave, who > > built the dark fiber into the hotel and are providing the upstream. > > The last mile fiber into the hotel is Wave. > > > > > > -Eric > > > > > From alexis.letessier at gmail.com Tue Jun 6 21:03:14 2017 From: alexis.letessier at gmail.com (Alexis Letessier) Date: Tue, 6 Jun 2017 23:03:14 +0200 Subject: Templating/automating configuration In-Reply-To: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> Message-ID: Go templates: http://golang.org Fast and simple with gRPC and other good stuff like kelsey?s confd (a daemon that watches for changes and update templates) % go doc text/template package template // import "text/template" Package template implements data-driven templates for generating textual output. To generate HTML output, see package html/template, which has the same interface as this package but automatically secures HTML output against certain attacks. Templates are executed by applying them to a data structure. Annotations in the template refer to elements of the data structure (typically a field of a struct or a key in a map) to control execution and derive values to be displayed. Execution of the template walks the structure and sets the cursor, represented by a period '.' and called "dot", to the value at the current location in the structure as execution proceeds. The input text for a template is UTF-8-encoded text in any format. "Actions"--data evaluations or control structures--are delimited by "{{" and "}}"; all text outside actions is copied to the output unchanged. Except for raw strings, actions may not span newlines, although comments can. Once parsed, a template may be executed safely in parallel. Here is a trivial example that prints "17 items are made of wool". type Inventory struct { Material string Count uint } sweaters := Inventory{"wool", 17} tmpl, err := template.New("test").Parse("{{.Count}} items are made of {{.Material}}") if err != nil { panic(err) } err = tmpl.Execute(os.Stdout, sweaters) if err != nil { panic(err) } Alexis > On 6 Jun 2017, at 15:22, Graham Johnston wrote: > > Short of complete SDN, for those of you that have some degree of configuration templating and/or automation tools what is it that you run? I'm envisioning some sort of tool that let's me define template snippets of configuration and aids in their deployment to devices. I'm okay doing the heaving lifting in defining everything, I'm just looking for the tool that stitches it together and hopefully makes things a little less error prone for those who aren't as adept. > > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > From andy at meniscus.org Tue Jun 6 22:39:44 2017 From: andy at meniscus.org (Andy Grosser) Date: Tue, 6 Jun 2017 18:39:44 -0400 Subject: NANOG70 tee shirt mystery In-Reply-To: References: Message-ID: <1C71D1EA-EB1E-42C7-A0C6-11B94E162AA6@meniscus.org> That's correct. Andy > On Jun 4, 2017, at 8:10 PM, Jon Sevier wrote: > > It's a play on Pearl Jam's "Ten" album cover as best as I can tell. > > -Jon > >> On Jun 4, 2017 16:57, "Matthew Petach" wrote: >> >> So, I've been staring at the NANOG70 tee shirt for >> a bit now: >> >> https://flic.kr/p/VejX5y >> >> and I have to admit, I'm a bit stymied. >> >> Usually, the tee-shirts are somewhat referential >> to the location or to a particular event; but this >> one is leaving me scratching my head. >> >> Is it perhaps a shot of the network engineering >> "Ooops (I broke the network again)" concert >> tour? >> >> Or is there some other cultural reference at >> play that I'm not aware of? >> >> Enquiring minds want to know!(tm). :) >> >> Matt >> From bjackson at napshome.net Tue Jun 6 22:32:49 2017 From: bjackson at napshome.net (Brandon Jackson) Date: Tue, 6 Jun 2017 18:32:49 -0400 Subject: AT&T Broken Uverse IPv6 routing. Message-ID: Sorry for the noise but normal support channels are not understanding IPv6 is broken, they just see IPv4 works. Can anyone contact me or maybe provide a contact or pass this along to someone in ATT who can deal with broken IPv6 routing for Uverse Res/Small Biz IPv6 blocks that are being assigned. For Example one block that was delegated via DHCP-DP is 2600:1700:8250:8390::/60 tracing to it from anywhere outside of AT&T gets a "Destination net unreachable". Note this seems to have going on since atleast the 31st but likely longer, that's just when the gateway was updated to DHCP-PD from 6rd. 3 Examples of traces below. Note even 2001:506:7825:839::1 seems to issues with connectivity but it might not matter as much as that just the "WAN" of the gateway. >From an HE.net connection 2 ge5-4.core1.ash1.he.net (2001:470:0:90::1) 25.200 ms 24.878 ms 24.650 ms 3 100ge3-1.core1.nyc4.he.net (2001:470:0:299::2) 33.407 ms 25.643 ms 25.245 ms 4 as7018-att.10gigabitethernet2-3.core1.nyc4.he.net (2001:470:0:1dd::2) 29.880 ms !N 32.288 ms !N 31.917 ms !N >From Cogent Looking Glass in ATL traceroute to 2600:1700:8250:8390::1 (2600:1700:8250:8390::1), 30 hops max, 80 byte packets 1 2001:550:1:310::1 (2001:550:1:310::1) 0.989 ms 0.992 ms 2 te0-18-0-2.ccr42.atl01.atlas.cogentco.com (2001:550:0:1000::9a36:2fc5) 0.983 ms 0.990 ms 3 be2848.ccr41.atl04.atlas.cogentco.com (2001:550:0:1000::9a36:676) 2.018 ms be2790.ccr22.atl02.atlas.cogentco.com (2001:550:0:1000::9a36:1ba6) 1.191 ms 4 2001:1890:1fff:501:192:205:36:237 (2001:1890:1fff:501:192:205:36:237) 8.640 ms !N 2001:550:3::166 (2001:550:3::166) 8.270 ms !N >From Sprint Looking Glass in ATL traceroute6 to 2600:1700:8250:8390::1 (2600:1700:8250:8390::1) from 2600:0:1:1239:144:228:243:98, 64 hops max, 12 byte packets 1 sl-mst50-atl-ae10.0.v6.sprintlink.net (2600:0:2:1239:144:232:14:86) 0.635 ms 0.551 ms 0.457 ms 2 2600:0:3:1239:144:232:0:6a (2600:0:3:1239:144:232:0:6a) 6.672 ms !N 7.277 ms !N 7.984 ms !N From drevlan at outlook.com Tue Jun 6 18:54:08 2017 From: drevlan at outlook.com (Andrew Conrad) Date: Tue, 6 Jun 2017 18:54:08 +0000 Subject: NANOG 70 network diagram and upstream In-Reply-To: References: <001401d2dbe2$73248230$596d8690$@gvtc.com> , Message-ID: Looks like the network diagram was updated and they ended up with just 2x 10Gb circuits from Wave. I guess the 100Gb connections and redundant carriers fell through? --Andrew > On Jun 4, 2017, at 5:33 PM, Eric Kuhnke wrote: > > Doesn't cost a lot to use the regional shelf spares stocked by Juniper for > a couple of days... > > On Jun 4, 2017 4:03 PM, "James Breeden" wrote: > >> Yeah, I was wondering about that 4x100G. is that a necessity or a "because >> we can" move? >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas >> Sent: Friday, June 2, 2017 4:35 PM >> To: Aaron Gould >> Cc: NANOG >> Subject: RE: NANOG 70 network diagram and upstream >> >> And the 4x100G. That's four times the capacity of the network I work for. >> ~100k subs. >> >>> On Jun 2, 2017 16:54, "Aaron Gould" wrote: >>> >>> Btw.... >>> >>> Wow, a ~2 million dollar boundary (dual PTX1000's) for the NANOG 70 >>> conference.... geez >>> >>> -aaron >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke >>> Sent: Friday, June 2, 2017 1:43 PM >>> To: nanog at nanog.org list >>> Subject: NANOG 70 network diagram and upstream >>> >>> Just a small thing, but as one of the folks who used to work on the >>> core network gear of AS11404, the network diagram has something in it >>> that might confuse attendees as to who is really sponsoring the upstream: >>> >>> https://www.nanog.org/meetings/nanog70/diagram >>> >>> AS11404 was formerly known as Spectrum Networks, acquired in 2013 by >>> Wavedivision Holdings LLC (Wave Broadband) and became the backbone of >>> the Wave network. It's a totally different thing than the Charter >>> service which is trademarked as as Spectrum. >>> >>> https://www.peeringdb.com/asn/11404 >>> >>> The logo in the right side bubble there shouldn't be the >>> Charter/Spectrum trademarked font, but rather should be Wave, who >>> built the dark fiber into the hotel and are providing the upstream. >>> The last mile fiber into the hotel is Wave. >>> >>> >>> -Eric >>> >>> >> From Oliver.Elliott at bristol.ac.uk Tue Jun 6 13:30:15 2017 From: Oliver.Elliott at bristol.ac.uk (Oliver Elliott) Date: Tue, 6 Jun 2017 14:30:15 +0100 Subject: Templating/automating configuration In-Reply-To: <3f6cec0b-f904-141a-d535-4fd7cf0df76c@edylie.net> References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> <3f6cec0b-f904-141a-d535-4fd7cf0df76c@edylie.net> Message-ID: I echo Ansible. I'm using it with NAPALM and jinja2 templates to push and verify config on switches. Oli On 6 June 2017 at 14:27, Pui Edylie wrote: > Hi, > > Take a look at Ansible > > https://www.ansible.com/ > > Our whole infra is automated using it and it is great! > > Regards, > Edy > > > > On 6/6/2017 9:22 PM, Graham Johnston wrote: > >> Short of complete SDN, for those of you that have some degree of >> configuration templating and/or automation tools what is it that you run? >> I'm envisioning some sort of tool that let's me define template snippets of >> configuration and aids in their deployment to devices. I'm okay doing the >> heaving lifting in defining everything, I'm just looking for the tool that >> stitches it together and hopefully makes things a little less error prone >> for those who aren't as adept. >> >> Graham Johnston >> Network Planner >> Westman Communications Group >> 204.717.2829 >> johnstong at westmancom.com >> >> >> > > -- Oliver Elliott Senior Network Specialist IT Services, University of Bristol t: 0117 39 (41131) From s at xopher.net Tue Jun 6 13:14:59 2017 From: s at xopher.net (Scott Christopher) Date: Tue, 06 Jun 2017 16:14:59 +0300 Subject: IPv4 Hijacking For Idiots In-Reply-To: <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> Message-ID: <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> Hank Nussbacher wrote: > 2. Create a domain called acme-corp.com and a user called peering Or one could register a?me.com (If the reader can't tell the difference between acme.com and a?me.com , the reader is using one of the multitude of email clients and/or fonts that presents Unicode poorly.) > 3. Contact an IX, preferably not one in a Westernized, clueful area: > https://en.wikipedia.org/wiki/List_of_Internet_exchange_points I don't think the ordinary Westernized IX is immune to this. Any system requiring human scrutiny is only as secure as the laziest human employed by it. Don't underestimate the "too busy to check this crap" attitude and its potential for serious problems. -- Regards, S.C. From samiii at protonmail.com Tue Jun 6 21:43:46 2017 From: samiii at protonmail.com (Sami) Date: Tue, 06 Jun 2017 17:43:46 -0400 Subject: Proxying NetFlow traffic correctly Message-ID: Hello, I have been searching for a solution that collects/duplicates NetFlow traffic properly for a while but i couldn't find any. Do you know any good unix alternative to ntopng, flowd, flow-tools? nprobe of netflow seems to be the closest one to fit my needs but i want to see if there are any other solution. My goal is to centralize NetFlow traffic into a single machine and then proxy some flows to other destinations for further analysis Best Regards, Sami From niels=nanog at bakker.net Tue Jun 6 23:25:43 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 7 Jun 2017 01:25:43 +0200 Subject: NANOG70 tee shirt mystery In-Reply-To: <7F2D923B-A55D-4D22-AECB-FEDFBF925DC7@yahoo.com> References: <7F2D923B-A55D-4D22-AECB-FEDFBF925DC7@yahoo.com> Message-ID: <20170606232543.GJ86663@excession.tpb.net> * David Barak [Mon 05 Jun 2017, 02:09 CEST]: >https://en.m.wikipedia.org/wiki/Ten_(Pearl_Jam_album) > >Pearl Jam are from Seattle... I only knew the CD version, which looks cropped from the LP edition: https://www.discogs.com/Pearl-Jam-Ten/release/376650#images/3899643 -- Niels. From raphael.timothy at gmail.com Tue Jun 6 23:35:05 2017 From: raphael.timothy at gmail.com (Tim Raphael) Date: Wed, 7 Jun 2017 09:35:05 +1000 Subject: Proxying NetFlow traffic correctly In-Reply-To: References: Message-ID: <6274FEA6-8EBB-4449-A92F-FEDDA5907C95@gmail.com> nProbe is what you want, it?s another product from NTop. http://www.ntop.org/products/netflow/nprobe/ - Tim > On 7 Jun 2017, at 7:43 am, Sami via NANOG wrote: > > Hello, > I have been searching for a solution that collects/duplicates NetFlow traffic properly for a while but i couldn't find any. > Do you know any good unix alternative to ntopng, flowd, flow-tools? > > nprobe of netflow seems to be the closest one to fit my needs but i want to see if there are any other solution. > > My goal is to centralize NetFlow traffic into a single machine and then proxy some flows to other destinations for further analysis > > Best Regards, > Sami From hugo at slabnet.com Tue Jun 6 23:39:16 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 6 Jun 2017 16:39:16 -0700 Subject: Proxying NetFlow traffic correctly In-Reply-To: References: Message-ID: <20170606233916.GC7539@bamboo.slabnet.com> On Tue 2017-Jun-06 17:43:46 -0400, Sami via NANOG wrote: >Hello, >I have been searching for a solution that collects/duplicates NetFlow traffic properly for a while but i couldn't find any. >Do you know any good unix alternative to ntopng, flowd, flow-tools? > >nprobe of netflow seems to be the closest one to fit my needs but i want to see if there are any other solution. > >My goal is to centralize NetFlow traffic into a single machine and then proxy some flows to other destinations for further analysis > >Best Regards, >Sami Flexible: pmacct[1][2] Simple and does what you ask: samplicate[3] -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal [1] http://pmacct.net/ [2] https://github.com/pmacct/pmacct [3] https://github.com/sleinen/samplicator -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bernat at luffy.cx Tue Jun 6 23:43:27 2017 From: bernat at luffy.cx (Vincent Bernat) Date: Wed, 07 Jun 2017 01:43:27 +0200 Subject: Templating/automating configuration In-Reply-To: (Oliver Elliott's message of "Tue, 6 Jun 2017 14:30:15 +0100") References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> <3f6cec0b-f904-141a-d535-4fd7cf0df76c@edylie.net> Message-ID: <87k24od6n4.fsf@luffy.cx> ? 6 juin 2017 14:30 +0100, Oliver Elliott ?: > I echo Ansible. I'm using it with NAPALM and jinja2 templates to push and > verify config on switches. Why not using the builtin ability of ansible for most vendors? (genuine question) http://docs.ansible.com/ansible/list_of_network_modules.html -- Make it clear before you make it faster. - The Elements of Programming Style (Kernighan & Plauger) From hugo at slabnet.com Tue Jun 6 23:45:56 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 6 Jun 2017 16:45:56 -0700 Subject: Proxying NetFlow traffic correctly In-Reply-To: <20170606233916.GC7539@bamboo.slabnet.com> References: <20170606233916.GC7539@bamboo.slabnet.com> Message-ID: <20170606234556.GD7539@bamboo.slabnet.com> On Tue 2017-Jun-06 16:39:16 -0700, Hugo Slabbert wrote: > >On Tue 2017-Jun-06 17:43:46 -0400, Sami via NANOG wrote: > >>Hello, >>I have been searching for a solution that collects/duplicates NetFlow traffic properly for a while but i couldn't find any. >>Do you know any good unix alternative to ntopng, flowd, flow-tools? >> >>nprobe of netflow seems to be the closest one to fit my needs but i want to see if there are any other solution. >> >>My goal is to centralize NetFlow traffic into a single machine and then proxy some flows to other destinations for further analysis >> >>Best Regards, >>Sami > >Flexible: pmacct[1][2] >Simple and does what you ask: samplicate[3] Actually: samplicate is more all-or-nothing as far as I'm aware. So it could proxy a full set of flows, but the "some flows" part of your request I'm not so sure about. > >-- >Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com >pgp key: B178313E | also on Signal > >[1] http://pmacct.net/ >[2] https://github.com/pmacct/pmacct >[3] https://github.com/sleinen/samplicator -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From marka at isc.org Wed Jun 7 00:26:40 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 07 Jun 2017 10:26:40 +1000 Subject: IPv4 Hijacking For Idiots In-Reply-To: Your message of "Tue, 06 Jun 2017 16:14:59 +0300." <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> Message-ID: <20170607002640.22DA37B45E94@rock.dv.isc.org> In message <1496754899.2014592.1000384072.3E55368A at webmail.messagingengine.com>, Scott Christopher writes: > Hank Nussbacher wrote: > > > 2. Create a domain called acme-corp.com and a user called peering > > Or one could register a??me.com > > (If the reader can't tell the difference between acme.com and a??me.com , > the reader is using one of the multitude of email clients and/or fonts > that presents Unicode poorly.) > > > 3. Contact an IX, preferably not one in a Westernized, clueful area: > > https://en.wikipedia.org/wiki/List_of_Internet_exchange_points > > I don't think the ordinary Westernized IX is immune to this. Any system > requiring human scrutiny is only as secure as the laziest human employed > by it. Don't underestimate the "too busy to check this crap" > attitude and its potential for serious problems. > > -- > Regards, > S.C. Route hijacking is theoretically preventable. You have machines verify the bonifides. This does require that people take the time to get the bonifides machines can process but we do have the tech to do this. Now we could continue discussing how easy it is to hijack addresses of we could spend the time addressing the problem. All it takes is a couple of transit providers to no longer accept word-of-mouth and the world will transition overnight. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Wed Jun 7 00:52:44 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Jun 2017 20:52:44 -0400 Subject: IPv4 Hijacking For Idiots In-Reply-To: <20170607002640.22DA37B45E94@rock.dv.isc.org> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> Message-ID: On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews wrote: > Now we could continue discussing how easy it is to hijack addresses > of we could spend the time addressing the problem. All it takes is > a couple of transit providers to no longer accept word-of-mouth and > the world will transition overnight. > i don't think any transit providers were used in the previous thread worth of examples/comms... I don't know that IXP folk either: 1) want to be the police of this 2) should actually be the police of this (what is internet abuse? from who's perspective? oh...) The 'solution' here isn't new though... well, one solution anyway: https://tools.ietf.org/html/rfc6810 From marka at isc.org Wed Jun 7 01:13:41 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 07 Jun 2017 11:13:41 +1000 Subject: IPv4 Hijacking For Idiots In-Reply-To: Your message of "Tue, 06 Jun 2017 20:52:44 -0400." References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> Message-ID: <20170607011341.1F1AD7B4653C@rock.dv.isc.org> In message , Christopher Morrow writes: > > On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews wrote: > > > Now we could continue discussing how easy it is to hijack addresses > > of we could spend the time addressing the problem. All it takes is > > a couple of transit providers to no longer accept word-of-mouth and > > the world will transition overnight. > > i don't think any transit providers were used in the previous thread worth > of examples/comms... > I don't know that IXP folk either: > 1) want to be the police of this > 2) should actually be the police of this (what is internet abuse? from > who's perspective? oh...) > > The 'solution' here isn't new though... well, one solution anyway: > https://tools.ietf.org/html/rfc6810 You missed the point. We have the mechanisms to prevent hijacking today. We just need to use them and stop using the traditional mechanisms which cannot be mathematically be verified as correct. Getting to that stage requires several companies to simultaneously say "we will no longer accept as valid mechanisms to verify routes announcements. You need to use X or else we won't accept the announcement". Yes, this requires guts to do. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Wed Jun 7 01:16:05 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Jun 2017 21:16:05 -0400 Subject: IPv4 Hijacking For Idiots In-Reply-To: <20170607011341.1F1AD7B4653C@rock.dv.isc.org> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> <20170607011341.1F1AD7B4653C@rock.dv.isc.org> Message-ID: On Tue, Jun 6, 2017 at 9:13 PM, Mark Andrews wrote: > > In message gmail.com>, Christopher Morrow writes: > > > > On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews wrote: > > > > > Now we could continue discussing how easy it is to hijack addresses > > > of we could spend the time addressing the problem. All it takes is > > > a couple of transit providers to no longer accept word-of-mouth and > > > the world will transition overnight. > > > > i don't think any transit providers were used in the previous thread > worth > > of examples/comms... > > I don't know that IXP folk either: > > 1) want to be the police of this > > 2) should actually be the police of this (what is internet abuse? from > > who's perspective? oh...) > > > > The 'solution' here isn't new though... well, one solution anyway: > > https://tools.ietf.org/html/rfc6810 > > You missed the point. We have the mechanisms to prevent hijacking > today. We just need to use them and stop using the traditional > apologies for taking your bait. > mechanisms which cannot be mathematically be verified as correct. > > i agree. > Getting to that stage requires several companies to simultaneously > say "we will no longer accept as valid mechanisms to verify > routes announcements. You need to use X or else we won't accept > the announcement". Yes, this requires guts to do. > > agreed here as well. > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From Bryan at bryanfields.net Wed Jun 7 01:25:41 2017 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 6 Jun 2017 21:25:41 -0400 Subject: IPv4 Hijacking For Idiots In-Reply-To: <20170607011341.1F1AD7B4653C@rock.dv.isc.org> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> <20170607011341.1F1AD7B4653C@rock.dv.isc.org> Message-ID: <2541cadf-4a76-b172-b395-0822f18898f8@bryanfields.net> On 6/6/17 9:13 PM, Mark Andrews wrote: > Getting to that stage requires several companies to simultaneously > say "we will no longer accept as valid mechanisms to verify > routes announcements. You need to use X or else we won't accept > the announcement". Yes, this requires guts to do. And what of legacy address holders? ARIN will not permit RPKI use of their blocks. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From marka at isc.org Wed Jun 7 01:55:53 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 07 Jun 2017 11:55:53 +1000 Subject: IPv4 Hijacking For Idiots In-Reply-To: Your message of "Tue, 06 Jun 2017 21:25:41 -0400." <2541cadf-4a76-b172-b395-0822f18898f8@bryanfields.net> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> <20170607011341.1F1AD7B4653C@rock.dv.isc.org> <2541cadf-4a76-b172-b395-0822f18898f8@bryanfields.net> Message-ID: <20170607015553.8BB1A7B46CEE@rock.dv.isc.org> In message <2541cadf-4a76-b172-b395-0822f18898f8 at bryanfields.net>, Bryan Fields writes: > On 6/6/17 9:13 PM, Mark Andrews wrote: > > Getting to that stage requires several companies to simultaneously > > say "we will no longer accept as valid mechanisms to verify > > routes announcements. You need to use X or else we won't accept > > the announcement". Yes, this requires guts to do. > > And what of legacy address holders? ARIN will not permit RPKI use of their > blocks. This really doesn't prevent it being used. RPKI could have a forth CA for legacy holders that don't accept ARIN's terms for issuing of RPKI. You just need to co-ordinate yourselves. There is nothing magical about the current three other than they are accepted by everyone. Or we can just abandon IPv4 and its legacy baggage and do it for IPv6. Mark > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Wed Jun 7 01:57:36 2017 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 7 Jun 2017 01:57:36 +0000 (UTC) Subject: Spectrum TV authentication failures Message-ID: <1672878928.574530.1496800656055.JavaMail.zimbra@baylink.com> NANOG is probably not the optimal venue for looking into auth failures on the IPTV service which Spectrum/Charter/TWC/BH's TV app for Android uses (which are legion), even though it probably uses RADIUS to get the work done. Anyone got a pointer to a better venue for such questions? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From rdobbins at arbor.net Wed Jun 7 02:39:15 2017 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 7 Jun 2017 02:39:15 +0000 Subject: Proxying NetFlow traffic correctly In-Reply-To: References: Message-ID: <0EC13A32-A983-40A9-99E3-576F3EA6F221@arbor.net> On Jun 7, 2017, at 06:32, Sami via NANOG > wrote: My goal is to centralize NetFlow traffic into a single machine and then proxy some flows to other destinations for further analysis Or nprobe, as was already mentioned. ----------------------------------- Roland Dobbins > From selphie.keller at gmail.com Wed Jun 7 02:56:50 2017 From: selphie.keller at gmail.com (Selphie Keller) Date: Tue, 6 Jun 2017 20:56:50 -0600 Subject: Proxying NetFlow traffic correctly In-Reply-To: <0EC13A32-A983-40A9-99E3-576F3EA6F221@arbor.net> References: <0EC13A32-A983-40A9-99E3-576F3EA6F221@arbor.net> Message-ID: samplicate is very good, been using it for 6 years for netflow duplication using botth the spoofing and non, depending on the sensor's needs if it needs to retain the source ip or not. On 6 June 2017 at 20:39, Dobbins, Roland wrote: > > > On Jun 7, 2017, at 06:32, Sami via NANOG nanog.org>> wrote: > > My goal is to centralize NetFlow traffic into a single machine and then > proxy some flows to other destinations for further analysis > > > > Or nprobe, as was already mentioned. > > ----------------------------------- > Roland Dobbins > > From jason at thebaughers.com Wed Jun 7 05:17:54 2017 From: jason at thebaughers.com (Jason Baugher) Date: Wed, 7 Jun 2017 00:17:54 -0500 Subject: DMCA processing software Message-ID: I'm curious what people are using to manage DMCA takedown notices in mid-sized networks. I've been searching, and have found the ACNS spec, and a few obscure references to an RT plugin, but not much else. As the ISP I work for grows, manual handling of notices is starting to be a problem. I'd prefer something open-source so we can extend it to hook into our other systems, but primarily I need something to parse the notice emails, store the information, track the number of incidents over time, and generate letters to users. If nothing exists, and everyone just has in-house proprietary systems, then we'll start down the same road, but I don't like to re-invent the wheel if I can help it. Thanks From tony at wicks.co.nz Wed Jun 7 05:30:54 2017 From: tony at wicks.co.nz (Tony Wicks) Date: Wed, 7 Jun 2017 17:30:54 +1200 Subject: DMCA processing software In-Reply-To: References: Message-ID: <00b301d2df4f$3cf0f340$b6d2d9c0$@wicks.co.nz> Speaking for Networks outside of the USA (and not being at all helpful sorry), /dev/null works well. Sorry, couldn't help myself... -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Baugher Sent: Wednesday, 7 June 2017 5:18 PM To: NANOG Subject: DMCA processing software I'm curious what people are using to manage DMCA takedown notices in mid-sized networks. I've been searching, and have found the ACNS spec, and a few obscure references to an RT plugin, but not much else. As the ISP I work for grows, manual handling of notices is starting to be a problem. I'd prefer something open-source so we can extend it to hook into our other systems, but primarily I need something to parse the notice emails, store the information, track the number of incidents over time, and generate letters to users. If nothing exists, and everyone just has in-house proprietary systems, then we'll start down the same road, but I don't like to re-invent the wheel if I can help it. Thanks From marka at isc.org Wed Jun 7 06:30:54 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 07 Jun 2017 16:30:54 +1000 Subject: IPv4 Hijacking For Idiots In-Reply-To: Your message of "Wed, 07 Jun 2017 09:22:22 +0300." <1496816542.3628250.1001312328.70DF4DB2@webmail.messagingengine.com> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> <1496816542.3628250.1001312328.70DF4DB2@webmail.messagingengine.com> Message-ID: <20170607063054.168A07B49F75@rock.dv.isc.org> In message <1496816542.3628250.1001312328.70DF4DB2 at webmail.messagingengine.com> , Scott Christopher writes: > Mark Andrews wrote: > > > but we do have the tech to do this. > > I wholeheartedly agree. > > > All it takes is a couple of transit providers to no longer accept word-of-m > outh and > > the world will transition overnight. > > This is the hard part. > > It seems trivial - being probably only a handful of transit providers - > but then again, these providers have massive infrastructure spread > globally, often ancient legacy systems that still work, and management > has a legal responsibility in most places to maximize the profits of > their shareholders. > > Look at the rollout of EMV in the U.S.: the world "has done had that > tech to do that" for decades (in Europe) but it only arrived in the U.S. > two years ago. And the U.S. doesn't do the (more secure) chip-and-pin > like the rest of the world (that costs too much money according to the > banks) but rather chip-and-signature. > > Whereas U.S. banks are (sometimes) liable for fraud on their systems, > transit providers don't have any liability for anything in the U.S. And > they are actively fighting for their right to transit some packets > faster than others - for an additional fee, of course! Actually they do have liability. It just needs someone to sue them for them to wake up. The injured party isn't a customer of the transit provider so there isn't any weasle worded contract to sace the transit provider. > I think the solution is legislation + regulations. > > -- > Regards, > S.C. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jwbensley at gmail.com Wed Jun 7 07:38:32 2017 From: jwbensley at gmail.com (James Bensley) Date: Wed, 7 Jun 2017 08:38:32 +0100 Subject: Templating/automating configuration In-Reply-To: <87k24od6n4.fsf@luffy.cx> References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> <3f6cec0b-f904-141a-d535-4fd7cf0df76c@edylie.net> <87k24od6n4.fsf@luffy.cx> Message-ID: On 7 June 2017 at 00:43, Vincent Bernat wrote: > ? 6 juin 2017 14:30 +0100, Oliver Elliott : > >> I echo Ansible. I'm using it with NAPALM and jinja2 templates to push and >> verify config on switches. > > Why not using the builtin ability of ansible for most vendors? (genuine > question) > > http://docs.ansible.com/ansible/list_of_network_modules.html One reason, which is our reason for using NAPALM with Ansible, is that the built in Ansible modules often just edit certain lines of config in the target device. For example, the Cisco IOS module within Ansible scans the device config for say the line starting with "Interface Etherernet 1/1" and then I tell it to ensure the lines " ip vrf customer A" and " ip address x.x.x.x n.n.n.n" are under the search line. It's OK but its text matching and not fool proof. It also doesn't help me to guarantee the state of our tin (I might push an update to one interface on a device and simultaneously someone else might pushes an update to a different interface, our respective views of the device config might not include each other?s updates). We use the NAPALM module although it needs to be a bit more than just NAPALM, its not a panacea. We generate a full device config (even for a one line interface update) and push that into atomic storage (git), when then pass that file from git to NAPALM. NAPALM will copy the file to the device and do a full config replace for us, and we can get a diff from before and after that process and report that back and ensure that exactly what we wanted to change has been changed only. All changes come through git which act?s like a queue meaning that if two people make simultaneous updates to different interfaces there?ll be a git commit/push error. [1] Cheers, James. [1] That?s the plan at least, the reality though is that vendor bugs are plentiful. From marco at paesani.it Wed Jun 7 08:33:57 2017 From: marco at paesani.it (Marco Paesani) Date: Wed, 7 Jun 2017 10:33:57 +0200 Subject: Telxius AS12956 Message-ID: Hi, I need a peering contact for Telxius, can you help me ? Thanks ! kind regards, Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From tim at pelican.org Wed Jun 7 09:23:33 2017 From: tim at pelican.org (tim at pelican.org) Date: Wed, 7 Jun 2017 10:23:33 +0100 (BST) Subject: Templating/automating configuration In-Reply-To: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> References: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> Message-ID: <1496827413.28878943@apps.rackspace.com> Hi Brian, On Tuesday, 6 June, 2017 21:48, "Brian Knight" said: > Because we had different sources of truth which were written in-house, we wound up > rolling our own template engine in Python. It took about 3 weeks to write the > engine and adapt existing templates. Given a circuit ID, it generates the full > config for copy and paste into a terminal session. It also hooks into a > configuration parser tool, written in-house, that tracks configured interfaces, so > it is easy to see whether the template would overwrite an existing interface. Interesting. I'm going through much the same process at the moment, due to similar requirements - multiple sources of truth, validation that there's no clash with existing configs, but also with a requirement for network-wide atomic operations. The latter has been a strong driver for a custom tool - it's now grabbing an exclusive lock on all the devices, making all the checks, pushing all the config, commit check everywhere, commit everywhere, and only once all the commits succeed, release the locks. If any of those steps fail anywhere, we get to roll back everywhere. (Obviously with appropriate timeouts / back-offs / deadlock prevention, and specific to platforms with sane config management - no vanilla IOS). Did you find anything to give you a leg-up on config parsing, or did you have to do that completely from scratch? At the moment, I'm working with PyEZ (I know, vendor lock-in, but we're firmly a Juniper shop, and going in eyes-open to the lock-in) to build a limited model of just the parts of the config I'm interested in validating, and it seems to be working. > If I had a free hand and unlimited budget, I would find a single app that > functions as a source of truth for all circuits and products, which includes a > templating engine that hooks in easily. Plus the business buy-in and the resource to go back and standardise all the existing configs, so the application can fully parse and understand the network before it starts. That, and a pony :) Regards, Tim. From jloiacon at csc.com Wed Jun 7 13:19:59 2017 From: jloiacon at csc.com (Joe Loiacono) Date: Wed, 7 Jun 2017 09:19:59 -0400 Subject: Proxying NetFlow traffic correctly In-Reply-To: References: Message-ID: You may want to check out the SiLK netflow capture and analysis tool suite. Look in particular at it's SiLK Administrators Tools section which provides extensive flexibility for manipulating netflow exports. The analysis tools are quite good too. http://tools.netsa.cert.org/silk/silk-reference-guide.pdf Joe "NANOG" wrote on 06/06/2017 05:43:46 PM: > From: Sami via NANOG > To: "nanog at nanog.org" > Date: 06/06/2017 07:33 PM > Subject: Proxying NetFlow traffic correctly > Sent by: "NANOG" > > Hello, > I have been searching for a solution that collects/duplicates > NetFlow traffic properly for a while but i couldn't find any. > Do you know any good unix alternative to ntopng, flowd, flow-tools? > > nprobe of netflow seems to be the closest one to fit my needs but i > want to see if there are any other solution. > > My goal is to centralize NetFlow traffic into a single machine and > then proxy some flows to other destinations for further analysis > > Best Regards, > Sami From mike at sabbota.com Tue Jun 6 23:38:44 2017 From: mike at sabbota.com (Mike Sabbota) Date: Tue, 6 Jun 2017 16:38:44 -0700 Subject: Proxying NetFlow traffic correctly In-Reply-To: References: Message-ID: Check out samplicator. https://github.com/sleinen/samplicator --Mike On Tue, Jun 6, 2017 at 2:43 PM, Sami via NANOG wrote: > Hello, > I have been searching for a solution that collects/duplicates NetFlow > traffic properly for a while but i couldn't find any. > Do you know any good unix alternative to ntopng, flowd, flow-tools? > > nprobe of netflow seems to be the closest one to fit my needs but i want > to see if there are any other solution. > > My goal is to centralize NetFlow traffic into a single machine and then > proxy some flows to other destinations for further analysis > > Best Regards, > Sami From peter at petermayhew.net Wed Jun 7 03:13:54 2017 From: peter at petermayhew.net (Peter Mayhew) Date: Tue, 6 Jun 2017 23:13:54 -0400 (EDT) Subject: AT&T Broken Uverse IPv6 routing. In-Reply-To: References: Message-ID: <523118286.1879.1496805234164.JavaMail.zimbra@petermayhew.net> Brandon, I have heard some brief mentions on the web about AT&T converting some customers from 6rd to native IPv6 that has caused some problems, but I have not heard from enough people to confirm with great certainty. If you look at the RG stats page does it still mention 6rd? Out of curiosity, which market are you in and which gateways are you seeing this change? Peter ----- Original Message ----- From: "Brandon Jackson via NANOG" To: nanog at nanog.org Sent: Tuesday, June 6, 2017 6:32:49 PM Subject: AT&T Broken Uverse IPv6 routing. Sorry for the noise but normal support channels are not understanding IPv6 is broken, they just see IPv4 works. Can anyone contact me or maybe provide a contact or pass this along to someone in ATT who can deal with broken IPv6 routing for Uverse Res/Small Biz IPv6 blocks that are being assigned. For Example one block that was delegated via DHCP-DP is 2600:1700:8250:8390::/60 tracing to it from anywhere outside of AT&T gets a "Destination net unreachable". Note this seems to have going on since atleast the 31st but likely longer, that's just when the gateway was updated to DHCP-PD from 6rd. 3 Examples of traces below. Note even 2001:506:7825:839::1 seems to issues with connectivity but it might not matter as much as that just the "WAN" of the gateway. >From an HE.net connection 2 ge5-4.core1.ash1.he.net (2001:470:0:90::1) 25.200 ms 24.878 ms 24.650 ms 3 100ge3-1.core1.nyc4.he.net (2001:470:0:299::2) 33.407 ms 25.643 ms 25.245 ms 4 as7018-att.10gigabitethernet2-3.core1.nyc4.he.net (2001:470:0:1dd::2) 29.880 ms !N 32.288 ms !N 31.917 ms !N >From Cogent Looking Glass in ATL traceroute to 2600:1700:8250:8390::1 (2600:1700:8250:8390::1), 30 hops max, 80 byte packets 1 2001:550:1:310::1 (2001:550:1:310::1) 0.989 ms 0.992 ms 2 te0-18-0-2.ccr42.atl01.atlas.cogentco.com (2001:550:0:1000::9a36:2fc5) 0.983 ms 0.990 ms 3 be2848.ccr41.atl04.atlas.cogentco.com (2001:550:0:1000::9a36:676) 2.018 ms be2790.ccr22.atl02.atlas.cogentco.com (2001:550:0:1000::9a36:1ba6) 1.191 ms 4 2001:1890:1fff:501:192:205:36:237 (2001:1890:1fff:501:192:205:36:237) 8.640 ms !N 2001:550:3::166 (2001:550:3::166) 8.270 ms !N >From Sprint Looking Glass in ATL traceroute6 to 2600:1700:8250:8390::1 (2600:1700:8250:8390::1) from 2600:0:1:1239:144:228:243:98, 64 hops max, 12 byte packets 1 sl-mst50-atl-ae10.0.v6.sprintlink.net (2600:0:2:1239:144:232:14:86) 0.635 ms 0.551 ms 0.457 ms 2 2600:0:3:1239:144:232:0:6a (2600:0:3:1239:144:232:0:6a) 6.672 ms !N 7.277 ms !N 7.984 ms !N From s at xopher.net Wed Jun 7 06:22:22 2017 From: s at xopher.net (Scott Christopher) Date: Wed, 07 Jun 2017 09:22:22 +0300 Subject: IPv4 Hijacking For Idiots In-Reply-To: <20170607002640.22DA37B45E94@rock.dv.isc.org> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> <20170607002640.22DA37B45E94@rock.dv.isc.org> Message-ID: <1496816542.3628250.1001312328.70DF4DB2@webmail.messagingengine.com> Mark Andrews wrote: > but we do have the tech to do this. I wholeheartedly agree. > All it takes is a couple of transit providers to no longer accept word-of-mouth and > the world will transition overnight. This is the hard part. It seems trivial - being probably only a handful of transit providers - but then again, these providers have massive infrastructure spread globally, often ancient legacy systems that still work, and management has a legal responsibility in most places to maximize the profits of their shareholders. Look at the rollout of EMV in the U.S.: the world "has done had that tech to do that" for decades (in Europe) but it only arrived in the U.S. two years ago. And the U.S. doesn't do the (more secure) chip-and-pin like the rest of the world (that costs too much money according to the banks) but rather chip-and-signature. Whereas U.S. banks are (sometimes) liable for fraud on their systems, transit providers don't have any liability for anything in the U.S. And they are actively fighting for their right to transit some packets faster than others - for an additional fee, of course! I think the solution is legislation + regulations. -- Regards, S.C. From erich at gotfusion.net Wed Jun 7 15:41:16 2017 From: erich at gotfusion.net (Kaiser, Erich) Date: Wed, 7 Jun 2017 10:41:16 -0500 Subject: Merit RADB support Message-ID: Anyone gonna email me back from RADB support? Erich Kaiser The Fusion Network erich at gotfusion.net Office: 630-621-4804 Cell: 630-777-9291 From cra at WPI.EDU Wed Jun 7 16:08:50 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 7 Jun 2017 12:08:50 -0400 Subject: [SPF:Probably_Forged] Merit RADB support In-Reply-To: References: Message-ID: <20170607160850.GD18086@angus.ind.wpi.edu> On Wed, Jun 07, 2017 at 10:41:16AM -0500, Kaiser, Erich wrote: > Anyone gonna email me back from RADB support? In my experience, no. From cra at WPI.EDU Wed Jun 7 16:21:34 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 7 Jun 2017 12:21:34 -0400 Subject: Merit RADB support In-Reply-To: <30716_1496851746_v57G8xoE010727_20170607160850.GD18086@angus.ind.wpi.edu> References: <30716_1496851746_v57G8xoE010727_20170607160850.GD18086@angus.ind.wpi.edu> Message-ID: <20170607162134.GA16002@angus.ind.wpi.edu> On Wed, Jun 07, 2017 at 12:08:50PM -0400, Chuck Anderson wrote: > On Wed, Jun 07, 2017 at 10:41:16AM -0500, Kaiser, Erich wrote: > > Anyone gonna email me back from RADB support? > > In my experience, no. Apologies to Merit RADB, it was BGPmon that never responds. Merit RADB actually does respond--my frustration is more about the difficulty in getting them to delete stale objects that others registered, although I was finally able to get my objects cleaned up. From ESundberg at nitelusa.com Wed Jun 7 16:54:34 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Wed, 7 Jun 2017 16:54:34 +0000 Subject: Merit RADB support In-Reply-To: <20170607162134.GA16002@angus.ind.wpi.edu> References: <30716_1496851746_v57G8xoE010727_20170607160850.GD18086@angus.ind.wpi.edu> <20170607162134.GA16002@angus.ind.wpi.edu> Message-ID: <495D0934DA46854A9CA758393724D5907557FDCD@NI-MAIL02.nii.ads> For RADB, I was able to get them to delete a stale object 2 weeks ago. Only had to copy them on an email to the original source and wait 24 hours. I wish it was less because we are the netblock owner of the stale route object in question. Erik Sundberg Sr. Network Engineering Network Engineering Department p: 773.661.5532 c: 708.710.7419 e: esundberg at nitelusa.com Main: 888.450.2100 NOC 24/7: 866.892.0915 350 North Orleans Street, Suite 1300N Chicago, IL 60654 www.nitelusa.com Managed Telecom Services MPLS | Ethernet | Private Line | Internet | Voice | Security -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chuck Anderson Sent: Wednesday, June 7, 2017 11:22 AM To: nanog at nanog.org Subject: Re: Merit RADB support On Wed, Jun 07, 2017 at 12:08:50PM -0400, Chuck Anderson wrote: > On Wed, Jun 07, 2017 at 10:41:16AM -0500, Kaiser, Erich wrote: > > Anyone gonna email me back from RADB support? > > In my experience, no. Apologies to Merit RADB, it was BGPmon that never responds. Merit RADB actually does respond--my frustration is more about the difficulty in getting them to delete stale objects that others registered, although I was finally able to get my objects cleaned up. ________________________________ 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. From jra at baylink.com Wed Jun 7 17:30:53 2017 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 7 Jun 2017 17:30:53 +0000 (UTC) Subject: Spectrum TV authentication failures In-Reply-To: <1672878928.574530.1496800656055.JavaMail.zimbra@baylink.com> References: <1672878928.574530.1496800656055.JavaMail.zimbra@baylink.com> Message-ID: <1687886006.577329.1496856653623.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "jra" > NANOG is probably not the optimal venue for looking into auth failures on > the IPTV service which Spectrum/Charter/TWC/BH's TV app for Android uses > (which are legion), even though it probably uses RADIUS to get the work > done. Thanks to a couple people who provided pointers; I'll summarize if anything useful comes of it... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From eric at telic.us Wed Jun 7 16:30:20 2017 From: eric at telic.us (Eric Krichbaum) Date: Wed, 7 Jun 2017 11:30:20 -0500 Subject: Merit RADB support In-Reply-To: <20170607162134.GA16002@angus.ind.wpi.edu> References: <30716_1496851746_v57G8xoE010727_20170607160850.GD18086@angus.ind.wpi.edu> <20170607162134.GA16002@angus.ind.wpi.edu> Message-ID: <00c301d2dfab$5b7ac5a0$127050e0$@telic.us> That's an inherent problem with the IRR system (and I am still a big proponent). There is every operational benefit from entering an object. The object augments policy. But, what is the benefit of removing an object? It doesn't operationally benefit (size of prefix lists, etc. aside) anything. I would prefer that people who proxy register, also proxy delete when services are terminated. If wishes were horses.... Eric -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chuck Anderson Sent: Wednesday, June 07, 2017 11:22 AM To: nanog at nanog.org Subject: Re: Merit RADB support On Wed, Jun 07, 2017 at 12:08:50PM -0400, Chuck Anderson wrote: > On Wed, Jun 07, 2017 at 10:41:16AM -0500, Kaiser, Erich wrote: > > Anyone gonna email me back from RADB support? > > In my experience, no. Apologies to Merit RADB, it was BGPmon that never responds. Merit RADB actually does respond--my frustration is more about the difficulty in getting them to delete stale objects that others registered, although I was finally able to get my objects cleaned up. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From ml at knight-networks.com Wed Jun 7 18:52:22 2017 From: ml at knight-networks.com (Brian Knight) Date: Wed, 07 Jun 2017 13:52:22 -0500 Subject: Templating/automating configuration In-Reply-To: <1496827413.28878943@apps.rackspace.com> References: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> <1496827413.28878943@apps.rackspace.com> Message-ID: <15c83e689c5.b67adcbb317379.1778392953822404155@knight-networks.com> ---- On Wed, 07 Jun 2017 04:23:33 -0500 <tim at pelican.org> wrote ---- Hi Brian, On Tuesday, 6 June, 2017 21:48, "Brian Knight" <ml at knight-networks.com> said: > Because we had different sources of truth which were written in-house, we wound up > rolling our own template engine in Python. It took about 3 weeks to write the > engine and adapt existing templates. Given a circuit ID, it generates the full > config for copy and paste into a terminal session. It also hooks into a > configuration parser tool, written in-house, that tracks configured interfaces, so > it is easy to see whether the template would overwrite an existing interface. Interesting. I'm going through much the same process at the moment, due to similar requirements - multiple sources of truth, validation that there's no clash with existing configs, but also with a requirement for network-wide atomic operations. The latter has been a strong driver for a custom tool - it's now grabbing an exclusive lock on all the devices, making all the checks, pushing all the config, commit check everywhere, commit everywhere, and only once all the commits succeed, release the locks. If any of those steps fail anywhere, we get to roll back everywhere. (Obviously with appropriate timeouts / back-offs / deadlock prevention, and specific to platforms with sane config management - no vanilla IOS). Did you find anything to give you a leg-up on config parsing, or did you have to do that completely from scratch? At the moment, I'm working with PyEZ (I know, vendor lock-in, but we're firmly a Juniper shop, and going in eyes-open to the lock-in) to build a limited model of just the parts of the config I'm interested in validating, and it seems to be working. The import process to the database runs directly on our rancid server, reading the downloaded configs out of the appropriate directory within rancid. Most of our gear is Cisco, so the ciscoconfparse module for Python helps a lot with organizing and querying the config. From there, the config is parsed for key items like interface name, description, configured bandwidth, etc., and that info is then added or updated as necessary in the database. Because it's dependent on rancid, there is some lag time between when a change is made and when the database gets updated, so we still strongly encourage running the pre-config checks for new circuits. But with PyEZ, it looks like you easily could, after grabbing that lock, validate the existing config before pushing down new config. Lots of possibilities there. I'm envious that you have a vendor-written Python module as a choice! > If I had a free hand and unlimited budget, I would find a single app that > functions as a source of truth for all circuits and products, which includes a > templating engine that hooks in easily. Plus the business buy-in and the resource to go back and standardise all the existing configs, so the application can fully parse and understand the network before it starts. That, and a pony :) Or, at least, rebuild the existing configs based on the new source of truth, so that subsequent config parsing conforms to a single standard. Regards, Tim. Cheers, -Brian From andree+nanog at toonk.nl Wed Jun 7 18:55:09 2017 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 07 Jun 2017 19:55:09 +0100 Subject: Merit RADB support In-Reply-To: <20170607162134.GA16002@angus.ind.wpi.edu> References: <30716_1496851746_v57G8xoE010727_20170607160850.GD18086@angus.ind.wpi.edu> <20170607162134.GA16002@angus.ind.wpi.edu> Message-ID: <59384C0D.9060505@toonk.nl> Hi Chuck, My secret spy satellite informs me that Chuck Anderson wrote On 2017-06-07, 5:21 PM: > Apologies to Merit RADB, it was BGPmon that never responds. Merit > RADB actually does respond--my frustration is more about the > difficulty in getting them to delete stale objects that others > registered, although I was finally able to get my objects cleaned up. Happy to look into this for you. We should (and normally do) follow-up on all support requests (support @ bgpmon). Regarding route objects: BGPmon syncs twice a day with all IRRs for route objects. Route objects that haven't been seen in the IRR for more than 48 hours are deleted from our local database (cache so we don't hammer the IRR). Could be a bug, happy to look into this but the issues doesn't immediately ring a bell. I'll reach out to you off-list as well to see what's going on. Cheers Andree (BGPmon) From jwbensley at gmail.com Wed Jun 7 19:29:39 2017 From: jwbensley at gmail.com (James Bensley) Date: Wed, 7 Jun 2017 20:29:39 +0100 Subject: Templating/automating configuration In-Reply-To: <15c83e689c5.b67adcbb317379.1778392953822404155@knight-networks.com> References: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> <1496827413.28878943@apps.rackspace.com> <15c83e689c5.b67adcbb317379.1778392953822404155@knight-networks.com> Message-ID: On 7 June 2017 at 19:52, Brian Knight wrote: > The import process to the database runs directly on our rancid server, reading the downloaded configs out of the appropriate directory within rancid. Most of our gear is Cisco, so the ciscoconfparse module for Python helps a lot with organizing and querying the config. From there, the config is parsed for key items like interface name, description, configured bandwidth, etc., and that info is then added or updated as necessary in the database. > > > > Because it's dependent on rancid, there is some lag time between when a change is made and when the database gets updated, so we still strongly encourage running the pre-config checks for new circuits. But with PyEZ, it looks like you easily could, after grabbing that lock, validate the existing config before pushing down new config. Lots of possibilities there. I'm envious that you have a vendor-written Python module as a choice! ... > > Or, at least, rebuild the existing configs based on the new source of truth, so that subsequent config parsing conforms to a single standard. Cisco IOS and IOS-XE have config locks on the CLI, as well as automatic configuration rollbacks and the ability to generate a config diff on deice. For some reason lots of people seem to forget/ignore this. If you are using NAPALM then I believe you can also implement this through NAPALM. Cheers, James. From lists at tigertech.com Wed Jun 7 20:16:28 2017 From: lists at tigertech.com (Robert L Mathews) Date: Wed, 7 Jun 2017 13:16:28 -0700 Subject: IPv4 Hijacking For Idiots In-Reply-To: <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> References: <88661.1496660174@segfault.tristatelogic.com> <115957cb-34f8-e2ee-b53b-12b3d5842521@efes.iucc.ac.il> <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com> Message-ID: <5a42242d-5eb1-9237-469f-2fba5a702222@tigertech.com> On 6/6/17 6:14 AM, Scott Christopher wrote: > Or one could register a?me.com For what it's worth, that domain name (with a Cyrillic character 0441 replacing the "c" in "acme") wouldn't be allowed based on this: https://www.verisign.com/en_US/channel-resources/domain-registry-products/idn/idn-policy/registration-rules/index.xhtml (See section 3, "For example, a character from the Latin script cannot be used in the same IDN with any Cyrillic character.") But those rules are not foolproof. "???.com" is entirely Cyrillic (0430 0441 0435), and is in fact registered. Compare these in Firefox: http://ace.com/ http://???.com/ Chrome has protection against this, displaying the latter as "http://xn--80ak9a.com/" due to: https://www.xudongz.com/blog/2017/idn-phishing/ But it's all very much ad-hoc. > (If the reader can't tell the difference between acme.com and a?me.com , > the reader is using one of the multitude of email clients and/or fonts > that presents Unicode poorly.) Even the Unicode sample glyph charts render code points 0063 and 0441 identically: http://www.unicode.org/charts/PDF/U0000.pdf http://www.unicode.org/charts/PDF/U0400.pdf And there are lots of other examples. It's hard to say how to fix all possible cases of what amounts to a human language problem. -- Robert L Mathews From eric.kuhnke at gmail.com Wed Jun 7 20:20:17 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 7 Jun 2017 13:20:17 -0700 Subject: DMCA processing software In-Reply-To: <00b301d2df4f$3cf0f340$b6d2d9c0$@wicks.co.nz> References: <00b301d2df4f$3cf0f340$b6d2d9c0$@wicks.co.nz> Message-ID: Now new and improved for the modern era: https://devnull-as-a-service.com/home/ On Tue, Jun 6, 2017 at 10:30 PM, Tony Wicks wrote: > Speaking for Networks outside of the USA (and not being at all helpful > sorry), /dev/null works well. Sorry, couldn't help myself... > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Baugher > Sent: Wednesday, 7 June 2017 5:18 PM > To: NANOG > Subject: DMCA processing software > > I'm curious what people are using to manage DMCA takedown notices in > mid-sized networks. I've been searching, and have found the ACNS spec, and > a few obscure references to an RT plugin, but not much else. As the ISP I > work for grows, manual handling of notices is starting to be a problem. I'd > prefer something open-source so we can extend it to hook into our other > systems, but primarily I need something to parse the notice emails, store > the information, track the number of incidents over time, and generate > letters to users. > > If nothing exists, and everyone just has in-house proprietary systems, > then we'll start down the same road, but I don't like to re-invent the > wheel if I can help it. > > Thanks > > From adampf at gmail.com Wed Jun 7 22:17:35 2017 From: adampf at gmail.com (Andrew Dampf) Date: Wed, 07 Jun 2017 22:17:35 +0000 Subject: Templating/automating configuration In-Reply-To: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> Message-ID: Salt is great for generating configs based on jinja templates, and you can use napalm in conjunction with salt to push the configs to the device on a set schedule (typically this is done hourly). If manual changes are made to the router, salt would override them on the next run, so it's a great way to make sure configs are consistent. On Tue, Jun 6, 2017 at 9:25 AM Graham Johnston wrote: > Short of complete SDN, for those of you that have some degree of > configuration templating and/or automation tools what is it that you run? > I'm envisioning some sort of tool that let's me define template snippets of > configuration and aids in their deployment to devices. I'm okay doing the > heaving lifting in defining everything, I'm just looking for the tool that > stitches it together and hopefully makes things a little less error prone > for those who aren't as adept. > > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 <(204)%20717-2829> > johnstong at westmancom.com > > From jerome at fleury.net Thu Jun 8 05:02:48 2017 From: jerome at fleury.net (=?UTF-8?B?SsOpcsO0bWUgRmxldXJ5?=) Date: Wed, 7 Jun 2017 22:02:48 -0700 Subject: Proxying NetFlow traffic correctly In-Reply-To: References: Message-ID: We use pmacct with it's tee plugin - it gets the job done beautifully and it's a one-liner config. https://github.com/pmacct/pmacct/blob/master/CONFIG-KEYS On Tue, Jun 6, 2017 at 2:43 PM, Sami via NANOG wrote: > Hello, > I have been searching for a solution that collects/duplicates NetFlow > traffic properly for a while but i couldn't find any. > Do you know any good unix alternative to ntopng, flowd, flow-tools? > > nprobe of netflow seems to be the closest one to fit my needs but i want > to see if there are any other solution. > > My goal is to centralize NetFlow traffic into a single machine and then > proxy some flows to other destinations for further analysis > > Best Regards, > Sami From benoit.panizzon at imp.ch Thu Jun 8 07:28:51 2017 From: benoit.panizzon at imp.ch (Benoit Panizzon) Date: Thu, 8 Jun 2017 09:28:51 +0200 Subject: DMCA processing software In-Reply-To: <00b301d2df4f$3cf0f340$b6d2d9c0$@wicks.co.nz> References: <00b301d2df4f$3cf0f340$b6d2d9c0$@wicks.co.nz> Message-ID: <20170608092851.0557ef2f@go.imp.ch> Hi > Speaking for Networks outside of the USA (and not being at all > helpful sorry), /dev/null works well. Sorry, couldn't help myself... Same here, most notices about PI infringements our abuse desk is getting are from companies operating on a 'bounty' scheme, trying to get some personal details of the user of an IP address to be able to sell that information to the copyright holder. As soon as we try to instruct them on how to correctly proceed in Switzerland, we either don't hear from then any more, or keep getting the same messages again and again which we then consider 'spam' as obviously no human is sending then, or reviewing the answers our abuse desks sends. -Beno?t Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ From surfer at mauigateway.com Thu Jun 8 09:50:25 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 8 Jun 2017 02:50:25 -0700 Subject: IPv4 Hijacking For Idiots Message-ID: <20170608025025.6776333A@m0117460.ppops.net> --- s at xopher.net wrote: From: Scott Christopher I think the solution is legislation + regulations. --------------------------------- For sure dude, because, you know, they do such a great job of all the other stuff they touch! scott ps. NOT! From bortzmeyer at nic.fr Fri Jun 9 07:47:05 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 9 Jun 2017 09:47:05 +0200 Subject: IP Hijacking For Dummies In-Reply-To: <91149.1496706364@segfault.tristatelogic.com> References: <91149.1496706364@segfault.tristatelogic.com> Message-ID: <20170609074705.wh5lnnwy3dmu6yt6@nic.fr> On Mon, Jun 05, 2017 at 04:46:04PM -0700, Ronald F. Guilmette wrote a message of 85 lines which said: > I just think that by now, in 2017, we should have a somewhat more > skilled class of frauds, rogues, criminals and spies on the > Internet. "This city deserves a better class of criminal and I'm gonna give it to them." -- The Joker (in one of the Batman movies) From cscora at apnic.net Fri Jun 9 18:02:55 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Jun 2017 04:02:55 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170609180255.8C1BDC44B5@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 10 Jun, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 650823 Prefixes after maximum aggregation (per Origin AS): 253584 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 314080 Total ASes present in the Internet Routing Table: 57448 Prefixes per ASN: 11.33 Origin-only ASes present in the Internet Routing Table: 49725 Origin ASes announcing only one prefix: 21980 Transit ASes present in the Internet Routing Table: 7723 Transit-only ASes present in the Internet Routing Table: 224 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 45 Max AS path prepend of ASN ( 55644) 41 Prefixes from unregistered ASNs in the Routing Table: 54 Numnber of instances of unregistered ASNs: 58 Number of 32-bit ASNs allocated by the RIRs: 18953 Number of 32-bit ASNs visible in the Routing Table: 14709 Prefixes from 32-bit ASNs in the Routing Table: 59673 Number of bogon 32-bit ASNs visible in the Routing Table: 65 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 369 Number of addresses announced to Internet: 2848626788 Equivalent to 169 /8s, 202 /16s and 152 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.6 Total number of prefixes smaller than registry allocations: 217103 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 178366 Total APNIC prefixes after maximum aggregation: 51373 APNIC Deaggregation factor: 3.47 Prefixes being announced from the APNIC address blocks: 177587 Unique aggregates announced from the APNIC address blocks: 73377 APNIC Region origin ASes present in the Internet Routing Table: 8152 APNIC Prefixes per ASN: 21.78 APNIC Region origin ASes announcing only one prefix: 2278 APNIC Region transit ASes present in the Internet Routing Table: 1159 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 45 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2980 Number of APNIC addresses announced to Internet: 763641700 Equivalent to 45 /8s, 132 /16s and 63 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 197893 Total ARIN prefixes after maximum aggregation: 94548 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 199901 Unique aggregates announced from the ARIN address blocks: 91948 ARIN Region origin ASes present in the Internet Routing Table: 17891 ARIN Prefixes per ASN: 11.17 ARIN Region origin ASes announcing only one prefix: 6615 ARIN Region transit ASes present in the Internet Routing Table: 1765 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2011 Number of ARIN addresses announced to Internet: 1110673568 Equivalent to 66 /8s, 51 /16s and 136 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 175540 Total RIPE prefixes after maximum aggregation: 85525 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 171131 Unique aggregates announced from the RIPE address blocks: 102774 RIPE Region origin ASes present in the Internet Routing Table: 24103 RIPE Prefixes per ASN: 7.10 RIPE Region origin ASes announcing only one prefix: 11101 RIPE Region transit ASes present in the Internet Routing Table: 3402 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5887 Number of RIPE addresses announced to Internet: 711837824 Equivalent to 42 /8s, 109 /16s and 200 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 81750 Total LACNIC prefixes after maximum aggregation: 18287 LACNIC Deaggregation factor: 4.47 Prefixes being announced from the LACNIC address blocks: 83002 Unique aggregates announced from the LACNIC address blocks: 38736 LACNIC Region origin ASes present in the Internet Routing Table: 6001 LACNIC Prefixes per ASN: 13.83 LACNIC Region origin ASes announcing only one prefix: 1653 LACNIC Region transit ASes present in the Internet Routing Table: 1113 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3514 Number of LACNIC addresses announced to Internet: 170730208 Equivalent to 10 /8s, 45 /16s and 34 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 17174 Total AfriNIC prefixes after maximum aggregation: 3805 AfriNIC Deaggregation factor: 4.51 Prefixes being announced from the AfriNIC address blocks: 18833 Unique aggregates announced from the AfriNIC address blocks: 6915 AfriNIC Region origin ASes present in the Internet Routing Table: 1048 AfriNIC Prefixes per ASN: 17.97 AfriNIC Region origin ASes announcing only one prefix: 332 AfriNIC Region transit ASes present in the Internet Routing Table: 198 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 317 Number of AfriNIC addresses announced to Internet: 91322368 Equivalent to 5 /8s, 113 /16s and 120 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5545 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3942 403 376 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2975 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2783 11137 760 KIXS-AS-KR Korea Telecom, KR 9829 2747 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2216 8699 34 CMNET-GD Guangdong Mobile Communication 4755 2090 422 222 TATACOMM-AS TATA Communications formerl 45899 1984 1392 107 VNPT-AS-VN VNPT Corp, VN 7552 1620 1100 66 VIETEL-AS-AP Viettel Corporation, VN 9498 1582 360 138 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3822 2969 154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3400 1333 80 SHAW - Shaw Communications Inc., CA 18566 2128 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2066 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2009 2172 413 CHARTER-NET-HKY-NC - Charter Communicat 209 1816 5069 639 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1810 3441 585 AMAZON-02 - Amazon.com, Inc., US 30036 1781 324 315 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1696 854 232 ITCDELTA - Earthlink, Inc., US 701 1562 10578 636 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3208 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2915 989 2097 AKAMAI-ASN1, US 34984 2020 328 390 TELLCOM-AS, TR 9121 1977 1691 17 TTNET, TR 12479 1598 1044 52 UNI2-AS, ES 13188 1597 99 55 TRIOLAN, UA 12389 1524 1408 625 ROSTELECOM-AS, RU 9198 1325 352 25 KAZTELECOM-AS, KZ 6849 1225 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3545 545 153 Telmex Colombia S.A., CO 8151 2543 3404 573 Uninet S.A. de C.V., MX 11830 2084 369 57 Instituto Costarricense de Electricidad 7303 1568 1010 247 Telecom Argentina S.A., AR 6503 1538 437 53 Axtel, S.A.B. de C.V., MX 6147 1267 377 27 Telefonica del Peru S.A.A., PE 3816 1013 494 186 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 998 2300 175 CLARO S.A., BR 11172 906 126 81 Alestra, S. de R.L. de C.V., MX 18881 895 1052 23 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1260 398 48 LINKdotNET-AS, EG 37611 715 67 7 Afrihost, ZA 36903 713 358 123 MT-MPLS, MA 36992 627 1375 26 ETISALAT-MISR, EG 24835 495 850 15 RAYA-AS, EG 29571 419 36 10 CITelecom-AS, CI 37492 407 320 75 ORANGE-, TN 8452 388 1730 17 TE-AS TE-AS, EG 15399 353 35 7 WANANCHI-, KE 2018 298 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5545 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3942 403 376 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3822 2969 154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3545 545 153 Telmex Colombia S.A., CO 6327 3400 1333 80 SHAW - Shaw Communications Inc., CA 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3208 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 17974 2975 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2915 989 2097 AKAMAI-ASN1, US 4766 2783 11137 760 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3822 3668 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3942 3566 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3545 3392 Telmex Colombia S.A., CO 6327 3400 3320 SHAW - Shaw Communications Inc., CA 39891 3338 3316 ALJAWWALSTC-AS, SA 8551 3208 3168 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2975 2902 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9829 2747 2207 BSNL-NIB National Internet Backbone, IN 9808 2216 2182 CMNET-GD Guangdong Mobile Communication Co.Ltd. 11830 2084 2027 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 66255 UNALLOCATED 45.6.244.0/22 16735 ALGAR TELECOM S/A, BR 66255 UNALLOCATED 45.6.245.0/24 16735 ALGAR TELECOM S/A, BR 66255 UNALLOCATED 45.6.246.0/24 16735 ALGAR TELECOM S/A, BR 66255 UNALLOCATED 45.6.247.0/24 16735 ALGAR TELECOM S/A, BR 65010 PRIVATE 46.56.192.0/21 42772 VELCOM-AS, BY 65010 PRIVATE 46.56.224.0/21 42772 VELCOM-AS, BY 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 36.255.248.0/24 64091 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:280 /13:546 /14:1045 /15:1850 /16:13492 /17:7626 /18:13428 /19:24669 /20:38590 /21:41145 /22:77218 /23:64196 /24:364348 /25:835 /26:612 /27:643 /28:43 /29:32 /30:26 /31:3 /32:28 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3193 3400 SHAW - Shaw Communications Inc., CA 22773 2971 3822 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2898 3338 ALJAWWALSTC-AS, SA 8551 2673 3208 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2021 2128 MEGAPATH5-US - MegaPath Corporation, US 30036 1577 1781 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1474 2084 Instituto Costarricense de Electricidad y Telec 10620 1471 3545 Telmex Colombia S.A., CO 6389 1373 2066 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 9121 1369 1977 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1604 2:841 4:18 5:2429 6:34 8:1038 12:1828 13:122 14:1771 15:27 16:2 17:123 18:121 20:57 23:2329 24:1828 25:2 27:2426 31:1904 32:83 33:9 35:20 36:414 37:2589 38:1325 39:42 40:98 41:2991 42:470 43:1935 44:72 45:2755 46:2780 47:122 49:1214 50:983 51:18 52:824 54:360 55:5 56:4 57:42 58:1600 59:1047 60:391 61:1947 62:1595 63:1913 64:4549 65:2208 66:4509 67:2247 68:1229 69:3361 70:1148 71:584 72:2179 74:2690 75:387 76:430 77:1469 78:1448 79:2503 80:1402 81:1386 82:995 83:720 84:877 85:1751 86:483 87:1156 88:766 89:2065 90:176 91:6204 92:1027 93:2389 94:2373 95:2758 96:622 97:352 98:1054 99:89 100:154 101:1270 103:14931 104:2913 105:191 106:483 107:1651 108:818 109:2964 110:1427 111:1727 112:1187 113:1237 114:1034 115:1697 116:1788 117:1717 118:2164 119:1590 120:1031 121:1111 122:2257 123:1817 124:1515 125:1891 128:780 129:645 130:440 131:1389 132:530 133:199 134:647 135:221 136:455 137:436 138:1947 139:486 140:394 141:568 142:759 143:923 144:800 145:181 146:1032 147:672 148:1433 149:580 150:713 151:976 152:797 153:291 154:814 155:746 156:591 157:636 158:452 159:1464 160:661 161:745 162:2521 163:530 164:792 165:1225 166:385 167:1254 168:2658 169:777 170:3363 171:318 172:1020 173:1908 174:800 175:748 176:1848 177:4038 178:2500 179:1162 180:2214 181:1886 182:2361 183:995 184:864 185:9850 186:3101 187:2170 188:2698 189:1831 190:8184 191:1310 192:9433 193:5786 194:4651 195:3891 196:2114 197:1281 198:5494 199:5883 200:7435 201:4326 202:10366 203:9994 204:4480 205:2812 206:3025 207:3167 208:3981 209:4021 210:3968 211:2147 212:2854 213:2484 214:880 215:67 216:5738 217:2102 218:851 219:600 220:1649 221:912 222:761 223:1178 End of report From jordi.palet at consulintel.es Sun Jun 11 09:25:43 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 11 Jun 2017 11:25:43 +0200 Subject: plea for increase participation in v6ops/IETF Message-ID: Hello all, At the last LACNIC event, I mentioned on a couple of occasions the need for ISPs in the region, especially small and medium-sized ones, to participate in the decisions taken in the IETF IPv6 Operations Working Group (v6ops). I?m sending this here as well, as I believe the situation also apply to this region. When I asked among the attendees how many participate in v6ops, only one person raised his hand. What does it mean to participate in the mailing list? Follow some emails (sometimes only 1-2 a week, sometimes they can be several in a day), and therefore learn about what is being discussed and give your opinion and, given that decisions are made by Consensus, influence them. What consequences has NOT participating? That decisions against your interests/opinions could be taken, and obviously do not consider your perspective in the standards. Generally large operators are involved, which implies that your interests are not sufficiently represented, and in general are contrary to yours. Your "vote/opinion" is not worth more than yours, but the big one is present and the small/medium NO! I give you a very concrete example. The serious problem that small and medium ISPs have, is to continue offering IPv6 and IPv4 services to their customers, when they already do not have IPv4 addresses. Only the biggest ISPs have a great purchasing power and can influence the manufacturers to do for them what they need. One possibility to solve it, extending the life of IPv4, but not necessarily deploying IPv6, is using CGN, which is also very expensive, and breaks many things. The solution is simple. Deploying IPv6-only services in the last mile, which involves using transition mechanisms, such as 464XLAT that has been deployed on millions of smartphones worldwide, so that applications continue to operate transparently as they "believe" they have IPv4. What is the problem, then? That manufacturers of CPEs are based on an old specification (RFC7084) that does not contemplate these transition mechanisms, so when a small/medium ISP asks a manufacturer for a firmware upgrade or a new CPE, they do not include that solution and perhaps they offer it with an extra cost. In my view, this should change, and that is why I am working on a number of documents, including RFC7084-bis (https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/), To update this situation, but there is opposition from large ISPs and virtually no small/medium "talks" about it, and in fact these large ISPs deny the situation. In addition, the document also specifies the "automated" support of those cases in which the user installs other routers (which is very common as we all know, and will be more and more in IPv6, IoT, etc.), behind the router installed by the ISP, through homenet (HNCP). I am not asking for your support for my documents, but for understanding the problem and the solution that is being proposed and/or possible new ones, and for the opinion of not only those very few ?big ones?, but also of many small and medium, who are most affected. If you want to subscribe to this list, search for "subscribing" at: https://www.ietf.org/mailman/listinfo/v6ops You can see the files of the discussion in: https://mailarchive.ietf.org/arch/search/?email_list=v6ops I remind you that participating in the IETF does not require a presence in the meetings, as consensus is agreed in the list. Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From cook at cookreport.com Sun Jun 11 15:38:17 2017 From: cook at cookreport.com (Gordon Cook) Date: Sun, 11 Jun 2017 11:38:17 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: Message-ID: <3E988FA7-709A-4767-955D-536673B15F0E@cookreport.com> Hi Sean You and I first met when i was at OIA about 1992 LOONG TIME ago Always thought of you as brilliant collector of info as well as analyst there of this question of yours is absolutely brilliant look at the responses (more) than 45!!! > On Jun 1, 2017, at 2:02 PM, Sean Donelan wrote: > > > There must be a perfectly logical explanation.... Yes, people in the industry know where the choke points are. But the choke points aren't always the most obvious places. Its kinda a weird for diplomats to show up there. > > On the other hand, I've been a fiber optic tourist. I've visited many critical choke points in the USA and other countries, and even took selfies :-) > > > http://www.politico.com/story/2017/06/01/russia-spies-espionage-trump-239003 > > In the throes of the 2016 campaign, the FBI found itself with an escalating problem: Russian diplomats, whose travel was supposed to be tracked by the State Department, were going missing. > > The diplomats, widely assumed to be intelligence operatives, would eventually turn up in odd places, often in middle-of-nowhere USA. One was found on a beach, nowhere near where he was supposed to be. In one particularly bizarre case, relayed by a U.S. intelligence official, another turned up wandering around in the middle of the desert. Interestingly, both seemed to be lingering where underground fiber-optic cables tend to run. > > According to another U.S. intelligence official, ?They find these guys driving around in circles in Kansas. It?s a pretty aggressive effort.? > > It?s a trend that has led intelligence officials to conclude that the Kremlin is waging a quiet effort to map the United States? telecommunications infrastructure, perhaps preparing for an opportunity to disrupt it. > From bortzmeyer at nic.fr Sun Jun 11 16:40:42 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 11 Jun 2017 18:40:42 +0200 Subject: IP Hijacking For Dummies In-Reply-To: <91149.1496706364@segfault.tristatelogic.com> References: <91149.1496706364@segfault.tristatelogic.com> Message-ID: <20170611164042.sgn5hu73ofvmo5af@nic.fr> On Mon, Jun 05, 2017 at 04:46:04PM -0700, Ronald F. Guilmette wrote a message of 85 lines which said: > Late last night, I put together the following simple annotated listing of > the routes being announced by AS34991. Note that they apparently stopped on 7 june. From cook at cookreport.com Sun Jun 11 18:59:30 2017 From: cook at cookreport.com (Gordon Cook) Date: Sun, 11 Jun 2017 14:59:30 -0400 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: <3E988FA7-709A-4767-955D-536673B15F0E@cookreport.com> References: <3E988FA7-709A-4767-955D-536673B15F0E@cookreport.com> Message-ID: I have just scanned this whole thread - it is the most amazing analysis of technical details I have e ver seen national security also sean I am taking this in the sense of what the hell could these russian diplomats be doing? I have been a nanog reader since this list began in the spring of 1995 i believe remember i am parsing comments from the russian side as well i met aleksei soldatov at the kurchatov institute for the first time in april 1992. about 3 days earlier i met the demos guys who told soldatov suggested to soldatov that he should met me at kurchatov I followed the development of the russian internet very closely between April 1992 and 1999 not much after that. meanwhile i am well aware of international fiber optic cables geographic issues of same ? see telegeography for example, His coordinates etc interception of cable via submarine etc see the US Sub named Jimmy carter I visited Russia for the first time in 1964 my dissertation completed in 1972 dis on site work for the Phd in Russia for 2 months summer of 1970 including pushkinskii Dom Thanks to steve Goldstein of NSF I received an invite to attend the second Nato sponsored conference on the future e of the russian internet met larry land weber there at Golitsyno - the conf was sept 30 to Oct 2 1994 The point? I have long experience with my Cook Report on Internet Protocol in April 1992 issue #1 and an even lon\ger experience with russian history language and culture I am also well aware this message will be readable by a ver large number of people both here and abroad. even visited the westin bldg In i think 1994. take a bow Sean!! :-) > On Jun 11, 2017, at 11:38 AM, Gordon Cook wrote: > > Hi Sean > > You and I first met when i was at OIA about 1992 LOONG TIME ago > > Always thought of you as brilliant collector of info as well as analyst there of > > this question of yours is absolutely brilliant > > look at the responses (more) than 45!!! > > > > > > >> On Jun 1, 2017, at 2:02 PM, Sean Donelan wrote: >> >> >> There must be a perfectly logical explanation.... Yes, people in the industry know where the choke points are. But the choke points aren't always the most obvious places. Its kinda a weird for diplomats to show up there. >> >> On the other hand, I've been a fiber optic tourist. I've visited many critical choke points in the USA and other countries, and even took selfies :-) >> >> >> http://www.politico.com/story/2017/06/01/russia-spies-espionage-trump-239003 >> >> In the throes of the 2016 campaign, the FBI found itself with an escalating problem: Russian diplomats, whose travel was supposed to be tracked by the State Department, were going missing. >> >> The diplomats, widely assumed to be intelligence operatives, would eventually turn up in odd places, often in middle-of-nowhere USA. One was found on a beach, nowhere near where he was supposed to be. In one particularly bizarre case, relayed by a U.S. intelligence official, another turned up wandering around in the middle of the desert. Interestingly, both seemed to be lingering where underground fiber-optic cables tend to run. >> >> According to another U.S. intelligence official, ?They find these guys driving around in circles in Kansas. It?s a pretty aggressive effort.? >> >> It?s a trend that has led intelligence officials to conclude that the Kremlin is waging a quiet effort to map the United States? telecommunications infrastructure, perhaps preparing for an opportunity to disrupt it. >> > > From lyndon at orthanc.ca Sun Jun 11 22:27:09 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 11 Jun 2017 15:27:09 -0700 Subject: mailops https breakage In-Reply-To: <20160828014627.GE4869@hezmatt.org> References: <20160827012542.43353.qmail@ary.lan> <20160828014627.GE4869@hezmatt.org> Message-ID: > On Aug 27, 2016, at 6:46 PM, Matt Palmer wrote: > > On Sat, Aug 27, 2016 at 01:25:42AM -0000, John Levine wrote: >> In article you write: >>> I was working within the limits of what I had available. >> >> Here's the subscription page for mailop. It's got about as odd >> a mix of people as nanog, ranging from people with single user linux >> machines to people who run some of the largest mail systems in >> the world, including Gmail: >> >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > I know they're mailops, and not tlsops, but surely presenting a cert that > didn't expire six months ago isn't beyond the site admin's capabilities? I tried again, ten months later. Still broken :-( Is there a replacement site I'm missing out on? From cook at cookreport.com Sun Jun 11 23:58:04 2017 From: cook at cookreport.com (Gordon Cook) Date: Sun, 11 Jun 2017 19:58:04 -0400 Subject: Templating/automating configuration In-Reply-To: References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> Message-ID: again I understand and agree the reach of your drowning analysis and understanding is awesome hi randy bush oops and hi jp confused of calcutta and chris locke rage boy > On Jun 7, 2017, at 6:17 PM, Andrew Dampf wrote: > > Salt is great for generating configs based on jinja templates, and you can > use napalm in conjunction with salt to push the configs to the device on a > set schedule (typically this is done hourly). If manual changes are made to > the router, salt would override them on the next run, so it's a great way > to make sure configs are consistent. > > > On Tue, Jun 6, 2017 at 9:25 AM Graham Johnston > wrote: > >> Short of complete SDN, for those of you that have some degree of >> configuration templating and/or automation tools what is it that you run? >> I'm envisioning some sort of tool that let's me define template snippets of >> configuration and aids in their deployment to devices. I'm okay doing the >> heaving lifting in defining everything, I'm just looking for the tool that >> stitches it together and hopefully makes things a little less error prone >> for those who aren't as adept. >> >> Graham Johnston >> Network Planner >> Westman Communications Group >> 204.717.2829 <(204)%20717-2829> >> johnstong at westmancom.com >> >> > From cook at cookreport.com Mon Jun 12 00:23:38 2017 From: cook at cookreport.com (Gordon Cook) Date: Sun, 11 Jun 2017 20:23:38 -0400 Subject: Templating/automating configuration In-Reply-To: References: <82C0CE81789FE64D8F4D15263191829715CDE7BB@MSG6.westman.int> Message-ID: <6B29E10D-3257-439B-AF9A-1E1052E8BFE3@cookreport.com> agree again all of the above thanks > On Jun 11, 2017, at 7:58 PM, Gordon Cook wrote: > > again I understand and agree > > > > the reach of your drowning analysis and understanding is awesome > > hi randy bush > > > oops and hi jp confused of calcutta and chris locke rage boy > >> On Jun 7, 2017, at 6:17 PM, Andrew Dampf wrote: >> >> Salt is great for generating configs based on jinja templates, and you can >> use napalm in conjunction with salt to push the configs to the device on a >> set schedule (typically this is done hourly). If manual changes are made to >> the router, salt would override them on the next run, so it's a great way >> to make sure configs are consistent. >> >> >> On Tue, Jun 6, 2017 at 9:25 AM Graham Johnston >> wrote: >> >>> Short of complete SDN, for those of you that have some degree of >>> configuration templating and/or automation tools what is it that you run? >>> I'm envisioning some sort of tool that let's me define template snippets of >>> configuration and aids in their deployment to devices. I'm okay doing the >>> heaving lifting in defining everything, I'm just looking for the tool that >>> stitches it together and hopefully makes things a little less error prone >>> for those who aren't as adept. >>> >>> Graham Johnston >>> Network Planner >>> Westman Communications Group >>> 204.717.2829 <(204)%20717-2829> >>> johnstong at westmancom.com >>> >>> >> > > From rjoffe at centergate.com Tue Jun 13 12:59:51 2017 From: rjoffe at centergate.com (Rodney Joffe) Date: Tue, 13 Jun 2017 08:59:51 -0400 Subject: Vendors spamming NANOG attendees Message-ID: It seems that more than just a few of us were spammed by Glenn Stern (gstern at calient.net), an employee of Calient following NANOG 70. The spammer had the balls to say, in his email: > > We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. He does not show as an attendee at NANOG, but another executive, David Altstaetter, daltstaetter at calient.net did register, and may have even shown up. Hopefully those of you who have traditional community attitudes will show your reaction via your pocketbooks. Maybe its time for the NANOG board and staff to step in, and develop some teeth to use in cases like these? Unless the majority of you members are cool with unfettered spamming of member and attendee lists. In which case, have at it! Rodney From mel at beckman.org Tue Jun 13 15:02:55 2017 From: mel at beckman.org (Mel Beckman) Date: Tue, 13 Jun 2017 15:02:55 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: References: Message-ID: Rodney, What do you suggest? Shoot them at Dawn? :-) The standard warning and education has always been adequate in the past. We don't have a runaway spamming problem on the list. -mel beckman > On Jun 13, 2017, at 6:00 AM, Rodney Joffe wrote: > > It seems that more than just a few of us were spammed by Glenn Stern (gstern at calient.net), an employee of Calient following NANOG 70. > > The spammer had the balls to say, in his email: > >> >> We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. > > He does not show as an attendee at NANOG, but another executive, David Altstaetter, daltstaetter at calient.net did register, and may have even shown up. Hopefully those of you who have traditional community attitudes will show your reaction via your pocketbooks. > > Maybe its time for the NANOG board and staff to step in, and develop some teeth to use in cases like these? Unless the majority of you members are cool with unfettered spamming of member and attendee lists. In which case, have at it! > > Rodney > From rjoffe at centergate.com Tue Jun 13 15:19:46 2017 From: rjoffe at centergate.com (Rodney Joffe) Date: Tue, 13 Jun 2017 08:19:46 -0700 Subject: Vendors spamming NANOG attendees In-Reply-To: References: Message-ID: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> > On Jun 13, 2017, at 9:02 AM, Mel Beckman wrote: > > Rodney, > > What do you suggest? Shoot them at Dawn? :-) > > The standard warning and education has always been adequate in the past. We don't have a runaway spamming problem on the list. What standard warning and education? We have filters to stop spam making it to the list. But there is definitely a spamming problem of sorts amongst vendors, to subscriber addresses. I see something every couple of months that I can track back to NANOG, or ARIN. What I *know* is that if you open the door, and ignore it with vendors on NANOG, the list members will end up having a problem. If you want to know why I consider myself an expert, feel free to ask me offline about what the attitude that those of us who ran "the backbone" in 1994 had - and how that worked out. On the other hand, as a senior citizen, at the end of my tech days, with enable grudgingly given up, I guess I could turn away and say "not my problem, really". YMMV. > > -mel beckman > >> On Jun 13, 2017, at 6:00 AM, Rodney Joffe wrote: >> >> It seems that more than just a few of us were spammed by Glenn Stern (gstern at calient.net), an employee of Calient following NANOG 70. >> >> The spammer had the balls to say, in his email: >> >>> >>> We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. >> >> He does not show as an attendee at NANOG, but another executive, David Altstaetter, daltstaetter at calient.net did register, and may have even shown up. Hopefully those of you who have traditional community attitudes will show your reaction via your pocketbooks. >> >> Maybe its time for the NANOG board and staff to step in, and develop some teeth to use in cases like these? Unless the majority of you members are cool with unfettered spamming of member and attendee lists. In which case, have at it! >> >> Rodney >> From mel at beckman.org Tue Jun 13 15:31:46 2017 From: mel at beckman.org (Mel Beckman) Date: Tue, 13 Jun 2017 15:31:46 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> References: , <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> Message-ID: <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> Rodney, You said "I see something every couple of months that I can track back to NANOG, or ARIN." I would hardly call this a flood. But my point is that most people posting to NANOG, being technical people, respond to notifications that they are spamming. Your example email illustrates this perfectly. Sometimes they're ignorant and don't realize they're spamming. If they're persistent they get removed from the list (I don't think that has had to happen for several years). The remaining spammers are easily caught by filters, as you can plainly see. I don't see your need for urgency, and you still haven't said what you propose as a better arrangement. I made my suggestion. What's yours? -mel > On Jun 13, 2017, at 8:19 AM, Rodney Joffe wrote: > > >> On Jun 13, 2017, at 9:02 AM, Mel Beckman wrote: >> >> Rodney, >> >> What do you suggest? Shoot them at Dawn? :-) >> >> The standard warning and education has always been adequate in the past. We don't have a runaway spamming problem on the list. > > What standard warning and education? > > We have filters to stop spam making it to the list. > > But there is definitely a spamming problem of sorts amongst vendors, to subscriber addresses. > > I see something every couple of months that I can track back to NANOG, or ARIN. > > What I *know* is that if you open the door, and ignore it with vendors on NANOG, the list members will end up having a problem. If you want to know why I consider myself an expert, feel free to ask me offline about what the attitude that those of us who ran "the backbone" in 1994 had - and how that worked out. > > On the other hand, as a senior citizen, at the end of my tech days, with enable grudgingly given up, I guess I could turn away and say "not my problem, really". > > YMMV. >> >> -mel beckman >> >>> On Jun 13, 2017, at 6:00 AM, Rodney Joffe wrote: >>> >>> It seems that more than just a few of us were spammed by Glenn Stern (gstern at calient.net), an employee of Calient following NANOG 70. >>> >>> The spammer had the balls to say, in his email: >>> >>>> >>>> We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. >>> >>> He does not show as an attendee at NANOG, but another executive, David Altstaetter, daltstaetter at calient.net did register, and may have even shown up. Hopefully those of you who have traditional community attitudes will show your reaction via your pocketbooks. >>> >>> Maybe its time for the NANOG board and staff to step in, and develop some teeth to use in cases like these? Unless the majority of you members are cool with unfettered spamming of member and attendee lists. In which case, have at it! >>> >>> Rodney > From rjoffe at centergate.com Tue Jun 13 15:57:05 2017 From: rjoffe at centergate.com (Rodney Joffe) Date: Tue, 13 Jun 2017 08:57:05 -0700 Subject: Vendors spamming NANOG attendees In-Reply-To: <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> Message-ID: <31B7C3EA-25C7-428D-9E95-EB680589FD33@centergate.com> > On Jun 13, 2017, at 8:31 AM, Mel Beckman wrote: > > Rodney, > > You said "I see something every couple of months that I can track back to NANOG, or ARIN." > > I would hardly call this a flood. But my point is that most people posting to NANOG, being technical people, respond to notifications that they are spamming. Your example email illustrates this perfectly. Sometimes they're ignorant and don't realize they're spamming. If they're persistent they get removed from the list (I don't think that has had to happen for several years). > > The remaining spammers are easily caught by filters, as you can plainly see. > > I don't see your need for urgency, and you still haven't said what you propose as a better arrangement. I made my suggestion. What's yours? I'm one of 10,000. I assume others see as many as I do (I have no idea how many get caught in my filters). I don't recall calling this a flood. Did I? And I don't believe he is on the list so there's no way to "remove" him. I think the list does a good job over time "training" subscribers. But I did say that if others don't respond to spammers to this list from vendors, it will become a problem. The list is fertile ground. And I'm not sure that Sterns response indicates any awareness. He admitted he used the 1,300 person attendee list as a prospecting tool. So all that I am suggesting is that others take the time to respond to spam from vendors (as I did) rather than ignoring it (just hitting delete doesn't work out in the long run). I have to assume that after a reasonable number of people do complain to his company, they'll learn. And others on the list who are tempted, change their minds. I don't think the list itself per se suffers from a spam problem - although my 3 emails probably qualify as too much noise already. But it is vendors who use the list to prospect who should be discouraged. Btw I have no doubt that rogue salesmen from my companies over the years have tried it once. When I find out about it, I do kick butts. I'm hoping that this discussion is enough to get Calient to rethink their strategy. For crying out loud, the guy is a VP in their company. What kind of example is that? I'll end my public noise here :-) Rodney > > -mel > >> On Jun 13, 2017, at 8:19 AM, Rodney Joffe wrote: >> >> >>> On Jun 13, 2017, at 9:02 AM, Mel Beckman wrote: >>> >>> Rodney, >>> >>> What do you suggest? Shoot them at Dawn? :-) >>> >>> The standard warning and education has always been adequate in the past. We don't have a runaway spamming problem on the list. >> >> What standard warning and education? >> >> We have filters to stop spam making it to the list. >> >> But there is definitely a spamming problem of sorts amongst vendors, to subscriber addresses. >> >> I see something every couple of months that I can track back to NANOG, or ARIN. >> >> What I *know* is that if you open the door, and ignore it with vendors on NANOG, the list members will end up having a problem. If you want to know why I consider myself an expert, feel free to ask me offline about what the attitude that those of us who ran "the backbone" in 1994 had - and how that worked out. >> >> On the other hand, as a senior citizen, at the end of my tech days, with enable grudgingly given up, I guess I could turn away and say "not my problem, really". >> >> YMMV. >>> >>> -mel beckman >>> >>>> On Jun 13, 2017, at 6:00 AM, Rodney Joffe wrote: >>>> >>>> It seems that more than just a few of us were spammed by Glenn Stern (gstern at calient.net), an employee of Calient following NANOG 70. >>>> >>>> The spammer had the balls to say, in his email: >>>> >>>>> >>>>> We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. >>>> >>>> He does not show as an attendee at NANOG, but another executive, David Altstaetter, daltstaetter at calient.net did register, and may have even shown up. Hopefully those of you who have traditional community attitudes will show your reaction via your pocketbooks. >>>> >>>> Maybe its time for the NANOG board and staff to step in, and develop some teeth to use in cases like these? Unless the majority of you members are cool with unfettered spamming of member and attendee lists. In which case, have at it! >>>> >>>> Rodney >> From mel at beckman.org Tue Jun 13 16:37:44 2017 From: mel at beckman.org (Mel Beckman) Date: Tue, 13 Jun 2017 16:37:44 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: <31B7C3EA-25C7-428D-9E95-EB680589FD33@centergate.com> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <31B7C3EA-25C7-428D-9E95-EB680589FD33@centergate.com> Message-ID: <2013E4B9-7304-4B52-BFCF-CD7225264A89@beckman.org> Rodney, My misunderstanding. Despite the subject line noting NANOG attendees, I interpreted your statement "It seems that more than just a few of us were spammed?? to be referring to the NANOG mailing list (?us?). I figured the spammer was signing up to the list first. As for the attendee list, short of making it secret I?m (which would be counterproductive), I think we just have to live with it (I did not attend this year, and thus didn?t get spammed). -mel On Jun 13, 2017, at 8:57 AM, Rodney Joffe > wrote: On Jun 13, 2017, at 8:31 AM, Mel Beckman > wrote: Rodney, You said "I see something every couple of months that I can track back to NANOG, or ARIN." I would hardly call this a flood. But my point is that most people posting to NANOG, being technical people, respond to notifications that they are spamming. Your example email illustrates this perfectly. Sometimes they're ignorant and don't realize they're spamming. If they're persistent they get removed from the list (I don't think that has had to happen for several years). The remaining spammers are easily caught by filters, as you can plainly see. I don't see your need for urgency, and you still haven't said what you propose as a better arrangement. I made my suggestion. What's yours? I'm one of 10,000. I assume others see as many as I do (I have no idea how many get caught in my filters). I don't recall calling this a flood. Did I? And I don't believe he is on the list so there's no way to "remove" him. I think the list does a good job over time "training" subscribers. But I did say that if others don't respond to spammers to this list from vendors, it will become a problem. The list is fertile ground. And I'm not sure that Sterns response indicates any awareness. He admitted he used the 1,300 person attendee list as a prospecting tool. So all that I am suggesting is that others take the time to respond to spam from vendors (as I did) rather than ignoring it (just hitting delete doesn't work out in the long run). I have to assume that after a reasonable number of people do complain to his company, they'll learn. And others on the list who are tempted, change their minds. I don't think the list itself per se suffers from a spam problem - although my 3 emails probably qualify as too much noise already. But it is vendors who use the list to prospect who should be discouraged. Btw I have no doubt that rogue salesmen from my companies over the years have tried it once. When I find out about it, I do kick butts. I'm hoping that this discussion is enough to get Calient to rethink their strategy. For crying out loud, the guy is a VP in their company. What kind of example is that? I'll end my public noise here :-) Rodney -mel On Jun 13, 2017, at 8:19 AM, Rodney Joffe > wrote: On Jun 13, 2017, at 9:02 AM, Mel Beckman > wrote: Rodney, What do you suggest? Shoot them at Dawn? :-) The standard warning and education has always been adequate in the past. We don't have a runaway spamming problem on the list. What standard warning and education? We have filters to stop spam making it to the list. But there is definitely a spamming problem of sorts amongst vendors, to subscriber addresses. I see something every couple of months that I can track back to NANOG, or ARIN. What I *know* is that if you open the door, and ignore it with vendors on NANOG, the list members will end up having a problem. If you want to know why I consider myself an expert, feel free to ask me offline about what the attitude that those of us who ran "the backbone" in 1994 had - and how that worked out. On the other hand, as a senior citizen, at the end of my tech days, with enable grudgingly given up, I guess I could turn away and say "not my problem, really". YMMV. -mel beckman On Jun 13, 2017, at 6:00 AM, Rodney Joffe > wrote: It seems that more than just a few of us were spammed by Glenn Stern (gstern at calient.net), an employee of Calient following NANOG 70. The spammer had the balls to say, in his email: We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. He does not show as an attendee at NANOG, but another executive, David Altstaetter, daltstaetter at calient.net did register, and may have even shown up. Hopefully those of you who have traditional community attitudes will show your reaction via your pocketbooks. Maybe its time for the NANOG board and staff to step in, and develop some teeth to use in cases like these? Unless the majority of you members are cool with unfettered spamming of member and attendee lists. In which case, have at it! Rodney From rsk at gsp.org Tue Jun 13 17:12:07 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 13 Jun 2017 13:12:07 -0400 Subject: Vendors spamming NANOG attendees In-Reply-To: <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> Message-ID: <20170613171207.GA13643@gsp.org> On Tue, Jun 13, 2017 at 03:31:46PM +0000, Mel Beckman wrote: > Sometimes they're ignorant and don't realize they're spamming. That excuse stopped being viable sometime in the last century. They know exactly what they're doing, they're just counting on the prospective gains to outweigh the prospective losses. If they're right, then the spamming will not only continue, it will increase. (As we've seen: over and over and over again.) That's because they don't care about being professional or responsible or ethical: they only care about profits. So the choice is clear: either make it plain to such "people" (if I may dignify sociopathic filth with that term) that this is absolutely unacceptable and that it will have serious, immediate, ongoing negative financial consequences, or do nothing while the problem escalates indefinitely. If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well". --- Paul Vixie, on NANOG ---rsk From cra at WPI.EDU Tue Jun 13 17:47:17 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 13 Jun 2017 13:47:17 -0400 Subject: Vendors spamming NANOG attendees In-Reply-To: <20170613171207.GA13643@gsp.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> Message-ID: <20170613174717.GE29294@angus.ind.wpi.edu> I've started keeping a list of companies who make unsolicited calls/emails. I tell them that I put them on my list of companies never to do business with. On Tue, Jun 13, 2017 at 01:12:07PM -0400, Rich Kulawiec wrote: > On Tue, Jun 13, 2017 at 03:31:46PM +0000, Mel Beckman wrote: > > Sometimes they're ignorant and don't realize they're spamming. > > That excuse stopped being viable sometime in the last century. They know > exactly what they're doing, they're just counting on the prospective > gains to outweigh the prospective losses. If they're right, then the > spamming will not only continue, it will increase. (As we've seen: > over and over and over again.) That's because they don't care about > being professional or responsible or ethical: they only care about profits. > > So the choice is clear: either make it plain to such "people" (if I > may dignify sociopathic filth with that term) that this is absolutely > unacceptable and that it will have serious, immediate, ongoing negative > financial consequences, or do nothing while the problem escalates > indefinitely. > > If you give people the means to hurt you, and they do it, and > you take no action except to continue giving them the means to > hurt you, and they take no action except to keep hurting you, > then one of the ways you can describe the situation is "it isn't > scaling well". > --- Paul Vixie, on NANOG > > ---rsk From mel at beckman.org Tue Jun 13 17:47:23 2017 From: mel at beckman.org (Mel Beckman) Date: Tue, 13 Jun 2017 17:47:23 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: <20170613171207.GA13643@gsp.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org>, <20170613171207.GA13643@gsp.org> Message-ID: <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> That still leaves the question: how to you invoke this financial punishment? Prohibit NANOG members from buying their products? -mel via cell > On Jun 13, 2017, at 10:12 AM, Rich Kulawiec wrote: > >> On Tue, Jun 13, 2017 at 03:31:46PM +0000, Mel Beckman wrote: >> Sometimes they're ignorant and don't realize they're spamming. > > That excuse stopped being viable sometime in the last century. They know > exactly what they're doing, they're just counting on the prospective > gains to outweigh the prospective losses. If they're right, then the > spamming will not only continue, it will increase. (As we've seen: > over and over and over again.) That's because they don't care about > being professional or responsible or ethical: they only care about profits. > > So the choice is clear: either make it plain to such "people" (if I > may dignify sociopathic filth with that term) that this is absolutely > unacceptable and that it will have serious, immediate, ongoing negative > financial consequences, or do nothing while the problem escalates > indefinitely. > > If you give people the means to hurt you, and they do it, and > you take no action except to continue giving them the means to > hurt you, and they take no action except to keep hurting you, > then one of the ways you can describe the situation is "it isn't > scaling well". > --- Paul Vixie, on NANOG > > ---rsk From nanog at ics-il.net Tue Jun 13 18:02:12 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 13 Jun 2017 13:02:12 -0500 (CDT) Subject: Vendors spamming NANOG attendees In-Reply-To: <20170613174717.GE29294@angus.ind.wpi.edu> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <20170613174717.GE29294@angus.ind.wpi.edu> Message-ID: <1494961893.1781.1497376929625.JavaMail.mhammett@ThunderFuck> Overreact much? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Chuck Anderson" To: nanog at nanog.org Sent: Tuesday, June 13, 2017 12:47:17 PM Subject: Re: Vendors spamming NANOG attendees I've started keeping a list of companies who make unsolicited calls/emails. I tell them that I put them on my list of companies never to do business with. On Tue, Jun 13, 2017 at 01:12:07PM -0400, Rich Kulawiec wrote: > On Tue, Jun 13, 2017 at 03:31:46PM +0000, Mel Beckman wrote: > > Sometimes they're ignorant and don't realize they're spamming. > > That excuse stopped being viable sometime in the last century. They know > exactly what they're doing, they're just counting on the prospective > gains to outweigh the prospective losses. If they're right, then the > spamming will not only continue, it will increase. (As we've seen: > over and over and over again.) That's because they don't care about > being professional or responsible or ethical: they only care about profits. > > So the choice is clear: either make it plain to such "people" (if I > may dignify sociopathic filth with that term) that this is absolutely > unacceptable and that it will have serious, immediate, ongoing negative > financial consequences, or do nothing while the problem escalates > indefinitely. > > If you give people the means to hurt you, and they do it, and > you take no action except to continue giving them the means to > hurt you, and they take no action except to keep hurting you, > then one of the ways you can describe the situation is "it isn't > scaling well". > --- Paul Vixie, on NANOG > > ---rsk From Bryan at bryanfields.net Tue Jun 13 18:07:08 2017 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 13 Jun 2017 14:07:08 -0400 Subject: Vendors spamming NANOG attendees In-Reply-To: <20170613171207.GA13643@gsp.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> Message-ID: <1d24a0f4-6071-9b3e-e334-eddc3c224f37@bryanfields.net> On 6/13/17 1:12 PM, Rich Kulawiec wrote: > That excuse stopped being viable sometime in the last century. They know > exactly what they're doing, they're just counting on the prospective > gains to outweigh the prospective losses. If they're right, then the > spamming will not only continue, it will increase. (As we've seen: > over and over and over again.) That's because they don't care about > being professional or responsible or ethical: they only care about profits. Isn't that why we all work in this industry? Sure it's fun, but at the end of month it's that sizable deposit in our checking (or chequeing) accounts. > So the choice is clear: either make it plain to such "people" (if I > may dignify sociopathic filth with that term) that this is absolutely > unacceptable and that it will have serious, immediate, ongoing negative > financial consequences, or do nothing while the problem escalates > indefinitely. > > If you give people the means to hurt you, and they do it, and > you take no action except to continue giving them the means to > hurt you, and they take no action except to keep hurting you, > then one of the ways you can describe the situation is "it isn't > scaling well". > --- Paul Vixie, on NANOG It's vendor spam. It's annoying, but it's not life or death. Educate/shame, and move on. When it happens the second time, then get your pitchforks and rifles out :) how I feel about it: https://i.imgur.com/v7SJdmq.png -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From goemon at sasami.anime.net Tue Jun 13 18:34:51 2017 From: goemon at sasami.anime.net (Dan Hollis) Date: Tue, 13 Jun 2017 11:34:51 -0700 (PDT) Subject: Vendors spamming NANOG attendees In-Reply-To: <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org>, <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> Message-ID: It's funny to see all this apologia for nanog spammers and attempts to normalize the practice and brush it off as acceptable or unavoidable, especially after the "omg evil politicans voted to rollback fcc privacy rules and let companies sell your data" derpy derp thread. You can't have it both ways. -Dan From mel at beckman.org Tue Jun 13 19:25:24 2017 From: mel at beckman.org (Mel Beckman) Date: Tue, 13 Jun 2017 19:25:24 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org>, <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org>, Message-ID: <957A8B03-3400-4D4D-BD45-0F775F1BB78D@beckman.org> Dan, And your proposed solution is? -mel via cell > On Jun 13, 2017, at 11:35 AM, Dan Hollis wrote: > > It's funny to see all this apologia for nanog spammers and attempts to normalize the practice and brush it off as acceptable or unavoidable, especially after the "omg evil politicans voted to rollback fcc privacy rules and let companies sell your data" derpy derp thread. > > You can't have it both ways. > > -Dan From kmedcalf at dessus.com Tue Jun 13 19:36:32 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 13 Jun 2017 13:36:32 -0600 Subject: More Critical Microsoft Patches including XP/2003 Message-ID: Microsoft has released "critical patches" for "recently disclosed vulnerabilities which may be used for imminent attacks". Main page is here: https://technet.microsoft.com/en-us/library/security/4025685.aspx and that has links to the appropriate articles and places where you can actually download the patches. --- Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" -- Hunter S. Thompson From niels=nanog at bakker.net Tue Jun 13 20:16:31 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 13 Jun 2017 22:16:31 +0200 Subject: Vendors spamming NANOG attendees In-Reply-To: <957A8B03-3400-4D4D-BD45-0F775F1BB78D@beckman.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> <957A8B03-3400-4D4D-BD45-0F775F1BB78D@beckman.org> Message-ID: <20170613201631.GK86663@excession.tpb.net> * mel at beckman.org (Mel Beckman) [Tue 13 Jun 2017, 21:26 CEST]: >And your proposed solution is? Simple. Stop buying from spammers. -- Niels. From josmon at rigozsaurus.com Tue Jun 13 20:27:34 2017 From: josmon at rigozsaurus.com (John Osmon) Date: Tue, 13 Jun 2017 14:27:34 -0600 Subject: Vendors spamming NANOG attendees In-Reply-To: <1494961893.1781.1497376929625.JavaMail.mhammett@ThunderFuck> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <20170613174717.GE29294@angus.ind.wpi.edu> <1494961893.1781.1497376929625.JavaMail.mhammett@ThunderFuck> Message-ID: <20170613202734.GA20262@jeeves.rigozsaurus.com> > > From: "Chuck Anderson" > > To: nanog at nanog.org > > Sent: Tuesday, June 13, 2017 12:47:17 PM > > Subject: Re: Vendors spamming NANOG attendees > > > > I've started keeping a list of companies who make unsolicited > > calls/emails. I tell them that I put them on my list of companies > > never to do business with. On Tue, Jun 13, 2017 at 01:02:12PM -0500, Mike Hammett wrote: > Overreact much? Mike -- I suspect he *under*Reacts. I go so far as giving out unique e-mail whenever possible so that I can track the origin of scraped addresses... *And* I remind sales folks (and their bosses) why I won't buy from them. I guess they should be happy that I don't sign a lot of orders anymore... :-) From rsk at gsp.org Tue Jun 13 20:47:03 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 13 Jun 2017 16:47:03 -0400 Subject: Vendors spamming NANOG attendees In-Reply-To: <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> Message-ID: <20170613204702.GA29482@gsp.org> On Tue, Jun 13, 2017 at 05:47:23PM +0000, Mel Beckman wrote: > That still leaves the question: how to you invoke this financial > punishment? Prohibit NANOG members from buying their products? I don't think there's a mechanism to do that. (Please correct me if I'm wrong.) However, I think it's feasible to construct a list and make it publicly available so that folks can consult it before making purchase decisions. ---rsk From nanog at ics-il.net Tue Jun 13 20:56:12 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 13 Jun 2017 15:56:12 -0500 (CDT) Subject: Vendors spamming NANOG attendees In-Reply-To: <20170613204702.GA29482@gsp.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> <20170613204702.GA29482@gsp.org> Message-ID: <995439918.1893.1497387369860.JavaMail.mhammett@ThunderFuck> I think it would too subject to wild variance in what someone views as bad. Actual SPAM (viagra, Nigerian prices, etc.), of course. Industry-related SPAM, probably. Targeted marketing (looking for someone at Facebook, seeing someone from Facebook and tracking them down... or seeing someone at someone in a specific area or...) ehh, probably not ----- 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, June 13, 2017 3:47:03 PM Subject: Re: Vendors spamming NANOG attendees On Tue, Jun 13, 2017 at 05:47:23PM +0000, Mel Beckman wrote: > That still leaves the question: how to you invoke this financial > punishment? Prohibit NANOG members from buying their products? I don't think there's a mechanism to do that. (Please correct me if I'm wrong.) However, I think it's feasible to construct a list and make it publicly available so that folks can consult it before making purchase decisions. ---rsk From goemon at sasami.anime.net Tue Jun 13 22:16:57 2017 From: goemon at sasami.anime.net (Dan Hollis) Date: Tue, 13 Jun 2017 15:16:57 -0700 (PDT) Subject: Vendors spamming NANOG attendees In-Reply-To: <995439918.1893.1497387369860.JavaMail.mhammett@ThunderFuck> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> <20170613204702.GA29482@gsp.org> <995439918.1893.1497387369860.JavaMail.mhammett@ThunderFuck> Message-ID: On Tue, 13 Jun 2017, Mike Hammett wrote: > I think it would too subject to wild variance in what someone views as bad. > Actual SPAM (viagra, Nigerian prices, etc.), of course. > Industry-related SPAM, probably. > Targeted marketing (looking for someone at Facebook, seeing someone from Facebook and tracking them down... or seeing someone at someone in a specific area or...) ehh, probably not Do you view collecting lists of nanog members and using it for unsolicited marketing purposes as bad or not? -Dan From nanog at ics-il.net Tue Jun 13 22:22:15 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 13 Jun 2017 17:22:15 -0500 (CDT) Subject: Vendors spamming NANOG attendees In-Reply-To: References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> <20170613204702.GA29482@gsp.org> <995439918.1893.1497387369860.JavaMail.mhammett@ThunderFuck> Message-ID: <90420635.1926.1497392533850.JavaMail.mhammett@ThunderFuck> Does it fit into one of the categories I defined? I wasn't overly clear in the second example of the last category. Seeing someone working for someone that's in a specific area and then reaching out to them about something specific to their area... probably not. Further examples of yes\no for targeted marketing: Most any equipment vendor, unless it's quite geographically specific to someone, no, not unique enough. New provider, data center, IX, etc. geographically near a given company and they find "you" work at that company... sure, that seems like a perfectly valid use. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Dan Hollis" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Tuesday, June 13, 2017 5:16:57 PM Subject: Re: Vendors spamming NANOG attendees On Tue, 13 Jun 2017, Mike Hammett wrote: > I think it would too subject to wild variance in what someone views as bad. > Actual SPAM (viagra, Nigerian prices, etc.), of course. > Industry-related SPAM, probably. > Targeted marketing (looking for someone at Facebook, seeing someone from Facebook and tracking them down... or seeing someone at someone in a specific area or...) ehh, probably not Do you view collecting lists of nanog members and using it for unsolicited marketing purposes as bad or not? -Dan From marka at isc.org Wed Jun 14 00:10:37 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 14 Jun 2017 10:10:37 +1000 Subject: Vendors spamming NANOG attendees In-Reply-To: Your message of "Tue, 13 Jun 2017 17:47:23 +0000." <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org>, <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> Message-ID: <20170614001037.527487BA2FBB@rock.dv.isc.org> In message <38E506A8-247A-478F-9C4D-21602BEE6028 at beckman.org>, Mel Beckman writes: > That still leaves the question: how to you invoke this financial > punishment? Prohibit NANOG members from buying their products? Everyone that has received the email bring a action under the CAN-SPAM act. Really if you don't want the list to be harvested, which is illegal under the act, bring the action. Opt out doesn't save the sender if they have already committed a illegal act. Mark > -mel via cell > > > On Jun 13, 2017, at 10:12 AM, Rich Kulawiec wrote: > > > >> On Tue, Jun 13, 2017 at 03:31:46PM +0000, Mel Beckman wrote: > >> Sometimes they're ignorant and don't realize they're spamming. > > > > That excuse stopped being viable sometime in the last century. They > know > > exactly what they're doing, they're just counting on the prospective > > gains to outweigh the prospective losses. If they're right, then the > > spamming will not only continue, it will increase. (As we've seen: > > over and over and over again.) That's because they don't care about > > being professional or responsible or ethical: they only care about > profits. > > > > So the choice is clear: either make it plain to such "people" (if I > > may dignify sociopathic filth with that term) that this is absolutely > > unacceptable and that it will have serious, immediate, ongoing negative > > financial consequences, or do nothing while the problem escalates > > indefinitely. > > > > If you give people the means to hurt you, and they do it, and > > you take no action except to continue giving them the means to > > hurt you, and they take no action except to keep hurting you, > > then one of the ways you can describe the situation is "it isn't > > scaling well". > > --- Paul Vixie, on NANOG > > > > ---rsk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jhellenthal at dataix.net Wed Jun 14 00:19:36 2017 From: jhellenthal at dataix.net (J. Hellenthal) Date: Tue, 13 Jun 2017 19:19:36 -0500 Subject: More Critical Microsoft Patches including XP/2003 In-Reply-To: References: Message-ID: <877F8428-A7DE-42F5-A1DD-8BE701084956@DataIX.net> Thank you -- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN On Jun 13, 2017, at 14:36, Keith Medcalf wrote: Microsoft has released "critical patches" for "recently disclosed vulnerabilities which may be used for imminent attacks". Main page is here: https://technet.microsoft.com/en-us/library/security/4025685.aspx and that has links to the appropriate articles and places where you can actually download the patches. --- Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" -- Hunter S. Thompson From mel at beckman.org Wed Jun 14 01:39:39 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 14 Jun 2017 01:39:39 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: <20170614001037.527487BA2FBB@rock.dv.isc.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org>, <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org>, <20170614001037.527487BA2FBB@rock.dv.isc.org> Message-ID: Mark, The problem with your idea is that these NANOG attendee emails aren't illegal under CAN-SPAM. This toothless Act let's anyone email any address they want, however obtained, with virtually any content (except sexually explicit), as long as they don't use misleading headers, deceptive subject lines, or obscure the fact that the email is an ad. Those features, plus clear identification of the originator and an opt-out mechanism, let anyone send unlimited spam. So, in reality, these so-called NANOG spammers are within the law. We just don't like what they're doing. We definitely can't sue them as you advise. In fact, individual CANT use under CAN-SPAM. Only we network operators can. Thanks for nothing, Congress. -mel via cell > On Jun 13, 2017, at 5:10 PM, Mark Andrews wrote: > > > In message <38E506A8-247A-478F-9C4D-21602BEE6028 at beckman.org>, Mel Beckman writes: >> That still leaves the question: how to you invoke this financial >> punishment? Prohibit NANOG members from buying their products? > > Everyone that has received the email bring a action under the > CAN-SPAM act. Really if you don't want the list to be harvested, > which is illegal under the act, bring the action. Opt out doesn't > save the sender if they have already committed a illegal act. > > Mark > >> -mel via cell >> >>>> On Jun 13, 2017, at 10:12 AM, Rich Kulawiec wrote: >>>> >>>> On Tue, Jun 13, 2017 at 03:31:46PM +0000, Mel Beckman wrote: >>>> Sometimes they're ignorant and don't realize they're spamming. >>> >>> That excuse stopped being viable sometime in the last century. They >> know >>> exactly what they're doing, they're just counting on the prospective >>> gains to outweigh the prospective losses. If they're right, then the >>> spamming will not only continue, it will increase. (As we've seen: >>> over and over and over again.) That's because they don't care about >>> being professional or responsible or ethical: they only care about >> profits. >>> >>> So the choice is clear: either make it plain to such "people" (if I >>> may dignify sociopathic filth with that term) that this is absolutely >>> unacceptable and that it will have serious, immediate, ongoing negative >>> financial consequences, or do nothing while the problem escalates >>> indefinitely. >>> >>> If you give people the means to hurt you, and they do it, and >>> you take no action except to continue giving them the means to >>> hurt you, and they take no action except to keep hurting you, >>> then one of the ways you can describe the situation is "it isn't >>> scaling well". >>> --- Paul Vixie, on NANOG >>> >>> ---rsk > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Wed Jun 14 01:58:08 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 14 Jun 2017 11:58:08 +1000 Subject: Vendors spamming NANOG attendees In-Reply-To: Your message of "Wed, 14 Jun 2017 01:39:39 +0000." References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org>, <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org>, <20170614001037.527487BA2FBB@rock.dv.isc.org> Message-ID: <20170614015808.DF69F7BA9F2C@rock.dv.isc.org> In message , Mel Beckman writes: > Mark, > > The problem with your idea is that these NANOG attendee emails aren't > illegal under CAN-SPAM. This toothless Act let's anyone email any address > they want, however obtained, with virtually any content (except sexually > explicit), as long as they don't use misleading headers, deceptive > subject lines, or obscure the fact that the email is an ad. Those > features, plus clear identification of the originator and an opt-out > mechanism, let anyone send unlimited spam. The act of harvesting the email addresses is illegal which makes the subsequent emails illegal even if they meet all the other requirements of the CAN-SPAM act. > So, in reality, these so-called NANOG spammers are within the law. We > just don't like what they're doing. > > We definitely can't sue them as you advise. In fact, individual CANT use > under CAN-SPAM. Only we network operators can. > > Thanks for nothing, Congress. As someone with stonger local anti-spam legislation that has to put up with the spam from US sources I have to agree. Mark > -mel via cell > > > On Jun 13, 2017, at 5:10 PM, Mark Andrews wrote: > > > > > > In message <38E506A8-247A-478F-9C4D-21602BEE6028 at beckman.org>, Mel > Beckman writes: > >> That still leaves the question: how to you invoke this financial > >> punishment? Prohibit NANOG members from buying their products? > > > > Everyone that has received the email bring a action under the > > CAN-SPAM act. Really if you don't want the list to be harvested, > > which is illegal under the act, bring the action. Opt out doesn't > > save the sender if they have already committed a illegal act. > > > > Mark > > > >> -mel via cell > >> > >>>> On Jun 13, 2017, at 10:12 AM, Rich Kulawiec wrote: > >>>> > >>>> On Tue, Jun 13, 2017 at 03:31:46PM +0000, Mel Beckman wrote: > >>>> Sometimes they're ignorant and don't realize they're spamming. > >>> > >>> That excuse stopped being viable sometime in the last century. They > >> know > >>> exactly what they're doing, they're just counting on the prospective > >>> gains to outweigh the prospective losses. If they're right, then the > >>> spamming will not only continue, it will increase. (As we've seen: > >>> over and over and over again.) That's because they don't care about > >>> being professional or responsible or ethical: they only care about > >> profits. > >>> > >>> So the choice is clear: either make it plain to such "people" (if I > >>> may dignify sociopathic filth with that term) that this is absolutely > >>> unacceptable and that it will have serious, immediate, ongoing > negative > >>> financial consequences, or do nothing while the problem escalates > >>> indefinitely. > >>> > >>> If you give people the means to hurt you, and they do it, and > >>> you take no action except to continue giving them the means to > >>> hurt you, and they take no action except to keep hurting you, > >>> then one of the ways you can describe the situation is "it isn't > >>> scaling well". > >>> --- Paul Vixie, on NANOG > >>> > >>> ---rsk > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mel at beckman.org Wed Jun 14 02:34:50 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 14 Jun 2017 02:34:50 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: <20170614015808.DF69F7BA9F2C@rock.dv.isc.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org>, <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org>, <20170614001037.527487BA2FBB@rock.dv.isc.org> , <20170614015808.DF69F7BA9F2C@rock.dv.isc.org> Message-ID: Mark, What law makes the harvesting of email addresses illegal? None that I know of. -mel via cell > On Jun 13, 2017, at 6:58 PM, Mark Andrews wrote: > > > In message , Mel Beckman writes: >> Mark, >> >> The problem with your idea is that these NANOG attendee emails aren't >> illegal under CAN-SPAM. This toothless Act let's anyone email any address >> they want, however obtained, with virtually any content (except sexually >> explicit), as long as they don't use misleading headers, deceptive >> subject lines, or obscure the fact that the email is an ad. Those >> features, plus clear identification of the originator and an opt-out >> mechanism, let anyone send unlimited spam. > > The act of harvesting the email addresses is illegal which makes > the subsequent emails illegal even if they meet all the other > requirements of the CAN-SPAM act. > >> So, in reality, these so-called NANOG spammers are within the law. We >> just don't like what they're doing. >> >> We definitely can't sue them as you advise. In fact, individual CANT use >> under CAN-SPAM. Only we network operators can. >> >> Thanks for nothing, Congress. > > As someone with stonger local anti-spam legislation that has to put > up with the spam from US sources I have to agree. > > Mark > >> -mel via cell >> >>> On Jun 13, 2017, at 5:10 PM, Mark Andrews wrote: >>> >>> >>> In message <38E506A8-247A-478F-9C4D-21602BEE6028 at beckman.org>, Mel >> Beckman writes: >>>> That still leaves the question: how to you invoke this financial >>>> punishment? Prohibit NANOG members from buying their products? >>> >>> Everyone that has received the email bring a action under the >>> CAN-SPAM act. Really if you don't want the list to be harvested, >>> which is illegal under the act, bring the action. Opt out doesn't >>> save the sender if they have already committed a illegal act. >>> >>> Mark >>> >>>> -mel via cell >>>> >>>>>> On Jun 13, 2017, at 10:12 AM, Rich Kulawiec wrote: >>>>>> >>>>>> On Tue, Jun 13, 2017 at 03:31:46PM +0000, Mel Beckman wrote: >>>>>> Sometimes they're ignorant and don't realize they're spamming. >>>>> >>>>> That excuse stopped being viable sometime in the last century. They >>>> know >>>>> exactly what they're doing, they're just counting on the prospective >>>>> gains to outweigh the prospective losses. If they're right, then the >>>>> spamming will not only continue, it will increase. (As we've seen: >>>>> over and over and over again.) That's because they don't care about >>>>> being professional or responsible or ethical: they only care about >>>> profits. >>>>> >>>>> So the choice is clear: either make it plain to such "people" (if I >>>>> may dignify sociopathic filth with that term) that this is absolutely >>>>> unacceptable and that it will have serious, immediate, ongoing >> negative >>>>> financial consequences, or do nothing while the problem escalates >>>>> indefinitely. >>>>> >>>>> If you give people the means to hurt you, and they do it, and >>>>> you take no action except to continue giving them the means to >>>>> hurt you, and they take no action except to keep hurting you, >>>>> then one of the ways you can describe the situation is "it isn't >>>>> scaling well". >>>>> --- Paul Vixie, on NANOG >>>>> >>>>> ---rsk >>> >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Wed Jun 14 03:39:04 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 14 Jun 2017 13:39:04 +1000 Subject: Vendors spamming NANOG attendees In-Reply-To: Your message of "Wed, 14 Jun 2017 02:34:50 +0000." References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org>, <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org>, <20170614001037.527487BA2FBB@rock.dv.isc.org> , <20170614015808.DF69F7BA9F2C@rock.dv.isc.org> Message-ID: <20170614033904.3E66C7BAB637@rock.dv.isc.org> In message , Mel Beckman writes: > Mark, > > What law makes the harvesting of email addresses illegal? None that I > know of. If you can trust wikipedia sending to harvested addresses is illegal under CAN-SPAM. https://en.wikipedia.org/wiki/CAN-SPAM_Act_of_2003 While this is not US law, the act of harvesting addresses is illegal under the Australian anti-spam act https://www.legislation.gov.au/Details/C2016C00614 Mark > -mel via cell > > > On Jun 13, 2017, at 6:58 PM, Mark Andrews wrote: > > > > > > In message , Mel > Beckman writes: > >> Mark, > >> > >> The problem with your idea is that these NANOG attendee emails aren't > >> illegal under CAN-SPAM. This toothless Act let's anyone email any > address > >> they want, however obtained, with virtually any content (except > sexually > >> explicit), as long as they don't use misleading headers, deceptive > >> subject lines, or obscure the fact that the email is an ad. Those > >> features, plus clear identification of the originator and an opt-out > >> mechanism, let anyone send unlimited spam. > > > > The act of harvesting the email addresses is illegal which makes > > the subsequent emails illegal even if they meet all the other > > requirements of the CAN-SPAM act. > > > >> So, in reality, these so-called NANOG spammers are within the law. We > >> just don't like what they're doing. > >> > >> We definitely can't sue them as you advise. In fact, individual CANT > use > >> under CAN-SPAM. Only we network operators can. > >> > >> Thanks for nothing, Congress. > > > > As someone with stonger local anti-spam legislation that has to put > > up with the spam from US sources I have to agree. > > > > Mark > > > >> -mel via cell > >> > >>> On Jun 13, 2017, at 5:10 PM, Mark Andrews wrote: > >>> > >>> > >>> In message <38E506A8-247A-478F-9C4D-21602BEE6028 at beckman.org>, Mel > >> Beckman writes: > >>>> That still leaves the question: how to you invoke this financial > >>>> punishment? Prohibit NANOG members from buying their products? > >>> > >>> Everyone that has received the email bring a action under the > >>> CAN-SPAM act. Really if you don't want the list to be harvested, > >>> which is illegal under the act, bring the action. Opt out doesn't > >>> save the sender if they have already committed a illegal act. > >>> > >>> Mark > >>> > >>>> -mel via cell > >>>> > >>>>>> On Jun 13, 2017, at 10:12 AM, Rich Kulawiec wrote: > >>>>>> > >>>>>> On Tue, Jun 13, 2017 at 03:31:46PM +0000, Mel Beckman wrote: > >>>>>> Sometimes they're ignorant and don't realize they're spamming. > >>>>> > >>>>> That excuse stopped being viable sometime in the last century. They > >>>> know > >>>>> exactly what they're doing, they're just counting on the prospective > >>>>> gains to outweigh the prospective losses. If they're right, then > the > >>>>> spamming will not only continue, it will increase. (As we've seen: > >>>>> over and over and over again.) That's because they don't care about > >>>>> being professional or responsible or ethical: they only care about > >>>> profits. > >>>>> > >>>>> So the choice is clear: either make it plain to such "people" (if I > >>>>> may dignify sociopathic filth with that term) that this is > absolutely > >>>>> unacceptable and that it will have serious, immediate, ongoing > >> negative > >>>>> financial consequences, or do nothing while the problem escalates > >>>>> indefinitely. > >>>>> > >>>>> If you give people the means to hurt you, and they do it, and > >>>>> you take no action except to continue giving them the means to > >>>>> hurt you, and they take no action except to keep hurting you, > >>>>> then one of the ways you can describe the situation is "it isn't > >>>>> scaling well". > >>>>> --- Paul Vixie, on NANOG > >>>>> > >>>>> ---rsk > >>> > >>> -- > >>> Mark Andrews, ISC > >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From randy at psg.com Wed Jun 14 03:43:38 2017 From: randy at psg.com (Randy Bush) Date: Wed, 14 Jun 2017 10:43:38 +0700 Subject: Vendors spamming NANOG attendees In-Reply-To: References: Message-ID: > It seems that more than just a few of us were spammed by Glenn Stern > (gstern at calient.net), an employee of Calient following NANOG 70. > ... > Hopefully those of you who have traditional community attitudes will > show your reaction via your pocketbooks. traditional community attitudes left the building long ago. nanog has become a trade show, for which this is normal behavior. i expect mail "stop by our booth at nanog 42," and so forth. randy From surfer at mauigateway.com Wed Jun 14 04:27:36 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 13 Jun 2017 21:27:36 -0700 Subject: Vendors spamming NANOG attendees Message-ID: <20170613212736.677A4120@m0117566.ppops.net> :: What do you suggest? Shoot them at Dawn? :-) Not all of them. Just shoot the first one and the rest will pay attention! ;-) :: We don't have a runaway spamming problem on the list. A lot of it has to do with naming-n-shaming, which he did. Instead of a firing squad, it's a financial punishment squad. That's the only place it hurts them and if made public it's even more effective. :: And your proposed solution is? Let the naming-n-shaming continue, rather than supporting the slimy spammer's position! There's not a naming-n-shaming problem here, either. :: Prohibit NANOG members from buying their products? No, we will do that ourselves. scott ps. I feel like I'm in a different universe when NANOG folks are supporting the spammer's side on the list! From mel at beckman.org Wed Jun 14 05:28:37 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 14 Jun 2017 05:28:37 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: References: , Message-ID: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> But as I said, harvesting emails is not illegal under can spam. And the requirement to not send you UCE to harvested emails is pointless, because how do you prove that someone did that? -mel via cell On Jun 13, 2017, at 8:44 PM, Randy Bush wrote: >> It seems that more than just a few of us were spammed by Glenn Stern >> (gstern at calient.net), an employee of Calient following NANOG 70. >> ... >> Hopefully those of you who have traditional community attitudes will >> show your reaction via your pocketbooks. > > traditional community attitudes left the building long ago. nanog has > become a trade show, for which this is normal behavior. i expect mail > "stop by our booth at nanog 42," and so forth. > > randy From rjoffe at centergate.com Wed Jun 14 12:26:31 2017 From: rjoffe at centergate.com (Rodney Joffe) Date: Wed, 14 Jun 2017 05:26:31 -0700 Subject: Vendors spamming NANOG attendees In-Reply-To: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> Message-ID: <087770A4-F6FC-478B-A725-6189844F2744@centergate.com> > On Jun 13, 2017, at 10:28 PM, Mel Beckman wrote: > > But as I said, harvesting emails is not illegal under can spam. And the requirement to not send you UCE to harvested emails is pointless, because how do you prove that someone did that? > Because he said so? >>>> The spammer had the balls to say, in his email: >>>> >>>>> >>>>> We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. From mel at beckman.org Wed Jun 14 13:21:21 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 14 Jun 2017 13:21:21 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: <087770A4-F6FC-478B-A725-6189844F2744@centergate.com> References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org>, <087770A4-F6FC-478B-A725-6189844F2744@centergate.com> Message-ID: <5478E2D1-D0E9-4183-9EAF-D750CBF57DC6@beckman.org> Rodney, You make a good point. But I wonder how often spammers are so obvious, and I wonder if his "leveraging" falls amiss of CAN-SPAM's specific prohibition: (I) harvesting electronic mail addresses of the users of a website, proprietary service, or other online public forum operated by another person, without the authorization of such person; and (II) randomly generating electronic mail addresses by computer; Technically, this spammer harvested the names of attendees at a physical conference, not of some online resource, which is what CAN-SPAM prohibits. I know it's splitting hairs, but that's what spammers do. My point is that CAN-SPAM is virtually useless. There have been a handful of prosecutions in more than a decade, and spammers are not seeming to be deterred. I know there are honeypots that try to catch electronic harvesters, but I don't think they could provide proof of someone who got his emails from a list of attendees at an event, a shared customer list, etc. -mel On Jun 14, 2017, at 5:26 AM, Rodney Joffe > wrote: On Jun 13, 2017, at 10:28 PM, Mel Beckman > wrote: But as I said, harvesting emails is not illegal under can spam. And the requirement to not send you UCE to harvested emails is pointless, because how do you prove that someone did that? Because he said so? The spammer had the balls to say, in his email: We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. From mel at beckman.org Wed Jun 14 13:22:40 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 14 Jun 2017 13:22:40 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> <087770A4-F6FC-478B-A725-6189844F2744@centergate.com>, Message-ID: Ge, On the contrary, the discussion has been limited, focused, and amazingly civil for NANOG :) I find it valuable. -mel On Jun 14, 2017, at 5:33 AM, Ge Dupin > wrote: It looks like there are more spams coming from these discussions than from the original Scams/Spams.. Ge Le 14 juin 2017 ? 14:26, Rodney Joffe > a ?crit : On Jun 13, 2017, at 10:28 PM, Mel Beckman > wrote: But as I said, harvesting emails is not illegal under can spam. And the requirement to not send you UCE to harvested emails is pointless, because how do you prove that someone did that? Because he said so? The spammer had the balls to say, in his email: We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. From rjoffe at centergate.com Wed Jun 14 13:43:45 2017 From: rjoffe at centergate.com (Rodney Joffe) Date: Wed, 14 Jun 2017 06:43:45 -0700 Subject: Vendors spamming NANOG attendees In-Reply-To: References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> <087770A4-F6FC-478B-A725-6189844F2744@centergate.com> Message-ID: <40B271A9-9997-4E02-B2C7-D0E95EA6B8F3@centergate.com> I guess that explains why so many newcomers are confused about what spam is. > On Jun 14, 2017, at 5:33 AM, Ge Dupin wrote: > > It looks like there are more spams coming from these discussions than from the original Scams/Spams.. > Ge > >>> Le 14 juin 2017 ? 14:26, Rodney Joffe a ?crit : >>> >>> >>> >>> On Jun 13, 2017, at 10:28 PM, Mel Beckman wrote: >>> >>> But as I said, harvesting emails is not illegal under can spam. And the requirement to not send you UCE to harvested emails is pointless, because how do you prove that someone did that? >>> >> Because he said so? >> >>>>>> The spammer had the balls to say, in his email: >>>>>> >>>>>>> >>>>>>> We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. >> >> > From rbf+nanog at panix.com Wed Jun 14 16:26:44 2017 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 14 Jun 2017 11:26:44 -0500 Subject: Vendors spamming NANOG attendees In-Reply-To: <5478E2D1-D0E9-4183-9EAF-D750CBF57DC6@beckman.org> Message-ID: <20170614162644.GA29491@panix.com> On Wed, Jun 14, 2017 at 01:21:21PM +0000, Mel Beckman wrote: > Rodney, > > You make a good point. But I wonder how often spammers are so > obvious, and I wonder if his "leveraging" falls amiss of CAN-SPAM's > specific prohibition: > > (I) harvesting electronic mail addresses of the users of a website, > proprietary service, or other online public forum operated by another > person, without the authorization of such person; and > > (II) randomly generating electronic mail addresses by computer; > > Technically, this spammer harvested the names of attendees at a > physical conference, not of some online resource, which is what > CAN-SPAM prohibits. I know it's splitting hairs, but that's what > spammers do. There is no such specific prohibition in CAN-SPAM. The section of CAN SPAN from which you are quoting (15 USC 7703) instructs the Sentencing Commission to consider sentence enhancements for criminals convicted under existing computer crimes laws if they did one of the two things you list above. The part you left out (and which immediately precedes the part you quoted) reads: (2) In carrying out this subsection, the Sentencing Commission shall consider providing sentencing enhancements for? (A) those convicted under section 1037 of title 18 who? (i) obtained electronic mail addresses through improper means, including? [ then (I) and (II) from above ] Merely sending non-misleading spam does not violate 18 USC 1037. > My point is that CAN-SPAM is virtually useless. There have been a > handful of prosecutions in more than a decade, and spammers are not > seeming to be deterred. > > I know there are honeypots that try to catch electronic harvesters, > but I don't think they could provide proof of someone who got his > emails from a list of attendees at an event, a shared customer list, > etc. And even if someone did, no crime is committed. But if someone uses those addresses in the commission of another crime, he might go to prison for longer. -- Brett From johnl at iecc.com Wed Jun 14 14:02:47 2017 From: johnl at iecc.com (John Levine) Date: 14 Jun 2017 14:02:47 -0000 Subject: Vendors spamming NANOG attendees In-Reply-To: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> Message-ID: <20170614140247.4917.qmail@ary.lan> In article <63CD2031-701D-4567-B88A-2986E8B3F359 at beckman.org> you write: >But as I said, harvesting emails is not illegal under can spam. This might be a good time to review 15 USC 7704(b)(1), which is titled "Address harvesting and dictionary attacks". >And the requirement to not send you UCE to harvested emails >is pointless, because how do you prove that someone did that? This is law, not software. If a bunch of people who went to a trade show get spam to the addresses they used when they registered, well, duh. R's, John From rbf+nanog at panix.com Wed Jun 14 17:54:02 2017 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 14 Jun 2017 12:54:02 -0500 Subject: Vendors spamming NANOG attendees In-Reply-To: <20170614140247.4917.qmail@ary.lan> References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> <20170614140247.4917.qmail@ary.lan> Message-ID: <20170614175402.GA26695@panix.com> On Wed, Jun 14, 2017 at 02:02:47PM -0000, John Levine wrote: > In article <63CD2031-701D-4567-B88A-2986E8B3F359 at beckman.org> you write: > >But as I said, harvesting emails is not illegal under can spam. > > This might be a good time to review 15 USC 7704(b)(1), which is titled > "Address harvesting and dictionary attacks". When reviewing it, make sure to read the whole thing. Including the part where it doesn't prohibit those things (harvesting and dictionary attacks), but, instead, declares that those things are aggravating factors if done my someone as part of doing things that are prohibited by the section that actually prohibits things, which is 7704(a). -- Brett From bzs at theworld.com Wed Jun 14 19:24:07 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 14 Jun 2017 15:24:07 -0400 Subject: Vendors spamming NANOG attendees In-Reply-To: <20170613201631.GK86663@excession.tpb.net> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> <957A8B03-3400-4D4D-BD45-0F775F1BB78D@beckman.org> <20170613201631.GK86663@excession.tpb.net> Message-ID: <22849.36183.901425.150167@gargle.gargle.HOWL> On June 13, 2017 at 22:16 niels=nanog at bakker.net (Niels Bakker) wrote: > * mel at beckman.org (Mel Beckman) [Tue 13 Jun 2017, 21:26 CEST]: > >And your proposed solution is? > > Simple. Stop buying from spammers. Although a perfectly reasonable suggestion the problem is that the cost of spamming is so low that even yielding zero clients isn't much of a loss. And if just one person finds the tease interesting it's a big win for the vendor. So there's a huge scaling advantage with spam, always has been. It's more akin to someone going thru your neighborhood with a vehicle with a bullhorn at 3AM suggesting some product. Merely deciding not to patronize them may not be sufficient and that's why we make that sort of thing just outright illegal rather than hope market forces will suffice. Another problem is that even with zero direct returns the sender gets other value. The usual rule of thumb used to be that you had to see an ad about eight times before your were likely to remember the product. So, spam, 7 more times. And branding. You goog for a particular type of router or whatever and you're hit with several that seem like they'd do the job. But you don't recognize the vendor names which makes you uneasy...except that one, hmm, that's a familiar name...not sure why...ok let's give them a closer look... They're getting value even if not immediately obvious. And you'll probably forget they spammed you long before you stop recognizing their name as familiar. The point is why should they get all that value for just about free? -- -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 johnstong at westmancom.com Wed Jun 14 19:50:05 2017 From: johnstong at westmancom.com (Graham Johnston) Date: Wed, 14 Jun 2017 19:50:05 +0000 Subject: Templating/automating configuration In-Reply-To: References: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> Message-ID: <82C0CE81789FE64D8F4D15263191829715CEB2C1@MSG6.westman.int> Job, Would you be able to provide any further insight into your Don?t #5 ? ?Don?t agree to change management. Managers are rarely engineers and should not be making technical decisions. (nor should sales)?. Thanks, Graham From: Job Snijders [mailto:job at ntt.net] Sent: Tuesday, June 6, 2017 4:03 PM To: Brian Knight ; Graham Johnston Cc: nanog at nanog.org Subject: Re: Templating/automating configuration Hi, Here are some extra pointers: https://youtube.com/watch?v=C7pkab8n7ys https://www.nanog.org/sites/default/files/dosdontsnetworkautomation.pdf https://github.com/coloclue/kees Kind regards, Job On Tue, 6 Jun 2017 at 13:49, Brian Knight > wrote: Because we had different sources of truth which were written in-house, we wound up rolling our own template engine in Python. It took about 3 weeks to write the engine and adapt existing templates. Given a circuit ID, it generates the full config for copy and paste into a terminal session. It also hooks into a configuration parser tool, written in-house, that tracks configured interfaces, so it is easy to see whether the template would overwrite an existing interface. I used the Jinja2 template engine, along with pyodbc/unixODBC/FreeTDS for access to a Microsoft SQL backend. The keys for us are: * extracting information from a source of truth * validating the information for correctness * making sure you don't overwrite existing config * outputting the right templates for the circuit features It made more sense to write a tool than it did to try to adapt something for our environment. If I had a free hand and unlimited budget, I would find a single app that functions as a source of truth for all circuits and products, which includes a templating engine that hooks in easily. -Brian ---- On Tue, 06 Jun 2017 08:22:59 -0500 Graham Johnston <johnstong at westmancom.com> wrote ---- Short of complete SDN, for those of you that have some degree of configuration templating and/or automation tools what is it that you run? I'm envisioning some sort of tool that let's me define template snippets of configuration and aids in their deployment to devices. I'm okay doing the heaving lifting in defining everything, I'm just looking for the tool that stitches it together and hopefully makes things a little less error prone for those who aren't as adept. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com<mailto:johnstong at westmancom.com> From job at ntt.net Wed Jun 14 20:16:45 2017 From: job at ntt.net ('Job Snijders') Date: Wed, 14 Jun 2017 22:16:45 +0200 Subject: Templating/automating configuration In-Reply-To: <82C0CE81789FE64D8F4D15263191829715CEB2C1@MSG6.westman.int> References: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> <82C0CE81789FE64D8F4D15263191829715CEB2C1@MSG6.westman.int> Message-ID: <20170614201645.z2oflcpsjg64j3xv@Vurt.local> Hi Graham, The talk was giving in context of motivating people to start with network automation and help them go from 'no automation' to a step further 'some automation'. On Wed, Jun 14, 2017 at 07:50:05PM +0000, Graham Johnston wrote: > Would you be able to provide any further insight into your Don?t #5 ? > ?Don?t agree to change management. I think the development team of the network automation software should define their own process around change management. If you want to use kanban? great! if you want to use simple fifo model applied to issues filed on your private github project? great! My point was: don't let someone from higher up dictate how, and when you do software releases. Another aspect is that you most likely will have proceses that should run without any human intervention: such as the nightly update for all EBGP prefix-filters. You don't want to end up in a situation where a computer generates those configs and has to hand them over to a human for some additional checks and subsequently pushing it out to the network. Imagine having the computer print out your automatically generated configs, a human pick them up, review them, and type them back into a computer for the changes to take effect! That would be terrible. > Managers are rarely engineers and should not be making technical > decisions. (nor should sales)?. That was a simple point: ideally a manager enables you to do your work, and trusts you to do the work. If you have a manager who opinionatedly argues with you on tabs vs spaces or how to push a configuration to a device, you might find that you don't have enough freedom of movement to succesfully bootstrap the automation project. In other words: don't roll over and blindly accept what other (inexperienced) folks within the organisation tell you, try to find your own path. However, do make sure you steal the good ideas from the sysadmins: they often are ahead of netops in terms of automation and understanding idempotency. Kind regards, Job From nick at foobar.org Wed Jun 14 20:35:59 2017 From: nick at foobar.org (Nick Hilliard) Date: Wed, 14 Jun 2017 21:35:59 +0100 Subject: Templating/automating configuration In-Reply-To: <82C0CE81789FE64D8F4D15263191829715CEB2C1@MSG6.westman.int> References: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> <82C0CE81789FE64D8F4D15263191829715CEB2C1@MSG6.westman.int> Message-ID: <59419E2F.3030207@foobar.org> Graham Johnston wrote: > Would you be able to provide any further insight into your Don?t #5 ? > ?Don?t agree to change management. Managers are rarely engineers and > should not be making technical decisions. (nor should sales)?. What do you think the purpose of change control / management is? Nick From dave at temk.in Wed Jun 14 20:55:03 2017 From: dave at temk.in (Dave Temkin) Date: Wed, 14 Jun 2017 16:55:03 -0400 Subject: Vendors spamming NANOG attendees In-Reply-To: References: Message-ID: On Tue, Jun 13, 2017 at 11:43 PM, Randy Bush wrote: > > It seems that more than just a few of us were spammed by Glenn Stern > > (gstern at calient.net), an employee of Calient following NANOG 70. > > ... > > Hopefully those of you who have traditional community attitudes will > > show your reaction via your pocketbooks. > > traditional community attitudes left the building long ago. nanog has > become a trade show, for which this is normal behavior. i expect mail > "stop by our booth at nanog 42," and so forth. This is highly inaccurate. The PC and Board have done everything in our power to keep sponsorship out of the program. Yes, Beer & Gear looks like a NASCAR race, but that helps fund not only the program, but the numerous other outreach programs that NANOG has undertaken. Sponsors who have stepped on the rules have had their sponsorship rights revoked - temporarily, and in egregious cases, permanently. We (the NANOG organization) take this incredibly seriously. While it's hard to solve for the exact case above (scraping registrant lists and then comparing to CRM to glean contact info) we absolutely do aggressively pursue any abuse of NANOG's attendee information, trademarks, and mailing list. -Dave Temkin Chair, NANOG Board of Directors From job at ntt.net Wed Jun 14 20:55:10 2017 From: job at ntt.net (Job Snijders) Date: Wed, 14 Jun 2017 22:55:10 +0200 Subject: Templating/automating configuration In-Reply-To: <59419E2F.3030207@foobar.org> References: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> <82C0CE81789FE64D8F4D15263191829715CEB2C1@MSG6.westman.int> <59419E2F.3030207@foobar.org> Message-ID: <20170614205510.76mdghvprn3o4vwr@Vurt.local> On Wed, Jun 14, 2017 at 09:35:59PM +0100, Nick Hilliard wrote: > Graham Johnston wrote: > > Would you be able to provide any further insight into your Don?t #5 ? > > ?Don?t agree to change management. Managers are rarely engineers and > > should not be making technical decisions. (nor should sales)?. > > What do you think the purpose of change control / management is? well, http://dilbert.com/strip/1995-05-29 From jlewis at lewis.org Wed Jun 14 21:04:07 2017 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 14 Jun 2017 17:04:07 -0400 (EDT) Subject: Vendors spamming NANOG attendees In-Reply-To: References: Message-ID: On Wed, 14 Jun 2017, Dave Temkin wrote: > This is highly inaccurate. The PC and Board have done everything in our > power to keep sponsorship out of the program. Yes, Beer & Gear looks like a > NASCAR race, but that helps fund not only the program, but the numerous > other outreach programs that NANOG has undertaken. > > Sponsors who have stepped on the rules have had their sponsorship rights > revoked - temporarily, and in egregious cases, permanently. We (the NANOG > organization) take this incredibly seriously. > > While it's hard to solve for the exact case above (scraping registrant > lists and then comparing to CRM to glean contact info) we absolutely do > aggressively pursue any abuse of NANOG's attendee information, trademarks, > and mailing list. Is it too simple a solution to post a warning on the page above the Attendee List saying something along the lines of "scraping the Attendee List for marketing purposes is forbidden, will result in public shaming, and may cause some attendees to completely boycott your company." ? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From dave at temk.in Wed Jun 14 21:05:22 2017 From: dave at temk.in (Dave Temkin) Date: Wed, 14 Jun 2017 17:05:22 -0400 Subject: Vendors spamming NANOG attendees In-Reply-To: References: Message-ID: On Wed, Jun 14, 2017 at 5:04 PM, Jon Lewis wrote: > On Wed, 14 Jun 2017, Dave Temkin wrote: > > This is highly inaccurate. The PC and Board have done everything in our >> power to keep sponsorship out of the program. Yes, Beer & Gear looks like >> a >> NASCAR race, but that helps fund not only the program, but the numerous >> other outreach programs that NANOG has undertaken. >> >> Sponsors who have stepped on the rules have had their sponsorship rights >> revoked - temporarily, and in egregious cases, permanently. We (the NANOG >> organization) take this incredibly seriously. >> >> While it's hard to solve for the exact case above (scraping registrant >> lists and then comparing to CRM to glean contact info) we absolutely do >> aggressively pursue any abuse of NANOG's attendee information, trademarks, >> and mailing list. >> > > Is it too simple a solution to post a warning on the page above the > Attendee List saying something along the lines of "scraping the Attendee > List for marketing purposes is forbidden, will result in public shaming, > and may cause some attendees to completely boycott your company." ? > This suggestion was made on the NANOG Facebook group and we will implement it with the new website coming before NANOG 71. -Dave From goemon at sasami.anime.net Wed Jun 14 21:22:40 2017 From: goemon at sasami.anime.net (Dan Hollis) Date: Wed, 14 Jun 2017 14:22:40 -0700 (PDT) Subject: Vendors spamming NANOG attendees In-Reply-To: <22849.36183.901425.150167@gargle.gargle.HOWL> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> <957A8B03-3400-4D4D-BD45-0F775F1BB78D@beckman.org> <20170613201631.GK86663@excession.tpb.net> <22849.36183.901425.150167@gargle.gargle.HOWL> Message-ID: On Wed, 14 Jun 2017, bzs at theworld.com wrote: > Merely deciding not to patronize them may not be sufficient and that's > why we make that sort of thing just outright illegal rather than hope > market forces will suffice. Most spam is sent from compromised machines anyway, so there are already criminal violations involved in sending spam. -Dan From mike.meredith at port.ac.uk Thu Jun 15 11:10:54 2017 From: mike.meredith at port.ac.uk (Mike Meredith) Date: Thu, 15 Jun 2017 12:10:54 +0100 Subject: Templating/automating configuration In-Reply-To: <59419E2F.3030207@foobar.org> References: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> <82C0CE81789FE64D8F4D15263191829715CEB2C1@MSG6.westman.int> <59419E2F.3030207@foobar.org> Message-ID: <20170615121054.3c277dbf@scrofula.eps.is.port.ac.uk> On Wed, 14 Jun 2017 21:35:59 +0100, Nick Hilliard may have written: > What do you think the purpose of change control / management is? To provide employment for change managers of course. -- Mike Meredith, University of Portsmouth Chief Systems Engineer, Hostmaster, Security, and Timelord! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mysidia at gmail.com Thu Jun 15 13:35:48 2017 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 15 Jun 2017 08:35:48 -0500 Subject: Templating/automating configuration In-Reply-To: <20170614205510.76mdghvprn3o4vwr@Vurt.local> References: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com> <82C0CE81789FE64D8F4D15263191829715CEB2C1@MSG6.westman.int> <59419E2F.3030207@foobar.org> <20170614205510.76mdghvprn3o4vwr@Vurt.local> Message-ID: On Wed, Jun 14, 2017 at 3:55 PM, Job Snijders wrote: > On Wed, Jun 14, 2017 at 09:35:59PM +0100, Nick Hilliard wrote: >> Graham Johnston wrote: >> > Would you be able to provide any further insight into your Don?t #5 ? >> > ?Don?t agree to change management. Managers are rarely engineers and >> > should not be making technical decisions. (nor should sales)?. >> >> What do you think the purpose of change control / management is? > > well, http://dilbert.com/strip/1995-05-29 > On Wed, Jun 14, 2017 at 09:35:59PM +0100, Nick Hilliard wrote: >> What do you think the purpose of change control / management is? Bureaucratic change control implementations using the ITIL view of change control with a formal CAB are likely an (over)reaction to human mistakes causing outages, most of which could probably be avoided with a simpler less-formal process such as peer or team review. Change control functions as a risk transfer away from operations teams to CAB board members, since if things go wrong b/c of a change: it is now the CAB's fault. There may also be bias towards change-aversity if the CAB cannot be held accountable for issues that come from delaying or rejecting important maintenance. Overall purpose for change control / management, when applied to substantial modifications to an operating environment or configuration of business-critical network/applications is To mitigate possibility of damage/outages from high-impact / high-risk changes made by humans to systems and network-devices by requiring standards of formal written documentation and planning, combined with peer review And approvals by business and technical stakeholders for the maintenance time, including evaluation of exact proposed configuration changes, implementation plans, and backout/contingency plan: for possible errors or omissions. But as with most things can be taken to an unreasonable extreme. The use of change management procedures has a high associated cost, b/c the time and labor to implement even simple relatively low-risk changes can be dramatically increased with an unreasonable delay, and extensive test labs may be necessary. There may actually be increases in various risks, if any kind of maintenance is delayed or lost in the paperwork. -- -JH From amitchell at isipp.com Thu Jun 15 14:47:52 2017 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Thu, 15 Jun 2017 08:47:52 -0600 Subject: Vendors spamming NANOG attendees In-Reply-To: References: Message-ID: > You make a good point. But I wonder how often spammers are so obvious, and I wonder if his "leveraging" falls amiss of CAN-SPAM's specific prohibition: > > > (I) harvesting electronic mail addresses of the users of a website, proprietary service, or other online public forum operated by another person, without the authorization of such person; and > Unfortunately, the actual language of that provision requires that the website from which it was scraped must also include a notice stating that the website will not "give, sell, or otherwise transfer addresses maintained by such website". Here is the actual language: "(i) the electronic mail address of the recipient was obtained using an automated means from an Internet website or proprietary online service operated by another person, and such website or online service included, at the time the address was obtained, a notice stating that the operator of such website or online service will not give, sell, or otherwise transfer addresses maintained by such website or online service to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages;" It would be interesting* if people had language printed right on their business cards along the lines of: "The presence of my email address on this card does not constitute permission for you to email me absent a prior agreement, or to put my email address on a mailing list." *And by interesting, I mean legally interesting. ;-) Anne* *Dictated due to broken wrist, please forgive top-posting and any weird grammar or typos Anne P. Mitchell, Attorney at Law Legislative Consultant CEO/President, Institute for Social Internet Public Policy Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Member, Board of Directors, Greenwood Wildlife Rehabilitation Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From carlosm3011 at gmail.com Thu Jun 15 16:19:07 2017 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Thu, 15 Jun 2017 13:19:07 -0300 Subject: Fwd: [lacnog] Call for Presentations =?utf-8?q?=E2=80=93?= LACNOG 2017 References: Message-ID: <016AC828-4441-447F-839F-9AF2968E9F20@gmail.com> FYI, apologies for duplicates. Forwarded message: > From: Tomas Lynch > To: lacnog at lacnog.org > Subject: [lacnog] Call for Presentations ? LACNOG 2017 > Date: Thu, 15 Jun 2017 08:55:17 -0400 > > LACNOG, the Latin American and Caribbean Network Operators Group, will > be > holding its annual conference ? LACNOG 2017 ? in the city of > Montevideo, > Uruguay, on 18-22 September 2017. This event will be co-located with > the > LACNIC 28 meeting. > > The 2017 LACNOG Program Committee invites the Internet community to > submit > their presentations for the event. > > > > Possible formats are as follows: > > - > > Lightning talk: short, 10-minute presentation with an additional 5 > minutes for questions. > - > > Presentation: 20-minute presentation with an additional 10 minutes > for > questions. > - > > Tutorial: 45-minute presentation with an additional 15 minutes for > questions. > > In the spirit of LACNOG, the topics to be covered by the presentations > should be geared towards regional Internet development. The topics of > interest to LACNOG 2017 include, but are not limited to: > > - > > Network operation and professional experiences, success stories > - > > IP network architecture, sizing, configuration and administration > - > > Routing and switching protocols, including unicast, multicast, > anycast, > and others > - > > End-user applications (e.g. E-mail, HTTP, DNS, etc.) > - > > Value-added services such as VPNs, distributed systems, cloud > computing, > etc. > - > > Peering, regional traffic exchange, IXPs > - > > Transition to IPv6 and IPv6 Deployment > - > > Network security and data management, attack mitigation > - > > Network monitoring, performance, measurements and telemetry > - > > Network automation, evolution and convergence > - > > Infrastructure and physical transport including optical and > wireless > networks > - > > Internet governance issues, legislation and regulations > - > > Research and education > > > > All submissions must meet the following requirements: > > - > > Proposals must be submitted in English, Portuguese or Spanish. > - > > Accepted formats: Microsoft Powerpoint (PPT, PPTX), Apache > OpenOffice > Presentation (ODP), LibreOffice Impress (ODP), or Portable Document > Format > (PDF). > - > > The number of slides must be appropriate for the time assigned for > the > presentation. As a rule of thumb, estimate 1-2 minutes per slide. > - > > We recommend following the Guidelines for Submitting a Presentation > . > > > > Presentations must be submitted according to the following schedule: > > - > > Reception of drafts and abstracts: 12 June to 17 July > - > > Evaluation by the Program Committee: 17 to 31 July > - > > Submission of the final presentation: 31 July to 28 August > - > > Event date: 18-22 September > > > > Anyone wishing to participate must submit a short biography, picture > and > abstract to > http://www.lacnog.org/en/call-for-presentations-lacnog-2017/ > > > > Presenters at the LACNOG 2017 conference will receive a certificate > attesting their participation. > > > > Program Committee > _______________________________________________ > LACNOG mailing list > LACNOG at lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog From bzs at theworld.com Thu Jun 15 18:09:58 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 15 Jun 2017 14:09:58 -0400 Subject: Vendors spamming NANOG attendees In-Reply-To: References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> <957A8B03-3400-4D4D-BD45-0F775F1BB78D@beckman.org> <20170613201631.GK86663@excession.tpb.net> <22849.36183.901425.150167@gargle.gargle.HOWL> Message-ID: <22850.52598.813219.757004@gargle.gargle.HOWL> On June 14, 2017 at 14:22 goemon at sasami.anime.net (Dan Hollis) wrote: > On Wed, 14 Jun 2017, bzs at theworld.com wrote: > > Merely deciding not to patronize them may not be sufficient and that's > > why we make that sort of thing just outright illegal rather than hope > > market forces will suffice. > > Most spam is sent from compromised machines anyway, so there are already > criminal violations involved in sending spam. FWIW I believe the context was a vendor spamming NANOG attendees (see the Subject:) so not likely being done from compromised machines. That said, yes, a lot of spam is sent from compromised machines as you say. But criminal violations can be additive, even rising to things like RICO charges (a pattern of organized criminal behavior etc.) which can be both criminal and civil and added onto charges like the criminality of specific mechanisms (compromised systems etc.) It really depends on how interested one can get the legal machinery in the problem. Thus far that's hit or miss. I can't find any instance where RICO charges were used against a spam gang tho, at least on a quick search. -- -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 outsider at scarynet.org Fri Jun 16 15:06:26 2017 From: outsider at scarynet.org (Alexander Maassen) Date: Fri, 16 Jun 2017 17:06:26 +0200 Subject: Vendors spamming NANOG attendees Message-ID: the discussion about the external spam kinda exceeds the volume of the spam itself. just my 2 cents. just block, delete, continue life Kind regards, Alexander Maassen - Technical Maintenance Engineer Parkstad Support BV- Maintainer DroneBL- Peplink Certified Engineer -------- Oorspronkelijk bericht --------Van: bzs at theworld.com Datum: 15-06-17 20:09 (GMT+01:00) Aan: Dan Hollis Cc: Niels Bakker , nanog at nanog.org, bzs at theworld.com Onderwerp: Re: Vendors spamming NANOG attendees On June 14, 2017 at 14:22 goemon at sasami.anime.net (Dan Hollis) wrote: > On Wed, 14 Jun 2017, bzs at theworld.com wrote: > > Merely deciding not to patronize them may not be sufficient and that's > > why we make that sort of thing just outright illegal rather than hope > > market forces will suffice. > > Most spam is sent from compromised machines anyway, so there are already > criminal violations involved in sending spam. FWIW I believe the context was a vendor spamming NANOG attendees (see the Subject:) so not likely being done from compromised machines. That said, yes, a lot of spam is sent from compromised machines as you say. But criminal violations can be additive, even rising to things like RICO charges (a pattern of organized criminal behavior etc.) which can be both criminal and civil and added onto charges like the criminality of specific mechanisms (compromised systems etc.) It really depends on how interested one can get the legal machinery in the problem. Thus far that's hit or miss. I can't find any instance where RICO charges were used against a spam gang tho, at least on a quick search. -- ??????? -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 cscora at apnic.net Fri Jun 16 18:02:51 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Jun 2017 04:02:51 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170616180251.0FA34C44B5@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 17 Jun, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 651216 Prefixes after maximum aggregation (per Origin AS): 253596 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 313678 Total ASes present in the Internet Routing Table: 57522 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 49794 Origin ASes announcing only one prefix: 21982 Transit ASes present in the Internet Routing Table: 7728 Transit-only ASes present in the Internet Routing Table: 221 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 42 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 50 Numnber of instances of unregistered ASNs: 54 Number of 32-bit ASNs allocated by the RIRs: 19084 Number of 32-bit ASNs visible in the Routing Table: 14816 Prefixes from 32-bit ASNs in the Routing Table: 60261 Number of bogon 32-bit ASNs visible in the Routing Table: 65 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 395 Number of addresses announced to Internet: 2848765156 Equivalent to 169 /8s, 204 /16s and 180 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.6 Total number of prefixes smaller than registry allocations: 216985 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 178613 Total APNIC prefixes after maximum aggregation: 51337 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 177820 Unique aggregates announced from the APNIC address blocks: 73451 APNIC Region origin ASes present in the Internet Routing Table: 8177 APNIC Prefixes per ASN: 21.75 APNIC Region origin ASes announcing only one prefix: 2284 APNIC Region transit ASes present in the Internet Routing Table: 1158 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 42 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3010 Number of APNIC addresses announced to Internet: 763804388 Equivalent to 45 /8s, 134 /16s and 186 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 198323 Total ARIN prefixes after maximum aggregation: 94647 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 200232 Unique aggregates announced from the ARIN address blocks: 92051 ARIN Region origin ASes present in the Internet Routing Table: 17902 ARIN Prefixes per ASN: 11.18 ARIN Region origin ASes announcing only one prefix: 6620 ARIN Region transit ASes present in the Internet Routing Table: 1776 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2033 Number of ARIN addresses announced to Internet: 1110205088 Equivalent to 66 /8s, 44 /16s and 98 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 175032 Total RIPE prefixes after maximum aggregation: 85556 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 170672 Unique aggregates announced from the RIPE address blocks: 102495 RIPE Region origin ASes present in the Internet Routing Table: 24125 RIPE Prefixes per ASN: 7.07 RIPE Region origin ASes announcing only one prefix: 11106 RIPE Region transit ASes present in the Internet Routing Table: 3388 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5917 Number of RIPE addresses announced to Internet: 711738752 Equivalent to 42 /8s, 108 /16s and 69 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 82046 Total LACNIC prefixes after maximum aggregation: 18272 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 83317 Unique aggregates announced from the LACNIC address blocks: 38421 LACNIC Region origin ASes present in the Internet Routing Table: 6022 LACNIC Prefixes per ASN: 13.84 LACNIC Region origin ASes announcing only one prefix: 1645 LACNIC Region transit ASes present in the Internet Routing Table: 1113 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3537 Number of LACNIC addresses announced to Internet: 170651872 Equivalent to 10 /8s, 43 /16s and 240 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 17102 Total AfriNIC prefixes after maximum aggregation: 3739 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 18780 Unique aggregates announced from the AfriNIC address blocks: 6926 AfriNIC Region origin ASes present in the Internet Routing Table: 1047 AfriNIC Prefixes per ASN: 17.94 AfriNIC Region origin ASes announcing only one prefix: 326 AfriNIC Region transit ASes present in the Internet Routing Table: 204 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 319 Number of AfriNIC addresses announced to Internet: 91917056 Equivalent to 5 /8s, 122 /16s and 139 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5543 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3929 403 356 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2977 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2787 11137 759 KIXS-AS-KR Korea Telecom, KR 9829 2752 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2205 8699 34 CMNET-GD Guangdong Mobile Communication 4755 2086 422 221 TATACOMM-AS TATA Communications formerl 45899 1989 1396 108 VNPT-AS-VN VNPT Corp, VN 7552 1630 1105 70 VIETEL-AS-AP Viettel Corporation, VN 9498 1591 361 139 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3809 2969 154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3419 1333 82 SHAW - Shaw Communications Inc., CA 18566 2127 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2066 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2009 2171 419 CHARTER-NET-HKY-NC - Charter Communicat 209 1816 5068 639 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1814 3441 585 AMAZON-02 - Amazon.com, Inc., US 30036 1786 325 307 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1696 854 232 ITCDELTA - Earthlink, Inc., US 701 1561 10578 635 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3184 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2893 969 2083 AKAMAI-ASN1, US 34984 2023 329 391 TELLCOM-AS, TR 9121 1971 1691 17 TTNET, TR 13188 1614 100 55 TRIOLAN, UA 12479 1603 1044 53 UNI2-AS, ES 12389 1525 1408 627 ROSTELECOM-AS, RU 6849 1226 355 21 UKRTELNET, UA 8402 1125 544 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3549 546 148 Telmex Colombia S.A., CO 8151 2542 3404 574 Uninet S.A. de C.V., MX 11830 2085 369 57 Instituto Costarricense de Electricidad 7303 1547 989 275 Telecom Argentina S.A., AR 6503 1540 437 53 Axtel, S.A.B. de C.V., MX 6147 1298 377 27 Telefonica del Peru S.A.A., PE 3816 1026 501 94 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 979 2299 177 CLARO S.A., BR 11172 910 126 82 Alestra, S. de R.L. de C.V., MX 18881 896 1052 23 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1261 398 48 LINKdotNET-AS, EG 37611 720 83 7 Afrihost, ZA 36903 713 358 123 MT-MPLS, MA 36992 638 1375 26 ETISALAT-MISR, EG 24835 495 850 15 RAYA-AS, EG 29571 421 36 10 CITelecom-AS, CI 37492 407 320 75 ORANGE-, TN 8452 361 1730 17 TE-AS TE-AS, EG 15399 353 35 7 WANANCHI-, KE 2018 300 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5543 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3929 403 356 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3809 2969 154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3549 546 148 Telmex Colombia S.A., CO 6327 3419 1333 82 SHAW - Shaw Communications Inc., CA 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3184 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 17974 2977 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2893 969 2083 AKAMAI-ASN1, US 4766 2787 11137 759 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3809 3655 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3929 3573 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3549 3401 Telmex Colombia S.A., CO 6327 3419 3337 SHAW - Shaw Communications Inc., CA 39891 3338 3316 ALJAWWALSTC-AS, SA 8551 3184 3144 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2977 2904 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9829 2752 2212 BSNL-NIB National Internet Backbone, IN 9808 2205 2171 CMNET-GD Guangdong Mobile Communication Co.Ltd. 4766 2787 2028 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65010 PRIVATE 46.56.192.0/21 42772 VELCOM-AS, BY 65010 PRIVATE 46.56.224.0/21 42772 VELCOM-AS, BY 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65346 PRIVATE 94.50.36.0/22 31094 TTKNET Tyumen, Russia, RU 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:280 /13:546 /14:1046 /15:1847 /16:13485 /17:7630 /18:13432 /19:24628 /20:38586 /21:41176 /22:77437 /23:64125 /24:364605 /25:841 /26:608 /27:644 /28:43 /29:32 /30:25 /31:3 /32:29 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3210 3419 SHAW - Shaw Communications Inc., CA 22773 2972 3809 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2898 3338 ALJAWWALSTC-AS, SA 8551 2649 3184 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2020 2127 MEGAPATH5-US - MegaPath Corporation, US 30036 1579 1786 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1475 2085 Instituto Costarricense de Electricidad y Telec 10620 1474 3549 Telmex Colombia S.A., CO 6389 1373 2066 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 9121 1363 1971 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1605 2:824 4:18 5:2431 6:34 8:1031 12:1830 13:122 14:1762 15:26 16:2 17:124 18:91 20:57 23:2366 24:1838 25:2 27:2434 31:1910 32:86 33:9 35:20 36:411 37:2329 38:1320 39:45 40:97 41:3019 42:463 43:1940 44:72 45:2777 46:2790 47:140 49:1225 50:984 51:18 52:825 54:363 55:6 56:4 57:42 58:1591 59:1048 60:391 61:1954 62:1602 63:1915 64:4558 65:2219 66:4519 67:2253 68:1241 69:3385 70:1147 71:585 72:2180 74:2691 75:386 76:431 77:1487 78:1450 79:2439 80:1399 81:1398 82:996 83:709 84:898 85:1747 86:481 87:1146 88:766 89:2071 90:176 91:6166 92:975 93:2379 94:2377 95:2681 96:624 97:353 98:1052 99:86 100:154 101:1272 103:15041 104:2923 105:194 106:489 107:1662 108:819 109:3013 110:1432 111:1724 112:1194 113:1233 114:1029 115:1716 116:1799 117:1719 118:2145 119:1592 120:1037 121:1111 122:2255 123:1819 124:1503 125:1897 128:776 129:646 130:431 131:1401 132:531 133:199 134:653 135:225 136:455 137:436 138:1930 139:489 140:395 141:571 142:760 143:928 144:793 145:181 146:1018 147:690 148:1432 149:581 150:706 151:974 152:707 153:302 154:816 155:750 156:600 157:647 158:449 159:1478 160:678 161:744 162:2525 163:533 164:794 165:1221 166:386 167:1252 168:2684 169:785 170:3383 171:319 172:1016 173:1913 174:811 175:748 176:1880 177:4079 178:2477 179:1176 180:2215 181:1897 182:2366 183:998 184:859 185:9851 186:3134 187:2223 188:2688 189:1814 190:8203 191:1353 192:9441 193:5787 194:4652 195:3909 196:2114 197:1313 198:5501 199:5894 200:7439 201:4334 202:10349 203:9956 204:4489 205:2816 206:3036 207:3167 208:3990 209:4025 210:3970 211:2148 212:2857 213:2491 214:889 215:66 216:5735 217:2102 218:855 219:600 220:1658 221:913 222:762 223:1176 End of report From ahebert at pubnix.net Fri Jun 16 22:58:31 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 16 Jun 2017 18:58:31 -0400 Subject: Google Cloud and IX - Traffic behavior Message-ID: Hi, Anyone aware of different traffic behavior depending if the target goes through normal peering than through an exchanges google exists in? We're facing a weird issue where the same GCLD Instance can upload up to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but cannot get more than 20Mbps on similar hosts (8 of them) sittings on our peering links. PS; Those sames hosts get up to their link limit ( 1Gbps ) between each others and others test points we have; PS: Wireshark capture show nothing abnormal; PS: Links aren't congested, and so on... Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only test point with a TorIX access -- ----- 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 From sf at lists.esoteric.ca Fri Jun 16 23:42:40 2017 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Fri, 16 Jun 2017 19:42:40 -0400 Subject: Google Cloud and IX - Traffic behavior In-Reply-To: References: Message-ID: Alain, When you refer to "normal peering" do you mean Internet transit? Or are these PNI's with Google? Do the GCLD instance you reach through "normal peering" have higher latency than through TorIX? -- Stephen On 2017-06-16 6:58 PM, Alain Hebert wrote: > Hi, > > Anyone aware of different traffic behavior depending if the target > goes through normal peering than through an exchanges google exists in? > > We're facing a weird issue where the same GCLD Instance can upload > up to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, > but cannot get more than 20Mbps on similar hosts (8 of them) sittings on > our peering links. > > PS; Those sames hosts get up to their link limit ( 1Gbps ) between > each others and others test points we have; > > PS: Wireshark capture show nothing abnormal; > > PS: Links aren't congested, and so on... > > Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only test > point with a TorIX access > From cook at cookreport.com Sat Jun 17 01:25:56 2017 From: cook at cookreport.com (Gordon Cook) Date: Fri, 16 Jun 2017 21:25:56 -0400 Subject: Google Cloud and IX - Traffic behavior In-Reply-To: References: Message-ID: <304AB7E9-7AA9-40CC-BCF5-DFAAC9A9C62E@cookreport.com> i also see now that you are a guru rinpoche as wlell but with valerie home any minute i must stop will come back though > On Jun 16, 2017, at 7:42 PM, Stephen Fulton wrote: > > Alain, > > When you refer to "normal peering" do you mean Internet transit? Or are these PNI's with Google? Do the GCLD instance you reach through "normal peering" have higher latency than through TorIX? > > -- Stephen > > On 2017-06-16 6:58 PM, Alain Hebert wrote: >> Hi, >> Anyone aware of different traffic behavior depending if the target goes through normal peering than through an exchanges google exists in? >> We're facing a weird issue where the same GCLD Instance can upload up to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but cannot get more than 20Mbps on similar hosts (8 of them) sittings on our peering links. >> PS; Those sames hosts get up to their link limit ( 1Gbps ) between each others and others test points we have; >> PS: Wireshark capture show nothing abnormal; >> PS: Links aren't congested, and so on... >> Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only test point with a TorIX access > From list at satchell.net Sat Jun 17 17:54:57 2017 From: list at satchell.net (Stephen Satchell) Date: Sat, 17 Jun 2017 10:54:57 -0700 Subject: Net neutrality filing Message-ID: <2b1076b3-e7ee-ac1c-efe6-1af06bf96a59@satchell.net> > https://ecfsapi.fcc.gov/file/10616167661646/satchell.answers2questions.NPRM.17-108.pdf Warning: this is 63 pages long, and dull as dishwater. It does have a few color pictures, though. And one comic strip. Summary: fix the statutes (thank you Sen. Stevens, for the junk!) and apply Title II only to monopoly Internet access service providers. I had sent this notice to a listserve (of which I'm a subscriber) of telecomm policy people, and I'm getting a whole lot of pushback. So I thought, why should NANOG lose out on the fun? So, instead of you hearing about this in the sweet bye and bye, I'll get the firestorm over with now, rather than stretching this out for three months. (I'm on this listserve, too.) And if you think my ideas are bad, perhaps you will propose a better suggestion to the FCC about the subject. From jhaustin at gmail.com Sat Jun 17 21:10:41 2017 From: jhaustin at gmail.com (Jeremy Austin) Date: Sat, 17 Jun 2017 13:10:41 -0800 Subject: Net neutrality filing In-Reply-To: <2b1076b3-e7ee-ac1c-efe6-1af06bf96a59@satchell.net> References: <2b1076b3-e7ee-ac1c-efe6-1af06bf96a59@satchell.net> Message-ID: On Sat, Jun 17, 2017 at 9:54 AM, Stephen Satchell wrote: > > It does have a few color pictures, though. And one comic strip. > Upvote for use of 'caisson'. There is at least one thing that Sen. Ted Stevens got right; in the fiber era, the Internet really *is* a series of tubes. I appreciate that a target of 35,000 per county or "county equivalent" (parish, borough?) is just a number ? but I believe I would prefer a metric keyed to actual geographic population density rather than to political or municipal boundaries qua boundaries. At least it seems to me that you are wanting to encourage rural development, given that the current broadband 'divide' is largely a rural vs. urban one, according to the 2016 Broadband Progress Report. Natural monopolies worked for electrification. Do you anticipate Title I providers as being sufficient to the task of narrowing this divide, with or without a federal incentives program? Historically, federal incentives have largely gone to Title II providers or their affiliated ISPs, if I understand the math correctly. https://www.brookings.edu/blog/the-avenue/2017/02/13/in-infrastructure-plan-a-big-opening-for-rural-broadband/ Jeremy Austin From list at satchell.net Sun Jun 18 01:13:27 2017 From: list at satchell.net (Stephen Satchell) Date: Sat, 17 Jun 2017 18:13:27 -0700 Subject: Net neutrality filing In-Reply-To: References: <2b1076b3-e7ee-ac1c-efe6-1af06bf96a59@satchell.net> Message-ID: <8ca45326-c685-948f-bb67-bad6b822c3ed@satchell.net> On 06/17/2017 02:10 PM, Jeremy Austin wrote: > I appreciate that a target of 35,000 per county or "county equivalent" > (parish, borough?) is just a number ? but I believe I would prefer a metric > keyed to actual geographic population density rather than to political or > municipal boundaries qua boundaries. At least it seems to me that you are > wanting to encourage rural development, given that the current broadband > 'divide' is largely a rural vs. urban one, according to the 2016 Broadband > Progress Report. If you have a better idea regarding how to differentiate rural monopoly broadband providers to urban monopoly providers, please submit a comment to the FCC about your ideas of the right way to differentiate them. > Natural monopolies worked for electrification. Do you anticipate Title I > providers as being sufficient to the task of narrowing this divide, with or > without a federal incentives program? Historically, federal incentives have > largely gone to Title II providers or their affiliated ISPs, if I > understand the math correctly. Title I providers did an excellent job back in the early days of the Internet providing service in virtually every area, including rural locations. Let me explain. I was on the Telecommunications Industry Associations' Transmitter Group 30 (TR30) by invitation of members, because I was publishing modem reviews in places like Byte and MacWorld magazines. The membership invited me to learn how to do it "right" to better serve the readership. (By the way, TIA TR30 used to be known as the "Modem Working Group". See the references to 47 CFR 68.) What was interesting is that the model "loops" (telephone circuits) included wire simulation for calls between rural locations to town upramps to the 'Net. When I incorporated the recommended loop models in my testing, I was able to show what modems would be good for the outliers to use. In that sense, that was the industry's way of trying to serve everyone, not just the "townies". The only Title II involvement was over the PSTN circuits themselves. Now, I can't talk to federal incentives. I can understand why, though -- the large providers have enough lawyers to put in bids "in the proper language" to win awards. The small ISPs can't afford a law firm with sixty names on the masthead. You may want to check the FCC site to see if there is a NPRM on subsidies on rural broadband, and comment on the questions contained in such a document. Or file a request for consideration -- there is a way to do that on EFCS. From nanog at radu-adrian.feurdean.net Sun Jun 18 13:36:10 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sun, 18 Jun 2017 15:36:10 +0200 Subject: IPv6 traffic percentages? In-Reply-To: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> References: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> Message-ID: <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> On Mon, Jun 5, 2017, at 14:51, Bajpai, Vaibhav wrote: > The v6 numbers from ^ NANOG post are now more than 1 year old. Thought > to re-bump this thread. Would it be possible to share updated numbers > of v6 traffic share within your network and % contribution by top apps. Hello, A little late and "out-of-geography", but still... On small-ish French ISP we have : - on the residential-only FTTH part, where all clients have IPv6 by default (unless they do something to avoid using it - and some do) : up to 30% of total is IPv6, and at least 60% of IPv6 is with Google. - globally (residential+business), the rate drops to 9% with peaks towards 20% on week-ends and public holidays. Same thing with Google doing most of IPv6. For the record, apart Google, there are less than 10 ASes that have more than 1% (but less than 10%) of the total IPv6 traffic. Everybody else is just traces.... Also for the record, business customers are much more active in *rejecting* IPv6, either explictely (they say they want it disabled) or implicitly (they install their own router, not configured for IPv6). The bigger the business, the bigger the chance of rejection. -- R-A.F. From notify.sina at gmail.com Sun Jun 18 18:59:41 2017 From: notify.sina at gmail.com (Sina Owolabi) Date: Sun, 18 Jun 2017 19:59:41 +0100 Subject: Internet connectivity in Nigeria Message-ID: Hi All Currently having a terrible situation in Nigeria where the GLO1 and MainOne cables appear to be both down. Can anyone suggest a good Nigerian ISP with redundancies enough to overcome at least two of the following dying out? SAT-3 WACS GLO1 ACE MainOne Please dont say MTN or any of the Nigerian telcos, except there are no other options, customer service will leave you trying to commit bodily harm. From rod.beck at unitedcablecompany.com Sun Jun 18 19:10:00 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Sun, 18 Jun 2017 19:10:00 +0000 Subject: Internet connectivity in Nigeria In-Reply-To: References: Message-ID: PCCW has a strong presence in Africa and they are easy to work with. - R. ________________________________ From: NANOG on behalf of Sina Owolabi Sent: Sunday, June 18, 2017 8:59:41 PM To: nanog at nanog.org list Subject: Internet connectivity in Nigeria Hi All Currently having a terrible situation in Nigeria where the GLO1 and MainOne cables appear to be both down. Can anyone suggest a good Nigerian ISP with redundancies enough to overcome at least two of the following dying out? SAT-3 WACS GLO1 ACE MainOne Please dont say MTN or any of the Nigerian telcos, except there are no other options, customer service will leave you trying to commit bodily harm. From notify.sina at gmail.com Sun Jun 18 19:29:23 2017 From: notify.sina at gmail.com (Sina Owolabi) Date: Sun, 18 Jun 2017 20:29:23 +0100 Subject: Internet connectivity in Nigeria In-Reply-To: References: Message-ID: PCCW? I dont think I've heard of them On Sun, Jun 18, 2017 at 8:10 PM, Rod Beck wrote: > > PCCW has a strong presence in Africa and they are easy to work with. > > > - R. > > ________________________________ > From: NANOG on behalf of Sina Owolabi > > Sent: Sunday, June 18, 2017 8:59:41 PM > To: nanog at nanog.org list > Subject: Internet connectivity in Nigeria > > Hi All > > Currently having a terrible situation in Nigeria where the GLO1 and > MainOne cables appear to be both down. > Can anyone suggest a good Nigerian ISP with redundancies enough to > overcome at least two of the following dying out? > > SAT-3 > WACS > GLO1 > ACE > MainOne > > Please dont say MTN or any of the Nigerian telcos, except there are no > other options, customer service will leave you trying to commit bodily > harm. From joelja at bogus.com Sun Jun 18 20:01:33 2017 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 18 Jun 2017 13:01:33 -0700 Subject: Internet connectivity in Nigeria In-Reply-To: References: Message-ID: <1E03945A-07D8-48B2-8D51-93AA19845139@bogus.com> Sent from my iPhone > On Jun 18, 2017, at 12:29, Sina Owolabi wrote: > > PCCW? I dont think I've heard of them Pccw would be sat3 glo1 and wacs maybe others. http://mediafiles.pccwglobal.com/images/downloads/Inf_map.pdf Their looking glass can give you some idea into their reach with Nigeria with a little experimentation. http://lookingglass.pccwglobal.com/ That said sat3 and glo1 combined have something like an order of magnitude less capacity than wacs so the survival / utility of any of the older systems when losing the newest ones is probably less than complete. > > On Sun, Jun 18, 2017 at 8:10 PM, Rod Beck > wrote: >> >> PCCW has a strong presence in Africa and they are easy to work with. >> >> >> - R. >> >> ________________________________ >> From: NANOG on behalf of Sina Owolabi >> >> Sent: Sunday, June 18, 2017 8:59:41 PM >> To: nanog at nanog.org list >> Subject: Internet connectivity in Nigeria >> >> Hi All >> >> Currently having a terrible situation in Nigeria where the GLO1 and >> MainOne cables appear to be both down. >> Can anyone suggest a good Nigerian ISP with redundancies enough to >> overcome at least two of the following dying out? >> >> SAT-3 >> WACS >> GLO1 >> ACE >> MainOne >> >> Please dont say MTN or any of the Nigerian telcos, except there are no >> other options, customer service will leave you trying to commit bodily >> harm. > From notify.sina at gmail.com Sun Jun 18 20:54:41 2017 From: notify.sina at gmail.com (Sina Owolabi) Date: Sun, 18 Jun 2017 21:54:41 +0100 Subject: Internet connectivity in Nigeria In-Reply-To: <1E03945A-07D8-48B2-8D51-93AA19845139@bogus.com> References: <1E03945A-07D8-48B2-8D51-93AA19845139@bogus.com> Message-ID: Yes I just tried a very comforting traceroute traceroute ip 63.223.7.7 Sun Jun 18 20:52:28.946 GMT Tracing the route to 63.223.7.7 1 TenGE13-3.br03.chc01.pccwbtn.net (63.218.4.253) [MPLS: Label 24967 Exp 0] 182 msec TenGE12-2.br03.chc01.pccwbtn.net (63.218.4.249) 182 msec TenGE13-3.br03.chc01.pccwbtn.net (63.218.4.253) 182 msec 2 TenGE13-3.br03.chc01.pccwbtn.net (63.218.4.253) [MPLS: Label 24967 Exp 0] 181 msec TenGE12-2.br03.chc01.pccwbtn.net (63.218.4.249) 182 msec 181 msec 3 TenGE15-0.cr04.chc01.pccwbtn.net (63.218.4.193) [MPLS: Label 5035 Exp 0] 181 msec 181 msec 181 msec 4 pos2-0.cr04.nyc02.pccwbtn.net (63.218.4.38) [MPLS: Label 20449 Exp 0] 181 msec 181 msec 180 msec 5 pos4-0.cr04.ldn01.pccwbtn.net (63.218.12.85) [MPLS: Label 24363 Exp 0] 181 msec 181 msec 181 msec 6 ge0-1.204.var01.los01.pccwbtn.net (63.223.7.41) 181 msec * 180 msec read timed-out Query Complete On Sun, Jun 18, 2017 at 9:01 PM, Joel Jaeggli wrote: > > > Sent from my iPhone > > On Jun 18, 2017, at 12:29, Sina Owolabi wrote: > > PCCW? I dont think I've heard of them > > > Pccw would be sat3 glo1 and wacs maybe others. > > http://mediafiles.pccwglobal.com/images/downloads/Inf_map.pdf > > Their looking glass can give you some idea into their reach with Nigeria > with a little experimentation. > > http://lookingglass.pccwglobal.com/ > > That said sat3 and glo1 combined have something like an order of magnitude > less capacity than wacs so the survival / utility of any of the older > systems when losing the newest ones is probably less than complete. > > > On Sun, Jun 18, 2017 at 8:10 PM, Rod Beck > wrote: > > > PCCW has a strong presence in Africa and they are easy to work with. > > > > - R. > > > ________________________________ > > From: NANOG on behalf of Sina Owolabi > > > > Sent: Sunday, June 18, 2017 8:59:41 PM > > To: nanog at nanog.org list > > Subject: Internet connectivity in Nigeria > > > Hi All > > > Currently having a terrible situation in Nigeria where the GLO1 and > > MainOne cables appear to be both down. > > Can anyone suggest a good Nigerian ISP with redundancies enough to > > overcome at least two of the following dying out? > > > SAT-3 > > WACS > > GLO1 > > ACE > > MainOne > > > Please dont say MTN or any of the Nigerian telcos, except there are no > > other options, customer service will leave you trying to commit bodily > > harm. > > From cook at cookreport.com Sun Jun 18 21:45:09 2017 From: cook at cookreport.com (Gordon Cook) Date: Sun, 18 Jun 2017 17:45:09 -0400 Subject: Google Cloud and IX - Traffic behavior In-Reply-To: <304AB7E9-7AA9-40CC-BCF5-DFAAC9A9C62E@cookreport.com> References: <304AB7E9-7AA9-40CC-BCF5-DFAAC9A9C62E@cookreport.com> Message-ID: <174CF0A0-3435-4C70-82AC-04BC8F73536C@cookreport.com> please accept my apologies this response was totally out of context > On Jun 16, 2017, at 9:25 PM, Gordon Cook wrote: > > > i also see now that you are a guru rinpoche as wlell > > but with valerie home any minute i must stop > > will come back though >> On Jun 16, 2017, at 7:42 PM, Stephen Fulton wrote: >> >> Alain, >> >> When you refer to "normal peering" do you mean Internet transit? Or are these PNI's with Google? Do the GCLD instance you reach through "normal peering" have higher latency than through TorIX? >> >> -- Stephen >> >> On 2017-06-16 6:58 PM, Alain Hebert wrote: >>> Hi, >>> Anyone aware of different traffic behavior depending if the target goes through normal peering than through an exchanges google exists in? >>> We're facing a weird issue where the same GCLD Instance can upload up to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but cannot get more than 20Mbps on similar hosts (8 of them) sittings on our peering links. >>> PS; Those sames hosts get up to their link limit ( 1Gbps ) between each others and others test points we have; >>> PS: Wireshark capture show nothing abnormal; >>> PS: Links aren't congested, and so on... >>> Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only test point with a TorIX access >> > > From vwittkop at nanog.org Sun Jun 18 22:32:31 2017 From: vwittkop at nanog.org (Valerie Wittkop) Date: Sun, 18 Jun 2017 18:32:31 -0400 Subject: [NANOG-announce] Mailman Maintenance Message-ID: <8F845A62-C524-4965-BD16-71FBBD56AEED@nanog.org> Hello NANOGers, The mailman servers will be undergoing maintenance tonight between 8:00 and 8:30pm Eastern. Mail sent to lists hosted on the NANOG mailman servers will be held during the maintenance window. Regular operations will resume once the maintenance is complete. Sincerely, NANOG Staff _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From aaron1 at gvtc.com Mon Jun 19 11:52:42 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Mon, 19 Jun 2017 06:52:42 -0500 Subject: IPv6 traffic percentages? In-Reply-To: <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> References: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> Message-ID: <000801d2e8f2$8fad88d0$af089a70$@gvtc.com> When you say some percentage is with Google, what do you mean by that ? What do you mean by "with Google" ? - Aaron Gould From fhr at fhrnet.eu Mon Jun 19 12:17:05 2017 From: fhr at fhrnet.eu (fhr at fhrnet.eu) Date: Mon, 19 Jun 2017 14:17:05 +0200 Subject: IPv6 traffic percentages? In-Reply-To: <000801d2e8f2$8fad88d0$af089a70$@gvtc.com> Message-ID: <868e7dfb-0820-4659-85ce-4a838b36ba40@email.android.com> From ahebert at pubnix.net Mon Jun 19 13:36:28 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 19 Jun 2017 09:36:28 -0400 Subject: Google Cloud and IX - Traffic behavior In-Reply-To: References: Message-ID: <0a58f4fe-8e77-cb9e-fa20-c4732ec6593c@pubnix.net> Hi, Yes Stephen, we're talking the usual like GTT... And no latency wise they're about the same. In the 35ms range. But I still can't figure out the 10 x drop, that level of latency alone cannot be the factor. ( And Gordy... what?!? ) ----- 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 06/16/17 19:42, Stephen Fulton wrote: > Alain, > > When you refer to "normal peering" do you mean Internet transit? Or > are these PNI's with Google? Do the GCLD instance you reach through > "normal peering" have higher latency than through TorIX? > > -- Stephen > > On 2017-06-16 6:58 PM, Alain Hebert wrote: >> Hi, >> >> Anyone aware of different traffic behavior depending if the >> target goes through normal peering than through an exchanges google >> exists in? >> >> We're facing a weird issue where the same GCLD Instance can >> upload up to 200Mbps (Ref 1) if the target path goes through, lets >> say TorIX, but cannot get more than 20Mbps on similar hosts (8 of >> them) sittings on our peering links. >> >> PS; Those sames hosts get up to their link limit ( 1Gbps ) >> between each others and others test points we have; >> >> PS: Wireshark capture show nothing abnormal; >> >> PS: Links aren't congested, and so on... >> >> Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only >> test point with a TorIX access >> > From aaron1 at gvtc.com Mon Jun 19 14:52:15 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Mon, 19 Jun 2017 09:52:15 -0500 Subject: GozNym - Gozi ISFB - Nymaim Message-ID: <003601d2e90b$a452d650$ecf882f0$@gvtc.com> Anyone experienced in stopping/blocking/cleaning GozNym - Gozi ISFB - Nymaim ? - Aaron Gould From anthony.kasza at gmail.com Mon Jun 19 15:53:08 2017 From: anthony.kasza at gmail.com (anthony kasza) Date: Mon, 19 Jun 2017 09:53:08 -0600 Subject: GozNym - Gozi ISFB - Nymaim In-Reply-To: <003601d2e90b$a452d650$ecf882f0$@gvtc.com> References: <003601d2e90b$a452d650$ecf882f0$@gvtc.com> Message-ID: Have you had a chance to read this blog? https://securityintelligence.com/meet-goznym-the-banking-malware-offspring-of-gozi-isfb-and-nymaim/ -AK On Jun 19, 2017 8:54 AM, "Aaron Gould" wrote: > Anyone experienced in stopping/blocking/cleaning GozNym - Gozi ISFB - > Nymaim > ? > > > > - Aaron Gould > > From aaron1 at gvtc.com Mon Jun 19 15:54:57 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Mon, 19 Jun 2017 10:54:57 -0500 Subject: GozNym - Gozi ISFB - Nymaim In-Reply-To: References: <003601d2e90b$a452d650$ecf882f0$@gvtc.com> Message-ID: <005201d2e914$66fc1560$34f44020$@gvtc.com> I was already reading that? haven?t finished? is there a section in there about cleaning/blocking it ? -Aaron Gould From: anthony kasza [mailto:anthony.kasza at gmail.com] Sent: Monday, June 19, 2017 10:53 AM To: Aaron Gould Cc: North American Network Operators Group Subject: Re: GozNym - Gozi ISFB - Nymaim Have you had a chance to read this blog? https://securityintelligence.com/meet-goznym-the-banking-malware-offspring-of-gozi-isfb-and-nymaim/ -AK On Jun 19, 2017 8:54 AM, "Aaron Gould" > wrote: Anyone experienced in stopping/blocking/cleaning GozNym - Gozi ISFB - Nymaim ? - Aaron Gould From nanog at radu-adrian.feurdean.net Mon Jun 19 16:39:19 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Mon, 19 Jun 2017 18:39:19 +0200 Subject: IPv6 traffic percentages? In-Reply-To: <868e7dfb-0820-4659-85ce-4a838b36ba40@email.android.com> References: <868e7dfb-0820-4659-85ce-4a838b36ba40@email.android.com> Message-ID: <1497890359.2565116.1014308952.218B537B@webmail.messagingengine.com> On Mon, Jun 19, 2017, at 14:17, fhr at fhrnet.eu wrote: > I assume it means 60% of all their IPv6 traffic is reaching Google > services, ie GMail or YouTube. Exactly. Or otherwise said, more than 60% of the IPv6 bytes (NOT flow entries) accounted via Sflow (residential) or sampled Netflow (whole traffic) come from or go to?2a00:1450::/29. We had month with over 67%. From colton.conor at gmail.com Mon Jun 19 18:26:55 2017 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 19 Jun 2017 13:26:55 -0500 Subject: DWDM Mux/Demux using 40G Optics Message-ID: We are building a 40G metro ring using 40-Gigabit Ethernet QSFP+ Transceivers. Specifically, we are using Juniper JNP-QSFP-40G-LR4. This is a QSFP+ Transceiver with a LC duplex head. We only have one pair of single mode dark fibers around the ring. Our distance between nodes around the ring are all less than 10KM, so we can use standard optics. We go out of one JNP-QSFP-40G-LR4 and into another JNP-QSFP-40G-LR4. There are no passive muxes involved. This is working great for 40G. My understanding is a JNP-QSFP-40G-LR4 is really a transceiver with a CWDM mux built into it. The spec sheet shows it sends 4 10G channels: https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/optical-interface-qfx-support.html Lane wavelength Lane 0?1264.5 nm through 1277.5 nm Lane 1?1284.5 nm through 1297.5 nm Lane 2?1304.5 nm through 1317.5 nm Lane 3?1324.5 nm through 1337.5 nm This setup is working fine, but now we want to do more than 40G around the ring. To my knowledge there are no other 40G QSFP+ transceivers that use four other channel/lanes than the ones already being used, so they only way to go higher than 40G is to stack 10G or 100G channels ontop of the fiber pair using a passive mux. 100G is too expensive for the time being, so we are looking to add 10G channels to a ring that already have one 40G channel using the QSFP+. I was reading this tutorial, and it mentions "there is a 1310 nm port integrated in a 40 channels DWDM Mux/Demux system. The 1310nm added port is a Wide Band Optic port (WBO) added to other specific DWDM wavelengths in a module. When we run out of all channels in a DWDM Mux/Demux system, we can add the extra optics via this 1310nm port." http://www.fs.com/upgrade-to-500g-with-40ch-dwdm-mux-demux-system-aid-493.html What I can't seem to understand is they are mentioning that this 1310 port can pass QSFP+ signals, so it sounds like its really a 1270nm through 1330nm port? Is this what they mean by Wide Band Optic port (WBO)? We don't need 40 10G channels plus a 40G for a total of 440G. More than likely we are looking at a 8 channel mux/demux, and 1 40G port for a total of 120G. I don't care if we do CWDM vs DWDM, but I assume it will be hard to find a CWDM mux that has one LC dupluex input for 1270nm through 1330nm channels? Maybe I should just ditch the 40G QSFP+ optics and use all 10G optics, but the switches I am using have 48 10G SFP+ ports and 6 QSFP+ ports built in. I know there are 40G breakout cables, but the whole point of 40G is to aggregate VLAN/circuits. Has anyone done this before? From tony at wicks.co.nz Mon Jun 19 18:43:03 2017 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 20 Jun 2017 06:43:03 +1200 Subject: DWDM Mux/Demux using 40G Optics Message-ID: <30lth88wlscu10jcr8so6hc3.1497897783074@email.android.com> The guys at fibrestore will point you in the right direction on all this if you ask them these questions. They are actually very helpful and will assign you a specialist to assist. -------- Original message -------- From: Colton Conor Date: 20/06/17 6:26 AM (GMT+12:00) To: NANOG Subject: DWDM Mux/Demux using 40G Optics We are building a 40G metro ring using 40-Gigabit Ethernet QSFP+ Transceivers. Specifically, we are using Juniper JNP-QSFP-40G-LR4. This is a QSFP+ Transceiver with a LC duplex head. We only have one pair of single mode dark fibers around the ring.? Our distance between nodes around the ring are all less than 10KM, so we can use standard optics. We go out of one JNP-QSFP-40G-LR4 and into another JNP-QSFP-40G-LR4. There are no passive muxes involved. This is working great for 40G. My understanding is a JNP-QSFP-40G-LR4 is really a transceiver with a CWDM mux built into it. The spec sheet shows it sends 4 10G channels: https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/optical-interface-qfx-support.html Lane wavelength Lane 0?1264.5 nm through 1277.5 nm Lane 1?1284.5 nm through 1297.5 nm Lane 2?1304.5 nm through 1317.5 nm Lane 3?1324.5 nm through 1337.5? nm This setup is working fine, but now we want to do more than 40G around the ring. To my knowledge there are no other 40G QSFP+ transceivers that use four other channel/lanes than the ones already being used, so they only way to go higher than 40G is to stack 10G or 100G channels ontop of the fiber pair using a passive mux. 100G is too expensive for the time being, so we are looking to add 10G channels to a ring that already have one 40G channel using the QSFP+. I was reading this tutorial, and it mentions "there is a 1310 nm port integrated in a 40 channels DWDM Mux/Demux system. The 1310nm added port is a Wide Band Optic port (WBO) added to other specific DWDM wavelengths in a module. When we run out of all channels in a DWDM Mux/Demux system, we can add the extra optics via this 1310nm port." http://www.fs.com/upgrade-to-500g-with-40ch-dwdm-mux-demux-system-aid-493.html What I can't seem to understand is they are mentioning that this 1310 port can pass QSFP+ signals, so it sounds like its really a 1270nm through 1330nm port? Is this what they mean by?? Wide Band Optic port (WBO)? We don't need 40 10G channels plus a 40G for a total of 440G. More than likely we are looking at a 8 channel mux/demux, and 1 40G port for a total of 120G. I don't care if we do CWDM vs DWDM, but I assume it will be hard to find a CWDM mux that has one LC dupluex input for? 1270nm through 1330nm channels? Maybe I should just ditch the 40G QSFP+ optics and use all 10G optics, but the switches I am using have 48 10G SFP+ ports and 6 QSFP+ ports built in. I know there are 40G breakout cables, but the whole point of 40G is to aggregate VLAN/circuits. Has anyone done this before? From md at bts.sk Mon Jun 19 18:51:35 2017 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Mon, 19 Jun 2017 20:51:35 +0200 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: Message-ID: <20170619183439.M12506@bts.sk> On Mon, 19 Jun 2017 13:26:55 -0500, Colton Conor wrote [snip] > Maybe I should just ditch the 40G QSFP+ optics and use all 10G optics, > but the switches I am using have 48 10G SFP+ ports and 6 QSFP+ ports > built in. I know there are 40G breakout cables, but the whole point of > 40G is to aggregate VLAN/circuits. Depending on switch vendor, it might be possible to create real 40GE interface also from 4 consecutive 10G SFP+ ports. Then you can use standard 10G CWDM/DWDM SFP+ optics and still benefit from wire-speed 40G uplinks. Note that this is *not* etherchannel/LAG, but true HW-based 40GE mode. M. From faisal at snappytelecom.net Mon Jun 19 19:01:45 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 19 Jun 2017 19:01:45 +0000 (GMT) Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: Message-ID: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> Answers in-line below. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Colton Conor" > To: "nanog list" > Sent: Monday, June 19, 2017 2:26:55 PM > Subject: DWDM Mux/Demux using 40G Optics > We are building a 40G metro ring using 40-Gigabit Ethernet QSFP+ > Transceivers. Specifically, we are using Juniper JNP-QSFP-40G-LR4. This is > a QSFP+ Transceiver with a LC duplex head. We only have one pair of single > mode dark fibers around the ring. Our distance between nodes around the > ring are all less than 10KM, so we can use standard optics. > > We go out of one JNP-QSFP-40G-LR4 and into another JNP-QSFP-40G-LR4. There > are no passive muxes involved. This is working great for 40G. > > My understanding is a JNP-QSFP-40G-LR4 is really a transceiver with a CWDM > mux built into it. The spec sheet shows it sends 4 10G channels: > > https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/optical-interface-qfx-support.html > > Lane wavelength > Lane 0?1264.5 nm through 1277.5 nm > Lane 1?1284.5 nm through 1297.5 nm > Lane 2?1304.5 nm through 1317.5 nm > Lane 3?1324.5 nm through 1337.5 nm > > YES this is correct and goes for pretty much all of the SMF QSFP+ 40g Optics. (they utilize 4 cwdm channels) > This setup is working fine, but now we want to do more than 40G around the > ring. To my knowledge there are no other 40G QSFP+ transceivers that use > four other channel/lanes than the ones already being used, so they only way > to go higher than 40G is to stack 10G or 100G channels ontop of the fiber > pair using a passive mux. > Typically you would stack 40G + 10g Channels or 100G+10g Channels (100g optics would be using 4 channels as well). > 100G is too expensive for the time being, so we are looking to add 10G > channels to a ring that already have one 40G channel using the QSFP+. Yep, that would be the cost effective way to do it. > > I was reading this tutorial, and it mentions "there is a 1310 nm port > integrated in a 40 channels DWDM Mux/Demux system. The 1310nm added port is > a Wide Band Optic port (WBO) added to other specific DWDM wavelengths in a > module. When we run out of all channels in a DWDM Mux/Demux system, we can > add the extra optics via this 1310nm port." > http://www.fs.com/upgrade-to-500g-with-40ch-dwdm-mux-demux-system-aid-493.html > > What I can't seem to understand is they are mentioning that this 1310 port > can pass QSFP+ signals, so it sounds like its really a 1270nm through > 1330nm port? Is this what they mean by Wide Band Optic port (WBO)? > Yes that would be correct, 1310nm is simple nomenclature when used with 40g/100g QSFP+ SMF optics > We don't need 40 10G channels plus a 40G for a total of 440G. More than > likely we are looking at a 8 channel mux/demux, and 1 40G port for a total > of 120G. > > I don't care if we do CWDM vs DWDM, but I assume it will be hard to find a > CWDM mux that has one LC dupluex input for 1270nm through 1330nm channels? If you look at the CWDM Muxes (8 or 9 channel) you will notice a common configuration of Upgrade Port (expansion port) + 1450 or 1470 to 1610nm in the DWDM muxes you will see them listed as # of Port + 1310 pass thru channel. These are exactly what you are looking for ..... :) > > Maybe I should just ditch the 40G QSFP+ optics and use all 10G optics, but > the switches I am using have 48 10G SFP+ ports and 6 QSFP+ ports built in. > I know there are 40G breakout cables, but the whole point of 40G is to > aggregate VLAN/circuits. > > Has anyone done this before? Am in the process of lighting a number of locations in this manner... From lguillory at reservetele.com Mon Jun 19 19:03:49 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 19 Jun 2017 19:03:49 +0000 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <30lth88wlscu10jcr8so6hc3.1497897783074@email.android.com> References: <30lth88wlscu10jcr8so6hc3.1497897783074@email.android.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE1B@RTC-EXCH01.RESERVE.LDS> The issue is that once you get above 10g things start to get expensive since you don't have options for straight 40g optics in different colors. At least not what I see, 4x10g like you have or a single 1310 40g with no way that I see to mux them. I guess the only way this might work would be to use optics that go from MTP to LCs for the 4x10 40s which you could then inject into a mux, for those colors along with a 1310 port for the other 40. This is same thing you run into when talking 100g, active DWDM with transponders is how that's done with local gear SFPs being 850nm being fed into the DWDM gear for transport. Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tony Wicks Sent: Monday, June 19, 2017 1:43 PM To: Colton Conor; NANOG Subject: Re: DWDM Mux/Demux using 40G Optics The guys at fibrestore will point you in the right direction on all this if you ask them these questions. They are actually very helpful and will assign you a specialist to assist. -------- Original message -------- From: Colton Conor Date: 20/06/17 6:26 AM (GMT+12:00) To: NANOG Subject: DWDM Mux/Demux using 40G Optics We are building a 40G metro ring using 40-Gigabit Ethernet QSFP+ Transceivers. Specifically, we are using Juniper JNP-QSFP-40G-LR4. This is a QSFP+ Transceiver with a LC duplex head. We only have one pair of single mode dark fibers around the ring. Our distance between nodes around the ring are all less than 10KM, so we can use standard optics. We go out of one JNP-QSFP-40G-LR4 and into another JNP-QSFP-40G-LR4. There are no passive muxes involved. This is working great for 40G. My understanding is a JNP-QSFP-40G-LR4 is really a transceiver with a CWDM mux built into it. The spec sheet shows it sends 4 10G channels: https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/optical-interface-qfx-support.html Lane wavelength Lane 0?1264.5 nm through 1277.5 nm Lane 1?1284.5 nm through 1297.5 nm Lane 2?1304.5 nm through 1317.5 nm Lane 3?1324.5 nm through 1337.5 nm This setup is working fine, but now we want to do more than 40G around the ring. To my knowledge there are no other 40G QSFP+ transceivers that use four other channel/lanes than the ones already being used, so they only way to go higher than 40G is to stack 10G or 100G channels ontop of the fiber pair using a passive mux. 100G is too expensive for the time being, so we are looking to add 10G channels to a ring that already have one 40G channel using the QSFP+. I was reading this tutorial, and it mentions "there is a 1310 nm port integrated in a 40 channels DWDM Mux/Demux system. The 1310nm added port is a Wide Band Optic port (WBO) added to other specific DWDM wavelengths in a module. When we run out of all channels in a DWDM Mux/Demux system, we can add the extra optics via this 1310nm port." http://www.fs.com/upgrade-to-500g-with-40ch-dwdm-mux-demux-system-aid-493.html What I can't seem to understand is they are mentioning that this 1310 port can pass QSFP+ signals, so it sounds like its really a 1270nm through 1330nm port? Is this what they mean by Wide Band Optic port (WBO)? We don't need 40 10G channels plus a 40G for a total of 440G. More than likely we are looking at a 8 channel mux/demux, and 1 40G port for a total of 120G. I don't care if we do CWDM vs DWDM, but I assume it will be hard to find a CWDM mux that has one LC dupluex input for 1270nm through 1330nm channels? Maybe I should just ditch the 40G QSFP+ optics and use all 10G optics, but the switches I am using have 48 10G SFP+ ports and 6 QSFP+ ports built in. I know there are 40G breakout cables, but the whole point of 40G is to aggregate VLAN/circuits. Has anyone done this before? From lguillory at reservetele.com Mon Jun 19 19:13:10 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 19 Jun 2017 19:13:10 +0000 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> Faisal, How would he inject his current 4x10 40g into the mux which is currently on a single LC cable? Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz Sent: Monday, June 19, 2017 2:02 PM To: Colton Conor Cc: nanog list Subject: Re: DWDM Mux/Demux using 40G Optics Answers in-line below. If you look at the CWDM Muxes (8 or 9 channel) you will notice a common configuration of Upgrade Port (expansion port) + 1450 or 1470 to 1610nm in the DWDM muxes you will see them listed as # of Port + 1310 pass thru channel. These are exactly what you are looking for ..... :) From nanog at ics-il.net Mon Jun 19 19:18:00 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 19 Jun 2017 14:18:00 -0500 (CDT) Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> Message-ID: <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> Verify pass-through frequencies for the 1310 (or equivalent) for the passive mux in question. This would only work for a single channel. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Luke Guillory" To: "Faisal Imtiaz" , "Colton Conor" Cc: "nanog list" Sent: Monday, June 19, 2017 2:13:10 PM Subject: RE: DWDM Mux/Demux using 40G Optics Faisal, How would he inject his current 4x10 40g into the mux which is currently on a single LC cable? Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz Sent: Monday, June 19, 2017 2:02 PM To: Colton Conor Cc: nanog list Subject: Re: DWDM Mux/Demux using 40G Optics Answers in-line below. If you look at the CWDM Muxes (8 or 9 channel) you will notice a common configuration of Upgrade Port (expansion port) + 1450 or 1470 to 1610nm in the DWDM muxes you will see them listed as # of Port + 1310 pass thru channel. These are exactly what you are looking for ..... :) From colton.conor at gmail.com Mon Jun 19 19:30:37 2017 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 19 Jun 2017 14:30:37 -0500 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> Message-ID: I guess that is the real question. Besides the client ports that are clearly identified by channel number on Muxes, what channels can the special ports handle? http://www.fs.com/products/43723.html It has 4 special service port options: 1. Expansion Port (Based on what I am seeing, I think this would be to stack another mux if you needed more channels. So I assume it allows all channels to be added besides the client channels?) 2. Monitor Port (I think this is just a tap that you would hook a monitor up to, and be able to see all channels coming through with a meter. I assume not a good idea to add/drop channels through this port)? 3. 1310nm Port (Labeled as 1310, but clearly allows more than just 1310 since tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, so what range does it really support or is there no a range?) 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the 1330nm?) Would you recommend a monitor port on every mux you buy? On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett wrote: > Verify pass-through frequencies for the 1310 (or equivalent) for the > passive mux in question. This would only work for a single channel. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Luke Guillory" > *To: *"Faisal Imtiaz" , "Colton Conor" < > colton.conor at gmail.com> > *Cc: *"nanog list" > *Sent: *Monday, June 19, 2017 2:13:10 PM > *Subject: *RE: DWDM Mux/Demux using 40G Optics > > > Faisal, > > How would he inject his current 4x10 40g into the mux which is currently > on a single LC cable? > > > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 <(985)%20536-1212> > Fax: 985.536.0300 <(985)%20536-0300> > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ____________________________________________________________ > _____________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz > Sent: Monday, June 19, 2017 2:02 PM > To: Colton Conor > Cc: nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Answers in-line below. > > > > If you look at the CWDM Muxes (8 or 9 channel) you will notice a common > configuration of > > Upgrade Port (expansion port) + 1450 or 1470 to 1610nm > > in the DWDM muxes you will see them listed as # of Port + 1310 pass > thru channel. > > These are exactly what you are looking for ..... :) > > > From faisal at snappytelecom.net Mon Jun 19 19:38:50 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 19 Jun 2017 19:38:50 +0000 (GMT) Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> Message-ID: <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> Answers in-line ... Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > From: "Colton Conor" > To: "Mike Hammett" > Cc: "Luke Guillory" , "nanog list" , > "Faisal Imtiaz" > Sent: Monday, June 19, 2017 3:30:37 PM > Subject: Re: DWDM Mux/Demux using 40G Optics > I guess that is the real question. Besides the client ports that are clearly > identified by channel number on Muxes, what channels can the special ports > handle? > http://www.fs.com/products/43723.html It has 4 special service port options: > 1. Expansion Port (Based on what I am seeing, I think this would be to stack > another mux if you needed more channels. So I assume it allows all channels to > be added besides the client channels?) Exactly... this is basically a pass thru port, i.e. what is not getting mux/demux should get passed thru (keep the insertion loss in mind). > 2. Monitor Port (I think this is just a tap that you would hook a monitor up to, > and be able to see all channels coming through with a meter. I assume not a > good idea to add/drop channels through this port)? I don't use this port, but supposedly it will pass a fraction 5% of the light from the main port so that it can be monitored. May be someone else can offer some practical use for this port. > 3. 1310nm Port (Labeled as 1310, but clearly allows more than just 1310 since > tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, so what range > does it really support or is there no a range?) Not sure about the range question, but this is the port for having the 40g/100g QSFP+ pass thru > 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the 1330nm?) I have not had the need to explore this in detail, but from my initial understanding, this can be used for ZR (long range optics) and or to stack a DWDM Mux > Would you recommend a monitor port on every mux you buy? As I shared above, I don't. > On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett < nanog at ics-il.net > wrote: >> Verify pass-through frequencies for the 1310 (or equivalent) for the passive mux >> in question. This would only work for a single channel. >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> Midwest-IX >> http://www.midwest-ix.com >> From: "Luke Guillory" < lguillory at reservetele.com > >> To: "Faisal Imtiaz" < faisal at snappytelecom.net >, "Colton Conor" < >> colton.conor at gmail.com > >> Cc: "nanog list" < nanog at nanog.org > >> Sent: Monday, June 19, 2017 2:13:10 PM >> Subject: RE: DWDM Mux/Demux using 40G Optics >> Faisal, >> How would he inject his current 4x10 40g into the mux which is currently on a >> single LC cable? >> Luke Guillory >> Network Operations Manager >> Tel: 985.536.1212 >> Fax: 985.536.0300 >> Email: lguillory at reservetele.com >> Reserve Telecommunications >> 100 RTC Dr >> Reserve, LA 70084 >> _________________________________________________________________________________________________ >> Disclaimer: >> The information transmitted, including attachments, is intended only for the >> person(s) or entity to which it is addressed and may contain confidential >> and/or privileged material which should not disseminate, distribute or be >> copied. Please notify Luke Guillory immediately by e-mail if you have received >> this e-mail by mistake and delete this e-mail from your system. E-mail >> transmission cannot be guaranteed to be secure or error-free as information >> could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or >> contain viruses. Luke Guillory therefore does not accept liability for any >> errors or omissions in the contents of this message, which arise as a result of >> e-mail transmission. . >> -----Original Message----- >> From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Faisal Imtiaz >> Sent: Monday, June 19, 2017 2:02 PM >> To: Colton Conor >> Cc: nanog list >> Subject: Re: DWDM Mux/Demux using 40G Optics >> Answers in-line below. >> If you look at the CWDM Muxes (8 or 9 channel) you will notice a common >> configuration of >> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >> in the DWDM muxes you will see them listed as # of Port + 1310 pass thru >> channel. >> These are exactly what you are looking for ..... :) From lguillory at reservetele.com Mon Jun 19 19:39:00 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 19 Jun 2017 19:39:00 +0000 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <1358879275.2667342.1497900412161.JavaMail.zimbra@snappytelecom.net> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <1358879275.2667342.1497900412161.JavaMail.zimbra@snappytelecom.net> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBFAB@RTC-EXCH01.RESERVE.LDS> And how would he pass his current 40g through that mux? Unless I'm misreading your email which I took as he can use his current setup along with a 40g 1310, though I'm thinking you're saying he can use 1310 40g with colored up 10gs alongside of it. -----Original Message----- From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] Sent: Monday, June 19, 2017 2:27 PM To: Luke Guillory Cc: Colton Conor; nanog list Subject: Re: DWDM Mux/Demux using 40G Optics Bench test of the system, with the muxes... sorry for the large pictures :) Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Luke Guillory" > To: "Faisal Imtiaz" , "Colton Conor" > > Cc: "nanog list" > Sent: Monday, June 19, 2017 3:13:10 PM > Subject: RE: DWDM Mux/Demux using 40G Optics > Faisal, > > How would he inject his current 4x10 40g into the mux which is > currently on a single LC cable? > > > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ______________________________________________________________________ > ___________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only > for the > person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by > e-mail if you have received this e-mail by mistake and delete this > e-mail from your system. E-mail transmission cannot be guaranteed to > be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or contain > viruses. Luke Guillory therefore does not accept liability for any > errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal > Imtiaz > Sent: Monday, June 19, 2017 2:02 PM > To: Colton Conor > Cc: nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Answers in-line below. > > > > If you look at the CWDM Muxes (8 or 9 channel) you will notice a > common configuration of > > Upgrade Port (expansion port) + 1450 or 1470 to 1610nm > > in the DWDM muxes you will see them listed as # of Port + 1310 pass thru > channel. > > These are exactly what you are looking for ..... :) From faisal at snappytelecom.net Mon Jun 19 19:44:59 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 19 Jun 2017 19:44:59 +0000 (GMT) Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBFAB@RTC-EXCH01.RESERVE.LDS> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <1358879275.2667342.1497900412161.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBFAB@RTC-EXCH01.RESERVE.LDS> Message-ID: <1002167353.2667504.1497901499838.JavaMail.zimbra@snappytelecom.net> Let me try to explain better... All Single Mode Fiber 40g Optics are using 4 cwdm channels ... If you use a cwdm mux/demux with and expansion port and it is only mux/de-muxing 1450 to 1610 (i.e. not using the 1270-1330) you can use the expansion port to connect the 40g Optics If you have a CWDM or DWDM Mux, with a specific 1310 pass thru port (Wide-band etc... check the specs) then you can plug the 40g Optics on to that port and it will pass the 4 channels thru it. e.g. with the cwdm mux (see picture in previous post) ..you end up with 1x40g (lane) + 8 or 9 10g (cwdm lanes). Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Luke Guillory" > To: "Faisal Imtiaz" > Cc: "Colton Conor" , "nanog list" > Sent: Monday, June 19, 2017 3:39:00 PM > Subject: RE: DWDM Mux/Demux using 40G Optics > And how would he pass his current 40g through that mux? Unless I'm misreading > your email which I took as he can use his current setup along with a 40g 1310, > though I'm thinking you're saying he can use 1310 40g with colored up 10gs > alongside of it. > > > > -----Original Message----- > From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] > Sent: Monday, June 19, 2017 2:27 PM > To: Luke Guillory > Cc: Colton Conor; nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Bench test of the system, with the muxes... > > sorry for the large pictures :) > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- >> From: "Luke Guillory" >> To: "Faisal Imtiaz" , "Colton Conor" >> >> Cc: "nanog list" >> Sent: Monday, June 19, 2017 3:13:10 PM >> Subject: RE: DWDM Mux/Demux using 40G Optics > >> Faisal, >> >> How would he inject his current 4x10 40g into the mux which is >> currently on a single LC cable? >> >> >> >> >> >> Luke Guillory >> Network Operations Manager >> >> Tel: 985.536.1212 >> Fax: 985.536.0300 >> Email: lguillory at reservetele.com >> >> Reserve Telecommunications >> 100 RTC Dr >> Reserve, LA 70084 >> >> ______________________________________________________________________ >> ___________________________ >> >> Disclaimer: >> The information transmitted, including attachments, is intended only >> for the >> person(s) or entity to which it is addressed and may contain >> confidential and/or privileged material which should not disseminate, >> distribute or be copied. Please notify Luke Guillory immediately by >> e-mail if you have received this e-mail by mistake and delete this >> e-mail from your system. E-mail transmission cannot be guaranteed to >> be secure or error-free as information could be intercepted, >> corrupted, lost, destroyed, arrive late or incomplete, or contain >> viruses. Luke Guillory therefore does not accept liability for any >> errors or omissions in the contents of this message, which arise as a result of >> e-mail transmission. . >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal >> Imtiaz >> Sent: Monday, June 19, 2017 2:02 PM >> To: Colton Conor >> Cc: nanog list >> Subject: Re: DWDM Mux/Demux using 40G Optics >> >> Answers in-line below. >> >> >> >> If you look at the CWDM Muxes (8 or 9 channel) you will notice a >> common configuration of >> >> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >> >> in the DWDM muxes you will see them listed as # of Port + 1310 pass thru >> channel. >> > > These are exactly what you are looking for ..... :) From nanog at ics-il.net Mon Jun 19 19:45:37 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 19 Jun 2017 14:45:37 -0500 (CDT) Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBFAB@RTC-EXCH01.RESERVE.LDS> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <1358879275.2667342.1497900412161.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBFAB@RTC-EXCH01.RESERVE.LDS> Message-ID: <551472810.6299.1497901536817.JavaMail.mhammett@ThunderFuck> Verify the wavelengths passed by the 1310 port. Verify the wavelengths used by his existing 40G optic. Plug the 40G optic into the 1310 port. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Luke Guillory" To: "Faisal Imtiaz" Cc: "nanog list" Sent: Monday, June 19, 2017 2:39:00 PM Subject: RE: DWDM Mux/Demux using 40G Optics And how would he pass his current 40g through that mux? Unless I'm misreading your email which I took as he can use his current setup along with a 40g 1310, though I'm thinking you're saying he can use 1310 40g with colored up 10gs alongside of it. -----Original Message----- From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] Sent: Monday, June 19, 2017 2:27 PM To: Luke Guillory Cc: Colton Conor; nanog list Subject: Re: DWDM Mux/Demux using 40G Optics Bench test of the system, with the muxes... sorry for the large pictures :) Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Luke Guillory" > To: "Faisal Imtiaz" , "Colton Conor" > > Cc: "nanog list" > Sent: Monday, June 19, 2017 3:13:10 PM > Subject: RE: DWDM Mux/Demux using 40G Optics > Faisal, > > How would he inject his current 4x10 40g into the mux which is > currently on a single LC cable? > > > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ______________________________________________________________________ > ___________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only > for the > person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by > e-mail if you have received this e-mail by mistake and delete this > e-mail from your system. E-mail transmission cannot be guaranteed to > be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or contain > viruses. Luke Guillory therefore does not accept liability for any > errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal > Imtiaz > Sent: Monday, June 19, 2017 2:02 PM > To: Colton Conor > Cc: nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Answers in-line below. > > > > If you look at the CWDM Muxes (8 or 9 channel) you will notice a > common configuration of > > Upgrade Port (expansion port) + 1450 or 1470 to 1610nm > > in the DWDM muxes you will see them listed as # of Port + 1310 pass thru > channel. > > These are exactly what you are looking for ..... :) From lguillory at reservetele.com Mon Jun 19 19:47:29 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 19 Jun 2017 19:47:29 +0000 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <1002167353.2667504.1497901499838.JavaMail.zimbra@snappytelecom.net> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <1358879275.2667342.1497900412161.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBFAB@RTC-EXCH01.RESERVE.LDS> <1002167353.2667504.1497901499838.JavaMail.zimbra@snappytelecom.net> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EC00D@RTC-EXCH01.RESERVE.LDS> Gotcha, figured I misread it. Sorry it's Monday. -----Original Message----- From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] Sent: Monday, June 19, 2017 2:45 PM To: Luke Guillory Cc: Colton Conor; nanog list Subject: Re: DWDM Mux/Demux using 40G Optics Let me try to explain better... All Single Mode Fiber 40g Optics are using 4 cwdm channels ... If you use a cwdm mux/demux with and expansion port and it is only mux/de-muxing 1450 to 1610 (i.e. not using the 1270-1330) you can use the expansion port to connect the 40g Optics If you have a CWDM or DWDM Mux, with a specific 1310 pass thru port (Wide-band etc... check the specs) then you can plug the 40g Optics on to that port and it will pass the 4 channels thru it. e.g. with the cwdm mux (see picture in previous post) ..you end up with 1x40g (lane) + 8 or 9 10g (cwdm lanes). Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Luke Guillory" > To: "Faisal Imtiaz" > Cc: "Colton Conor" , "nanog list" > > Sent: Monday, June 19, 2017 3:39:00 PM > Subject: RE: DWDM Mux/Demux using 40G Optics > And how would he pass his current 40g through that mux? Unless I'm > misreading your email which I took as he can use his current setup > along with a 40g 1310, though I'm thinking you're saying he can use > 1310 40g with colored up 10gs alongside of it. > > > > -----Original Message----- > From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] > Sent: Monday, June 19, 2017 2:27 PM > To: Luke Guillory > Cc: Colton Conor; nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Bench test of the system, with the muxes... > > sorry for the large pictures :) > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- >> From: "Luke Guillory" >> To: "Faisal Imtiaz" , "Colton Conor" >> >> Cc: "nanog list" >> Sent: Monday, June 19, 2017 3:13:10 PM >> Subject: RE: DWDM Mux/Demux using 40G Optics > >> Faisal, >> >> How would he inject his current 4x10 40g into the mux which is >> currently on a single LC cable? >> >> >> >> >> >> Luke Guillory >> Network Operations Manager >> >> Tel: 985.536.1212 >> Fax: 985.536.0300 >> Email: lguillory at reservetele.com >> >> Reserve Telecommunications >> 100 RTC Dr >> Reserve, LA 70084 >> >> _____________________________________________________________________ >> _ >> ___________________________ >> >> Disclaimer: >> The information transmitted, including attachments, is intended only >> for the >> person(s) or entity to which it is addressed and may contain >> confidential and/or privileged material which should not disseminate, >> distribute or be copied. Please notify Luke Guillory immediately by >> e-mail if you have received this e-mail by mistake and delete this >> e-mail from your system. E-mail transmission cannot be guaranteed to >> be secure or error-free as information could be intercepted, >> corrupted, lost, destroyed, arrive late or incomplete, or contain >> viruses. Luke Guillory therefore does not accept liability for any >> errors or omissions in the contents of this message, which arise as a >> result of e-mail transmission. . >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal >> Imtiaz >> Sent: Monday, June 19, 2017 2:02 PM >> To: Colton Conor >> Cc: nanog list >> Subject: Re: DWDM Mux/Demux using 40G Optics >> >> Answers in-line below. >> >> >> >> If you look at the CWDM Muxes (8 or 9 channel) you will notice a >> common configuration of >> >> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >> >> in the DWDM muxes you will see them listed as # of Port + 1310 pass thru >> channel. >> > > These are exactly what you are looking for ..... :) From faisal at snappytelecom.net Mon Jun 19 19:49:57 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 19 Jun 2017 19:49:57 +0000 (GMT) Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EC00D@RTC-EXCH01.RESERVE.LDS> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <1358879275.2667342.1497900412161.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBFAB@RTC-EXCH01.RESERVE.LDS> <1002167353.2667504.1497901499838.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EC00D@RTC-EXCH01.RESERVE.LDS> Message-ID: <1824088971.2667510.1497901797133.JavaMail.zimbra@snappytelecom.net> I tried to send some pictures, but looks like the message got stuck for moderator. Here is a link to pictures what Colton is trying to accomplish.... (my bench test :) ) https://1drv.ms/a/s!Ar2zoQlxIvI1gdV9tYj96YUDWElu6w Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Luke Guillory" > To: "Faisal Imtiaz" > Cc: "Colton Conor" , "nanog list" > Sent: Monday, June 19, 2017 3:47:29 PM > Subject: RE: DWDM Mux/Demux using 40G Optics > Gotcha, figured I misread it. Sorry it's Monday. > > > > -----Original Message----- > From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] > Sent: Monday, June 19, 2017 2:45 PM > To: Luke Guillory > Cc: Colton Conor; nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Let me try to explain better... > > All Single Mode Fiber 40g Optics are using 4 cwdm channels ... > > If you use a cwdm mux/demux with and expansion port and it is only mux/de-muxing > 1450 to 1610 (i.e. not using the 1270-1330) you can use the expansion port to > connect the 40g Optics > > If you have a CWDM or DWDM Mux, with a specific 1310 pass thru port (Wide-band > etc... check the specs) then you can plug the 40g Optics on to that port and it > will pass the 4 channels thru it. > > e.g. with the cwdm mux (see picture in previous post) ..you end up with 1x40g > (lane) + 8 or 9 10g (cwdm lanes). > > > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- >> From: "Luke Guillory" >> To: "Faisal Imtiaz" >> Cc: "Colton Conor" , "nanog list" >> >> Sent: Monday, June 19, 2017 3:39:00 PM >> Subject: RE: DWDM Mux/Demux using 40G Optics > >> And how would he pass his current 40g through that mux? Unless I'm >> misreading your email which I took as he can use his current setup >> along with a 40g 1310, though I'm thinking you're saying he can use >> 1310 40g with colored up 10gs alongside of it. >> >> >> >> -----Original Message----- >> From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] >> Sent: Monday, June 19, 2017 2:27 PM >> To: Luke Guillory >> Cc: Colton Conor; nanog list >> Subject: Re: DWDM Mux/Demux using 40G Optics >> >> Bench test of the system, with the muxes... >> >> sorry for the large pictures :) >> >> Faisal Imtiaz >> Snappy Internet & Telecom >> 7266 SW 48 Street >> Miami, FL 33155 >> Tel: 305 663 5518 x 232 >> >> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net >> >> ----- Original Message ----- >>> From: "Luke Guillory" >>> To: "Faisal Imtiaz" , "Colton Conor" >>> >>> Cc: "nanog list" >>> Sent: Monday, June 19, 2017 3:13:10 PM >>> Subject: RE: DWDM Mux/Demux using 40G Optics >> >>> Faisal, >>> >>> How would he inject his current 4x10 40g into the mux which is >>> currently on a single LC cable? >>> >>> >>> >>> >>> >>> Luke Guillory >>> Network Operations Manager >>> >>> Tel: 985.536.1212 >>> Fax: 985.536.0300 >>> Email: lguillory at reservetele.com >>> >>> Reserve Telecommunications >>> 100 RTC Dr >>> Reserve, LA 70084 >>> >>> _____________________________________________________________________ >>> _ >>> ___________________________ >>> >>> Disclaimer: >>> The information transmitted, including attachments, is intended only >>> for the >>> person(s) or entity to which it is addressed and may contain >>> confidential and/or privileged material which should not disseminate, >>> distribute or be copied. Please notify Luke Guillory immediately by >>> e-mail if you have received this e-mail by mistake and delete this >>> e-mail from your system. E-mail transmission cannot be guaranteed to >>> be secure or error-free as information could be intercepted, >>> corrupted, lost, destroyed, arrive late or incomplete, or contain >>> viruses. Luke Guillory therefore does not accept liability for any >>> errors or omissions in the contents of this message, which arise as a >>> result of e-mail transmission. . >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal >>> Imtiaz >>> Sent: Monday, June 19, 2017 2:02 PM >>> To: Colton Conor >>> Cc: nanog list >>> Subject: Re: DWDM Mux/Demux using 40G Optics >>> >>> Answers in-line below. >>> >>> >>> >>> If you look at the CWDM Muxes (8 or 9 channel) you will notice a >>> common configuration of >>> >>> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >>> >>> in the DWDM muxes you will see them listed as # of Port + 1310 pass thru >>> channel. >>> > > > These are exactly what you are looking for ..... :) From lguillory at reservetele.com Mon Jun 19 19:50:48 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 19 Jun 2017 19:50:48 +0000 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <1824088971.2667510.1497901797133.JavaMail.zimbra@snappytelecom.net> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <1358879275.2667342.1497900412161.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBFAB@RTC-EXCH01.RESERVE.LDS> <1002167353.2667504.1497901499838.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EC00D@RTC-EXCH01.RESERVE.LDS> <1824088971.2667510.1497901797133.JavaMail.zimbra@snappytelecom.net> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EC052@RTC-EXCH01.RESERVE.LDS> Pics came in on my side, that's when I figured you were saying 1 40g plus 10s. -----Original Message----- From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] Sent: Monday, June 19, 2017 2:50 PM To: Luke Guillory Cc: Colton Conor; nanog list Subject: Re: DWDM Mux/Demux using 40G Optics I tried to send some pictures, but looks like the message got stuck for moderator. Here is a link to pictures what Colton is trying to accomplish.... (my bench test :) ) https://1drv.ms/a/s!Ar2zoQlxIvI1gdV9tYj96YUDWElu6w Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Luke Guillory" > To: "Faisal Imtiaz" > Cc: "Colton Conor" , "nanog list" > > Sent: Monday, June 19, 2017 3:47:29 PM > Subject: RE: DWDM Mux/Demux using 40G Optics > Gotcha, figured I misread it. Sorry it's Monday. > > > > -----Original Message----- > From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] > Sent: Monday, June 19, 2017 2:45 PM > To: Luke Guillory > Cc: Colton Conor; nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Let me try to explain better... > > All Single Mode Fiber 40g Optics are using 4 cwdm channels ... > > If you use a cwdm mux/demux with and expansion port and it is only > mux/de-muxing > 1450 to 1610 (i.e. not using the 1270-1330) you can use the expansion > port to connect the 40g Optics > > If you have a CWDM or DWDM Mux, with a specific 1310 pass thru port > (Wide-band etc... check the specs) then you can plug the 40g Optics on > to that port and it will pass the 4 channels thru it. > > e.g. with the cwdm mux (see picture in previous post) ..you end up > with 1x40g > (lane) + 8 or 9 10g (cwdm lanes). > > > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- >> From: "Luke Guillory" >> To: "Faisal Imtiaz" >> Cc: "Colton Conor" , "nanog list" >> >> Sent: Monday, June 19, 2017 3:39:00 PM >> Subject: RE: DWDM Mux/Demux using 40G Optics > >> And how would he pass his current 40g through that mux? Unless I'm >> misreading your email which I took as he can use his current setup >> along with a 40g 1310, though I'm thinking you're saying he can use >> 1310 40g with colored up 10gs alongside of it. >> >> >> >> -----Original Message----- >> From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] >> Sent: Monday, June 19, 2017 2:27 PM >> To: Luke Guillory >> Cc: Colton Conor; nanog list >> Subject: Re: DWDM Mux/Demux using 40G Optics >> >> Bench test of the system, with the muxes... >> >> sorry for the large pictures :) >> >> Faisal Imtiaz >> Snappy Internet & Telecom >> 7266 SW 48 Street >> Miami, FL 33155 >> Tel: 305 663 5518 x 232 >> >> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net >> >> ----- Original Message ----- >>> From: "Luke Guillory" >>> To: "Faisal Imtiaz" , "Colton Conor" >>> >>> Cc: "nanog list" >>> Sent: Monday, June 19, 2017 3:13:10 PM >>> Subject: RE: DWDM Mux/Demux using 40G Optics >> >>> Faisal, >>> >>> How would he inject his current 4x10 40g into the mux which is >>> currently on a single LC cable? >>> >>> >>> >>> >>> >>> Luke Guillory >>> Network Operations Manager >>> >>> Tel: 985.536.1212 >>> Fax: 985.536.0300 >>> Email: lguillory at reservetele.com >>> >>> Reserve Telecommunications >>> 100 RTC Dr >>> Reserve, LA 70084 >>> >>> ____________________________________________________________________ >>> _ >>> _ >>> ___________________________ >>> >>> Disclaimer: >>> The information transmitted, including attachments, is intended only >>> for the >>> person(s) or entity to which it is addressed and may contain >>> confidential and/or privileged material which should not >>> disseminate, distribute or be copied. Please notify Luke Guillory >>> immediately by e-mail if you have received this e-mail by mistake >>> and delete this e-mail from your system. E-mail transmission cannot >>> be guaranteed to be secure or error-free as information could be >>> intercepted, corrupted, lost, destroyed, arrive late or incomplete, >>> or contain viruses. Luke Guillory therefore does not accept >>> liability for any errors or omissions in the contents of this >>> message, which arise as a result of e-mail transmission. . >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal >>> Imtiaz >>> Sent: Monday, June 19, 2017 2:02 PM >>> To: Colton Conor >>> Cc: nanog list >>> Subject: Re: DWDM Mux/Demux using 40G Optics >>> >>> Answers in-line below. >>> >>> >>> >>> If you look at the CWDM Muxes (8 or 9 channel) you will notice a >>> common configuration of >>> >>> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >>> >>> in the DWDM muxes you will see them listed as # of Port + 1310 pass thru >>> channel. >>> > > > These are exactly what you are looking for ..... :) From colton.conor at gmail.com Mon Jun 19 20:12:04 2017 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 19 Jun 2017 15:12:04 -0500 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <551472810.6299.1497901536817.JavaMail.mhammett@ThunderFuck> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <1358879275.2667342.1497900412161.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBFAB@RTC-EXCH01.RESERVE.LDS> <551472810.6299.1497901536817.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, Have any suggestion on a meter for CWDM and DWDM that is low cost? On Mon, Jun 19, 2017 at 2:45 PM, Mike Hammett wrote: > Verify the wavelengths passed by the 1310 port. Verify the wavelengths > used by his existing 40G optic. Plug the 40G optic into the 1310 port. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Luke Guillory" > To: "Faisal Imtiaz" > Cc: "nanog list" > Sent: Monday, June 19, 2017 2:39:00 PM > Subject: RE: DWDM Mux/Demux using 40G Optics > > And how would he pass his current 40g through that mux? Unless I'm > misreading your email which I took as he can use his current setup along > with a 40g 1310, though I'm thinking you're saying he can use 1310 40g with > colored up 10gs alongside of it. > > > > -----Original Message----- > From: Faisal Imtiaz [mailto:faisal at snappytelecom.net] > Sent: Monday, June 19, 2017 2:27 PM > To: Luke Guillory > Cc: Colton Conor; nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Bench test of the system, with the muxes... > > sorry for the large pictures :) > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > ----- Original Message ----- > > From: "Luke Guillory" > > To: "Faisal Imtiaz" , "Colton Conor" > > > > Cc: "nanog list" > > Sent: Monday, June 19, 2017 3:13:10 PM > > Subject: RE: DWDM Mux/Demux using 40G Optics > > > Faisal, > > > > How would he inject his current 4x10 40g into the mux which is > > currently on a single LC cable? > > > > > > > > > > > > Luke Guillory > > Network Operations Manager > > > > Tel: 985.536.1212 > > Fax: 985.536.0300 > > Email: lguillory at reservetele.com > > > > Reserve Telecommunications > > 100 RTC Dr > > Reserve, LA 70084 > > > > ______________________________________________________________________ > > ___________________________ > > > > Disclaimer: > > The information transmitted, including attachments, is intended only > > for the > > person(s) or entity to which it is addressed and may contain > > confidential and/or privileged material which should not disseminate, > > distribute or be copied. Please notify Luke Guillory immediately by > > e-mail if you have received this e-mail by mistake and delete this > > e-mail from your system. E-mail transmission cannot be guaranteed to > > be secure or error-free as information could be intercepted, > > corrupted, lost, destroyed, arrive late or incomplete, or contain > > viruses. Luke Guillory therefore does not accept liability for any > > errors or omissions in the contents of this message, which arise as a > result of e-mail transmission. . > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal > > Imtiaz > > Sent: Monday, June 19, 2017 2:02 PM > > To: Colton Conor > > Cc: nanog list > > Subject: Re: DWDM Mux/Demux using 40G Optics > > > > Answers in-line below. > > > > > > > > If you look at the CWDM Muxes (8 or 9 channel) you will notice a > > common configuration of > > > > Upgrade Port (expansion port) + 1450 or 1470 to 1610nm > > > > in the DWDM muxes you will see them listed as # of Port + 1310 pass thru > > channel. > > > > These are exactly what you are looking for ..... :) > > From colton.conor at gmail.com Mon Jun 19 20:14:19 2017 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 19 Jun 2017 15:14:19 -0500 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> Message-ID: Thanks for the answers. From the sounds of it, no one knows the real difference between the expansion port, 1310 port, and 1550 port. For real world applications, I would assume the monitor port would be to plug in a handheld meter, and see which channels are coming through that node without breaking the ring. Not sure if their would be a monitor port for both directions is you were using a OADM? On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz wrote: > Answers in-line ... > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 <(305)%20663-5518> > > Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email: > Support at Snappytelecom.net > > ------------------------------ > > *From: *"Colton Conor" > *To: *"Mike Hammett" > *Cc: *"Luke Guillory" , "nanog list" < > nanog at nanog.org>, "Faisal Imtiaz" > *Sent: *Monday, June 19, 2017 3:30:37 PM > *Subject: *Re: DWDM Mux/Demux using 40G Optics > > I guess that is the real question. Besides the client ports that are > clearly identified by channel number on Muxes, what channels can the > special ports handle? > http://www.fs.com/products/43723.html It has 4 special service port > options: > > 1. Expansion Port (Based on what I am seeing, I think this would be to > stack another mux if you needed more channels. So I assume it allows all > channels to be added besides the client channels?) > > > Exactly... this is basically a pass thru port, i.e. what is not getting > mux/demux should get passed thru (keep the insertion loss in mind). > > 2. Monitor Port (I think this is just a tap that you would hook a monitor > up to, and be able to see all channels coming through with a meter. I > assume not a good idea to add/drop channels through this port)? > > > I don't use this port, but supposedly it will pass a fraction 5% of the > light from the main port so that it can be monitored. May be someone else > can offer some practical use for this port. > > 3. 1310nm Port (Labeled as 1310, but clearly allows more than just 1310 > since tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, so what > range does it really support or is there no a range?) > > Not sure about the range question, but this is the port for having the > 40g/100g QSFP+ pass thru > > 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the 1330nm?) > > I have not had the need to explore this in detail, but from my initial > understanding, this can be used for ZR (long range optics) and or to stack > a DWDM Mux > > Would you recommend a monitor port on every mux you buy? > > As I shared above, I don't. > > > On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett wrote: > >> Verify pass-through frequencies for the 1310 (or equivalent) for the >> passive mux in question. This would only work for a single channel. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ------------------------------ >> *From: *"Luke Guillory" >> *To: *"Faisal Imtiaz" , "Colton Conor" < >> colton.conor at gmail.com> >> *Cc: *"nanog list" >> *Sent: *Monday, June 19, 2017 2:13:10 PM >> *Subject: *RE: DWDM Mux/Demux using 40G Optics >> >> >> Faisal, >> >> How would he inject his current 4x10 40g into the mux which is currently >> on a single LC cable? >> >> >> >> >> >> Luke Guillory >> Network Operations Manager >> >> Tel: 985.536.1212 <(985)%20536-1212> >> Fax: 985.536.0300 <(985)%20536-0300> >> Email: lguillory at reservetele.com >> >> Reserve Telecommunications >> 100 RTC Dr >> Reserve, LA 70084 >> >> ____________________________________________________________ >> _____________________________________ >> >> Disclaimer: >> The information transmitted, including attachments, is intended only for >> the person(s) or entity to which it is addressed and may contain >> confidential and/or privileged material which should not disseminate, >> distribute or be copied. Please notify Luke Guillory immediately by e-mail >> if you have received this e-mail by mistake and delete this e-mail from >> your system. E-mail transmission cannot be guaranteed to be secure or >> error-free as information could be intercepted, corrupted, lost, destroyed, >> arrive late or incomplete, or contain viruses. Luke Guillory therefore does >> not accept liability for any errors or omissions in the contents of this >> message, which arise as a result of e-mail transmission. . >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz >> Sent: Monday, June 19, 2017 2:02 PM >> To: Colton Conor >> Cc: nanog list >> Subject: Re: DWDM Mux/Demux using 40G Optics >> >> Answers in-line below. >> >> >> >> If you look at the CWDM Muxes (8 or 9 channel) you will notice a common >> configuration of >> >> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >> >> in the DWDM muxes you will see them listed as # of Port + 1310 pass >> thru channel. >> >> These are exactly what you are looking for ..... :) >> >> >> > From nanog at ics-il.net Mon Jun 19 20:17:00 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 19 Jun 2017 15:17:00 -0500 (CDT) Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> Message-ID: <263475836.6373.1497903419273.JavaMail.mhammett@ThunderFuck> I'd imagine they vary based on vendor, so you'd have to check with the specific vendor in terms of absolute technical specifications. A 1310 and 1550 port only allow those channels plus or minus some, manufacturer dependent. An expansion port passes everything not used by that device. Some manufacturers are even configurable pre-order, so you could get exactly what you needed (other than multiple 40G channels). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Colton Conor" To: "Faisal Imtiaz" Cc: "Mike Hammett" , "Luke Guillory" , "nanog list" Sent: Monday, June 19, 2017 3:14:19 PM Subject: Re: DWDM Mux/Demux using 40G Optics Thanks for the answers. From the sounds of it, no one knows the real difference between the expansion port, 1310 port, and 1550 port. For real world applications, I would assume the monitor port would be to plug in a handheld meter, and see which channels are coming through that node without breaking the ring. Not sure if their would be a monitor port for both directions is you were using a OADM? On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz < faisal at snappytelecom.net > wrote: Answers in-line ... Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net
From: "Colton Conor" < colton.conor at gmail.com > To: "Mike Hammett" < nanog at ics-il.net > Cc: "Luke Guillory" < lguillory at reservetele.com >, "nanog list" < nanog at nanog.org >, "Faisal Imtiaz" < faisal at snappytelecom.net > Sent: Monday, June 19, 2017 3:30:37 PM Subject: Re: DWDM Mux/Demux using 40G Optics
I guess that is the real question. Besides the client ports that are clearly identified by channel number on Muxes, what channels can the special ports handle? http://www.fs.com/products/43723.html It has 4 special service port options: 1. Expansion Port (Based on what I am seeing, I think this would be to stack another mux if you needed more channels. So I assume it allows all channels to be added besides the client channels?)
Exactly... this is basically a pass thru port, i.e. what is not getting mux/demux should get passed thru (keep the insertion loss in mind).
2. Monitor Port (I think this is just a tap that you would hook a monitor up to, and be able to see all channels coming through with a meter. I assume not a good idea to add/drop channels through this port)?
I don't use this port, but supposedly it will pass a fraction 5% of the light from the main port so that it can be monitored. May be someone else can offer some practical use for this port.
3. 1310nm Port (Labeled as 1310, but clearly allows more than just 1310 since tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, so what range does it really support or is there no a range?)
Not sure about the range question, but this is the port for having the 40g/100g QSFP+ pass thru
4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the 1330nm?)
I have not had the need to explore this in detail, but from my initial understanding, this can be used for ZR (long range optics) and or to stack a DWDM Mux
Would you recommend a monitor port on every mux you buy?
As I shared above, I don't.
On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett < nanog at ics-il.net > wrote:
Verify pass-through frequencies for the 1310 (or equivalent) for the passive mux in question. This would only work for a single channel. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Luke Guillory" < lguillory at reservetele.com > To: "Faisal Imtiaz" < faisal at snappytelecom.net >, "Colton Conor" < colton.conor at gmail.com > Cc: "nanog list" < nanog at nanog.org > Sent: Monday, June 19, 2017 2:13:10 PM Subject: RE: DWDM Mux/Demux using 40G Optics Faisal, How would he inject his current 4x10 40g into the mux which is currently on a single LC cable? Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Faisal Imtiaz Sent: Monday, June 19, 2017 2:02 PM To: Colton Conor Cc: nanog list Subject: Re: DWDM Mux/Demux using 40G Optics Answers in-line below. If you look at the CWDM Muxes (8 or 9 channel) you will notice a common configuration of Upgrade Port (expansion port) + 1450 or 1470 to 1610nm in the DWDM muxes you will see them listed as # of Port + 1310 pass thru channel. These are exactly what you are looking for ..... :)
From lguillory at reservetele.com Mon Jun 19 20:19:02 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 19 Jun 2017 20:19:02 +0000 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EC183@RTC-EXCH01.RESERVE.LDS> My understanding is that ports on the client side would have cut filters for that color, having 1310 and 1550 are nice since you can hang gear you already have off the mux for OOB and so on. I don?t think I have any CWDM with expansion ports to test with. We use the following for simple testing, is it there and what?s the power. http://solid-optics.com/tools/power-meter/so-osa-cwdm-18ch-id1685.html Luke Guillory Network Operations Manager [cid:image300878.JPG at eb7e400b.44984f6e] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From: Colton Conor [mailto:colton.conor at gmail.com] Sent: Monday, June 19, 2017 3:14 PM To: Faisal Imtiaz Cc: Mike Hammett; Luke Guillory; nanog list Subject: Re: DWDM Mux/Demux using 40G Optics Thanks for the answers. From the sounds of it, no one knows the real difference between the expansion port, 1310 port, and 1550 port. For real world applications, I would assume the monitor port would be to plug in a handheld meter, and see which channels are coming through that node without breaking the ring. Not sure if their would be a monitor port for both directions is you were using a OADM? On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz > wrote: Answers in-line ... Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ________________________________ From: "Colton Conor" > To: "Mike Hammett" > Cc: "Luke Guillory" >, "nanog list" >, "Faisal Imtiaz" > Sent: Monday, June 19, 2017 3:30:37 PM Subject: Re: DWDM Mux/Demux using 40G Optics I guess that is the real question. Besides the client ports that are clearly identified by channel number on Muxes, what channels can the special ports handle? http://www.fs.com/products/43723.html It has 4 special service port options: 1. Expansion Port (Based on what I am seeing, I think this would be to stack another mux if you needed more channels. So I assume it allows all channels to be added besides the client channels?) Exactly... this is basically a pass thru port, i.e. what is not getting mux/demux should get passed thru (keep the insertion loss in mind). 2. Monitor Port (I think this is just a tap that you would hook a monitor up to, and be able to see all channels coming through with a meter. I assume not a good idea to add/drop channels through this port)? I don't use this port, but supposedly it will pass a fraction 5% of the light from the main port so that it can be monitored. May be someone else can offer some practical use for this port. 3. 1310nm Port (Labeled as 1310, but clearly allows more than just 1310 since tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, so what range does it really support or is there no a range?) Not sure about the range question, but this is the port for having the 40g/100g QSFP+ pass thru 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the 1330nm?) I have not had the need to explore this in detail, but from my initial understanding, this can be used for ZR (long range optics) and or to stack a DWDM Mux Would you recommend a monitor port on every mux you buy? As I shared above, I don't. On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett > wrote: Verify pass-through frequencies for the 1310 (or equivalent) for the passive mux in question. This would only work for a single channel. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "Luke Guillory" > To: "Faisal Imtiaz" >, "Colton Conor" > Cc: "nanog list" > Sent: Monday, June 19, 2017 2:13:10 PM Subject: RE: DWDM Mux/Demux using 40G Optics Faisal, How would he inject his current 4x10 40g into the mux which is currently on a single LC cable? Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz Sent: Monday, June 19, 2017 2:02 PM To: Colton Conor Cc: nanog list Subject: Re: DWDM Mux/Demux using 40G Optics Answers in-line below. If you look at the CWDM Muxes (8 or 9 channel) you will notice a common configuration of Upgrade Port (expansion port) + 1450 or 1470 to 1610nm in the DWDM muxes you will see them listed as # of Port + 1310 pass thru channel. These are exactly what you are looking for ..... :) From vwittkop at nanog.org Mon Jun 19 20:23:05 2017 From: vwittkop at nanog.org (Valerie Wittkop) Date: Mon, 19 Jun 2017 16:23:05 -0400 Subject: [NANOG-announce] Mailman Maintenance - June 19 - 9PM Eastern Message-ID: <65892A28-3732-4D96-AC7E-37211FC46F14@nanog.org> Hello NANOGers, The mailman servers will be undergoing a second maintenance tonight between 9:00 and 10:00pm Eastern. Mail sent to lists hosted on the NANOG mailman servers will be held during the maintenance window. Regular operations will resume once the maintenance is complete. Sincerely, NANOG Staff -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From colton.conor at gmail.com Mon Jun 19 20:32:28 2017 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 19 Jun 2017 15:32:28 -0500 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <263475836.6373.1497903419273.JavaMail.mhammett@ThunderFuck> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> <263475836.6373.1497903419273.JavaMail.mhammett@ThunderFuck> Message-ID: I guess that makes sense. The plus or minus some is the question. FS is claiming their 1310 port support QSFP+, which is 1270, 1290, 1310, and 1330 combined. I understand you can us 1310, but I am still scratching my head as to how they all one minus and two above 1310 to work. Of course they don't have any datasheets to show the range either. On Mon, Jun 19, 2017 at 3:17 PM, Mike Hammett wrote: > I'd imagine they vary based on vendor, so you'd have to check with the > specific vendor in terms of absolute technical specifications. > > A 1310 and 1550 port only allow those channels plus or minus some, > manufacturer dependent. > An expansion port passes everything not used by that device. > > Some manufacturers are even configurable pre-order, so you could get > exactly what you needed (other than multiple 40G channels). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Colton Conor" > To: "Faisal Imtiaz" > Cc: "Mike Hammett" , "Luke Guillory" < > lguillory at reservetele.com>, "nanog list" > Sent: Monday, June 19, 2017 3:14:19 PM > Subject: Re: DWDM Mux/Demux using 40G Optics > > > Thanks for the answers. From the sounds of it, no one knows the real > difference between the expansion port, 1310 port, and 1550 port. For real > world applications, I would assume the monitor port would be to plug in a > handheld meter, and see which channels are coming through that node without > breaking the ring. Not sure if their would be a monitor port for both > directions is you were using a OADM? > > > On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz < faisal at snappytelecom.net > > wrote: > > > > > > Answers in-line ... > > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > > > >
> From: "Colton Conor" < colton.conor at gmail.com > > To: "Mike Hammett" < nanog at ics-il.net > > Cc: "Luke Guillory" < lguillory at reservetele.com >, "nanog list" < > nanog at nanog.org >, "Faisal Imtiaz" < faisal at snappytelecom.net > > Sent: Monday, June 19, 2017 3:30:37 PM > Subject: Re: DWDM Mux/Demux using 40G Optics > > > > >
> > I guess that is the real question. Besides the client ports that are > clearly identified by channel number on Muxes, what channels can the > special ports handle? > > http://www.fs.com/products/43723.html It has 4 special service port > options: > > 1. Expansion Port (Based on what I am seeing, I think this would be to > stack another mux if you needed more channels. So I assume it allows all > channels to be added besides the client channels?) >
> > > > Exactly... this is basically a pass thru port, i.e. what is not getting > mux/demux should get passed thru (keep the insertion loss in mind). > > >
> > > 2. Monitor Port (I think this is just a tap that you would hook a monitor > up to, and be able to see all channels coming through with a meter. I > assume not a good idea to add/drop channels through this port)? >
> > > > I don't use this port, but supposedly it will pass a fraction 5% of the > light from the main port so that it can be monitored. May be someone else > can offer some practical use for this port. >
> > > 3. 1310nm Port (Labeled as 1310, but clearly allows more than just 1310 > since tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, so what > range does it really support or is there no a range?) >
> > Not sure about the range question, but this is the port for having the > 40g/100g QSFP+ pass thru > > >
> > > 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the 1330nm?) > > >
> > I have not had the need to explore this in detail, but from my initial > understanding, this can be used for ZR (long range optics) and or to stack > a DWDM Mux > > >
> > > Would you recommend a monitor port on every mux you buy? > > >
> > As I shared above, I don't. > > > > >
> > > > On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett < nanog at ics-il.net > wrote: > >
> > > Verify pass-through frequencies for the 1310 (or equivalent) for the > passive mux in question. This would only work for a single channel. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > > > From: "Luke Guillory" < lguillory at reservetele.com > > To: "Faisal Imtiaz" < faisal at snappytelecom.net >, "Colton Conor" < > colton.conor at gmail.com > > Cc: "nanog list" < nanog at nanog.org > > Sent: Monday, June 19, 2017 2:13:10 PM > Subject: RE: DWDM Mux/Demux using 40G Optics > > > > Faisal, > > How would he inject his current 4x10 40g into the mux which is currently > on a single LC cable? > > > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ____________________________________________________________ > _____________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Faisal Imtiaz > Sent: Monday, June 19, 2017 2:02 PM > To: Colton Conor > Cc: nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Answers in-line below. > > > > If you look at the CWDM Muxes (8 or 9 channel) you will notice a common > configuration of > > Upgrade Port (expansion port) + 1450 or 1470 to 1610nm > > in the DWDM muxes you will see them listed as # of Port + 1310 pass thru > channel. > > These are exactly what you are looking for ..... :) > > > >
> > >
> >
> > > From tony at wicks.co.nz Mon Jun 19 20:40:03 2017 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 20 Jun 2017 08:40:03 +1200 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> Message-ID: <002b01d2e93c$3c1563b0$b4402b10$@wicks.co.nz> I think you will find the "monitor" port is most likely to be used for "lawful" intercept by unnamed government entities. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor Sent: Tuesday, 20 June 2017 8:14 AM To: Faisal Imtiaz Cc: nanog list Subject: Re: DWDM Mux/Demux using 40G Optics Thanks for the answers. From the sounds of it, no one knows the real difference between the expansion port, 1310 port, and 1550 port. For real world applications, I would assume the monitor port would be to plug in a handheld meter, and see which channels are coming through that node without breaking the ring. Not sure if their would be a monitor port for both directions is you were using a OADM? On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz wrote: From lguillory at reservetele.com Mon Jun 19 20:40:46 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 19 Jun 2017 20:40:46 +0000 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> <263475836.6373.1497903419273.JavaMail.mhammett@ThunderFuck> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EC22A@RTC-EXCH01.RESERVE.LDS> If their 1310 passes them I would have to think you can't use is with other client ports that would fall within the window. Here is a graph showing those 4 for the 40g it seems. http://public-wordpress-kkc.s3.amazonaws.com/wp-content/uploads/2014/07/Graph1.jpg -----Original Message----- From: NANOG [mailto:nanog-bounces+lguillory=reservetele.com at nanog.org] On Behalf Of Colton Conor Sent: Monday, June 19, 2017 3:32 PM To: Mike Hammett Cc: nanog list Subject: Re: DWDM Mux/Demux using 40G Optics I guess that makes sense. The plus or minus some is the question. FS is claiming their 1310 port support QSFP+, which is 1270, 1290, 1310, and 1330 combined. I understand you can us 1310, but I am still scratching my head as to how they all one minus and two above 1310 to work. Of course they don't have any datasheets to show the range either. On Mon, Jun 19, 2017 at 3:17 PM, Mike Hammett wrote: > I'd imagine they vary based on vendor, so you'd have to check with the > specific vendor in terms of absolute technical specifications. > > A 1310 and 1550 port only allow those channels plus or minus some, > manufacturer dependent. > An expansion port passes everything not used by that device. > > Some manufacturers are even configurable pre-order, so you could get > exactly what you needed (other than multiple 40G channels). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Colton Conor" > To: "Faisal Imtiaz" > Cc: "Mike Hammett" , "Luke Guillory" < > lguillory at reservetele.com>, "nanog list" > Sent: Monday, June 19, 2017 3:14:19 PM > Subject: Re: DWDM Mux/Demux using 40G Optics > > > Thanks for the answers. From the sounds of it, no one knows the real > difference between the expansion port, 1310 port, and 1550 port. For > real world applications, I would assume the monitor port would be to > plug in a handheld meter, and see which channels are coming through > that node without breaking the ring. Not sure if their would be a > monitor port for both directions is you were using a OADM? > > > On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz < > faisal at snappytelecom.net > > wrote: > > > > > > Answers in-line ... > > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > > > >
> From: "Colton Conor" < colton.conor at gmail.com > > To: "Mike Hammett" < nanog at ics-il.net > > Cc: "Luke Guillory" < lguillory at reservetele.com >, "nanog list" < > nanog at nanog.org >, "Faisal Imtiaz" < faisal at snappytelecom.net > > Sent: Monday, June 19, 2017 3:30:37 PM > Subject: Re: DWDM Mux/Demux using 40G Optics > > > > >
> > I guess that is the real question. Besides the client ports that are > clearly identified by channel number on Muxes, what channels can the > special ports handle? > > http://www.fs.com/products/43723.html It has 4 special service port > options: > > 1. Expansion Port (Based on what I am seeing, I think this would be to > stack another mux if you needed more channels. So I assume it allows > all channels to be added besides the client channels?)
> > > > Exactly... this is basically a pass thru port, i.e. what is not > getting mux/demux should get passed thru (keep the insertion loss in mind). > > >
> > > 2. Monitor Port (I think this is just a tap that you would hook a > monitor up to, and be able to see all channels coming through with a > meter. I assume not a good idea to add/drop channels through this port)? >
> > > > I don't use this port, but supposedly it will pass a fraction 5% of > the light from the main port so that it can be monitored. May be > someone else can offer some practical use for this port. >
> > > 3. 1310nm Port (Labeled as 1310, but clearly allows more than just > 1310 since tutorial is saying it supports QSFP+ which is 1270 - 1330 > nm, so what range does it really support or is there no a range?) >
> > Not sure about the range question, but this is the port for having the > 40g/100g QSFP+ pass thru > > >
> > > 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the > 1330nm?) > > >
> > I have not had the need to explore this in detail, but from my initial > understanding, this can be used for ZR (long range optics) and or to > stack a DWDM Mux > > >
> > > Would you recommend a monitor port on every mux you buy? > > >
> > As I shared above, I don't. > > > > >
> > > > On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett < nanog at ics-il.net > wrote: > >
> > > Verify pass-through frequencies for the 1310 (or equivalent) for the > passive mux in question. This would only work for a single channel. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > > > From: "Luke Guillory" < lguillory at reservetele.com > > To: "Faisal Imtiaz" < faisal at snappytelecom.net >, "Colton Conor" < > colton.conor at gmail.com > > Cc: "nanog list" < nanog at nanog.org > > Sent: Monday, June 19, 2017 2:13:10 PM > Subject: RE: DWDM Mux/Demux using 40G Optics > > > > Faisal, > > How would he inject his current 4x10 40g into the mux which is > currently on a single LC cable? > > > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ____________________________________________________________ > _____________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only > for the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by > e-mail if you have received this e-mail by mistake and delete this > e-mail from your system. E-mail transmission cannot be guaranteed to > be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or contain > viruses. Luke Guillory therefore does not accept liability for any > errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Faisal > Imtiaz > Sent: Monday, June 19, 2017 2:02 PM > To: Colton Conor > Cc: nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Answers in-line below. > > > > If you look at the CWDM Muxes (8 or 9 channel) you will notice a > common configuration of > > Upgrade Port (expansion port) + 1450 or 1470 to 1610nm > > in the DWDM muxes you will see them listed as # of Port + 1310 pass > thru channel. > > These are exactly what you are looking for ..... :) > > > >
> > >
> >
> > > From colton.conor at gmail.com Mon Jun 19 20:46:41 2017 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 19 Jun 2017 15:46:41 -0500 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EC22A@RTC-EXCH01.RESERVE.LDS> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> <263475836.6373.1497903419273.JavaMail.mhammett@ThunderFuck> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EC22A@RTC-EXCH01.RESERVE.LDS> Message-ID: Luke, I agree, I would be talking about getting one with the 1310NM special port for the QSFP+ input that emitts 1270-1330nm light, and then say 4 client ports on different channels than that light range. On Mon, Jun 19, 2017 at 3:40 PM, Luke Guillory wrote: > If their 1310 passes them I would have to think you can't use is with > other client ports that would fall within the window. Here is a graph > showing those 4 for the 40g it seems. > > http://public-wordpress-kkc.s3.amazonaws.com/wp-content/ > uploads/2014/07/Graph1.jpg > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+lguillory=reservetele.com at nanog.org] On > Behalf Of Colton Conor > Sent: Monday, June 19, 2017 3:32 PM > To: Mike Hammett > Cc: nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > I guess that makes sense. The plus or minus some is the question. FS is > claiming their 1310 port support QSFP+, which is 1270, 1290, 1310, and 1330 > combined. I understand you can us 1310, but I am still scratching my head > as to how they all one minus and two above 1310 to work. Of course they > don't have any datasheets to show the range either. > > > > On Mon, Jun 19, 2017 at 3:17 PM, Mike Hammett wrote: > > > I'd imagine they vary based on vendor, so you'd have to check with the > > specific vendor in terms of absolute technical specifications. > > > > A 1310 and 1550 port only allow those channels plus or minus some, > > manufacturer dependent. > > An expansion port passes everything not used by that device. > > > > Some manufacturers are even configurable pre-order, so you could get > > exactly what you needed (other than multiple 40G channels). > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Colton Conor" > > To: "Faisal Imtiaz" > > Cc: "Mike Hammett" , "Luke Guillory" < > > lguillory at reservetele.com>, "nanog list" > > Sent: Monday, June 19, 2017 3:14:19 PM > > Subject: Re: DWDM Mux/Demux using 40G Optics > > > > > > Thanks for the answers. From the sounds of it, no one knows the real > > difference between the expansion port, 1310 port, and 1550 port. For > > real world applications, I would assume the monitor port would be to > > plug in a handheld meter, and see which channels are coming through > > that node without breaking the ring. Not sure if their would be a > > monitor port for both directions is you were using a OADM? > > > > > > On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz < > > faisal at snappytelecom.net > > > wrote: > > > > > > > > > > > > Answers in-line ... > > > > > > Faisal Imtiaz > > Snappy Internet & Telecom > > 7266 SW 48 Street > > Miami, FL 33155 > > Tel: 305 663 5518 x 232 > > > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > > > > > > > > > >
> > From: "Colton Conor" < colton.conor at gmail.com > > > To: "Mike Hammett" < nanog at ics-il.net > > > Cc: "Luke Guillory" < lguillory at reservetele.com >, "nanog list" < > > nanog at nanog.org >, "Faisal Imtiaz" < faisal at snappytelecom.net > > > Sent: Monday, June 19, 2017 3:30:37 PM > > Subject: Re: DWDM Mux/Demux using 40G Optics > > > > > > > > > >
> > > > I guess that is the real question. Besides the client ports that are > > clearly identified by channel number on Muxes, what channels can the > > special ports handle? > > > > http://www.fs.com/products/43723.html It has 4 special service port > > options: > > > > 1. Expansion Port (Based on what I am seeing, I think this would be to > > stack another mux if you needed more channels. So I assume it allows > > all channels to be added besides the client channels?)
> > > > > > > > Exactly... this is basically a pass thru port, i.e. what is not > > getting mux/demux should get passed thru (keep the insertion loss in > mind). > > > > > >
> > > > > > 2. Monitor Port (I think this is just a tap that you would hook a > > monitor up to, and be able to see all channels coming through with a > > meter. I assume not a good idea to add/drop channels through this port)? > >
> > > > > > > > I don't use this port, but supposedly it will pass a fraction 5% of > > the light from the main port so that it can be monitored. May be > > someone else can offer some practical use for this port. > >
> > > > > > 3. 1310nm Port (Labeled as 1310, but clearly allows more than just > > 1310 since tutorial is saying it supports QSFP+ which is 1270 - 1330 > > nm, so what range does it really support or is there no a range?) > >
> > > > Not sure about the range question, but this is the port for having the > > 40g/100g QSFP+ pass thru > > > > > >
> > > > > > 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the > > 1330nm?) > > > > > >
> > > > I have not had the need to explore this in detail, but from my initial > > understanding, this can be used for ZR (long range optics) and or to > > stack a DWDM Mux > > > > > >
> > > > > > Would you recommend a monitor port on every mux you buy? > > > > > >
> > > > As I shared above, I don't. > > > > > > > > > >
> > > > > > > > On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett < nanog at ics-il.net > > wrote: > > > >
> > > > > > Verify pass-through frequencies for the 1310 (or equivalent) for the > > passive mux in question. This would only work for a single channel. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > > > > > From: "Luke Guillory" < lguillory at reservetele.com > > > To: "Faisal Imtiaz" < faisal at snappytelecom.net >, "Colton Conor" < > > colton.conor at gmail.com > > > Cc: "nanog list" < nanog at nanog.org > > > Sent: Monday, June 19, 2017 2:13:10 PM > > Subject: RE: DWDM Mux/Demux using 40G Optics > > > > > > > > Faisal, > > > > How would he inject his current 4x10 40g into the mux which is > > currently on a single LC cable? > > > > > > > > > > > > Luke Guillory > > Network Operations Manager > > > > Tel: 985.536.1212 > > Fax: 985.536.0300 > > Email: lguillory at reservetele.com > > > > Reserve Telecommunications > > 100 RTC Dr > > Reserve, LA 70084 > > > > ____________________________________________________________ > > _____________________________________ > > > > Disclaimer: > > The information transmitted, including attachments, is intended only > > for the person(s) or entity to which it is addressed and may contain > > confidential and/or privileged material which should not disseminate, > > distribute or be copied. Please notify Luke Guillory immediately by > > e-mail if you have received this e-mail by mistake and delete this > > e-mail from your system. E-mail transmission cannot be guaranteed to > > be secure or error-free as information could be intercepted, > > corrupted, lost, destroyed, arrive late or incomplete, or contain > > viruses. Luke Guillory therefore does not accept liability for any > > errors or omissions in the contents of this message, which arise as a > result of e-mail transmission. . > > > > -----Original Message----- > > From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Faisal > > Imtiaz > > Sent: Monday, June 19, 2017 2:02 PM > > To: Colton Conor > > Cc: nanog list > > Subject: Re: DWDM Mux/Demux using 40G Optics > > > > Answers in-line below. > > > > > > > > If you look at the CWDM Muxes (8 or 9 channel) you will notice a > > common configuration of > > > > Upgrade Port (expansion port) + 1450 or 1470 to 1610nm > > > > in the DWDM muxes you will see them listed as # of Port + 1310 pass > > thru channel. > > > > These are exactly what you are looking for ..... :) > > > > > > > >
> > > > > >
> > > >
> > > > > > > From faisal at snappytelecom.net Mon Jun 19 21:52:16 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 19 Jun 2017 21:52:16 +0000 (GMT) Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> Message-ID: <1833014520.2668036.1497909136226.JavaMail.zimbra@snappytelecom.net> >>From the sounds of it, no one knows the real difference between the expansion port, 1310 port, and 1550 port Hmm.. not sure how you are reading this... I believe that there is no 'standard' and as such the actual filter on the mux/demux you are using may vary by mfg. I can confirm what is an expansion port... (pass everything thru that is not being filtered by the mux/demux ) I can also confirm that Fiberstore 1310nm port (not to be confused with the CWDM 1310 port) will pass all 4 wavelengths for 40g/100g optics. I don't have experience with the 1550nm port. >>For real world applications, I would assume the monitor port would be to plug in a handheld meter, and see which channels are coming through that node without breaking the ring. Correct that is what it is designed for..... it allows a fraction of light (I am guessing would also cause an increase in insertion loss figure). >> Not sure if their would be a monitor port for both directions is you were using a OADM? If you look at the OADM's e.g. like a Cisco CWDM OADM with monitor ports, you will see that they are on both sides east & west. Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > From: "Colton Conor" > To: "Faisal Imtiaz" > Cc: "Mike Hammett" , "Luke Guillory" > , "nanog list" > Sent: Monday, June 19, 2017 4:14:19 PM > Subject: Re: DWDM Mux/Demux using 40G Optics > Thanks for the answers. From the sounds of it, no one knows the real difference > between the expansion port, 1310 port, and 1550 port. For real world > applications, I would assume the monitor port would be to plug in a handheld > meter, and see which channels are coming through that node without breaking the > ring. Not sure if their would be a monitor port for both directions is you were > using a OADM? > On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz < faisal at snappytelecom.net > > wrote: >> Answers in-line ... >> Faisal Imtiaz >> Snappy Internet & Telecom >> 7266 SW 48 Street >> Miami, FL 33155 >> Tel: 305 663 5518 x 232 >> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net >>> From: "Colton Conor" < colton.conor at gmail.com > >>> To: "Mike Hammett" < nanog at ics-il.net > >>> Cc: "Luke Guillory" < lguillory at reservetele.com >, "nanog list" < >>> nanog at nanog.org >, "Faisal Imtiaz" < faisal at snappytelecom.net > >>> Sent: Monday, June 19, 2017 3:30:37 PM >>> Subject: Re: DWDM Mux/Demux using 40G Optics >>> I guess that is the real question. Besides the client ports that are clearly >>> identified by channel number on Muxes, what channels can the special ports >>> handle? >>> http://www.fs.com/products/43723.html It has 4 special service port options: >>> 1. Expansion Port (Based on what I am seeing, I think this would be to stack >>> another mux if you needed more channels. So I assume it allows all channels to >>> be added besides the client channels?) >> Exactly... this is basically a pass thru port, i.e. what is not getting >> mux/demux should get passed thru (keep the insertion loss in mind). >>> 2. Monitor Port (I think this is just a tap that you would hook a monitor up to, >>> and be able to see all channels coming through with a meter. I assume not a >>> good idea to add/drop channels through this port)? >> I don't use this port, but supposedly it will pass a fraction 5% of the light >> from the main port so that it can be monitored. May be someone else can offer >> some practical use for this port. >>> 3. 1310nm Port (Labeled as 1310, but clearly allows more than just 1310 since >>> tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, so what range >>> does it really support or is there no a range?) >> Not sure about the range question, but this is the port for having the 40g/100g >> QSFP+ pass thru >>> 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the 1330nm?) >> I have not had the need to explore this in detail, but from my initial >> understanding, this can be used for ZR (long range optics) and or to stack a >> DWDM Mux >>> Would you recommend a monitor port on every mux you buy? >> As I shared above, I don't. >>> On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett < nanog at ics-il.net > wrote: >>>> Verify pass-through frequencies for the 1310 (or equivalent) for the passive mux >>>> in question. This would only work for a single channel. >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> Midwest-IX >>>> http://www.midwest-ix.com >>>> From: "Luke Guillory" < lguillory at reservetele.com > >>>> To: "Faisal Imtiaz" < faisal at snappytelecom.net >, "Colton Conor" < >>>> colton.conor at gmail.com > >>>> Cc: "nanog list" < nanog at nanog.org > >>>> Sent: Monday, June 19, 2017 2:13:10 PM >>>> Subject: RE: DWDM Mux/Demux using 40G Optics >>>> Faisal, >>>> How would he inject his current 4x10 40g into the mux which is currently on a >>>> single LC cable? >>>> Luke Guillory >>>> Network Operations Manager >>>> Tel: 985.536.1212 >>>> Fax: 985.536.0300 >>>> Email: lguillory at reservetele.com >>>> Reserve Telecommunications >>>> 100 RTC Dr >>>> Reserve, LA 70084 >>>> _________________________________________________________________________________________________ >>>> Disclaimer: >>>> The information transmitted, including attachments, is intended only for the >>>> person(s) or entity to which it is addressed and may contain confidential >>>> and/or privileged material which should not disseminate, distribute or be >>>> copied. Please notify Luke Guillory immediately by e-mail if you have received >>>> this e-mail by mistake and delete this e-mail from your system. E-mail >>>> transmission cannot be guaranteed to be secure or error-free as information >>>> could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or >>>> contain viruses. Luke Guillory therefore does not accept liability for any >>>> errors or omissions in the contents of this message, which arise as a result of >>>> e-mail transmission. . >>>> -----Original Message----- >>>> From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Faisal Imtiaz >>>> Sent: Monday, June 19, 2017 2:02 PM >>>> To: Colton Conor >>>> Cc: nanog list >>>> Subject: Re: DWDM Mux/Demux using 40G Optics >>>> Answers in-line below. >>>> If you look at the CWDM Muxes (8 or 9 channel) you will notice a common >>>> configuration of >>>> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >>>> in the DWDM muxes you will see them listed as # of Port + 1310 pass thru >>>> channel. >>>> These are exactly what you are looking for ..... :) From colton.conor at gmail.com Mon Jun 19 23:14:53 2017 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 19 Jun 2017 18:14:53 -0500 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <1833014520.2668036.1497909136226.JavaMail.zimbra@snappytelecom.net> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> <1833014520.2668036.1497909136226.JavaMail.zimbra@snappytelecom.net> Message-ID: Do you have any idea if fiberstore has one with both a monitor and 1310 wideband port? I would want both. Seeing as how they don't charge extra for an expansion port, but do for other special ports I am thinking of just using the expansion port. On Mon, Jun 19, 2017 at 4:52 PM, Faisal Imtiaz wrote: > > >>From the sounds of it, no one knows the real difference between the > expansion port, 1310 port, and 1550 port > > Hmm.. not sure how you are reading this... > I believe that there is no 'standard' and as such the actual filter on the > mux/demux you are using may vary by mfg. > I can confirm what is an expansion port... (pass everything thru that is > not being filtered by the mux/demux ) > I can also confirm that Fiberstore 1310nm port (not to be confused with > the CWDM 1310 port) will pass all 4 wavelengths for 40g/100g optics. > I don't have experience with the 1550nm port. > > >>For real world applications, I would assume the monitor port would be to > plug in a handheld meter, and see which channels are coming through that > node without breaking the ring. > > Correct that is what it is designed for..... it allows a fraction of > light (I am guessing would also cause an increase in insertion loss > figure). > > >> Not sure if their would be a monitor port for both directions is you > were using a OADM? > If you look at the OADM's e.g. like a Cisco CWDM OADM with monitor ports, > you will see that they are on both sides east & west. > > > Regards. > > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 <(305)%20663-5518> > > Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email: > Support at Snappytelecom.net > > ------------------------------ > > *From: *"Colton Conor" > *To: *"Faisal Imtiaz" > *Cc: *"Mike Hammett" , "Luke Guillory" < > lguillory at reservetele.com>, "nanog list" > *Sent: *Monday, June 19, 2017 4:14:19 PM > > *Subject: *Re: DWDM Mux/Demux using 40G Optics > > Thanks for the answers. From the sounds of it, no one knows the real > difference between the expansion port, 1310 port, and 1550 port. For real > world applications, I would assume the monitor port would be to plug in a > handheld meter, and see which channels are coming through that node without > breaking the ring. Not sure if their would be a monitor port for both > directions is you were using a OADM? > > On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz > wrote: > >> Answers in-line ... >> >> Faisal Imtiaz >> Snappy Internet & Telecom >> 7266 SW 48 Street >> Miami, FL 33155 >> Tel: 305 663 5518 x 232 <(305)%20663-5518> >> >> Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email: >> Support at Snappytelecom.net >> ------------------------------ >> >> *From: *"Colton Conor" >> *To: *"Mike Hammett" >> *Cc: *"Luke Guillory" , "nanog list" < >> nanog at nanog.org>, "Faisal Imtiaz" >> *Sent: *Monday, June 19, 2017 3:30:37 PM >> *Subject: *Re: DWDM Mux/Demux using 40G Optics >> >> I guess that is the real question. Besides the client ports that are >> clearly identified by channel number on Muxes, what channels can the >> special ports handle? >> http://www.fs.com/products/43723.html It has 4 special service port >> options: >> >> 1. Expansion Port (Based on what I am seeing, I think this would be to >> stack another mux if you needed more channels. So I assume it allows all >> channels to be added besides the client channels?) >> >> >> Exactly... this is basically a pass thru port, i.e. what is not getting >> mux/demux should get passed thru (keep the insertion loss in mind). >> >> 2. Monitor Port (I think this is just a tap that you would hook a monitor >> up to, and be able to see all channels coming through with a meter. I >> assume not a good idea to add/drop channels through this port)? >> >> I don't use this port, but supposedly it will pass a fraction 5% of the >> light from the main port so that it can be monitored. May be someone else >> can offer some practical use for this port. >> >> 3. 1310nm Port (Labeled as 1310, but clearly allows more than just 1310 >> since tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, so what >> range does it really support or is there no a range?) >> >> Not sure about the range question, but this is the port for having the >> 40g/100g QSFP+ pass thru >> >> 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the 1330nm?) >> >> I have not had the need to explore this in detail, but from my initial >> understanding, this can be used for ZR (long range optics) and or to stack >> a DWDM Mux >> >> Would you recommend a monitor port on every mux you buy? >> >> As I shared above, I don't. >> >> >> On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett wrote: >> >>> Verify pass-through frequencies for the 1310 (or equivalent) for the >>> passive mux in question. This would only work for a single channel. >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> ------------------------------ >>> *From: *"Luke Guillory" >>> *To: *"Faisal Imtiaz" , "Colton Conor" < >>> colton.conor at gmail.com> >>> *Cc: *"nanog list" >>> *Sent: *Monday, June 19, 2017 2:13:10 PM >>> *Subject: *RE: DWDM Mux/Demux using 40G Optics >>> >>> >>> Faisal, >>> >>> How would he inject his current 4x10 40g into the mux which is currently >>> on a single LC cable? >>> >>> >>> >>> >>> >>> Luke Guillory >>> Network Operations Manager >>> >>> Tel: 985.536.1212 <(985)%20536-1212> >>> Fax: 985.536.0300 <(985)%20536-0300> >>> Email: lguillory at reservetele.com >>> >>> Reserve Telecommunications >>> 100 RTC Dr >>> Reserve, LA 70084 >>> >>> ____________________________________________________________ >>> _____________________________________ >>> >>> Disclaimer: >>> The information transmitted, including attachments, is intended only for >>> the person(s) or entity to which it is addressed and may contain >>> confidential and/or privileged material which should not disseminate, >>> distribute or be copied. Please notify Luke Guillory immediately by e-mail >>> if you have received this e-mail by mistake and delete this e-mail from >>> your system. E-mail transmission cannot be guaranteed to be secure or >>> error-free as information could be intercepted, corrupted, lost, destroyed, >>> arrive late or incomplete, or contain viruses. Luke Guillory therefore does >>> not accept liability for any errors or omissions in the contents of this >>> message, which arise as a result of e-mail transmission. . >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz >>> Sent: Monday, June 19, 2017 2:02 PM >>> To: Colton Conor >>> Cc: nanog list >>> Subject: Re: DWDM Mux/Demux using 40G Optics >>> >>> Answers in-line below. >>> >>> >>> >>> If you look at the CWDM Muxes (8 or 9 channel) you will notice a common >>> configuration of >>> >>> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >>> >>> in the DWDM muxes you will see them listed as # of Port + 1310 pass >>> thru channel. >>> >>> These are exactly what you are looking for ..... :) >>> >>> >>> >> > From imawsog at yahoo.com Fri Jun 9 23:53:07 2017 From: imawsog at yahoo.com (i mawsog) Date: Fri, 9 Jun 2017 23:53:07 +0000 (UTC) Subject: Top 5 BGP issues In-Reply-To: <20170609180255.8C1BDC44B5@thyme.apnic.net> References: <20170609180255.8C1BDC44B5@thyme.apnic.net> Message-ID: <2083031927.6604061.1497052387464@mail.yahoo.com> Wondering what are the top 5 ?BGP issues that folks on this list faces ? ?Any comments welcome.? From imawsog at yahoo.com Tue Jun 13 19:31:08 2017 From: imawsog at yahoo.com (i mawsog) Date: Tue, 13 Jun 2017 19:31:08 +0000 (UTC) Subject: Troubleshooting most encountered BGP issues References: <1385426581.58578.1497382268113.ref@mail.yahoo.com> Message-ID: <1385426581.58578.1497382268113@mail.yahoo.com> Trying ?to make a ?check list ?for ?troubleshooting ?common BGP issues . ?The list is as follows.? Configuration issues : 1. ?Incorrect MD52. ?Incorrect peer ASN, IP? Runtime issues : 1. ?Path flap?2. ?Path hijack? Would like to grow this ?list with appropriate pointers and details. ?Or, if anyone is aware of ?such such a list's existence , would be glad to added to that .? From imawsog at yahoo.com Wed Jun 14 14:41:03 2017 From: imawsog at yahoo.com (i mawsog) Date: Wed, 14 Jun 2017 14:41:03 +0000 (UTC) Subject: Vendors spamming NANOG attendees In-Reply-To: <40B271A9-9997-4E02-B2C7-D0E95EA6B8F3@centergate.com> References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> <087770A4-F6FC-478B-A725-6189844F2744@centergate.com> <40B271A9-9997-4E02-B2C7-D0E95EA6B8F3@centergate.com> Message-ID: <1223625887.1668089.1497451263448@mail.yahoo.com> Agree, this thread has generated more "spam" or noise for all of us collectively.? Some amount of relevant "spam" ?has to be tolerated for vendor to continue supporting NANOG. Also relevant "spam" or sales call is a good way to find out about new technologies , that one may not have heard about otherwise. ? Another tip, just ignore, ?the "spammer" will go away eventually. ? Sent from Yahoo Mail on Android On Wed, Jun 14, 2017 at 6:45 AM, Rodney Joffe wrote: I guess that explains why so many newcomers are confused about what spam is. > On Jun 14, 2017, at 5:33 AM, Ge Dupin wrote: > > It looks like there are more spams coming from these discussions than from the original Scams/Spams.. > Ge > >>> Le 14 juin 2017 ? 14:26, Rodney Joffe a ?crit : >>> >>> >>> >>> On Jun 13, 2017, at 10:28 PM, Mel Beckman wrote: >>> >>> But as I said, harvesting emails is not illegal under can spam. And the requirement to not send you UCE to harvested emails is pointless, because how do you prove that someone did that? >>> >> Because he said so? >> >>>>>> The spammer had the balls to say, in his email: >>>>>> >>>>>>> >>>>>>> We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. >> >> > From imawsog at yahoo.com Mon Jun 19 17:46:06 2017 From: imawsog at yahoo.com (i mawsog) Date: Mon, 19 Jun 2017 17:46:06 +0000 (UTC) Subject: test - ignore References: <1499652614.1541638.1497894366394.ref@mail.yahoo.com> Message-ID: <1499652614.1541638.1497894366394@mail.yahoo.com> test - ignore From chiel at gmx.net Thu Jun 15 09:10:33 2017 From: chiel at gmx.net (chiel) Date: Thu, 15 Jun 2017 11:10:33 +0200 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <20170614140247.4917.qmail@ary.lan> References: <20170614140247.4917.qmail@ary.lan> Message-ID: <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Hello, We are deploying more and more server based routers (based on BSD). We have now come to the point where we need to have 10GB uplinks one these devices and I prefer to plug in a long range 10GB fiber straight into the server without it going first into a router/switch from vendor x. It seems to me that all the 10GB PCIe cards only support either copper 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very few). Are there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I can't seem to find any. Chiel From joe at nethead.com Wed Jun 14 00:09:19 2017 From: joe at nethead.com (Joe Hamelin) Date: Tue, 13 Jun 2017 17:09:19 -0700 Subject: Vendors spamming NANOG attendees In-Reply-To: <90420635.1926.1497392533850.JavaMail.mhammett@ThunderFuck> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> <20170613204702.GA29482@gsp.org> <995439918.1893.1497387369860.JavaMail.mhammett@ThunderFuck> <90420635.1926.1497392533850.JavaMail.mhammett@ThunderFuck> Message-ID: If they paid for a booth at beer & gear (i.e.; indirectly bought me a drink), then I'd give them _one_ pass on a targeted email. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 From gdupin at taho.fr Wed Jun 14 12:33:03 2017 From: gdupin at taho.fr (Ge Dupin) Date: Wed, 14 Jun 2017 14:33:03 +0200 Subject: Vendors spamming NANOG attendees In-Reply-To: <087770A4-F6FC-478B-A725-6189844F2744@centergate.com> References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> <087770A4-F6FC-478B-A725-6189844F2744@centergate.com> Message-ID: It looks like there are more spams coming from these discussions than from the original Scams/Spams.. Ge > Le 14 juin 2017 ? 14:26, Rodney Joffe a ?crit : > > > >> On Jun 13, 2017, at 10:28 PM, Mel Beckman wrote: >> >> But as I said, harvesting emails is not illegal under can spam. And the requirement to not send you UCE to harvested emails is pointless, because how do you prove that someone did that? >> > Because he said so? > >>>>> The spammer had the balls to say, in his email: >>>>> >>>>>> >>>>>> We do not know each other. I'm leveraging the attendee list for NANOG to reach out and raise awareness of the value of OCS (Optical Circuit Switching) in the data center and in particular, the Carrier Neutral Hotel where we've been active with next generation MeetMeRoom discussions. > > From gdupin at taho.fr Fri Jun 16 21:42:39 2017 From: gdupin at taho.fr (Ge Dupin) Date: Fri, 16 Jun 2017 23:42:39 +0200 Subject: Vendors spamming NANOG attendees In-Reply-To: References: Message-ID: <363ABA0E-A9CE-41C1-B24C-AFB41C91A1D0@taho.fr> exactly it is becoming really painful Ge > Le 16 juin 2017 ? 17:06, Alexander Maassen a ?crit : > > the discussion about the external spam kinda exceeds the volume of the spam itself. just my 2 cents. > just block, delete, continue life > > Kind regards, > Alexander Maassen > - Technical Maintenance Engineer Parkstad Support BV- Maintainer DroneBL- Peplink Certified Engineer > > -------- Oorspronkelijk bericht --------Van: bzs at theworld.com Datum: 15-06-17 20:09 (GMT+01:00) Aan: Dan Hollis Cc: Niels Bakker , nanog at nanog.org, bzs at theworld.com Onderwerp: Re: Vendors spamming NANOG attendees > > On June 14, 2017 at 14:22 goemon at sasami.anime.net (Dan Hollis) wrote: >> On Wed, 14 Jun 2017, bzs at theworld.com wrote: >>> Merely deciding not to patronize them may not be sufficient and that's >>> why we make that sort of thing just outright illegal rather than hope >>> market forces will suffice. >> >> Most spam is sent from compromised machines anyway, so there are already >> criminal violations involved in sending spam. > > FWIW I believe the context was a vendor spamming NANOG attendees (see > the Subject:) so not likely being done from compromised machines. > > That said, yes, a lot of spam is sent from compromised machines as you > say. > > But criminal violations can be additive, even rising to things like > RICO charges (a pattern of organized criminal behavior etc.) which can > be both criminal and civil and added onto charges like the criminality > of specific mechanisms (compromised systems etc.) > > It really depends on how interested one can get the legal machinery in > the problem. Thus far that's hit or miss. I can't find any instance > where RICO charges were used against a spam gang tho, at least on a > quick search. > > -- > -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 EPers at ansencorp.com Thu Jun 15 12:19:22 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Thu, 15 Jun 2017 12:19:22 +0000 Subject: mailops https breakage In-Reply-To: References: <20160827012542.43353.qmail@ary.lan> <20160828014627.GE4869@hezmatt.org> Message-ID: Fun fact about letsencrypt certs, they expire after a month or so. Looks like the site admin never noticed/cared to update it (since 2016), even though there's a nice little helper program to auto-update them that you can throw in a cronjob (or scheduled task, if you're into IIS) and forget about Ed Pers -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lyndon Nerenberg Sent: Sunday, June 11, 2017 6:27 PM To: NANOG list Subject: mailops https breakage > On Aug 27, 2016, at 6:46 PM, Matt Palmer wrote: > > On Sat, Aug 27, 2016 at 01:25:42AM -0000, John Levine wrote: >> In article you write: >>> I was working within the limits of what I had available. >> >> Here's the subscription page for mailop. It's got about as odd a mix >> of people as nanog, ranging from people with single user linux >> machines to people who run some of the largest mail systems in the >> world, including Gmail: >> >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > I know they're mailops, and not tlsops, but surely presenting a cert > that didn't expire six months ago isn't beyond the site admin's capabilities? I tried again, ten months later. Still broken :-( Is there a replacement site I'm missing out on? From faisal at snappytelecom.net Mon Jun 19 19:26:52 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 19 Jun 2017 19:26:52 +0000 (GMT) Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> Message-ID: <1358879275.2667342.1497900412161.JavaMail.zimbra@snappytelecom.net> Bench test of the system, with the muxes... sorry for the large pictures :) Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Luke Guillory" > To: "Faisal Imtiaz" , "Colton Conor" > Cc: "nanog list" > Sent: Monday, June 19, 2017 3:13:10 PM > Subject: RE: DWDM Mux/Demux using 40G Optics > Faisal, > > How would he inject his current 4x10 40g into the mux which is currently on a > single LC cable? > > > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > _________________________________________________________________________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for the > person(s) or entity to which it is addressed and may contain confidential > and/or privileged material which should not disseminate, distribute or be > copied. Please notify Luke Guillory immediately by e-mail if you have received > this e-mail by mistake and delete this e-mail from your system. E-mail > transmission cannot be guaranteed to be secure or error-free as information > could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > contain viruses. Luke Guillory therefore does not accept liability for any > errors or omissions in the contents of this message, which arise as a result of > e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz > Sent: Monday, June 19, 2017 2:02 PM > To: Colton Conor > Cc: nanog list > Subject: Re: DWDM Mux/Demux using 40G Optics > > Answers in-line below. > > > > If you look at the CWDM Muxes (8 or 9 channel) you will notice a common > configuration of > > Upgrade Port (expansion port) + 1450 or 1470 to 1610nm > > in the DWDM muxes you will see them listed as # of Port + 1310 pass thru > channel. > > These are exactly what you are looking for ..... :) From jcouncil at akamai.com Mon Jun 12 17:41:49 2017 From: jcouncil at akamai.com (Councilman, John) Date: Mon, 12 Jun 2017 17:41:49 +0000 Subject: AT&T DNS Contact Message-ID: Is there anyone on-list who can help me (off list) with AT&T DNS? I?m looking for some information about caching DNS servers. Thanks. John Councilman Enterprise Architect / Media [ttps://www.akamai.com/us/en/multimedia/images/custom/akamai-logo.png] Cell: +1.770.625.6393 Desk: +1.404.442.6362 Extension: 66362 Akamai Technologies 3715 Northside Parkway , N.W. Building 200, Suite 300 Atlanta, GA 30327 Connect with Us: [ttps://www.akamai.com/us/en/multimedia/images/custom/community.jpg] [ttps://www.akamai.com/us/en/multimedia/images/custom/rss.png] [ttps://www.akamai.com/us/en/multimedia/images/custom/twitter.png] [ttps://www.akamai.com/us/en/multimedia/images/custom/fb.png] [ttps://www.akamai.com/us/en/multimedia/images/custom/in.png] [ttps://www.akamai.com/us/en/multimedia/images/custom/youtube.png] From ken.gilmour at gmail.com Fri Jun 9 00:03:00 2017 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Fri, 09 Jun 2017 00:03:00 +0000 Subject: Google Security Contact Message-ID: Hi, There is a potential vulnerability in Gmail / Google Inbox which I need to discuss and verify with the Google Security Team. Is there anyone on that team here on NANOG who can contact me off-list please? Best to contact me at kg at invinsec.com. Thanks! Ken From lee at asgard.org Fri Jun 16 12:11:56 2017 From: lee at asgard.org (Lee Howard) Date: Fri, 16 Jun 2017 08:11:56 -0400 Subject: IPv6 operations discussions Message-ID: The IETF v6ops working group is chartered to improve the operation of IPv6. We have several active documents right now that would benefit from broader operator feedback. For instance, there is current active discussion on: Requirements for IPv6 Routers This document provides a list of requirements for operators? routers. Is it clear and exhaustive? Basic Requirements for IPv6 Customer Edge Routers What transition technologies should all CPE vendors put in their devices? The current version proposes all of: 464xlat, DS-Lite, lw4o6, MAP-E, MAP-T, 6in4, and 6rd, as well as IPv4 multicast over IPv6. There are related documents that split out some requirements for further discussion. Happy Eyeballs Version 2: Better Connectivity Using Concurrency Is this a useful update to the existing Happy Eyeballs specification (rfc6555)? Should we update Happy Eyeballs? Considerations For Using Unique Local Addresses Are ULAs useful, or are they a natural and risky predecessor to IPv6 NAT? It would help future IPv6 operations if current operators would read these documents and comment on them on the mailing list: https://www.ietf.org/mailman/listinfo/v6ops Note Well that comments become part of the IETF record, and thank you for them. Lee v6ops co-chair From nanog at jack.fr.eu.org Mon Jun 19 12:08:09 2017 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Mon, 19 Jun 2017 14:08:09 +0200 Subject: IPv6 traffic percentages? In-Reply-To: <000801d2e8f2$8fad88d0$af089a70$@gvtc.com> References: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> <000801d2e8f2$8fad88d0$af089a70$@gvtc.com> Message-ID: <20264a07-3d74-6c63-ea5a-3a61fec19473@jack.fr.eu.org> More stats : https://as24904.kwaoo.net/as-stats/top.php We are one of raf's competitor in France, FTTH based operator ~ 20% of our customers are ipv6-enabled ~ 5% of total traffic is IPv6 On 19/06/2017 13:52, Aaron Gould wrote: > When you say some percentage is with Google, what do you mean by that ? What do you mean by "with Google" ? > > - Aaron Gould > > From pbmarcos at inf.ufrgs.br Tue Jun 13 13:17:57 2017 From: pbmarcos at inf.ufrgs.br (Pedro de Botelho Marcos) Date: Tue, 13 Jun 2017 10:17:57 -0300 Subject: Survey on Internet agreement ecosystem In-Reply-To: References: Message-ID: Dear NANOG community, we would like to share some preliminary results from our survey (circulated two weeks ago) on Internet agreements and to foster further participation. Would you help us by answering a set of objective questions reflecting your views (<10min)? Survey URL: http://bit.ly/2rfoQ3E We aim at drawing a picture of the dynamism, economics, and service level agreements aspects in today?s Internet interconnection ecosystem. So far, we observed that the majority of the respondents have between 6-20 agreements and 1 of every 4 respondents have Service Level Agreements for over 75-100% of these agreements. One of every three respondents have no more than 25% settlement-free agreements. Related to our envisioned scenario, the majority of operators are willing to have features to reduce the current agreement setup time (the overall time is indicated as "months") and to establish more fine-grained agreements (e.g. for a set of prefixes). We will share the final results in an aggregated form once collecting . Please write in the comments if you have any specific concern about sharing results in an aggregated form. Feel free to drop any comment on how to improve the survey in the future. Thank you very much, 2017-06-01 14:23 GMT-03:00 Pedro de Botelho Marcos : > Dear NANOG community, > > We are conducting a survey about Internet agreements, with a focus on > dynamism, economics, and service level agreements aspects. Can you please > help us by answering a set of objective questions reflecting your views > (<10min)? > > Feel free to drop any comment on how to improve the survey in the future. > > Survey URL: http://bit.ly/2rfoQ3E > > Thank you very much, > > Cheers, > -- > Pedro de Botelho Marcos > PhD Student > Computer Networks Research Group > Federal University of Rio Grande do Sul - UFRGS > > -- Pedro From s at xopher.net Thu Jun 8 16:18:48 2017 From: s at xopher.net (Scott Christopher) Date: Thu, 08 Jun 2017 19:18:48 +0300 Subject: IPv4 Hijacking For Idiots In-Reply-To: <20170608025025.6776333A@m0117460.ppops.net> References: <20170608025025.6776333A@m0117460.ppops.net> Message-ID: <1496938728.26171.1003124912.1B8D88B5@webmail.messagingengine.com> Scott Weeks wrote: > --- s at xopher.net wrote: > From: Scott Christopher > > I think the solution is legislation + regulations. > --------------------------------- > > For sure dude, because, you know, they do such a > great job of all the other stuff they touch! > > scott > > ps. NOT! I don't want to rain on all these sunny libertarian feelingz you have bottled up - but the reason we have an Internet where small companies can compete with big companies on equal footing is because of "net neutrality" and the regulations that make that. This is why today we are all using something better than AltaVista and faster than 56k dial-up. Right now there is a cartel of providers that have no incentive to secure BGP. Please explain how the free market fixes this on its own. -- Regards, S.C. From vireak.ouk at gmail.com Sat Jun 17 10:24:25 2017 From: vireak.ouk at gmail.com (Vireak Ouk) Date: Sat, 17 Jun 2017 17:24:25 +0700 Subject: Incapsula AS19551 Message-ID: Hello all If anyone from Incapsula can contact me off-list, I would highly appreciate. We are not able to access several sites hosted in Incapsula from source AS59318 and from our downstream. The issues only happened from yesterday. Many thanks vireak From faisal at snappytelecom.net Tue Jun 20 01:15:31 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 20 Jun 2017 01:15:31 +0000 (GMT) Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> <1833014520.2668036.1497909136226.JavaMail.zimbra@snappytelecom.net> Message-ID: <1157921337.2668552.1497921331364.JavaMail.zimbra@snappytelecom.net> You can see the CWDM mux listed on their site, and they will also make custom mux for you. Let me know if you need a Sales Contact for them.. My last set of muxes from them were custom muxes and they were able to get me a configuration with a lower insertion loss than what is listed on their website. ( I paid a small premium for that feature, which I was very happy to). Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > From: "Colton Conor" > To: "Faisal Imtiaz" > Cc: "Mike Hammett" , "Luke Guillory" > , "nanog list" > Sent: Monday, June 19, 2017 7:14:53 PM > Subject: Re: DWDM Mux/Demux using 40G Optics > Do you have any idea if fiberstore has one with both a monitor and 1310 wideband > port? I would want both. > Seeing as how they don't charge extra for an expansion port, but do for other > special ports I am thinking of just using the expansion port. > On Mon, Jun 19, 2017 at 4:52 PM, Faisal Imtiaz < faisal at snappytelecom.net > > wrote: >>>>From the sounds of it, no one knows the real difference between the expansion >> >>port, 1310 port, and 1550 port >> Hmm.. not sure how you are reading this... >> I believe that there is no 'standard' and as such the actual filter on the >> mux/demux you are using may vary by mfg. >> I can confirm what is an expansion port... (pass everything thru that is not >> being filtered by the mux/demux ) >> I can also confirm that Fiberstore 1310nm port (not to be confused with the CWDM >> 1310 port) will pass all 4 wavelengths for 40g/100g optics. >> I don't have experience with the 1550nm port. >>>>For real world applications, I would assume the monitor port would be to plug in >>>>a handheld meter, and see which channels are coming through that node without >> >>breaking the ring. >> Correct that is what it is designed for..... it allows a fraction of light (I am >> guessing would also cause an increase in insertion loss figure). >>>> Not sure if their would be a monitor port for both directions is you were using >> >> a OADM? >> If you look at the OADM's e.g. like a Cisco CWDM OADM with monitor ports, you >> will see that they are on both sides east & west. >> Regards. >> Faisal Imtiaz >> Snappy Internet & Telecom >> 7266 SW 48 Street >> Miami, FL 33155 >> Tel: 305 663 5518 x 232 >> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net >>> From: "Colton Conor" < colton.conor at gmail.com > >>> To: "Faisal Imtiaz" < faisal at snappytelecom.net > >>> Cc: "Mike Hammett" < nanog at ics-il.net >, "Luke Guillory" < >>> lguillory at reservetele.com >, "nanog list" < nanog at nanog.org > >>> Sent: Monday, June 19, 2017 4:14:19 PM >>> Subject: Re: DWDM Mux/Demux using 40G Optics >>> Thanks for the answers. From the sounds of it, no one knows the real difference >>> between the expansion port, 1310 port, and 1550 port. For real world >>> applications, I would assume the monitor port would be to plug in a handheld >>> meter, and see which channels are coming through that node without breaking the >>> ring. Not sure if their would be a monitor port for both directions is you were >>> using a OADM? >>> On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz < faisal at snappytelecom.net > >>> wrote: >>>> Answers in-line ... >>>> Faisal Imtiaz >>>> Snappy Internet & Telecom >>>> 7266 SW 48 Street >>>> Miami, FL 33155 >>>> Tel: 305 663 5518 x 232 >>>> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net >>>>> From: "Colton Conor" < colton.conor at gmail.com > >>>>> To: "Mike Hammett" < nanog at ics-il.net > >>>>> Cc: "Luke Guillory" < lguillory at reservetele.com >, "nanog list" < >>>>> nanog at nanog.org >, "Faisal Imtiaz" < faisal at snappytelecom.net > >>>>> Sent: Monday, June 19, 2017 3:30:37 PM >>>>> Subject: Re: DWDM Mux/Demux using 40G Optics >>>>> I guess that is the real question. Besides the client ports that are clearly >>>>> identified by channel number on Muxes, what channels can the special ports >>>>> handle? >>>>> http://www.fs.com/products/43723.html It has 4 special service port options: >>>>> 1. Expansion Port (Based on what I am seeing, I think this would be to stack >>>>> another mux if you needed more channels. So I assume it allows all channels to >>>>> be added besides the client channels?) >>>> Exactly... this is basically a pass thru port, i.e. what is not getting >>>> mux/demux should get passed thru (keep the insertion loss in mind). >>>>> 2. Monitor Port (I think this is just a tap that you would hook a monitor up to, >>>>> and be able to see all channels coming through with a meter. I assume not a >>>>> good idea to add/drop channels through this port)? >>>> I don't use this port, but supposedly it will pass a fraction 5% of the light >>>> from the main port so that it can be monitored. May be someone else can offer >>>> some practical use for this port. >>>>> 3. 1310nm Port (Labeled as 1310, but clearly allows more than just 1310 since >>>>> tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, so what range >>>>> does it really support or is there no a range?) >>>> Not sure about the range question, but this is the port for having the 40g/100g >>>> QSFP+ pass thru >>>>> 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the 1330nm?) >>>> I have not had the need to explore this in detail, but from my initial >>>> understanding, this can be used for ZR (long range optics) and or to stack a >>>> DWDM Mux >>>>> Would you recommend a monitor port on every mux you buy? >>>> As I shared above, I don't. >>>>> On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett < nanog at ics-il.net > wrote: >>>>>> Verify pass-through frequencies for the 1310 (or equivalent) for the passive mux >>>>>> in question. This would only work for a single channel. >>>>>> ----- >>>>>> Mike Hammett >>>>>> Intelligent Computing Solutions >>>>>> http://www.ics-il.com >>>>>> Midwest-IX >>>>>> http://www.midwest-ix.com >>>>>> From: "Luke Guillory" < lguillory at reservetele.com > >>>>>> To: "Faisal Imtiaz" < faisal at snappytelecom.net >, "Colton Conor" < >>>>>> colton.conor at gmail.com > >>>>>> Cc: "nanog list" < nanog at nanog.org > >>>>>> Sent: Monday, June 19, 2017 2:13:10 PM >>>>>> Subject: RE: DWDM Mux/Demux using 40G Optics >>>>>> Faisal, >>>>>> How would he inject his current 4x10 40g into the mux which is currently on a >>>>>> single LC cable? >>>>>> Luke Guillory >>>>>> Network Operations Manager >>>>>> Tel: 985.536.1212 >>>>>> Fax: 985.536.0300 >>>>>> Email: lguillory at reservetele.com >>>>>> Reserve Telecommunications >>>>>> 100 RTC Dr >>>>>> Reserve, LA 70084 >>>>>> _________________________________________________________________________________________________ >>>>>> Disclaimer: >>>>>> The information transmitted, including attachments, is intended only for the >>>>>> person(s) or entity to which it is addressed and may contain confidential >>>>>> and/or privileged material which should not disseminate, distribute or be >>>>>> copied. Please notify Luke Guillory immediately by e-mail if you have received >>>>>> this e-mail by mistake and delete this e-mail from your system. E-mail >>>>>> transmission cannot be guaranteed to be secure or error-free as information >>>>>> could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or >>>>>> contain viruses. Luke Guillory therefore does not accept liability for any >>>>>> errors or omissions in the contents of this message, which arise as a result of >>>>>> e-mail transmission. . >>>>>> -----Original Message----- >>>>>> From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Faisal Imtiaz >>>>>> Sent: Monday, June 19, 2017 2:02 PM >>>>>> To: Colton Conor >>>>>> Cc: nanog list >>>>>> Subject: Re: DWDM Mux/Demux using 40G Optics >>>>>> Answers in-line below. >>>>>> If you look at the CWDM Muxes (8 or 9 channel) you will notice a common >>>>>> configuration of >>>>>> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >>>>>> in the DWDM muxes you will see them listed as # of Port + 1310 pass thru >>>>>> channel. >>>>>> These are exactly what you are looking for ..... :) From mark.tinka at seacom.mu Tue Jun 20 02:31:48 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 20 Jun 2017 09:31:48 +0200 Subject: SAFNOG-3: Sponsorship Opportunities Message-ID: <0e40751b-2fdb-8214-7477-c9204b30407c@seacom.mu> Hello all. It gives me great pleasure to announce that the Sponsorship Matrix for SAFNOG-3 is now available at the link below: http://www.safnog.org/matrix.html If you are interested in collaborating with SAFNOG-3 as a sponsor, please do not hesitate to reach out to: secretariat at safnog dot org Any and all support will be sincerely appreciated. We look forward to seeing you in Durban for our next meeting. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From karsten.elfenbein at gmail.com Tue Jun 20 02:44:02 2017 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Tue, 20 Jun 2017 09:44:02 +0200 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: Hi, most 10GE cards have either direct 10GBASE-T port(s)s or SFP+ slot(s). The SFP+ transceiver you plug in determines the range. (SMF/MMF, wavelength, link budget) Reading the optical parameters is a bit tricky on most NICs. Karsten 2017-06-15 11:10 GMT+02:00 chiel : > Hello, > > We are deploying more and more server based routers (based on BSD). We have > now come to the point where we need to have 10GB uplinks one these devices > and I prefer to plug in a long range 10GB fiber straight into the server > without it going first into a router/switch from vendor x. It seems to me > that all the 10GB PCIe cards only support either copper 10GBASE-T, short > range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very few). Are there any > PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I can't seem to find any. > > Chiel From swmike at swm.pp.se Tue Jun 20 02:54:39 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 20 Jun 2017 09:54:39 +0200 (CEST) Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: On Thu, 15 Jun 2017, chiel wrote: > Hello, > > We are deploying more and more server based routers (based on BSD). We > have now come to the point where we need to have 10GB uplinks one these > devices and I prefer to plug in a long range 10GB fiber straight into > the server without it going first into a router/switch from vendor x. It > seems to me that all the 10GB PCIe cards only support either copper > 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very > few). Are there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I > can't seem to find any. The Intel XF SR2 card actually has XFPs and I have LR optics in one here. I don't see any reason it wouldn't support ER or ZR as well. -- Mikael Abrahamsson email: swmike at swm.pp.se From Jeroen.Wunnink at gtt.net Tue Jun 20 03:55:06 2017 From: Jeroen.Wunnink at gtt.net (Jeroen Wunnink) Date: Tue, 20 Jun 2017 08:55:06 +0000 Subject: DWDM Mux/Demux using 40G Optics In-Reply-To: References: <956350497.2667155.1497898905539.JavaMail.zimbra@snappytelecom.net> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB1EBE5C@RTC-EXCH01.RESERVE.LDS> <700937523.6268.1497899875929.JavaMail.mhammett@ThunderFuck> <1312148074.2667408.1497901130535.JavaMail.zimbra@snappytelecom.net> <1833014520.2668036.1497909136226.JavaMail.zimbra@snappytelecom.net> Message-ID: Another alternative is to ask the http://www.beetlefiberoptics.com guys. They build muxes on spec and they can also provide a 1310nm wide-band port on their units which allows a 40/100G-LR4 aside from the 1550nm DWDM band. We’ve used some simple splitters (line/1310nm LR4/1550nm DWDM ports on a unit) and full passive DWDM muxes with a 40/100G-LR4 port on there and these work pretty good. Jeroen Wunnink IP Engineering manager office: +31.208.200.622 ext. 1011 Amsterdam Office www.gtt.net On 20/06/2017, 01:14, "NANOG on behalf of Colton Conor" wrote: Do you have any idea if fiberstore has one with both a monitor and 1310 wideband port? I would want both. Seeing as how they don't charge extra for an expansion port, but do for other special ports I am thinking of just using the expansion port. On Mon, Jun 19, 2017 at 4:52 PM, Faisal Imtiaz wrote: > > >>From the sounds of it, no one knows the real difference between the > expansion port, 1310 port, and 1550 port > > Hmm.. not sure how you are reading this... > I believe that there is no 'standard' and as such the actual filter on the > mux/demux you are using may vary by mfg. > I can confirm what is an expansion port... (pass everything thru that is > not being filtered by the mux/demux ) > I can also confirm that Fiberstore 1310nm port (not to be confused with > the CWDM 1310 port) will pass all 4 wavelengths for 40g/100g optics. > I don't have experience with the 1550nm port. > > >>For real world applications, I would assume the monitor port would be to > plug in a handheld meter, and see which channels are coming through that > node without breaking the ring. > > Correct that is what it is designed for..... it allows a fraction of > light (I am guessing would also cause an increase in insertion loss > figure). > > >> Not sure if their would be a monitor port for both directions is you > were using a OADM? > If you look at the OADM's e.g. like a Cisco CWDM OADM with monitor ports, > you will see that they are on both sides east & west. > > > Regards. > > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 <(305)%20663-5518> > > Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email: > Support at Snappytelecom.net > > ------------------------------ > > *From: *"Colton Conor" > *To: *"Faisal Imtiaz" > *Cc: *"Mike Hammett" , "Luke Guillory" < > lguillory at reservetele.com>, "nanog list" > *Sent: *Monday, June 19, 2017 4:14:19 PM > > *Subject: *Re: DWDM Mux/Demux using 40G Optics > > Thanks for the answers. From the sounds of it, no one knows the real > difference between the expansion port, 1310 port, and 1550 port. For real > world applications, I would assume the monitor port would be to plug in a > handheld meter, and see which channels are coming through that node without > breaking the ring. Not sure if their would be a monitor port for both > directions is you were using a OADM? > > On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz > wrote: > >> Answers in-line ... >> >> Faisal Imtiaz >> Snappy Internet & Telecom >> 7266 SW 48 Street >> Miami, FL 33155 >> Tel: 305 663 5518 x 232 <(305)%20663-5518> >> >> Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email: >> Support at Snappytelecom.net >> ------------------------------ >> >> *From: *"Colton Conor" >> *To: *"Mike Hammett" >> *Cc: *"Luke Guillory" , "nanog list" < >> nanog at nanog.org>, "Faisal Imtiaz" >> *Sent: *Monday, June 19, 2017 3:30:37 PM >> *Subject: *Re: DWDM Mux/Demux using 40G Optics >> >> I guess that is the real question. Besides the client ports that are >> clearly identified by channel number on Muxes, what channels can the >> special ports handle? >> http://www.fs.com/products/43723.html It has 4 special service port >> options: >> >> 1. Expansion Port (Based on what I am seeing, I think this would be to >> stack another mux if you needed more channels. So I assume it allows all >> channels to be added besides the client channels?) >> >> >> Exactly... this is basically a pass thru port, i.e. what is not getting >> mux/demux should get passed thru (keep the insertion loss in mind). >> >> 2. Monitor Port (I think this is just a tap that you would hook a monitor >> up to, and be able to see all channels coming through with a meter. I >> assume not a good idea to add/drop channels through this port)? >> >> I don't use this port, but supposedly it will pass a fraction 5% of the >> light from the main port so that it can be monitored. May be someone else >> can offer some practical use for this port. >> >> 3. 1310nm Port (Labeled as 1310, but clearly allows more than just 1310 >> since tutorial is saying it supports QSFP+ which is 1270 - 1330 nm, so what >> range does it really support or is there no a range?) >> >> Not sure about the range question, but this is the port for having the >> 40g/100g QSFP+ pass thru >> >> 4. 1550nm Port (Labeled as 1550nm, but I wonder if its like the 1330nm?) >> >> I have not had the need to explore this in detail, but from my initial >> understanding, this can be used for ZR (long range optics) and or to stack >> a DWDM Mux >> >> Would you recommend a monitor port on every mux you buy? >> >> As I shared above, I don't. >> >> >> On Mon, Jun 19, 2017 at 2:18 PM, Mike Hammett wrote: >> >>> Verify pass-through frequencies for the 1310 (or equivalent) for the >>> passive mux in question. This would only work for a single channel. >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> ------------------------------ >>> *From: *"Luke Guillory" >>> *To: *"Faisal Imtiaz" , "Colton Conor" < >>> colton.conor at gmail.com> >>> *Cc: *"nanog list" >>> *Sent: *Monday, June 19, 2017 2:13:10 PM >>> *Subject: *RE: DWDM Mux/Demux using 40G Optics >>> >>> >>> Faisal, >>> >>> How would he inject his current 4x10 40g into the mux which is currently >>> on a single LC cable? >>> >>> >>> >>> >>> >>> Luke Guillory >>> Network Operations Manager >>> >>> Tel: 985.536.1212 <(985)%20536-1212> >>> Fax: 985.536.0300 <(985)%20536-0300> >>> Email: lguillory at reservetele.com >>> >>> Reserve Telecommunications >>> 100 RTC Dr >>> Reserve, LA 70084 >>> >>> ____________________________________________________________ >>> _____________________________________ >>> >>> Disclaimer: >>> The information transmitted, including attachments, is intended only for >>> the person(s) or entity to which it is addressed and may contain >>> confidential and/or privileged material which should not disseminate, >>> distribute or be copied. Please notify Luke Guillory immediately by e-mail >>> if you have received this e-mail by mistake and delete this e-mail from >>> your system. E-mail transmission cannot be guaranteed to be secure or >>> error-free as information could be intercepted, corrupted, lost, destroyed, >>> arrive late or incomplete, or contain viruses. Luke Guillory therefore does >>> not accept liability for any errors or omissions in the contents of this >>> message, which arise as a result of e-mail transmission. . >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz >>> Sent: Monday, June 19, 2017 2:02 PM >>> To: Colton Conor >>> Cc: nanog list >>> Subject: Re: DWDM Mux/Demux using 40G Optics >>> >>> Answers in-line below. >>> >>> >>> >>> If you look at the CWDM Muxes (8 or 9 channel) you will notice a common >>> configuration of >>> >>> Upgrade Port (expansion port) + 1450 or 1470 to 1610nm >>> >>> in the DWDM muxes you will see them listed as # of Port + 1310 pass >>> thru channel. >>> >>> These are exactly what you are looking for ..... :) >>> >>> >>> >> > From aaron1 at gvtc.com Tue Jun 20 07:33:11 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 20 Jun 2017 07:33:11 -0500 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: <001201d2e9c1$6136b1a0$23a414e0$@gvtc.com> As a thought, would seem to make sense to modularize that server nic so we can slide in whatever optic we desire...copper, fiber short mm, fiber long range sm, etc -Aaron From rod.beck at unitedcablecompany.com Tue Jun 20 08:26:20 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 20 Jun 2017 13:26:20 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: References: , Message-ID: And how do you tell if an address was scraped or not? There are databases and zillions of other ways of gaining addresses. I doubt you can distinguish the source with any real reliability. - R. ________________________________ From: NANOG on behalf of Dave Temkin Sent: Wednesday, June 14, 2017 11:05 PM To: Jon Lewis Cc: NANOG Subject: Re: Vendors spamming NANOG attendees On Wed, Jun 14, 2017 at 5:04 PM, Jon Lewis wrote: > On Wed, 14 Jun 2017, Dave Temkin wrote: > > This is highly inaccurate. The PC and Board have done everything in our >> power to keep sponsorship out of the program. Yes, Beer & Gear looks like >> a >> NASCAR race, but that helps fund not only the program, but the numerous >> other outreach programs that NANOG has undertaken. >> >> Sponsors who have stepped on the rules have had their sponsorship rights >> revoked - temporarily, and in egregious cases, permanently. We (the NANOG >> organization) take this incredibly seriously. >> >> While it's hard to solve for the exact case above (scraping registrant >> lists and then comparing to CRM to glean contact info) we absolutely do >> aggressively pursue any abuse of NANOG's attendee information, trademarks, >> and mailing list. >> > > Is it too simple a solution to post a warning on the page above the > Attendee List saying something along the lines of "scraping the Attendee > List for marketing purposes is forbidden, will result in public shaming, > and may cause some attendees to completely boycott your company." ? > This suggestion was made on the NANOG Facebook group and we will implement it with the new website coming before NANOG 71. -Dave From maxtul at netassist.ua Tue Jun 20 08:30:03 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 20 Jun 2017 16:30:03 +0300 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: <5949235B.7020307@netassist.ua> We use Intel NICs with SFP+ holes. It works good with long and short range SFP+ modules, including CWDM/DWDM. On 15.06.17 12:10, chiel wrote: > Hello, > > We are deploying more and more server based routers (based on BSD). We > have now come to the point where we need to have 10GB uplinks one these > devices and I prefer to plug in a long range 10GB fiber straight into > the server without it going first into a router/switch from vendor x. It > seems to me that all the 10GB PCIe cards only support either copper > 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very > few). Are there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I > can't seem to find any. > > Chiel > From tim at pelican.org Tue Jun 20 08:37:09 2017 From: tim at pelican.org (tim at pelican.org) Date: Tue, 20 Jun 2017 14:37:09 +0100 (BST) Subject: Vendors spamming NANOG attendees In-Reply-To: References: , Message-ID: <1497965829.578913311@apps.rackspace.com> On Tuesday, 20 June, 2017 14:26, "Rod Beck" said: > And how do you tell if an address was scraped or not? There are databases and > zillions of other ways of gaining addresses. > > > I doubt you can distinguish the source with any real reliability. Depending on whether you're registered with personal or corporate email, and how much control you have over the platform in question, you can distinguish the source with fairly high reliability. Just generate a new 'bob+nanog70 at bobsdomain.org' style address for every event you register for, every website that requires a contact address, every mailing list, ... If you're concerned that people will twig, and use the naked 'bob@' address, you could work with multiple names including a hash that look like internal nonsense, e.g. 'bob34adf@', or block the un-plussed 'bob@' entirely and use e.g. 'robert@' for people you trust to have your real, non-circumstance-specific email address. I know people who do this, it really depends how much you care about being able to trace and block people who are either scraping or re-selling your details. Regards, Tim. From nanog at ics-il.net Tue Jun 20 08:41:13 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 20 Jun 2017 08:41:13 -0500 (CDT) Subject: Vendors spamming NANOG attendees In-Reply-To: <1497965829.578913311@apps.rackspace.com> References: <1497965829.578913311@apps.rackspace.com> Message-ID: <583541363.462.1497966071756.JavaMail.mhammett@ThunderFuck> I'm still not sure people understand the situation. There's an attendee list, but that list doesn't have e-mail addresses. It didn't come from the mailing list. The person looked up who went to the conference and then found their e-mail address elsewhere. I also don't think the above is wrong in any way and people should just get on with their lives. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: tim at pelican.org To: "NANOG" Sent: Tuesday, June 20, 2017 8:37:09 AM Subject: Re: Vendors spamming NANOG attendees On Tuesday, 20 June, 2017 14:26, "Rod Beck" said: > And how do you tell if an address was scraped or not? There are databases and > zillions of other ways of gaining addresses. > > > I doubt you can distinguish the source with any real reliability. Depending on whether you're registered with personal or corporate email, and how much control you have over the platform in question, you can distinguish the source with fairly high reliability. Just generate a new 'bob+nanog70 at bobsdomain.org' style address for every event you register for, every website that requires a contact address, every mailing list, ... If you're concerned that people will twig, and use the naked 'bob@' address, you could work with multiple names including a hash that look like internal nonsense, e.g. 'bob34adf@', or block the un-plussed 'bob@' entirely and use e.g. 'robert@' for people you trust to have your real, non-circumstance-specific email address. I know people who do this, it really depends how much you care about being able to trace and block people who are either scraping or re-selling your details. Regards, Tim. From tim at pelican.org Tue Jun 20 08:46:21 2017 From: tim at pelican.org (tim at pelican.org) Date: Tue, 20 Jun 2017 14:46:21 +0100 (BST) Subject: Vendors spamming NANOG attendees In-Reply-To: <583541363.462.1497966071756.JavaMail.mhammett@ThunderFuck> References: <1497965829.578913311@apps.rackspace.com> <583541363.462.1497966071756.JavaMail.mhammett@ThunderFuck> Message-ID: <1497966381.281729634@apps.rackspace.com> On Tuesday, 20 June, 2017 14:41, "Mike Hammett" said: > I'm still not sure people understand the situation. There's an attendee list, but > that list doesn't have e-mail addresses. It didn't come from the mailing list. The > person looked up who went to the conference and then found their e-mail address > elsewhere. I also don't think the above is wrong in any way and people should just > get on with their lives. Fair point, that's a lot harder to tie back to NANOG (although, of course, if you follow the scheme religiously, you *can* find out where they looked you up :) ) Regards, Tim. From rod.beck at unitedcablecompany.com Tue Jun 20 08:46:43 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 20 Jun 2017 13:46:43 +0000 Subject: Vendors spamming NANOG attendees In-Reply-To: <583541363.462.1497966071756.JavaMail.mhammett@ThunderFuck> References: <1497965829.578913311@apps.rackspace.com>, <583541363.462.1497966071756.JavaMail.mhammett@ThunderFuck> Message-ID: Exactly. But some people enjoy complaining. - R. ________________________________ From: NANOG on behalf of Mike Hammett Sent: Tuesday, June 20, 2017 3:41:13 PM Cc: NANOG Subject: Re: Vendors spamming NANOG attendees I'm still not sure people understand the situation. There's an attendee list, but that list doesn't have e-mail addresses. It didn't come from the mailing list. The person looked up who went to the conference and then found their e-mail address elsewhere. I also don't think the above is wrong in any way and people should just get on with their lives. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: tim at pelican.org To: "NANOG" Sent: Tuesday, June 20, 2017 8:37:09 AM Subject: Re: Vendors spamming NANOG attendees On Tuesday, 20 June, 2017 14:26, "Rod Beck" said: > And how do you tell if an address was scraped or not? There are databases and > zillions of other ways of gaining addresses. > > > I doubt you can distinguish the source with any real reliability. Depending on whether you're registered with personal or corporate email, and how much control you have over the platform in question, you can distinguish the source with fairly high reliability. Just generate a new 'bob+nanog70 at bobsdomain.org' style address for every event you register for, every website that requires a contact address, every mailing list, ... If you're concerned that people will twig, and use the naked 'bob@' address, you could work with multiple names including a hash that look like internal nonsense, e.g. 'bob34adf@', or block the un-plussed 'bob@' entirely and use e.g. 'robert@' for people you trust to have your real, non-circumstance-specific email address. I know people who do this, it really depends how much you care about being able to trace and block people who are either scraping or re-selling your details. Regards, Tim. From baldur.norddahl at gmail.com Tue Jun 20 10:15:06 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 20 Jun 2017 17:15:06 +0200 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: The real question here is: will my NIC support other SFP+ modules than the few options carried by the NIC vendor? For example Intel claims the Intel NICs can only accept SFP+ modules by Intel. They probably do not make optics themselves and only have few options available. And indeed if you put in a third party optic it will be rejected. There are two ways around that. One is finding a device driver with vendor check disabled. The other option is to get optics that pretend to be Intel. You can get optics with vendor ID many places. A good place to start is Fiberstore fs.com because they have public pricing on the website. With the vendor id the answer to the question is that all NICs with SFP+ I ever heard about will support any range, WDM or other special SFP+ module. Regards, Baldur Den 20. jun. 2017 02.59 skrev "chiel" : > Hello, > > We are deploying more and more server based routers (based on BSD). We > have now come to the point where we need to have 10GB uplinks one these > devices and I prefer to plug in a long range 10GB fiber straight into the > server without it going first into a router/switch from vendor x. It seems > to me that all the 10GB PCIe cards only support either copper 10GBASE-T, > short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very few). Are > there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I can't seem > to find any. > > Chiel > From nanog at shankland.org Tue Jun 20 15:26:00 2017 From: nanog at shankland.org (Jim Shankland) Date: Tue, 20 Jun 2017 08:26:00 -0700 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: On 6/20/17 8:15 AM, Baldur Norddahl wrote: > The real question here is: will my NIC support other SFP+ modules than the > few options carried by the NIC vendor? > > For example Intel claims the Intel NICs can only accept SFP+ modules by > Intel. They probably do not make optics themselves and only have few > options available. And indeed if you put in a third party optic it will be > rejected. > The last I looked -- and it's been a few years, so it might no longer be true -- the check for this was in the driver software, which is open-sourced. The check was even guarded by an ifdef so that it was easily disabled. If you disabled the check, you got a hyperventilating syslog warning saying you were taking your life into your hands by using unapproved equipment. That warning could then be ignored while it receded into rotated and, eventually, expunged log history. As I said, that was a few years ago, so would need to be reconfirmed. Jim From cma at cmadams.net Tue Jun 20 15:26:21 2017 From: cma at cmadams.net (Chris Adams) Date: Tue, 20 Jun 2017 10:26:21 -0500 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: <20170620152621.GA28069@cmadams.net> Once upon a time, Baldur Norddahl said: > There are two ways around that. One is finding a device driver with vendor > check disabled. The other option is to get optics that pretend to be Intel. For Linux at least, the standard driver includes a load-time option to disable vendor check. Just add "options ixgbe allow_unsupported_sfp=1" to your module config and it works just fine. "ethtool -m" reads the DOM fine as well (actually shows more info than some router/switch OSes). -- Chris Adams From jk at ip-clear.de Tue Jun 20 15:31:24 2017 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Tue, 20 Jun 2017 17:31:24 +0200 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: Nowadays its just an ixgbe-parameter: parm: allow_unsupported_sfp:Allow unsupported and untested SFP+ modules on 82599-based adapters (uint) Jörg On 20 Jun 2017, at 17:26, Jim Shankland wrote: > The last I looked -- and it's been a few years, so it might no longer > be true -- the check for this was in the driver software, which is > open-sourced. The check was even guarded by an ifdef so that it was > easily disabled. If you disabled the check, you got a hyperventilating > syslog warning saying you were taking your life into your hands by > using unapproved equipment. That warning could then be ignored while > it receded into rotated and, eventually, expunged log history. > > As I said, that was a few years ago, so would need to be reconfirmed. > > Jim From hf0002+nanog at uah.edu Tue Jun 20 15:59:06 2017 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Tue, 20 Jun 2017 15:59:06 +0000 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <20170620152621.GA28069@cmadams.net> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> <20170620152621.GA28069@cmadams.net> Message-ID: On Tue, Jun 20, 2017 at 10:29 AM Chris Adams wrote: > For Linux at least, the standard driver includes a load-time option to > disable vendor check. Just add "options ixgbe allow_unsupported_sfp=1" > to your module config and it works just fine. For anyone who may be going down this road, if you have a two-port Intel NIC, I discovered you have to pass "allow_unsupported_sfp=1,1" or it will only apply to the first port. Hope that helps someone. -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From denys at visp.net.lb Tue Jun 20 16:09:38 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Tue, 20 Jun 2017 19:09:38 +0300 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <5949235B.7020307@netassist.ua> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> <5949235B.7020307@netassist.ua> Message-ID: <56d38257d1b65fa05890a87801ccde9c@visp.net.lb> I guess it depends on NIC, there is many spinoffs of Intel X520 with much weaker power supply circuitry. It might work with good NIC, but you can't rely on it on long term, IMHO. Even 40km Finisar SFP+ has Pdiss 1.5W. Also they mention: "The typical power consumption of the FTLX1672D3BTL may exceed the limit of 1.5W specified for the Power Level II transceivers" If we talk about 80km, Pdiss is 1.8W. While 10GBASE-LR is <1W On 2017-06-20 16:30, Max Tulyev wrote: > We use Intel NICs with SFP+ holes. It works good with long and short > range SFP+ modules, including CWDM/DWDM. > > On 15.06.17 12:10, chiel wrote: >> Hello, >> >> We are deploying more and more server based routers (based on BSD). We >> have now come to the point where we need to have 10GB uplinks one >> these >> devices and I prefer to plug in a long range 10GB fiber straight into >> the server without it going first into a router/switch from vendor x. >> It >> seems to me that all the 10GB PCIe cards only support either copper >> 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only >> very >> few). Are there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? >> I >> can't seem to find any. >> >> Chiel >> From denys at visp.net.lb Tue Jun 20 16:10:42 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Tue, 20 Jun 2017 19:10:42 +0300 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> <20170620152621.GA28069@cmadams.net> Message-ID: <841b5077b2fc94efc83f11252aed049c@visp.net.lb> On 2017-06-20 18:59, Hunter Fuller wrote: > On Tue, Jun 20, 2017 at 10:29 AM Chris Adams wrote: > >> For Linux at least, the standard driver includes a load-time option to >> disable vendor check. Just add "options ixgbe >> allow_unsupported_sfp=1" >> to your module config and it works just fine. > > > For anyone who may be going down this road, if you have a two-port > Intel > NIC, I discovered you have to pass "allow_unsupported_sfp=1,1" or it > will > only apply to the first port. Hope that helps someone. Also it wont work with X710, you need to do NVRAM hack for it, SFP are checked in firmware. From baldur.norddahl at gmail.com Tue Jun 20 19:07:21 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 20 Jun 2017 21:07:21 +0200 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <56d38257d1b65fa05890a87801ccde9c@visp.net.lb> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> <5949235B.7020307@netassist.ua> <56d38257d1b65fa05890a87801ccde9c@visp.net.lb> Message-ID: I would expect anything mounted in a computer to have all the power you could want. It is not like the ATX power supply cares about an extra watt or two. As I understand the issue it is more about cooling than power and is primarly a concern in high density switches were you could have 48 or more to power and cool. Den 20. jun. 2017 18.09 skrev "Denys Fedoryshchenko" : > I guess it depends on NIC, there is many spinoffs of Intel X520 with much > weaker power supply circuitry. > It might work with good NIC, but you can't rely on it on long term, IMHO. > Even 40km Finisar SFP+ has Pdiss 1.5W. Also they mention: "The typical > power consumption of the FTLX1672D3BTL may exceed the limit of 1.5W > specified for the Power Level II transceivers" > If we talk about 80km, Pdiss is 1.8W. > While 10GBASE-LR is <1W > > On 2017-06-20 16:30, Max Tulyev wrote: > >> We use Intel NICs with SFP+ holes. It works good with long and short >> range SFP+ modules, including CWDM/DWDM. >> >> On 15.06.17 12:10, chiel wrote: >> >>> Hello, >>> >>> We are deploying more and more server based routers (based on BSD). We >>> have now come to the point where we need to have 10GB uplinks one these >>> devices and I prefer to plug in a long range 10GB fiber straight into >>> the server without it going first into a router/switch from vendor x. It >>> seems to me that all the 10GB PCIe cards only support either copper >>> 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very >>> few). Are there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I >>> can't seem to find any. >>> >>> Chiel >>> >>> From denys at visp.net.lb Tue Jun 20 20:24:37 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Tue, 20 Jun 2017 23:24:37 +0300 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> <5949235B.7020307@netassist.ua> <56d38257d1b65fa05890a87801ccde9c@visp.net.lb> Message-ID: On 2017-06-20 22:07, Baldur Norddahl wrote: > I would expect anything mounted in a computer to have all the power you > could want. It is not like the ATX power supply cares about an extra > watt > or two. > > As I understand the issue it is more about cooling than power and is > primarly a concern in high density switches were you could have 48 or > more > to power and cool. SFP needs 3.3V, it might be supplied from regulator on the card or directly PCI-Express, can't be absolutely sure, in reference design it is just 3.3V_NIA and then filter, also reference design SFP power circuit define max 750mA/3.3V max to SFP, thats only 2.475W. FTLX1471D3BCV (10km SM) - up to 285mA FTLX1671D3BCL (40km SM) - up to 400mA, and thumb rule in electronics it is better to not exceed 50% of max specs of designed max current, as for many parts it is stated for 25C & etc operating conditions. I expect it might work, but noone knows how long, and how reliable, if it is not cooled very well. And 82599 sensitive to cooling(it is very old card after all), as soon as it is not enough, it starts to glitch. > > > Den 20. jun. 2017 18.09 skrev "Denys Fedoryshchenko" > : > >> I guess it depends on NIC, there is many spinoffs of Intel X520 with >> much >> weaker power supply circuitry. >> It might work with good NIC, but you can't rely on it on long term, >> IMHO. >> Even 40km Finisar SFP+ has Pdiss 1.5W. Also they mention: "The typical >> power consumption of the FTLX1672D3BTL may exceed the limit of 1.5W >> specified for the Power Level II transceivers" >> If we talk about 80km, Pdiss is 1.8W. >> While 10GBASE-LR is <1W >> >> On 2017-06-20 16:30, Max Tulyev wrote: >> >>> We use Intel NICs with SFP+ holes. It works good with long and short >>> range SFP+ modules, including CWDM/DWDM. >>> >>> On 15.06.17 12:10, chiel wrote: >>> >>>> Hello, >>>> >>>> We are deploying more and more server based routers (based on BSD). >>>> We >>>> have now come to the point where we need to have 10GB uplinks one >>>> these >>>> devices and I prefer to plug in a long range 10GB fiber straight >>>> into >>>> the server without it going first into a router/switch from vendor >>>> x. It >>>> seems to me that all the 10GB PCIe cards only support either copper >>>> 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only >>>> very >>>> few). Are there any PCIe cards that support 10GBASE-ER and >>>> 10GBASE-ZR? I >>>> can't seem to find any. >>>> >>>> Chiel >>>> >>>> From mike at sentex.net Tue Jun 20 20:28:46 2017 From: mike at sentex.net (Mike Tancsa) Date: Tue, 20 Jun 2017 16:28:46 -0400 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: On 6/15/2017 5:10 AM, chiel wrote: > the server without it going first into a router/switch from vendor x. It > seems to me that all the 10GB PCIe cards only support either copper > 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very > few). Are there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I > can't seem to find any. The chelsio 10G (T420 and T520) cards seem to support a wide variety. I only have a couple of LR SFPs. Not sure about longer distances but they seem to support every SFP I have tried in them. They are relatively inexpensive. Perhaps give it a try and see ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From baldur.norddahl at gmail.com Tue Jun 20 20:44:58 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 20 Jun 2017 22:44:58 +0200 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> <5949235B.7020307@netassist.ua> <56d38257d1b65fa05890a87801ccde9c@visp.net.lb> Message-ID: But what foundation do you have for asserting that switch hardware is any different in this regard? I can say that we are using 80 km modules in various hardware without any issues. I admittedly do not use any high power modules in servers, but I will need better evidence than this to assume that it would not work just fine. Den 20. jun. 2017 22.24 skrev "Denys Fedoryshchenko" : On 2017-06-20 22:07, Baldur Norddahl wrote: > I would expect anything mounted in a computer to have all the power you > could want. It is not like the ATX power supply cares about an extra watt > or two. > > As I understand the issue it is more about cooling than power and is > primarly a concern in high density switches were you could have 48 or more > to power and cool. > SFP needs 3.3V, it might be supplied from regulator on the card or directly PCI-Express, can't be absolutely sure, in reference design it is just 3.3V_NIA and then filter, also reference design SFP power circuit define max 750mA/3.3V max to SFP, thats only 2.475W. FTLX1471D3BCV (10km SM) - up to 285mA FTLX1671D3BCL (40km SM) - up to 400mA, and thumb rule in electronics it is better to not exceed 50% of max specs of designed max current, as for many parts it is stated for 25C & etc operating conditions. I expect it might work, but noone knows how long, and how reliable, if it is not cooled very well. And 82599 sensitive to cooling(it is very old card after all), as soon as it is not enough, it starts to glitch. > > Den 20. jun. 2017 18.09 skrev "Denys Fedoryshchenko" : > > I guess it depends on NIC, there is many spinoffs of Intel X520 with much >> weaker power supply circuitry. >> It might work with good NIC, but you can't rely on it on long term, IMHO. >> Even 40km Finisar SFP+ has Pdiss 1.5W. Also they mention: "The typical >> power consumption of the FTLX1672D3BTL may exceed the limit of 1.5W >> specified for the Power Level II transceivers" >> If we talk about 80km, Pdiss is 1.8W. >> While 10GBASE-LR is <1W >> >> On 2017-06-20 16:30, Max Tulyev wrote: >> >> We use Intel NICs with SFP+ holes. It works good with long and short >>> range SFP+ modules, including CWDM/DWDM. >>> >>> On 15.06.17 12:10, chiel wrote: >>> >>> Hello, >>>> >>>> We are deploying more and more server based routers (based on BSD). We >>>> have now come to the point where we need to have 10GB uplinks one these >>>> devices and I prefer to plug in a long range 10GB fiber straight into >>>> the server without it going first into a router/switch from vendor x. It >>>> seems to me that all the 10GB PCIe cards only support either copper >>>> 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very >>>> few). Are there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I >>>> can't seem to find any. >>>> >>>> Chiel >>>> >>>> >>>> From denys at visp.net.lb Tue Jun 20 21:07:39 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 21 Jun 2017 00:07:39 +0300 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> <5949235B.7020307@netassist.ua> <56d38257d1b65fa05890a87801ccde9c@visp.net.lb> Message-ID: <45058675603762696050ded93c7752e4@nuclearcat.com> On 2017-06-20 23:44, Baldur Norddahl wrote: > But what foundation do you have for asserting that switch hardware is > any > different in this regard? I can say that we are using 80 km modules in > various hardware without any issues. I admittedly do not use any high > power > modules in servers, but I will need better evidence than this to assume > that it would not work just fine. For switches i guess it is same story as for PoE on them - total power budget matters. So if you will pack whole EX4500 with 10G 80km SFP+ it might have problems as well, but for normal use, and if few only are "long distance/high power", at any case 3.3V supply rail by design in switch should handle many SFP, so if there is 48 ports, it should handle by specs at least 72W peak load. It might be multiple power rails for groups of ports, but still, much better than just 750mA on network card. But that's just guessing, i never seen circuit diagrams of good switches, or at least reference design, as it is all NDA material. > > > Den 20. jun. 2017 22.24 skrev "Denys Fedoryshchenko" > : > > On 2017-06-20 22:07, Baldur Norddahl wrote: > >> I would expect anything mounted in a computer to have all the power >> you >> could want. It is not like the ATX power supply cares about an extra >> watt >> or two. >> >> As I understand the issue it is more about cooling than power and is >> primarly a concern in high density switches were you could have 48 or >> more >> to power and cool. >> > SFP needs 3.3V, it might be supplied from regulator on the card or > directly > PCI-Express, > can't be absolutely sure, in reference design it is just 3.3V_NIA and > then > filter, > also reference design SFP power circuit define max 750mA/3.3V max to > SFP, > thats only 2.475W. > > FTLX1471D3BCV (10km SM) - up to 285mA > FTLX1671D3BCL (40km SM) - up to 400mA, and thumb rule in electronics it > is > better to not exceed 50% > of max specs of designed max current, as for many parts it is stated > for > 25C & etc operating conditions. > > I expect it might work, but noone knows how long, and how reliable, if > it > is not cooled very well. > And 82599 sensitive to cooling(it is very old card after all), as soon > as > it is not enough, it starts to glitch. > > > >> >> Den 20. jun. 2017 18.09 skrev "Denys Fedoryshchenko" >> : >> >> I guess it depends on NIC, there is many spinoffs of Intel X520 with >> much >>> weaker power supply circuitry. >>> It might work with good NIC, but you can't rely on it on long term, >>> IMHO. >>> Even 40km Finisar SFP+ has Pdiss 1.5W. Also they mention: "The >>> typical >>> power consumption of the FTLX1672D3BTL may exceed the limit of 1.5W >>> specified for the Power Level II transceivers" >>> If we talk about 80km, Pdiss is 1.8W. >>> While 10GBASE-LR is <1W >>> >>> On 2017-06-20 16:30, Max Tulyev wrote: >>> >>> We use Intel NICs with SFP+ holes. It works good with long and short >>>> range SFP+ modules, including CWDM/DWDM. >>>> >>>> On 15.06.17 12:10, chiel wrote: >>>> >>>> Hello, >>>>> >>>>> We are deploying more and more server based routers (based on BSD). >>>>> We >>>>> have now come to the point where we need to have 10GB uplinks one >>>>> these >>>>> devices and I prefer to plug in a long range 10GB fiber straight >>>>> into >>>>> the server without it going first into a router/switch from vendor >>>>> x. It >>>>> seems to me that all the 10GB PCIe cards only support either copper >>>>> 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only >>>>> very >>>>> few). Are there any PCIe cards that support 10GBASE-ER and >>>>> 10GBASE-ZR? I >>>>> can't seem to find any. >>>>> >>>>> Chiel >>>>> >>>>> >>>>> From marka at isc.org Tue Jun 20 23:05:01 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 21 Jun 2017 09:05:01 +1000 Subject: Vendors spamming NANOG attendees In-Reply-To: Your message of "Tue, 20 Jun 2017 08:41:13 -0500." <583541363.462.1497966071756.JavaMail.mhammett@ThunderFuck> References: <1497965829.578913311@apps.rackspace.com> <583541363.462.1497966071756.JavaMail.mhammett@ThunderFuck> Message-ID: <20170620230501.7B6547BF9000@rock.dv.isc.org> In message <583541363.462.1497966071756.JavaMail.mhammett at ThunderFuck>, Mike Ha mmett writes: > I'm still not sure people understand the situation. There's an attendee > list, but that list doesn't have e-mail addresses. It didn't come from > the mailing list. The person looked up who went to the conference and > then found their e-mail address elsewhere. I also don't think the above > is wrong in any way and people should just get on with their lives. When will the US get sane anti-spam laws. No, I don't expect a answer. That behaviour here is illegal. Any Australian company / individual that does this can be fined regardless of where the email is sent from in the world or which third party they hire to do it. If you send to a Australian email address you can also be fined, provided you know it is a Australian address, as you are implicitly doing business in Australia. Remember you are choosing to do business with Australia when you send the email. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From james.braunegg at micron21.com Tue Jun 20 23:12:45 2017 From: james.braunegg at micron21.com (James Braunegg) Date: Tue, 20 Jun 2017 23:12:45 +0000 Subject: Long AS Path Message-ID: Dear All Just wondering if anyone else saw this yesterday afternoon ? Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH= AS_SEQ(2) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (567) More than configured MAXAS-LIMIT Jun 20 16:15:26:E:BGP: From Peer 78.X.X.X received Long AS_PATH= AS_SEQ(2) 5580 3257 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (568) More than configured MAXAS-LIMIT Someone is having fun, creating weird and wonderful long AS paths based around AS 23456, we saw the same pattern of data from numerous upstream providers. Kindest Regards, James Braunegg [cid:image001.png at 01D280A4.01865B60] 1300 769 972 / 0488 997 207 james at micron21.com www.micron21.com/ [cid:image002.png at 01D280A4.01865B60] [cid:image003.png at 01D280A4.01865B60] [cid:image004.png at 01D280A4.01865B60] Follow us on Twitter for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. From goemon at sasami.anime.net Tue Jun 20 23:17:18 2017 From: goemon at sasami.anime.net (Dan Hollis) Date: Tue, 20 Jun 2017 16:17:18 -0700 (PDT) Subject: Vendors spamming NANOG attendees In-Reply-To: References: , Message-ID: On Tue, 20 Jun 2017, Rod Beck wrote: > And how do you tell if an address was scraped or not? There are databases and zillions of other ways of gaining addresses. One-off addresses. I've used it numerous times to catch the origin, companies like Roland Corporation either leaking databases or selling to spammers. -Dan From surfer at mauigateway.com Tue Jun 20 23:23:25 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 20 Jun 2017 16:23:25 -0700 Subject: Vendors spamming NANOG attendees Message-ID: <20170620162325.C6AC36CC@m0117458.ppops.net> --- nanog at nanog.org wrote: From: i mawsog via NANOG :: Agree, this thread has generated more "spam" or noise :: for all of us collectively.  It's not spam. Look up the definition of spam. Also, just block the thread in your email client. :: Some amount of relevant "spam"  has to be tolerated for :: vendor to continue supporting NANOG. No, that is absolutely wrong! :: Also relevant "spam" or sales call is a good way to find :: out about new technologies , that one may not have heard :: about otherwise. No, wrong again. One of the most attractive things about NANOG is learning these things from **peers**, not spam. :: Another tip, just ignore,  the "spammer" will go away :: eventually.   If they're not named-n-shamed they will continue. I have had quite a few go after me aggressively to sell me something after a NANOG post. They didn't stop until I named-n-shamed them. Their supervisors wrote me, personally apologized and, due to that, I put their companies back on my list of companies to do business with. I write this not just to you, but as an explanation to other new folks why the old schoolers name-n-shame. scott From olivier.benghozi at wifirst.fr Tue Jun 20 23:33:07 2017 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Wed, 21 Jun 2017 01:33:07 +0200 Subject: Long AS Path In-Reply-To: References: Message-ID: Yes, we had this kind of stuff in our logs: Jun 20 08:15:25 cr-co-01-pareq2-re0 rpd[9656]: %DAEMON-3: Prefix Send failed ! x:x:186.177.176.0/23 (label 19) bgp_rt_trace_too_big_message:1213 path attribute too big. Cannot build update. The AS path we have here is currently 12956 262206 262206 262197... > On 21 june 2017 at 01:12, James Braunegg wrote : > > Just wondering if anyone else saw this yesterday afternoon ? > > Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH= AS_SEQ(2) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (567) More than configured MAXAS-LIMIT > > Someone is having fun, creating weird and wonderful long AS paths based around AS 23456, we saw the same pattern of data from numerous upstream providers. From randy at psg.com Tue Jun 20 23:34:16 2017 From: randy at psg.com (Randy Bush) Date: Wed, 21 Jun 2017 08:34:16 +0900 Subject: mailops https breakage In-Reply-To: References: <20160827012542.43353.qmail@ary.lan> <20160828014627.GE4869@hezmatt.org> Message-ID: > Fun fact about letsencrypt certs, they expire after a month or so. 90 days From laszlo at heliacal.net Tue Jun 20 23:52:09 2017 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Tue, 20 Jun 2017 23:52:09 +0000 Subject: Long AS Path In-Reply-To: References: Message-ID: <10cb9cf3-f78a-0e98-bbba-5076e1594236@heliacal.net> On 2017-06-20 23:12, James Braunegg wrote: > Dear All > > Just wondering if anyone else saw this yesterday afternoon ? > > Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH= AS_SEQ(2) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (567) More than configured MAXAS-LIMIT > > Jun 20 16:15:26:E:BGP: From Peer 78.X.X.X received Long AS_PATH= AS_SEQ(2) 5580 3257 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (568) More than configured MAXAS-LIMIT > > Someone is having fun, creating weird and wonderful long AS paths based around AS 23456, we saw the same pattern of data from numerous upstream providers. > > Kindest Regards, > > James Braunegg > > > > [cid:image001.png at 01D280A4.01865B60] > > 1300 769 972 / 0488 997 207 > > james at micron21.com > > www.micron21.com/ > > > [cid:image002.png at 01D280A4.01865B60] > > > [cid:image003.png at 01D280A4.01865B60] > > [cid:image004.png at 01D280A4.01865B60] > > Follow us on Twitter for important service and system updates. > > > This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. > > > > Could be this: http://blog.ipspace.net/2009/02/root-cause-analysis-oversized-as-paths.html From kmedcalf at dessus.com Tue Jun 20 23:57:45 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 20 Jun 2017 17:57:45 -0600 Subject: mailops https breakage In-Reply-To: Message-ID: <3b120f83b051204cbf59a3ae039d8f7a@mail.dessus.com> How else would one maintain government control over free encryption certificates? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush > Sent: Tuesday, 20 June, 2017 17:34 > To: Edwin Pers > Cc: NANOG list > Subject: Re: mailops https breakage > > > Fun fact about letsencrypt certs, they expire after a month or so. > > 90 days From randy at psg.com Wed Jun 21 00:00:09 2017 From: randy at psg.com (Randy Bush) Date: Wed, 21 Jun 2017 09:00:09 +0900 Subject: mailops https breakage In-Reply-To: <3b120f83b051204cbf59a3ae039d8f7a@mail.dessus.com> References: <3b120f83b051204cbf59a3ae039d8f7a@mail.dessus.com> Message-ID: > How else would one maintain government control over free encryption > certificates? black helicopters From sethm at rollernet.us Wed Jun 21 00:04:55 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 20 Jun 2017 17:04:55 -0700 Subject: mailops https breakage In-Reply-To: <3b120f83b051204cbf59a3ae039d8f7a@mail.dessus.com> References: <3b120f83b051204cbf59a3ae039d8f7a@mail.dessus.com> Message-ID: On 6/20/17 16:57, Keith Medcalf wrote: > How else would one maintain government control over free encryption certificates? So Let's Encrypt is run by the Illuminati now? Or is it Freemasons? It's hard to keep track. From cook at cookreport.com Wed Jun 21 00:49:14 2017 From: cook at cookreport.com (Gordon Cook) Date: Tue, 20 Jun 2017 20:49:14 -0400 Subject: Google Cloud and IX - Traffic behavior In-Reply-To: <0a58f4fe-8e77-cb9e-fa20-c4732ec6593c@pubnix.net> References: <0a58f4fe-8e77-cb9e-fa20-c4732ec6593c@pubnix.net> Message-ID: Hi Alain and all the rest I het it now no offense and alain no harm done and all of nanog thank you and i will continue observing as i have since 1995 thank you allagin PS and BTW i am interested in CLOUD :-) thanks once more > On Jun 19, 2017, at 9:36 AM, Alain Hebert wrote: > > Hi, > > Yes Stephen, we're talking the usual like GTT... > > And no latency wise they're about the same. In the 35ms range. > > But I still can't figure out the 10 x drop, that level of latency alone cannot be the factor. > > ( And Gordy... what?!? ) > > ----- > 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 06/16/17 19:42, Stephen Fulton wrote: >> Alain, >> >> When you refer to "normal peering" do you mean Internet transit? Or are these PNI's with Google? Do the GCLD instance you reach through "normal peering" have higher latency than through TorIX? >> >> -- Stephen >> >> On 2017-06-16 6:58 PM, Alain Hebert wrote: >>> Hi, >>> >>> Anyone aware of different traffic behavior depending if the target goes through normal peering than through an exchanges google exists in? >>> >>> We're facing a weird issue where the same GCLD Instance can upload up to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but cannot get more than 20Mbps on similar hosts (8 of them) sittings on our peering links. >>> >>> PS; Those sames hosts get up to their link limit ( 1Gbps ) between each others and others test points we have; >>> >>> PS: Wireshark capture show nothing abnormal; >>> >>> PS: Links aren't congested, and so on... >>> >>> Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only test point with a TorIX access >>> >> > > From jay at west.net Wed Jun 21 05:28:19 2017 From: jay at west.net (Jay Hennigan) Date: Tue, 20 Jun 2017 22:28:19 -0700 Subject: Vendors spamming NANOG attendees In-Reply-To: <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> Message-ID: On 6/13/17 8:31 AM, Mel Beckman wrote: > I would hardly call this a flood. But my point is that most people posting to NANOG, being technical people, respond to notifications that they are spamming. Your example email illustrates this perfectly. Sometimes they're ignorant and don't realize they're spamming. This guy definitely knew he was spamming and didn't care. "We do not know each other. I'm leveraging the attendee list for NANOG...." And he didn't even attend, though someone from his company did. > If they're persistent they get removed from the list This isn't about spam to this list, it's about spammers scraping the attendee lists and spamming them directly. > I made my suggestion. Shoot them at dawn? I kind of like that idea. +1. Guillotine, however, makes heads on pikes as a deterrent less messy. > What's yours? Name and shame. As Rodney did. Maybe seed the attendee lists with a spamtrap or two and publicly out the abusers on the NANOG website. Very few of them will openly brag about spamming the list as Glenn Stern (gstern at calient.net) did. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jay at west.net Wed Jun 21 05:38:58 2017 From: jay at west.net (Jay Hennigan) Date: Tue, 20 Jun 2017 22:38:58 -0700 Subject: Vendors spamming NANOG attendees In-Reply-To: <995439918.1893.1497387369860.JavaMail.mhammett@ThunderFuck> References: <5005117F-2EA8-44DE-A303-A2005DD2CF7E@centergate.com> <1CFA0A13-7AFE-4489-B9EB-35DB0403E74D@beckman.org> <20170613171207.GA13643@gsp.org> <38E506A8-247A-478F-9C4D-21602BEE6028@beckman.org> <20170613204702.GA29482@gsp.org> <995439918.1893.1497387369860.JavaMail.mhammett@ThunderFuck> Message-ID: On 6/13/17 1:56 PM, Mike Hammett wrote: > I think it would too subject to wild variance in what someone views as bad. > > Actual SPAM (viagra, Nigerian prices, etc.), of course. > Industry-related SPAM, probably. > Targeted marketing (looking for someone at Facebook, seeing someone from Facebook and tracking them down... or seeing someone at someone in a specific area or...) ehh, probably not "Targeted marketing" is spam. The NANOG attendee list is a target. Downtown Fallujah was a target. As a rule, being targeted is shortly followed by being fired upon. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From swmike at swm.pp.se Wed Jun 21 05:40:13 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 21 Jun 2017 07:40:13 +0200 (CEST) Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <45058675603762696050ded93c7752e4@nuclearcat.com> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> <5949235B.7020307@netassist.ua> <56d38257d1b65fa05890a87801ccde9c@visp.net.lb> <45058675603762696050ded93c7752e4@nuclearcat.com> Message-ID: On Wed, 21 Jun 2017, Denys Fedoryshchenko wrote: > For switches i guess it is same story as for PoE on them - total power > budget matters. So if you will pack whole EX4500 with 10G 80km SFP+ it > might have problems as well, but for normal use, and if few only are > "long distance/high power", at any case 3.3V supply rail by design in > switch should handle many SFP, so if there is 48 ports, it should handle > by specs at least 72W peak load. It might be multiple power rails for > groups of ports, but still, much better than just 750mA on network card. > But that's just guessing, i never seen circuit diagrams of good > switches, or at least reference design, as it is all NDA material. Several of the limitations in switches/routers comes out to cooling, especially since there is a requirement for normal operation in case of failed climate control with ambient temp in the 40-50C range. -- Mikael Abrahamsson email: swmike at swm.pp.se From jay at west.net Wed Jun 21 05:45:00 2017 From: jay at west.net (Jay Hennigan) Date: Tue, 20 Jun 2017 22:45:00 -0700 Subject: Vendors spamming NANOG attendees In-Reply-To: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> Message-ID: <679a72a7-bb51-d32b-ced8-df96f50ecf22@west.net> On 6/13/17 10:28 PM, Mel Beckman wrote: > But as I said, harvesting emails is not illegal under can spam. And the requirement to not send you UCE to harvested emails is pointless, because how do you prove that someone did that? Seed the list with one or two spamtrap addresses never seen in the wild. Wait. In this case, the spammer was stupid enough hot only to abuse a list of technical people who run networks, but to brag about it within the body of the spam. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jwbensley at gmail.com Wed Jun 21 07:35:33 2017 From: jwbensley at gmail.com (James Bensley) Date: Wed, 21 Jun 2017 08:35:33 +0100 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: <841b5077b2fc94efc83f11252aed049c@visp.net.lb> References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> <20170620152621.GA28069@cmadams.net> <841b5077b2fc94efc83f11252aed049c@visp.net.lb> Message-ID: On 20 June 2017 at 17:10, Denys Fedoryshchenko wrote: > On 2017-06-20 18:59, Hunter Fuller wrote: >> >> On Tue, Jun 20, 2017 at 10:29 AM Chris Adams wrote: >> >>> For Linux at least, the standard driver includes a load-time option to >>> disable vendor check. Just add "options ixgbe allow_unsupported_sfp=1" >>> to your module config and it works just fine. >> >> For anyone who may be going down this road, if you have a two-port Intel >> NIC, I discovered you have to pass "allow_unsupported_sfp=1,1" or it will >> only apply to the first port. Hope that helps someone. > > Also it wont work with X710, you need to do NVRAM hack for it, SFP are > checked in firmware. We have third party SFPs in X710 "based" NIC. To be exact we some HPE servers which have a "HPE Ethernet 10Gb 2-port 562SFP+ Adapter" which uses an OEM X710 controller branded as HP. So it maybe that the HP SoC on the NIC is allowing us to use any SFP. We haven't added any kernel module load parameters to make that work or NVRAM hacks, we just flashed the NIC to the lasted firmware version upon arrival as a general good practice move and compiled the latest i40e & i40evf drivers. We have third party 10G SFP+'s (single more / 10Km / LC) working and 1G copper SFPs too, the ports are multi-rate. Again this may be something special about the HP NIC and the X710 controller is ignorant of the PHY <> MAC conversation or something. Cheers, James. From sthaug at nethelp.no Wed Jun 21 07:56:26 2017 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 21 Jun 2017 09:56:26 +0200 (CEST) Subject: Long AS Path In-Reply-To: References: Message-ID: <20170621.095626.74671742.sthaug@nethelp.no> > Just wondering if anyone else saw this yesterday afternoon ? > > Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH=3D AS_SEQ(2= > ) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 234= > 56 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 = > 23456 23456 23456 23456 23456 ... attribute length (567) More than configur= > ed MAXAS-LIMIT There are quite a few examples of people using stupidly long AS paths. For instance 177.23.232.0/24 *[BGP/170] 00:52:40, MED 0, localpref 105 AS path: 6939 16735 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262949 52938 52938 52938 52938 52938 52938 52938 52938 52938 52938 52938 I I currently have 27 prefixes in my Internet routing table with 40 or more ASes in the AS path (show route aspath-regex ".{40,}"). I see no valid reason for such long AS paths. Time to update filters here. I'm tempted to set the cutoff at 30 - can anybody see a good reason to permit longer AS paths? Steinar Haug, Nethelp consulting, sthaug at nethelp.no From EPers at ansencorp.com Wed Jun 21 11:46:50 2017 From: EPers at ansencorp.com (Edwin Pers) Date: Wed, 21 Jun 2017 11:46:50 +0000 Subject: mailops https breakage In-Reply-To: References: <3b120f83b051204cbf59a3ae039d8f7a@mail.dessus.com> Message-ID: Both. Either. Take your pick Ed Pers From: Seth Mattinen Sent: Tuesday, June 20, 8:06 PM Subject: Re: mailops https breakage To: nanog at nanog.org On 6/20/17 16:57, Keith Medcalf wrote: > How else would one maintain government control over free encryption certificates? So Let's Encrypt is run by the Illuminati now? Or is it Freemasons? It's hard to keep track. From randy at psg.com Wed Jun 21 12:27:57 2017 From: randy at psg.com (Randy Bush) Date: Wed, 21 Jun 2017 21:27:57 +0900 Subject: Long AS Path In-Reply-To: <20170621.095626.74671742.sthaug@nethelp.no> References: <20170621.095626.74671742.sthaug@nethelp.no> Message-ID: > 177.23.232.0/24 *[BGP/170] 00:52:40, MED 0, localpref 105 ... > ... > I see no valid reason for such long AS paths. [ assuming it is not the microtik thing ] the /24 can not be sliced to steer inbound, so they're desperately trying to push it away with prepend. of course, their upstreams all prefer customers, so they keep adding prepends in some vain hope. randy From list at satchell.net Wed Jun 21 12:31:51 2017 From: list at satchell.net (Stephen Satchell) Date: Wed, 21 Jun 2017 05:31:51 -0700 Subject: Long AS Path In-Reply-To: <20170621.095626.74671742.sthaug@nethelp.no> References: <20170621.095626.74671742.sthaug@nethelp.no> Message-ID: On 06/21/2017 12:56 AM, sthaug at nethelp.no wrote: > I see no valid reason for such long AS paths. Time to update filters > here. I'm tempted to set the cutoff at 30 - can anybody see a good > reason to permit longer AS paths? > Well, as I mentioned in my Net Neutrality filing to the FCC, a TTL of 30 is OK for intra-planet routing, but when you start leaving the big blue marble you will need to allow the packets to live longer. Your network, your decisions From ahebert at pubnix.net Wed Jun 21 12:41:17 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 21 Jun 2017 08:41:17 -0400 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: <0bdbbc1c-7e46-2a02-012e-b702d943af0c@pubnix.net> Hi, Remember to check the power available to the XFP/SFP+. Its the most common issue related with achievable distance. We worked with optic.ca to figured out that type of issue with some extreme network gear and after a few "patches" to the XGm board, it's been stable since. ----- 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 06/20/17 03:54, Mikael Abrahamsson wrote: > On Thu, 15 Jun 2017, chiel wrote: > >> Hello, >> >> We are deploying more and more server based routers (based on BSD). >> We have now come to the point where we need to have 10GB uplinks one >> these devices and I prefer to plug in a long range 10GB fiber >> straight into the server without it going first into a router/switch >> from vendor x. It seems to me that all the 10GB PCIe cards only >> support either copper 10GBASE-T, short range 10GBASE-SR or the 10 Km >> 10GBASE-LR (but only very few). Are there any PCIe cards that support >> 10GBASE-ER and 10GBASE-ZR? I can't seem to find any. > > The Intel XF SR2 card actually has XFPs and I have LR optics in one > here. I don't see any reason it wouldn't support ER or ZR as well. > From sthaug at nethelp.no Wed Jun 21 12:42:13 2017 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 21 Jun 2017 14:42:13 +0200 (CEST) Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> Message-ID: <20170621.144213.74665620.sthaug@nethelp.no> > > I see no valid reason for such long AS paths. Time to update filters > > here. I'm tempted to set the cutoff at 30 - can anybody see a good > > reason to permit longer AS paths? > > Well, as I mentioned in my Net Neutrality filing to the FCC, a TTL of 30 > is OK for intra-planet routing, but when you start leaving the big blue > marble you will need to allow the packets to live longer. TTL != AS path length I can certainly see the use for a TTL of 30. I cannot see the use for an AS path length greater than 30 (especially not when 2 ASes are each repeated 16 times). Steinar Haug, Nethelp consulting, sthaug at nethelp.no From josh at imaginenetworksllc.com Wed Jun 21 13:25:59 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 21 Jun 2017 09:25:59 -0400 Subject: Vendors spamming NANOG attendees In-Reply-To: <679a72a7-bb51-d32b-ced8-df96f50ecf22@west.net> References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> <679a72a7-bb51-d32b-ced8-df96f50ecf22@west.net> Message-ID: Does anyone else feel this thread has generated more spam in their inbox than the vendors? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 21, 2017 at 1:45 AM, Jay Hennigan wrote: > On 6/13/17 10:28 PM, Mel Beckman wrote: > >> But as I said, harvesting emails is not illegal under can spam. And the >> requirement to not send you UCE to harvested emails is pointless, because >> how do you prove that someone did that? >> > Seed the list with one or two spamtrap addresses never seen in the wild. > Wait. > > In this case, the spammer was stupid enough hot only to abuse a list of > technical people who run networks, but to brag about it within the body of > the spam. > > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From gdupin at taho.fr Wed Jun 21 13:38:28 2017 From: gdupin at taho.fr (Ge Dupin) Date: Wed, 21 Jun 2017 15:38:28 +0200 Subject: Vendors spamming NANOG attendees In-Reply-To: References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> <679a72a7-bb51-d32b-ced8-df96f50ecf22@west.net> Message-ID: <92E18798-976B-4965-8F7A-7E804ED591BA@taho.fr> I think so And I said it a coulpe of times already Ge > Le 21 juin 2017 à 15:25, Josh Luthman a écrit : > > Does anyone else feel this thread has generated more spam in their inbox > than the vendors? > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Wed, Jun 21, 2017 at 1:45 AM, Jay Hennigan wrote: > >> On 6/13/17 10:28 PM, Mel Beckman wrote: >> >>> But as I said, harvesting emails is not illegal under can spam. And the >>> requirement to not send you UCE to harvested emails is pointless, because >>> how do you prove that someone did that? >>> >> Seed the list with one or two spamtrap addresses never seen in the wild. >> Wait. >> >> In this case, the spammer was stupid enough hot only to abuse a list of >> technical people who run networks, but to brag about it within the body of >> the spam. >> >> >> -- >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >> Impulse Internet Service - http://www.impulse.net/ >> Your local telephone and internet company - 805 884-6323 - WB6RDV >> From beecher at beecher.cc Wed Jun 21 15:09:34 2017 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 21 Jun 2017 11:09:34 -0400 Subject: Vendors spamming NANOG attendees In-Reply-To: References: <63CD2031-701D-4567-B88A-2986E8B3F359@beckman.org> <679a72a7-bb51-d32b-ced8-df96f50ecf22@west.net> Message-ID: I was just thinking that as I caught up on the thread. I ignore unsolicited sales contacts as a general rule. If they persist to the point of annoyance, I'll kindly advise them that I'm not interested, and ask they cease. If they still persist, I'll drop out the 'I'll never do business with you, and will start advising my peers not to do so either.' It's very rare things ever get that far. Just ignore it. Or if you're feeling saucy, go full on '419 Eater' on them and burn up as much of their time as possible. I have no ethical issues about wasting someone's time after they've been asked politely not to waste mine. On Wed, Jun 21, 2017 at 9:25 AM, Josh Luthman wrote: > Does anyone else feel this thread has generated more spam in their inbox > than the vendors? > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Wed, Jun 21, 2017 at 1:45 AM, Jay Hennigan wrote: > > > On 6/13/17 10:28 PM, Mel Beckman wrote: > > > >> But as I said, harvesting emails is not illegal under can spam. And the > >> requirement to not send you UCE to harvested emails is pointless, > because > >> how do you prove that someone did that? > >> > > Seed the list with one or two spamtrap addresses never seen in the wild. > > Wait. > > > > In this case, the spammer was stupid enough hot only to abuse a list of > > technical people who run networks, but to brag about it within the body > of > > the spam. > > > > > > -- > > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > > Impulse Internet Service - http://www.impulse.net/ > > Your local telephone and internet company - 805 884-6323 - WB6RDV > > > From beecher at beecher.cc Wed Jun 21 15:12:24 2017 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 21 Jun 2017 11:12:24 -0400 Subject: Google Cloud and IX - Traffic behavior In-Reply-To: References: <0a58f4fe-8e77-cb9e-fa20-c4732ec6593c@pubnix.net> Message-ID: Just did a quick test from a personal VM, no throughput difference over direct peering, public IX, or transit. GCP might have a bottleneck in your case though, might be a good idea to ask them. Also, I'll have what Gordon is having. On Tue, Jun 20, 2017 at 8:49 PM, Gordon Cook wrote: > > > Hi Alain and all the rest > I het it now > > no offense and alain no harm done and all of nanog thank you and i will > continue observing as i have since 1995 > > thank you allagin > PS and BTW i am interested in CLOUD > > :-) > thanks once more > > > > > > On Jun 19, 2017, at 9:36 AM, Alain Hebert wrote: > > > > Hi, > > > > Yes Stephen, we're talking the usual like GTT... > > > > And no latency wise they're about the same. In the 35ms range. > > > > But I still can't figure out the 10 x drop, that level of latency > alone cannot be the factor. > > > > ( And Gordy... what?!? ) > > > > ----- > > 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 06/16/17 19:42, Stephen Fulton wrote: > >> Alain, > >> > >> When you refer to "normal peering" do you mean Internet transit? Or are > these PNI's with Google? Do the GCLD instance you reach through "normal > peering" have higher latency than through TorIX? > >> > >> -- Stephen > >> > >> On 2017-06-16 6:58 PM, Alain Hebert wrote: > >>> Hi, > >>> > >>> Anyone aware of different traffic behavior depending if the target > goes through normal peering than through an exchanges google exists in? > >>> > >>> We're facing a weird issue where the same GCLD Instance can upload > up to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but > cannot get more than 20Mbps on similar hosts (8 of them) sittings on our > peering links. > >>> > >>> PS; Those sames hosts get up to their link limit ( 1Gbps ) between > each others and others test points we have; > >>> > >>> PS: Wireshark capture show nothing abnormal; > >>> > >>> PS: Links aren't congested, and so on... > >>> > >>> Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only > test point with a TorIX access > >>> > >> > > > > > > From mel at beckman.org Wed Jun 21 15:49:30 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 21 Jun 2017 15:49:30 +0000 Subject: Long AS Path In-Reply-To: <20170621.095626.74671742.sthaug@nethelp.no> References: , <20170621.095626.74671742.sthaug@nethelp.no> Message-ID: Steinar, What reason is there to filter them? They are not a significant fraction of BGP paths. They cause no harm. It's just your sense of tidiness. You might consider contacting one of the operators to see if they do have a good reason you haven't considered. But absent a good reason *to* filter them, I would let BGP mechanics work as intended. -mel beckman On Jun 21, 2017, at 12:57 AM, "sthaug at nethelp.no" wrote: >> Just wondering if anyone else saw this yesterday afternoon ? >> >> Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH=3D AS_SEQ(2= >> ) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 234= >> 56 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 = >> 23456 23456 23456 23456 23456 ... attribute length (567) More than configur= >> ed MAXAS-LIMIT > > There are quite a few examples of people using stupidly long AS paths. > For instance > > 177.23.232.0/24 *[BGP/170] 00:52:40, MED 0, localpref 105 > AS path: 6939 16735 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262949 52938 52938 52938 52938 52938 52938 52938 52938 52938 52938 52938 I > > I currently have 27 prefixes in my Internet routing table with 40 or > more ASes in the AS path (show route aspath-regex ".{40,}"). > > I see no valid reason for such long AS paths. Time to update filters > here. I'm tempted to set the cutoff at 30 - can anybody see a good > reason to permit longer AS paths? > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no From ahebert at pubnix.net Wed Jun 21 15:51:32 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 21 Jun 2017 11:51:32 -0400 Subject: Google Cloud and IX - Traffic behavior In-Reply-To: References: <0a58f4fe-8e77-cb9e-fa20-c4732ec6593c@pubnix.net> Message-ID: <0757683e-5149-c89b-007d-12caac13828a@pubnix.net> Thanks Tom, Yeah my test points VM's where all FreeBSD 10.3/11.0, so I decided to randomize some of them and added a CentOS on my Telia peer (10Gbps), and start getting normal performance from GCLD ( In the 500Mbps/500Mbps range ) PS: Even weirderer(tm) The *BSD VMs always performed correctly in the past, but not for this particular case. I have some work left to normalizing those peers, the same tactic didn't work on the other ones. if anyone have some lead on a TCP stream analyzer that would cut down on the number of naps I need to take looking for clues in wireshark captures. ----- 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 06/21/17 11:12, Tom Beecher wrote: > Just did a quick test from a personal VM, no throughput difference > over direct peering, public IX, or transit. GCP might have a > bottleneck in your case though, might be a good idea to ask them. > > Also, I'll have what Gordon is having. > > On Tue, Jun 20, 2017 at 8:49 PM, Gordon Cook > wrote: > > > > Hi Alain and all the rest > I het it now > > no offense and alain no harm done and all of nanog thank you and i > will continue observing as i have since 1995 > > thank you allagin > PS and BTW i am interested in CLOUD > > :-) > thanks once more > > > > > > On Jun 19, 2017, at 9:36 AM, Alain Hebert > wrote: > > > > Hi, > > > > Yes Stephen, we're talking the usual like GTT... > > > > And no latency wise they're about the same. In the 35ms range. > > > > But I still can't figure out the 10 x drop, that level of > latency alone cannot be the factor. > > > > ( And Gordy... what?!? ) > > > > ----- > > 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 06/16/17 19:42, Stephen Fulton wrote: > >> Alain, > >> > >> When you refer to "normal peering" do you mean Internet > transit? Or are these PNI's with Google? Do the GCLD instance you > reach through "normal peering" have higher latency than through TorIX? > >> > >> -- Stephen > >> > >> On 2017-06-16 6:58 PM, Alain Hebert wrote: > >>> Hi, > >>> > >>> Anyone aware of different traffic behavior depending if > the target goes through normal peering than through an exchanges > google exists in? > >>> > >>> We're facing a weird issue where the same GCLD Instance > can upload up to 200Mbps (Ref 1) if the target path goes through, > lets say TorIX, but cannot get more than 20Mbps on similar hosts > (8 of them) sittings on our peering links. > >>> > >>> PS; Those sames hosts get up to their link limit ( 1Gbps ) > between each others and others test points we have; > >>> > >>> PS: Wireshark capture show nothing abnormal; > >>> > >>> PS: Links aren't congested, and so on... > >>> > >>> Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my > only test point with a TorIX access > >>> > >> > > > > > > From johnl at iecc.com Wed Jun 21 16:15:38 2017 From: johnl at iecc.com (John Levine) Date: 21 Jun 2017 16:15:38 -0000 Subject: mailops https breakage In-Reply-To: Message-ID: <20170621161538.22138.qmail@ary.lan> In article you write: >> Fun fact about letsencrypt certs, they expire after a month or so. > >90 days Well, yes. That's why highly skilled and experienced administrators such as yourself set up the automatic renewal scripts at the same time they install the initial cert, right? I use the acme.sh shell script. It ain't hard. R's, John From bob at FiberInternetCenter.com Wed Jun 21 16:42:56 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 21 Jun 2017 09:42:56 -0700 Subject: Long AS Path In-Reply-To: References: , <20170621.095626.74671742.sthaug@nethelp.no> Message-ID: <13197be6665b9e3940ea69bb7f3e70ce.squirrel@66.201.44.180> My cut off is 6 ASNs - more than 6 and it never makes it to the FIB. However, for this to be viable with plenty of unique prefixes to maintain a large table, we have lots and lots of direct big and small peers and much more than the usual amount of transit neighbors in our network. Silicon Valley companies are very demanding for the fasted path with the lowest number of router hops. ASN hops almost always lead to more router hops in the trace. We have customers that call us if everything is fine and they want to shave off milliseconds to favorite destinations. Picky, picky, picky. I am wondering how may other networks get requests (more like demands) from customers wanting you to speed packets up to and from a specific office in India or China. Customers knowing nothing about their office ISP overseas. BTW, it's almost always they have the cheapest congested shared office connection in the building overseas (especially in India). So they can't do anything there except "pretend" about the bandwidth available. About all they know is the IP address of the VPN and they were told they have a full gig connection. Sure they have a gig port, but it's on a switch together with 10 building neighbors that all also have a gig port on a circuit to the building that no one can maintain a gig for more than 3 ms. Go ahead try and fix that latency packet dropping issue with a firewall on both ends with SPI turned on in both directions. It's your fault if you cant make it better. After all their VPN from London to Bangalore works fine. And the ones in China all work fine to and from Australia. Anyways, I always wondered is it just me or do others get these kind of requests? Thank You Bob Evans CTO > Steinar, > > What reason is there to filter them? They are not a significant fraction > of BGP paths. They cause no harm. It's just your sense of tidiness. > > You might consider contacting one of the operators to see if they do have > a good reason you haven't considered. But absent a good reason *to* filter > them, I would let BGP mechanics work as intended. > > -mel beckman > > On Jun 21, 2017, at 12:57 AM, "sthaug at nethelp.no" > wrote: > >>> Just wondering if anyone else saw this yesterday afternoon ? >>> >>> Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH=3D >>> AS_SEQ(2= >>> ) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 >>> 234= >>> 56 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 >>> 23456 = >>> 23456 23456 23456 23456 23456 ... attribute length (567) More than >>> configur= >>> ed MAXAS-LIMIT >> >> There are quite a few examples of people using stupidly long AS paths. >> For instance >> >> 177.23.232.0/24 *[BGP/170] 00:52:40, MED 0, localpref 105 >> AS path: 6939 16735 28163 28163 28163 28163 28163 >> 28163 28163 28163 28163 28163 28163 28163 28163 >> 28163 28163 28163 262401 262401 262401 262401 >> 262401 262401 262401 262401 262401 262401 262401 >> 262401 262401 262401 262401 262401 262949 52938 >> 52938 52938 52938 52938 52938 52938 52938 52938 >> 52938 52938 I >> >> I currently have 27 prefixes in my Internet routing table with 40 or >> more ASes in the AS path (show route aspath-regex ".{40,}"). >> >> I see no valid reason for such long AS paths. Time to update filters >> here. I'm tempted to set the cutoff at 30 - can anybody see a good >> reason to permit longer AS paths? >> >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no > From saku at ytti.fi Wed Jun 21 17:11:37 2017 From: saku at ytti.fi (Saku Ytti) Date: Wed, 21 Jun 2017 20:11:37 +0300 Subject: Long AS Path In-Reply-To: <13197be6665b9e3940ea69bb7f3e70ce.squirrel@66.201.44.180> References: <20170621.095626.74671742.sthaug@nethelp.no> <13197be6665b9e3940ea69bb7f3e70ce.squirrel@66.201.44.180> Message-ID: Hey, Uou're saying, you drop long AS_PATH, to improve customer observed latency? Implication being, because you dropped the long AS_PATH prefixes, you're now selecting shorter AS_PATH prefixes to the FIB? Absent of this policy, in which scenario would you have inserted the filtered longer AS_PATH prefix to the FIB? I assume only scenario where this happens is where there is larger aggregate route, which is lower latency than the more specific route with longer as_path. Do you have data how many of such paths exist and what is the latency delta? I'm extremely skeptical that long AS_PATH rejection has any measurable impact on aggregate path latencies. On 21 June 2017 at 19:42, Bob Evans wrote: > My cut off is 6 ASNs - more than 6 and it never makes it to the FIB. > > However, for this to be viable with plenty of unique prefixes to maintain > a large table, we have lots and lots of direct big and small peers and > much more than the usual amount of transit neighbors in our network. > Silicon Valley companies are very demanding for the fasted path with the > lowest number of router hops. ASN hops almost always lead to more router > hops in the trace. We have customers that call us if everything is fine > and they want to shave off milliseconds to favorite destinations. Picky, > picky, picky. > > I am wondering how may other networks get requests (more like demands) > from customers wanting you to speed packets up to and from a specific > office in India or China. Customers knowing nothing about their office ISP > overseas. BTW, it's almost always they have the cheapest congested shared > office connection in the building overseas (especially in India). So they > can't do anything there except "pretend" about the bandwidth available. > About all they know is the IP address of the VPN and they were told they > have a full gig connection. Sure they have a gig port, but it's on a > switch together with 10 building neighbors that all also have a gig port > on a circuit to the building that no one can maintain a gig for more than > 3 ms. Go ahead try and fix that latency packet dropping issue with a > firewall on both ends with SPI turned on in both directions. It's your > fault if you cant make it better. After all their VPN from London to > Bangalore works fine. And the ones in China all work fine to and from > Australia. > > Anyways, I always wondered is it just me or do others get these kind of > requests? > > Thank You > Bob Evans > CTO > > > > >> Steinar, >> >> What reason is there to filter them? They are not a significant fraction >> of BGP paths. They cause no harm. It's just your sense of tidiness. >> >> You might consider contacting one of the operators to see if they do have >> a good reason you haven't considered. But absent a good reason *to* filter >> them, I would let BGP mechanics work as intended. >> >> -mel beckman >> >> On Jun 21, 2017, at 12:57 AM, "sthaug at nethelp.no" >> wrote: >> >>>> Just wondering if anyone else saw this yesterday afternoon ? >>>> >>>> Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH=3D >>>> AS_SEQ(2= >>>> ) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 >>>> 234= >>>> 56 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 >>>> 23456 = >>>> 23456 23456 23456 23456 23456 ... attribute length (567) More than >>>> configur= >>>> ed MAXAS-LIMIT >>> >>> There are quite a few examples of people using stupidly long AS paths. >>> For instance >>> >>> 177.23.232.0/24 *[BGP/170] 00:52:40, MED 0, localpref 105 >>> AS path: 6939 16735 28163 28163 28163 28163 28163 >>> 28163 28163 28163 28163 28163 28163 28163 28163 >>> 28163 28163 28163 262401 262401 262401 262401 >>> 262401 262401 262401 262401 262401 262401 262401 >>> 262401 262401 262401 262401 262401 262949 52938 >>> 52938 52938 52938 52938 52938 52938 52938 52938 >>> 52938 52938 I >>> >>> I currently have 27 prefixes in my Internet routing table with 40 or >>> more ASes in the AS path (show route aspath-regex ".{40,}"). >>> >>> I see no valid reason for such long AS paths. Time to update filters >>> here. I'm tempted to set the cutoff at 30 - can anybody see a good >>> reason to permit longer AS paths? >>> >>> Steinar Haug, Nethelp consulting, sthaug at nethelp.no >> > > -- ++ytti From beecher at beecher.cc Wed Jun 21 17:33:16 2017 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 21 Jun 2017 13:33:16 -0400 Subject: Long AS Path In-Reply-To: <13197be6665b9e3940ea69bb7f3e70ce.squirrel@66.201.44.180> References: <20170621.095626.74671742.sthaug@nethelp.no> <13197be6665b9e3940ea69bb7f3e70ce.squirrel@66.201.44.180> Message-ID: Usually when someone starts griping about RTT between destinations more than about 6 time zones apart, I start to talk to them about refraction indicies, platform specific switching delay differences, stuff like that. Normally I can chase them away or put them to sleep well before getting to 'I can break a lot of things, but physics is not one of them.' A longer ASN path is not an automatic signifier of a longer latency path. It can just as easily be a lower latency path that happens to traverse a expensive link that AS doesn't like to use normally, but wants a backup. Or maybe they have congestion inside their AS from that way in and want to influence traffic away from it. Or maybe they just read that chapter and thought it was a cool setting without knowing what it did. On Wed, Jun 21, 2017 at 12:42 PM, Bob Evans wrote: > My cut off is 6 ASNs - more than 6 and it never makes it to the FIB. > > However, for this to be viable with plenty of unique prefixes to maintain > a large table, we have lots and lots of direct big and small peers and > much more than the usual amount of transit neighbors in our network. > Silicon Valley companies are very demanding for the fasted path with the > lowest number of router hops. ASN hops almost always lead to more router > hops in the trace. We have customers that call us if everything is fine > and they want to shave off milliseconds to favorite destinations. Picky, > picky, picky. > > I am wondering how may other networks get requests (more like demands) > from customers wanting you to speed packets up to and from a specific > office in India or China. Customers knowing nothing about their office ISP > overseas. BTW, it's almost always they have the cheapest congested shared > office connection in the building overseas (especially in India). So they > can't do anything there except "pretend" about the bandwidth available. > About all they know is the IP address of the VPN and they were told they > have a full gig connection. Sure they have a gig port, but it's on a > switch together with 10 building neighbors that all also have a gig port > on a circuit to the building that no one can maintain a gig for more than > 3 ms. Go ahead try and fix that latency packet dropping issue with a > firewall on both ends with SPI turned on in both directions. It's your > fault if you cant make it better. After all their VPN from London to > Bangalore works fine. And the ones in China all work fine to and from > Australia. > > Anyways, I always wondered is it just me or do others get these kind of > requests? > > Thank You > Bob Evans > CTO > > > > > > Steinar, > > > > What reason is there to filter them? They are not a significant fraction > > of BGP paths. They cause no harm. It's just your sense of tidiness. > > > > You might consider contacting one of the operators to see if they do have > > a good reason you haven't considered. But absent a good reason *to* > filter > > them, I would let BGP mechanics work as intended. > > > > -mel beckman > > > > On Jun 21, 2017, at 12:57 AM, "sthaug at nethelp.no" > > wrote: > > > >>> Just wondering if anyone else saw this yesterday afternoon ? > >>> > >>> Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH=3D > >>> AS_SEQ(2= > >>> ) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 > >>> 234= > >>> 56 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 > >>> 23456 = > >>> 23456 23456 23456 23456 23456 ... attribute length (567) More than > >>> configur= > >>> ed MAXAS-LIMIT > >> > >> There are quite a few examples of people using stupidly long AS paths. > >> For instance > >> > >> 177.23.232.0/24 *[BGP/170] 00:52:40, MED 0, localpref 105 > >> AS path: 6939 16735 28163 28163 28163 28163 28163 > >> 28163 28163 28163 28163 28163 28163 28163 28163 > >> 28163 28163 28163 262401 262401 262401 262401 > >> 262401 262401 262401 262401 262401 262401 262401 > >> 262401 262401 262401 262401 262401 262949 52938 > >> 52938 52938 52938 52938 52938 52938 52938 52938 > >> 52938 52938 I > >> > >> I currently have 27 prefixes in my Internet routing table with 40 or > >> more ASes in the AS path (show route aspath-regex ".{40,}"). > >> > >> I see no valid reason for such long AS paths. Time to update filters > >> here. I'm tempted to set the cutoff at 30 - can anybody see a good > >> reason to permit longer AS paths? > >> > >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > > > > From amitchell at isipp.com Wed Jun 21 18:11:43 2017 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Wed, 21 Jun 2017 12:11:43 -0600 Subject: Vendors spamming NANOG attendees In-Reply-To: References: Message-ID: <502B1C03-F4B9-4E54-9EF2-E168A1627BA2@isipp.com> > On 6/13/17 10:28 PM, Mel Beckman wrote: >> But as I said, harvesting emails is not illegal under can spam. But it is illegal under the laws of nearly every other technology-enabled developed country. And there are at least a few people on this list who are in those countries. And once GDPR goes into effect there will be even more available remedies. Anne* *Dictated due to broken wrist, please forgive top posting and any weird grammar or typos. Anne P. Mitchell, Attorney at Law Legislative Consultant CEO/President, Institute for Social Internet Public Policy Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Member, Board of Directors, Greenwood Wildlife Rehabilitation Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From mel at beckman.org Wed Jun 21 20:45:16 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 21 Jun 2017 20:45:16 +0000 Subject: Long AS Path In-Reply-To: <20170621.144213.74665620.sthaug@nethelp.no> References: <20170621.095626.74671742.sthaug@nethelp.no> , <20170621.144213.74665620.sthaug@nethelp.no> Message-ID: <4FF09308-6FF0-4B72-9AEE-2A5C33852800@beckman.org> Why not ask the operator why they are pretending this path? Perhaps they have a good explanation that you haven't thought of. Blindly limiting otherwise legal path lengths is not a defensible practice, in my opinion. -mel beckman On Jun 21, 2017, at 1:36 PM, "sthaug at nethelp.no" wrote: >>> I see no valid reason for such long AS paths. Time to update filters >>> here. I'm tempted to set the cutoff at 30 - can anybody see a good >>> reason to permit longer AS paths? >> >> Well, as I mentioned in my Net Neutrality filing to the FCC, a TTL of 30 >> is OK for intra-planet routing, but when you start leaving the big blue >> marble you will need to allow the packets to live longer. > > TTL != AS path length > > I can certainly see the use for a TTL of 30. I cannot see the use for > an AS path length greater than 30 (especially not when 2 ASes are each > repeated 16 times). > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > From pf at tippete.net Thu Jun 22 06:09:41 2017 From: pf at tippete.net (Pierfrancesco Caci) Date: Thu, 22 Jun 2017 08:09:41 +0200 Subject: Long AS Path In-Reply-To: <4FF09308-6FF0-4B72-9AEE-2A5C33852800@beckman.org> (Mel Beckman's message of "Wed, 21 Jun 2017 20:45:16 +0000") References: <20170621.095626.74671742.sthaug@nethelp.no> <20170621.144213.74665620.sthaug@nethelp.no> <4FF09308-6FF0-4B72-9AEE-2A5C33852800@beckman.org> Message-ID: <874lv8zh7e.fsf@snoopy.tippete.net> >>>>> "Mel" == Mel Beckman writes: Mel> Why not ask the operator why they are pretending this path? Perhaps Mel> they have a good explanation that you haven't thought of. Blindly Mel> limiting otherwise legal path lengths is not a defensible practice, in Mel> my opinion. Mel> -mel beckman A prepend like that is usually the result of someone using the IOS syntax on a XR or Junos router. Long ago, someone accidentally prepending 255 times hit a bug (or was it a too strict bgp implementation? I don't remember) resulting in several networks across the globe dropping neighbors. One has to protect against these things somehow. As a data point, here is how many prefixes I see on my network for each as-path length, after removing prepends: aspath length count ------------------------- 0: 340 1: 47522 2: 292879 3: 227822 4: 58390 5: 10217 6: 2123 7: 638 8: 48 9: 58 11: 20 12: 2 So, does your customer have a legitimate reason to prepend more than 5 times? Maybe. I still think that anyone that does should have their BGP driving licence revoked, though. Pf -- Pierfrancesco Caci, ik5pvx From nanog at radu-adrian.feurdean.net Thu Jun 22 07:00:50 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Thu, 22 Jun 2017 09:00:50 +0200 Subject: IPv6 traffic percentages? In-Reply-To: References: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> Message-ID: <1498114850.2003210.1017519880.0B632BC0@webmail.messagingengine.com> On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote: > > On 18 June 2017 at 17:36, Radu-Adrian Feurdean adrian.feurdean.net> wrote:>> so for the record, business customers are much more active in >> *rejecting* IPv6, either explictely (they say they want it >> disabled) or>> implicitly (they install their own router, not configured for >> IPv6). The>> bigger the business, the bigger the chance of rejection. > > > Did they per chance state their reasons for rejecting it? Not explicitly. But when we get something like "turn off that IPv6 crap !" we take it for: - they don't have a clearly defined need for it - they don't know how to deal with it - they don't want to deal with things they don't need (see the irst point)... usually all of them at the same time. To make it short : education. And we as as small ISP we have neither the resources, nor the motivation (because $$$ on the issue is negative) to do it (the education). -- R-A.F. From swmike at swm.pp.se Thu Jun 22 07:08:44 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 22 Jun 2017 09:08:44 +0200 (CEST) Subject: IPv6 traffic percentages? In-Reply-To: <1498114850.2003210.1017519880.0B632BC0@webmail.messagingengine.com> References: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> <1498114850.2003210.1017519880.0B632BC0@webmail.messagingengine.com> Message-ID: On Thu, 22 Jun 2017, Radu-Adrian Feurdean wrote: > To make it short : education. And we as as small ISP we have neither the > resources, nor the motivation (because $$$ on the issue is negative) to > do it (the education). An ISP should be an enabler, and have a service portfolio to cover most customers need. Not all customers will want all the services, so if a customer doesn't want IPv6 then fine, turn it off for them. When they come back later and want it, they know you have it. You've done your part, and that's great! -- Mikael Abrahamsson email: swmike at swm.pp.se From jlewis at lewis.org Thu Jun 22 11:27:35 2017 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 22 Jun 2017 07:27:35 -0400 (EDT) Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> <13197be6665b9e3940ea69bb7f3e70ce.squirrel@66.201.44.180> Message-ID: On Wed, 21 Jun 2017, Saku Ytti wrote: > Hey, > > Uou're saying, you drop long AS_PATH, to improve customer observed > latency? Implication being, because you dropped the long AS_PATH > prefixes, you're now selecting shorter AS_PATH prefixes to the FIB? > > Absent of this policy, in which scenario would you have inserted the > filtered longer AS_PATH prefix to the FIB? I assume only scenario > where this happens is where there is larger aggregate route, which is > lower latency than the more specific route with longer as_path. You do have to wonder, what was the thought process that resulted in 35 being the right number of prepends "accomplish" whatever TE they were shooting for? AS path: 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 I don't mean to single out 55644. It's just the first/most obnoxiously long as-path I found when looking for long ones. I seriously doubt provider/customer/customer-of-customer relationships ever get much deeper than a handful or so of ASNs...so if prepending a few times doesn't get it done, 10-20-30 prepends are unlikely to help. In the above case, that long path is actually our best path. We localpref peering above transit. So, it doesn't matter how many prepends, they add, we're never going to not use this path if its available. We have transit paths to these routes that are only a single handful of ASNs long. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From deleskie at gmail.com Thu Jun 22 12:47:20 2017 From: deleskie at gmail.com (jim deleskie) Date: Thu, 22 Jun 2017 09:47:20 -0300 Subject: Long AS Path In-Reply-To: <874lv8zh7e.fsf@snoopy.tippete.net> References: <20170621.095626.74671742.sthaug@nethelp.no> <20170621.144213.74665620.sthaug@nethelp.no> <4FF09308-6FF0-4B72-9AEE-2A5C33852800@beckman.org> <874lv8zh7e.fsf@snoopy.tippete.net> Message-ID: I see 5+ prepends as maybe not reason to have your "BGP driving license revoked" but if I can continue with the concept that you have your BGP learners permit. If I think back to when I learned to code or when making ACL's, we still used line number and practice would be to give ourselves lots of space 5 or 10 numbers in case we have to insert something in the middle. ie I need 2 sets of prepends, I'm still learning this stuff so I'll go with 5 and 10. We all started somewhere, we all did dumb stuff, hopefully, we all learned. 12AS hops, I have to go see how they are connected now, maybe someone in that chain needs to be invited by an IX to a NANOG or GPF or some such, that can't be super efficient. -jim On Thu, Jun 22, 2017 at 3:09 AM, Pierfrancesco Caci wrote: > >>>>> "Mel" == Mel Beckman writes: > > > Mel> Why not ask the operator why they are pretending this path? > Perhaps > Mel> they have a good explanation that you haven't thought of. Blindly > Mel> limiting otherwise legal path lengths is not a defensible > practice, in > Mel> my opinion. > > Mel> -mel beckman > > > A prepend like that is usually the result of someone using the IOS > syntax on a XR or Junos router. > > Long ago, someone accidentally prepending 255 times hit a bug (or was it > a too strict bgp implementation? I don't remember) resulting in several > networks across the globe dropping neighbors. One has to protect against > these things somehow. > > As a data point, here is how many prefixes I see on my network for each > as-path length, after removing prepends: > > > aspath length count > ------------------------- > 0: 340 > 1: 47522 > 2: 292879 > 3: 227822 > 4: 58390 > 5: 10217 > 6: 2123 > 7: 638 > 8: 48 > 9: 58 > 11: 20 > 12: 2 > > > So, does your customer have a legitimate reason to prepend more than 5 > times? Maybe. I still think that anyone that does should have their BGP > driving licence revoked, though. > > Pf > > > > > -- > Pierfrancesco Caci, ik5pvx > From list at satchell.net Thu Jun 22 13:29:33 2017 From: list at satchell.net (Stephen Satchell) Date: Thu, 22 Jun 2017 06:29:33 -0700 Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> <13197be6665b9e3940ea69bb7f3e70ce.squirrel@66.201.44.180> Message-ID: <68b1b794-5565-2106-adf2-201dca07bddf@satchell.net> On 06/22/2017 04:27 AM, Jon Lewis wrote: > > You do have to wonder, what was the thought process that resulted in 35 > being the right number of prepends "accomplish" whatever TE they were > shooting for? > > AS path: 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 > 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 > 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 > 55644 55644 55644 45271 > > I don't mean to single out 55644. It's just the first/most obnoxiously > long as-path I found when looking for long ones. > > I seriously doubt provider/customer/customer-of-customer relationships > ever get much deeper than a handful or so of ASNs...so if prepending a > few times doesn't get it done, 10-20-30 prepends are unlikely to help. > > In the above case, that long path is actually our best path. We > localpref peering above transit. So, it doesn't matter how many > prepends, they add, we're never going to not use this path if its > available. We have transit paths to these routes that are only a single > handful of ASNs long. I think I understand the problem, and now I understand why prepends didn't do much for me. Over the years, I tended two multi-homed sites. In both cases, the two uplinks had different speeds. When I used prepend to try to get the outside world to prefer the faster link, some traffic was stubborn about coming in the slow one. Difference in speeds? In the first network it was 45 mbps and 10 mbps. In the second network it was 16 mbps and 1.5 mbps. Both network owners were too stingy at the time to opt for harmonized rates. Question: how could communities be used to "force" preference for one uplink over another by the peers? I'm long past needing this, but others might benefit. (And when you stop learning, you're dead.) From mel at beckman.org Thu Jun 22 14:25:40 2017 From: mel at beckman.org (Mel Beckman) Date: Thu, 22 Jun 2017 14:25:40 +0000 Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> <20170621.144213.74665620.sthaug@nethelp.no> <4FF09308-6FF0-4B72-9AEE-2A5C33852800@beckman.org> <874lv8zh7e.fsf@snoopy.tippete.net>, Message-ID: <8BC06B58-EEEF-4295-A778-E18FB24FDE76@beckman.org> You don't have to wonder. You can call and ask them. -mel via cell > On Jun 22, 2017, at 5:47 AM, jim deleskie wrote: > > I see 5+ prepends as maybe not reason to have your "BGP driving license > revoked" but if I can continue with the concept that you have your BGP > learners permit. > If I think back to when I learned to code or when making ACL's, we still > used line number and practice would be to give ourselves lots > of space 5 or 10 numbers in case we have to insert something in the middle. > ie I need 2 sets of prepends, I'm still learning this stuff > so I'll go with 5 and 10. We all started somewhere, we all did dumb stuff, > hopefully, we all learned. > > 12AS hops, I have to go see how they are connected now, maybe someone in > that chain needs to be invited by an IX to a NANOG or GPF or some such, > that can't be super efficient. > > -jim > > On Thu, Jun 22, 2017 at 3:09 AM, Pierfrancesco Caci wrote: > >>>>>>> "Mel" == Mel Beckman writes: >> >> >> Mel> Why not ask the operator why they are pretending this path? >> Perhaps >> Mel> they have a good explanation that you haven't thought of. Blindly >> Mel> limiting otherwise legal path lengths is not a defensible >> practice, in >> Mel> my opinion. >> >> Mel> -mel beckman >> >> >> A prepend like that is usually the result of someone using the IOS >> syntax on a XR or Junos router. >> >> Long ago, someone accidentally prepending 255 times hit a bug (or was it >> a too strict bgp implementation? I don't remember) resulting in several >> networks across the globe dropping neighbors. One has to protect against >> these things somehow. >> >> As a data point, here is how many prefixes I see on my network for each >> as-path length, after removing prepends: >> >> >> aspath length count >> ------------------------- >> 0: 340 >> 1: 47522 >> 2: 292879 >> 3: 227822 >> 4: 58390 >> 5: 10217 >> 6: 2123 >> 7: 638 >> 8: 48 >> 9: 58 >> 11: 20 >> 12: 2 >> >> >> So, does your customer have a legitimate reason to prepend more than 5 >> times? Maybe. I still think that anyone that does should have their BGP >> driving licence revoked, though. >> >> Pf >> >> >> >> >> -- >> Pierfrancesco Caci, ik5pvx >> From edugas at unknowndevice.ca Thu Jun 22 14:38:57 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Thu, 22 Jun 2017 10:38:57 -0400 Subject: Reliability of Juniper MIC3-3D-1X100GE-CFP and CFP in general Message-ID: Hello, We're planning to phase out some 10G link-aggregations in favor of 100G interfaces. We've been looking at buying MIC3-3D-1X100GE-CFP, MPC3E and Fiberstore CFPs. I've been told that CFPs (in general) weren't that reliable. They were kinda "replaced" almost a year and a half or so after its introduction by CFP2 and then by CFP4 and so on. Size and power consumption aside, are the MIC3-3D-1X100GE-CFP and CFP modules reliable at all? Are they the SFP-TX of the 100GBase? Eric From jheitz at cisco.com Thu Jun 22 14:52:11 2017 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Thu, 22 Jun 2017 14:52:11 +0000 Subject: Long AS Path In-Reply-To: References: Message-ID: <88C2D601-46A8-4071-AA22-0B5B53F1EE7E@cisco.com> 23456 is AS_TRANS. Either your router does not support 4 byte AS or there is a bug at AS 12956 or AS 12956 is intentionally prepending 23456. Thanks, Jakob. > > Date: Tue, 20 Jun 2017 23:12:45 +0000 > From: James Braunegg > To: "nanog at nanog.org" > Subject: Long AS Path > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Dear All > > Just wondering if anyone else saw this yesterday afternoon ? > > Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH= AS_SEQ(2) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (567) More than configured MAXAS-LIMIT > > Jun 20 16:15:26:E:BGP: From Peer 78.X.X.X received Long AS_PATH= AS_SEQ(2) 5580 3257 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (568) More than configured MAXAS-LIMIT > > Someone is having fun, creating weird and wonderful long AS paths based around AS 23456, we saw the same pattern of data from numerous upstream providers. > > Kindest Regards, > > James Braunegg > > From Oliver.Elliott at bristol.ac.uk Tue Jun 20 15:26:05 2017 From: Oliver.Elliott at bristol.ac.uk (Oliver Elliott) Date: Tue, 20 Jun 2017 16:26:05 +0100 Subject: PCIe adapters supporting long distance 10GB fiber? In-Reply-To: References: <20170614140247.4917.qmail@ary.lan> <1ad2f088-6183-0737-8d1c-f3b4d618be57@gmx.net> Message-ID: I have used 3rd party Cisco coded optics in an Intel SFP card successfully, but it won't be "officially supported". Oli On 20 June 2017 at 16:15, Baldur Norddahl wrote: > The real question here is: will my NIC support other SFP+ modules than the > few options carried by the NIC vendor? > > For example Intel claims the Intel NICs can only accept SFP+ modules by > Intel. They probably do not make optics themselves and only have few > options available. And indeed if you put in a third party optic it will be > rejected. > > There are two ways around that. One is finding a device driver with vendor > check disabled. The other option is to get optics that pretend to be Intel. > > You can get optics with vendor ID many places. A good place to start is > Fiberstore fs.com because they have public pricing on the website. > > With the vendor id the answer to the question is that all NICs with SFP+ I > ever heard about will support any range, WDM or other special SFP+ module. > > Regards, > > Baldur > > > Den 20. jun. 2017 02.59 skrev "chiel" : > > > Hello, > > > > We are deploying more and more server based routers (based on BSD). We > > have now come to the point where we need to have 10GB uplinks one these > > devices and I prefer to plug in a long range 10GB fiber straight into the > > server without it going first into a router/switch from vendor x. It > seems > > to me that all the 10GB PCIe cards only support either copper 10GBASE-T, > > short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very few). Are > > there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I can't seem > > to find any. > > > > Chiel > > > -- Oliver Elliott Senior Network Specialist IT Services, University of Bristol t: 0117 39 (41131) From steve at enta.net Wed Jun 21 16:50:27 2017 From: steve at enta.net (Steve Lalonde) Date: Wed, 21 Jun 2017 17:50:27 +0100 Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> Message-ID: <581B3C93-8208-44C0-85A0-3640B4301ACD@enta.net> Mel, There was a Cisco bug many years ago that caused lots of issues. Since then we have limited max-as to 50 and it has not caused any reported issues yet. Link that does not require a CCO login to view. http://blog.ipspace.net/2009/02/oversized-as-paths-cisco-ios-bug.html Regards Steve Lalonde > On 21 Jun 2017, at 16:49, Mel Beckman wrote: > > Steinar, > > What reason is there to filter them? They are not a significant fraction of BGP paths. They cause no harm. It's just your sense of tidiness. > > You might consider contacting one of the operators to see if they do have a good reason you haven't considered. But absent a good reason *to* filter them, I would let BGP mechanics work as intended. > > -mel beckman > > On Jun 21, 2017, at 12:57 AM, "sthaug at nethelp.no" wrote: > >>> Just wondering if anyone else saw this yesterday afternoon ? >>> >>> Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH=3D AS_SEQ(2= >>> ) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 234= >>> 56 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 = >>> 23456 23456 23456 23456 23456 ... attribute length (567) More than configur= >>> ed MAXAS-LIMIT >> >> There are quite a few examples of people using stupidly long AS paths. >> For instance >> >> 177.23.232.0/24 *[BGP/170] 00:52:40, MED 0, localpref 105 >> AS path: 6939 16735 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262949 52938 52938 52938 52938 52938 52938 52938 52938 52938 52938 52938 I >> >> I currently have 27 prefixes in my Internet routing table with 40 or >> more ASes in the AS path (show route aspath-regex ".{40,}"). >> >> I see no valid reason for such long AS paths. Time to update filters >> here. I'm tempted to set the cutoff at 30 - can anybody see a good >> reason to permit longer AS paths? >> >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no From alderfjh at emu.edu Wed Jun 21 19:51:05 2017 From: alderfjh at emu.edu (Jason Alderfer) Date: Wed, 21 Jun 2017 15:51:05 -0400 Subject: PCIe adapters supporting long distance 10GB fiber? Message-ID: On Tue, Jun 20, 2017 at 11:15 AM, Baldur Norddahl wrote: > The real question here is: will my NIC support other SFP+ modules than the > few options carried by the NIC vendor? Has anyone tried changing the vendor ID of an SFP+ with one of these? https://sfptotal.com/ I am highly intrigued and skeptical. Jason From mukom.tamon at gmail.com Thu Jun 22 06:18:10 2017 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Thu, 22 Jun 2017 10:18:10 +0400 Subject: IPv6 traffic percentages? In-Reply-To: <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> References: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> Message-ID: On 18 June 2017 at 17:36, Radu-Adrian Feurdean < nanog at radu-adrian.feurdean.net> wrote: > so for the record, business customers are much more active in > *rejecting* IPv6, either explictely (they say they want it disabled) or > implicitly (they install their own router, not configured for IPv6). The > bigger the business, the bigger the chance of rejection. > Did they per chance state their reasons for rejecting it? -- Mukom Akong T. LinkedIn:Mukom | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From joelja at bogus.com Thu Jun 22 15:24:20 2017 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 22 Jun 2017 08:24:20 -0700 Subject: Reliability of Juniper MIC3-3D-1X100GE-CFP and CFP in general In-Reply-To: References: Message-ID: <4DF2BE67-8894-40A1-8D00-7280F6585EE0@bogus.com> Sent from my iPhone > On Jun 22, 2017, at 07:38, Eric Dugas wrote: > > Hello, > > We're planning to phase out some 10G link-aggregations in favor of 100G > interfaces. We've been looking at buying MIC3-3D-1X100GE-CFP, MPC3E and > Fiberstore CFPs. > > I've been told that CFPs (in general) weren't that reliable. They were > kinda "replaced" almost a year and a half or so after its introduction by > CFP2 and then by CFP4 and so on. Size and power consumption aside, are the > MIC3-3D-1X100GE-CFP and CFP modules reliable at all? Are they the SFP-TX of > the 100GBase? CFP has been around a while, like 8 years at this point. CFP2 and CFP4 are significantly smaller have accordingly lower power budgets and do not include the DSP on board (the linecard for cfp/2/4/8 differs significantly respecting level of integration components and so forth and also port count). Apart from the resulting low port density per card, which makes them unsuitable for a number applications they're mature products at this point. > > Eric > From jwbensley at gmail.com Fri Jun 23 11:32:18 2017 From: jwbensley at gmail.com (James Bensley) Date: Fri, 23 Jun 2017 12:32:18 +0100 Subject: Long AS Path In-Reply-To: <581B3C93-8208-44C0-85A0-3640B4301ACD@enta.net> References: <20170621.095626.74671742.sthaug@nethelp.no> <581B3C93-8208-44C0-85A0-3640B4301ACD@enta.net> Message-ID: On 21 Jun 2017 17:51, "Mel Beckman" wrote: Steinar, What reason is there to filter them? The main reason I know of is this: On 22 Jun 2017 17:17, "Steve Lalonde" wrote: Mel, There was a Cisco bug many years ago that caused lots of issues. Since then we have limited max-as to 50 and it has not caused any reported issues yet. Link that does not require a CCO login to view. http://blog.ipspace.net/2009/02/oversized-as-paths-cisco-ios-bug.html Like many providers we do still have legacy kit tucked away with shameful firmware versions running and also multiple vendors in play so I can't be sure we don't have devices still susceptible to such a bug in view of the DFZ. On 21 Jun 2017 18:45, "Bob Evans" wrote: My cut off is 6 ASNs - more than 6 and it never makes it to the FIB. So for the above reason we do have an AS_PATH limit but it is quite high like 63 or 120 ASNs (on mobile can't remember and right now). I don't want to get near a ^2 boundary like 255 or 128 but also don't want to drop prefixes if possible like a last resort fail-safe, so it's a very high number and will remove it at some point. On 22 Jun 2017 14:49, "jim deleskie" wrote: I see 5+ prepends as maybe not reason to have your "BGP driving license revoked" but if I can continue with the concept that you have your BGP learners permit. That (6) seems pretty low to me. Apart from a potential bug the other reason we thought of to block routes with a massive AS_PATH is that it could be a sign that the operator of a network doesn't know what their doing or doesn't have good processes in place (YMMV). If you have a path twice in BGP, once with a "giant" path length and once with a "normal" length the provider offering the "longer" path may have any manner of problems internally if they can't even manage their BGP routing policies appropriately. I have seen genuine reasons for up to about 6 pre-prends and beyond so you're probably dropping a decent amount of routes. At the time I set our filter I think we were dropping one single route. No one has complained so its still in place. Giant AS_PATHs can be debated in a similar fashion to AS numbers used/restricted by RFCs. We have AS number filters in place to block prefixes with a private ASN in the path, any transit provider should block such routes, again if they aren't it's a sign to me they're not doing a really great job. But it's very hard to know if you can drop those routes without affecting your customer base or that a suitable alternative exists. Great care must be taken when doing this. Otherwise the following issue arises: On 21 Jun 2017 19:13, "Saku Ytti" wrote: Hey, Uou're saying, you drop long AS_PATH, to improve customer observed latency? Implication being, because you dropped the long AS_PATH prefixes, you're now selecting shorter AS_PATH prefixes to the FIB? Absent of this policy, in which scenario would you have inserted the filtered longer AS_PATH prefix to the FIB? I assume only scenario where this happens is where there is larger aggregate route, which is lower latency than the more specific route with longer as_path. So we drop "giant" AS_PATH length routes and routes with certain ASNs in the path, but we are fairly certain we don't need them / our customers don't need them etc. Not because we believe we are getting better (lower latency routes) routes from somewhere else as Saku said above, we can't feasibly "test" and compare the performance of every route we receive or need/want, but to protect our infrastructure. On 22 Jun 2017 16:54, "Jakob Heitz (jheitz)" wrote: 23456 is AS_TRANS. Either your router does not support 4 byte AS or there is a bug at AS 12956 or AS 12956 is intentionally prepending 23456. This ties in with my point about specific ASN filtering. Its not a problem seeing 23456 in your table but again perhaps an indicator of a problem or someone using legacy kit. No problem with 23456 routes like AS_PATH length of up to say 50 but beyond that, I can't thing of a genuine reasons and could be a sign that along the path there may be stability issues for example. Again, too difficult to measure. Depending on your customer base and requirements it can be safe to drop giant paths but care is needed, and if you do it, I think a number like 6 is way too low. Cheers, James. From mel at beckman.org Fri Jun 23 15:03:39 2017 From: mel at beckman.org (Mel Beckman) Date: Fri, 23 Jun 2017 15:03:39 +0000 Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> <581B3C93-8208-44C0-85A0-3640B4301ACD@enta.net>, Message-ID: James, The question is whether you would actually hear of any problems. Chances are that the problem would be experienced by somebody else, who has no idea that your filtering was causing it. -mel beckman > On Jun 23, 2017, at 4:33 AM, James Bensley wrote: > > On 21 Jun 2017 17:51, "Mel Beckman" wrote: > > Steinar, > > What reason is there to filter them? > > > The main reason I know of is this: > > On 22 Jun 2017 17:17, "Steve Lalonde" wrote: > > Mel, > > There was a Cisco bug many years ago that caused lots of issues. Since then > we have limited max-as to 50 and it has not caused any reported issues yet. > > Link that does not require a CCO login to view. > http://blog.ipspace.net/2009/02/oversized-as-paths-cisco-ios-bug.html > > > Like many providers we do still have legacy kit tucked away with shameful > firmware versions running and also multiple vendors in play so I can't be > sure we don't have devices still susceptible to such a bug in view of the > DFZ. > > On 21 Jun 2017 18:45, "Bob Evans" wrote: > > My cut off is 6 ASNs - more than 6 and it never makes it to the FIB. > > > So for the above reason we do have an AS_PATH limit but it is quite high > like 63 or 120 ASNs (on mobile can't remember and right now). I don't want > to get near a ^2 boundary like 255 or 128 but also don't want to drop > prefixes if possible like a last resort fail-safe, so it's a very high > number and will remove it at some point. > > On 22 Jun 2017 14:49, "jim deleskie" wrote: > > I see 5+ prepends as maybe not reason to have your "BGP driving license > revoked" but if I can continue with the concept that you have your BGP > learners permit. > > > That (6) seems pretty low to me. Apart from a potential bug the other > reason we thought of to block routes with a massive AS_PATH is that it > could be a sign that the operator of a network doesn't know what their > doing or doesn't have good processes in place (YMMV). If you have a path > twice in BGP, once with a "giant" path length and once with a "normal" > length the provider offering the "longer" path may have any manner of > problems internally if they can't even manage their BGP routing policies > appropriately. > > I have seen genuine reasons for up to about 6 pre-prends and beyond so > you're probably dropping a decent amount of routes. At the time I set our > filter I think we were dropping one single route. No one has complained so > its still in place. > > Giant AS_PATHs can be debated in a similar fashion to AS numbers > used/restricted by RFCs. We have AS number filters in place to block > prefixes with a private ASN in the path, any transit provider should block > such routes, again if they aren't it's a sign to me they're not doing a > really great job. But it's very hard to know if you can drop those routes > without affecting your customer base or that a suitable alternative exists. > Great care must be taken when doing this. > > Otherwise the following issue arises: > > On 21 Jun 2017 19:13, "Saku Ytti" wrote: > > Hey, > > Uou're saying, you drop long AS_PATH, to improve customer observed > latency? Implication being, because you dropped the long AS_PATH > prefixes, you're now selecting shorter AS_PATH prefixes to the FIB? > > Absent of this policy, in which scenario would you have inserted the > filtered longer AS_PATH prefix to the FIB? I assume only scenario > where this happens is where there is larger aggregate route, which is > lower latency than the more specific route with longer as_path. > > > So we drop "giant" AS_PATH length routes and routes with certain ASNs in > the path, but we are fairly certain we don't need them / our customers > don't need them etc. Not because we believe we are getting better (lower > latency routes) routes from somewhere else as Saku said above, we can't > feasibly "test" and compare the performance of every route we receive or > need/want, but to protect our infrastructure. > > On 22 Jun 2017 16:54, "Jakob Heitz (jheitz)" wrote: > > 23456 is AS_TRANS. Either your router does not support 4 byte AS or there > is a bug at AS 12956 or AS 12956 is intentionally prepending 23456. > > > This ties in with my point about specific ASN filtering. Its not a problem > seeing 23456 in your table but again perhaps an indicator of a problem or > someone using legacy kit. No problem with 23456 routes like AS_PATH length > of up to say 50 but beyond that, I can't thing of a genuine reasons and > could be a sign that along the path there may be stability issues for > example. Again, too difficult to measure. > > Depending on your customer base and requirements it can be safe to drop > giant paths but care is needed, and if you do it, I think a number like 6 > is way too low. > > Cheers, > James. From cscora at apnic.net Fri Jun 23 18:02:44 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Jun 2017 04:02:44 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170623180244.83D2985842@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 24 Jun, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 652252 Prefixes after maximum aggregation (per Origin AS): 253804 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 314199 Total ASes present in the Internet Routing Table: 57616 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 49870 Origin ASes announcing only one prefix: 22007 Transit ASes present in the Internet Routing Table: 7746 Transit-only ASes present in the Internet Routing Table: 221 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 50 Numnber of instances of unregistered ASNs: 54 Number of 32-bit ASNs allocated by the RIRs: 19170 Number of 32-bit ASNs visible in the Routing Table: 14928 Prefixes from 32-bit ASNs in the Routing Table: 60687 Number of bogon 32-bit ASNs visible in the Routing Table: 62 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 365 Number of addresses announced to Internet: 2850215268 Equivalent to 169 /8s, 226 /16s and 213 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 217120 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 178941 Total APNIC prefixes after maximum aggregation: 51343 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 178085 Unique aggregates announced from the APNIC address blocks: 73610 APNIC Region origin ASes present in the Internet Routing Table: 8215 APNIC Prefixes per ASN: 21.68 APNIC Region origin ASes announcing only one prefix: 2309 APNIC Region transit ASes present in the Internet Routing Table: 1158 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3044 Number of APNIC addresses announced to Internet: 763609444 Equivalent to 45 /8s, 131 /16s and 193 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 198554 Total ARIN prefixes after maximum aggregation: 94628 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 200377 Unique aggregates announced from the ARIN address blocks: 92081 ARIN Region origin ASes present in the Internet Routing Table: 17909 ARIN Prefixes per ASN: 11.19 ARIN Region origin ASes announcing only one prefix: 6615 ARIN Region transit ASes present in the Internet Routing Table: 1777 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2051 Number of ARIN addresses announced to Internet: 1110770080 Equivalent to 66 /8s, 53 /16s and 1 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 175121 Total RIPE prefixes after maximum aggregation: 85690 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 170888 Unique aggregates announced from the RIPE address blocks: 102704 RIPE Region origin ASes present in the Internet Routing Table: 24145 RIPE Prefixes per ASN: 7.08 RIPE Region origin ASes announcing only one prefix: 11099 RIPE Region transit ASes present in the Internet Routing Table: 3397 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5946 Number of RIPE addresses announced to Internet: 712074880 Equivalent to 42 /8s, 113 /16s and 102 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 82434 Total LACNIC prefixes after maximum aggregation: 18319 LACNIC Deaggregation factor: 4.50 Prefixes being announced from the LACNIC address blocks: 83737 Unique aggregates announced from the LACNIC address blocks: 38492 LACNIC Region origin ASes present in the Internet Routing Table: 6049 LACNIC Prefixes per ASN: 13.84 LACNIC Region origin ASes announcing only one prefix: 1656 LACNIC Region transit ASes present in the Internet Routing Table: 1115 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3566 Number of LACNIC addresses announced to Internet: 170779616 Equivalent to 10 /8s, 45 /16s and 227 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 17105 Total AfriNIC prefixes after maximum aggregation: 3779 AfriNIC Deaggregation factor: 4.53 Prefixes being announced from the AfriNIC address blocks: 18800 Unique aggregates announced from the AfriNIC address blocks: 6987 AfriNIC Region origin ASes present in the Internet Routing Table: 1049 AfriNIC Prefixes per ASN: 17.92 AfriNIC Region origin ASes announcing only one prefix: 327 AfriNIC Region transit ASes present in the Internet Routing Table: 202 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 321 Number of AfriNIC addresses announced to Internet: 92555264 Equivalent to 5 /8s, 132 /16s and 72 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5552 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3933 404 358 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2976 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2809 11135 760 KIXS-AS-KR Korea Telecom, KR 9829 2749 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2204 8699 34 CMNET-GD Guangdong Mobile Communication 4755 2087 422 221 TATACOMM-AS TATA Communications formerl 45899 2012 1407 107 VNPT-AS-VN VNPT Corp, VN 7552 1628 1105 71 VIETEL-AS-AP Viettel Corporation, VN 9498 1592 360 138 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3809 2953 160 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3395 1333 81 SHAW - Shaw Communications Inc., CA 6389 2064 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 18566 2053 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2009 2171 419 CHARTER-NET-HKY-NC - Charter Communicat 209 1825 5069 641 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1808 3647 587 AMAZON-02 - Amazon.com, Inc., US 30036 1791 325 307 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1695 854 231 ITCDELTA - Earthlink, Inc., US 701 1563 10562 633 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3338 187 22 ALJAWWALSTC-AS, SA 20940 2897 964 2086 AKAMAI-ASN1, US 8551 2892 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2026 329 393 TELLCOM-AS, TR 9121 1963 1691 17 TTNET, TR 12479 1610 1044 53 UNI2-AS, ES 13188 1601 99 55 TRIOLAN, UA 12389 1525 1408 627 ROSTELECOM-AS, RU 6849 1225 355 21 UKRTELNET, UA 8402 1155 544 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3548 546 153 Telmex Colombia S.A., CO 8151 2514 3402 576 Uninet S.A. de C.V., MX 11830 2086 369 57 Instituto Costarricense de Electricidad 7303 1571 1011 249 Telecom Argentina S.A., AR 6503 1542 437 53 Axtel, S.A.B. de C.V., MX 6147 1299 377 27 Telefonica del Peru S.A.A., PE 3816 1026 501 94 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 968 2298 188 CLARO S.A., BR 11172 915 126 82 Alestra, S. de R.L. de C.V., MX 18881 896 1052 23 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1254 398 48 LINKdotNET-AS, EG 37611 724 91 8 Afrihost, ZA 36903 712 358 126 MT-MPLS, MA 36992 643 1375 26 ETISALAT-MISR, EG 24835 498 850 15 RAYA-AS, EG 37492 407 320 75 ORANGE-, TN 29571 401 36 10 CITelecom-AS, CI 15399 353 35 7 WANANCHI-, KE 8452 345 1730 17 TE-AS TE-AS, EG 2018 300 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5552 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3933 404 358 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3809 2953 160 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3548 546 153 Telmex Colombia S.A., CO 6327 3395 1333 81 SHAW - Shaw Communications Inc., CA 39891 3338 187 22 ALJAWWALSTC-AS, SA 17974 2976 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2897 964 2086 AKAMAI-ASN1, US 8551 2892 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 4766 2809 11135 760 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3809 3649 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3933 3575 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3548 3395 Telmex Colombia S.A., CO 39891 3338 3316 ALJAWWALSTC-AS, SA 6327 3395 3314 SHAW - Shaw Communications Inc., CA 17974 2976 2903 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2892 2852 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9829 2749 2209 BSNL-NIB National Internet Backbone, IN 9808 2204 2170 CMNET-GD Guangdong Mobile Communication Co.Ltd. 4766 2809 2049 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65010 PRIVATE 46.56.192.0/21 42772 VELCOM-AS, BY 65010 PRIVATE 46.56.224.0/21 42772 VELCOM-AS, BY 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65346 PRIVATE 94.50.36.0/22 31094 TTKNET Tyumen, Russia, RU 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 23.226.112.0/20 62788 -Reserved AS-, ZZ 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:280 /13:547 /14:1049 /15:1848 /16:13482 /17:7630 /18:13448 /19:24686 /20:38583 /21:41236 /22:77532 /23:64266 /24:365232 /25:875 /26:612 /27:643 /28:43 /29:34 /30:27 /31:3 /32:28 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3187 3395 SHAW - Shaw Communications Inc., CA 22773 2974 3809 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2898 3338 ALJAWWALSTC-AS, SA 8551 2357 2892 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 1946 2053 MEGAPATH5-US - MegaPath Corporation, US 30036 1584 1791 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1476 2086 Instituto Costarricense de Electricidad y Telec 10620 1473 3548 Telmex Colombia S.A., CO 11492 1373 1518 CABLEONE - CABLE ONE, INC., US 6389 1371 2064 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1602 2:824 4:18 5:2437 6:34 8:1037 12:1834 13:120 14:1751 15:27 16:2 17:126 18:91 20:61 23:2373 24:1871 25:2 27:2445 31:1914 32:82 33:14 35:20 36:417 37:2346 38:1328 39:57 40:97 41:3026 42:483 43:1929 44:72 45:2820 46:2790 47:155 49:1233 50:989 51:18 52:830 54:362 55:7 56:4 57:42 58:1583 59:1052 60:391 61:1957 62:1603 63:1914 64:4547 65:2219 66:4550 67:2272 68:1241 69:3402 70:1149 71:586 72:2200 74:2687 75:386 76:432 77:1504 78:1462 79:2268 80:1407 81:1391 82:996 83:719 84:895 85:1750 86:478 87:1158 88:763 89:2101 90:176 91:6191 92:976 93:2384 94:2380 95:2710 96:632 97:354 98:1052 99:86 100:154 101:1198 103:15094 104:2935 105:182 106:503 107:1706 108:820 109:2903 110:1455 111:1726 112:1199 113:1255 114:1027 115:1720 116:1795 117:1702 118:2201 119:1608 120:1043 121:1109 122:2262 123:1827 124:1494 125:1898 128:791 129:648 130:431 131:1403 132:527 133:199 134:656 135:225 136:459 137:438 138:1941 139:494 140:395 141:592 142:759 143:892 144:795 145:182 146:1028 147:688 148:1436 149:573 150:700 151:978 152:707 153:304 154:815 155:751 156:604 157:645 158:453 159:1507 160:672 161:744 162:2526 163:537 164:799 165:1393 166:386 167:1249 168:2700 169:785 170:3400 171:319 172:1014 173:1931 174:809 175:749 176:1882 177:4064 178:2475 179:1144 180:2211 181:1898 182:2363 183:995 184:866 185:9985 186:3168 187:2232 188:2703 189:1805 190:8234 191:1366 192:9477 193:5789 194:4661 195:3914 196:2111 197:1295 198:5502 199:5897 200:7442 201:4319 202:10358 203:9980 204:4479 205:2821 206:3015 207:3112 208:3990 209:3928 210:3969 211:2145 212:2849 213:2497 214:879 215:66 216:5680 217:2110 218:861 219:600 220:1692 221:913 222:773 223:1178 End of report From ryan.nsplist at gmail.com Fri Jun 23 19:59:35 2017 From: ryan.nsplist at gmail.com (Ryan L) Date: Fri, 23 Jun 2017 15:59:35 -0400 Subject: Long AS Path In-Reply-To: <68b1b794-5565-2106-adf2-201dca07bddf@satchell.net> References: <20170621.095626.74671742.sthaug@nethelp.no> <13197be6665b9e3940ea69bb7f3e70ce.squirrel@66.201.44.180> <68b1b794-5565-2106-adf2-201dca07bddf@satchell.net> Message-ID: I didn't see anyone answer (sorry if I missed it and this is redundant) ... In the path selection algorithm, local preference is processed before AS-PATH. Within your provider's AS, your prefixes could be a default localpref of 100, and learned prefixes from their peers 85, for example. In this case, Intra-AS will always be preferred due to higher lpref. You may prepend a handful of times out of your connection that is within the provider's AS, thus making the overall AS-PATH longer, but localpref still remains 100 vs. peer 85, so intra-AS still preferred. Some providers allow you to send community attributes with your prefixes to modify the localpref within the provider AS and make it lower than their peer localpref. Solves this particular conundrum. Couple examples: https://onestep.net/communities/as3356/ https://onestep.net/communities/as1299/ Depending on your allocation size and your needs, if you wanted to force all traffic over the "fast" link and use the "slow" link as an emergency backup, it could be easier to just announce more specific routes out the faster connection and send an aggregate out the backup one. No communities needed in that scenario. All depends on what you need to do, of course. HTH, Ryan On Thu, Jun 22, 2017 at 9:29 AM, Stephen Satchell wrote: > On 06/22/2017 04:27 AM, Jon Lewis wrote: > > > > You do have to wonder, what was the thought process that resulted in 35 > > being the right number of prepends "accomplish" whatever TE they were > > shooting for? > > > > AS path: 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 > > 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 > > 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 > > 55644 55644 55644 45271 > > > > I don't mean to single out 55644. It's just the first/most obnoxiously > > long as-path I found when looking for long ones. > > > > I seriously doubt provider/customer/customer-of-customer relationships > > ever get much deeper than a handful or so of ASNs...so if prepending a > > few times doesn't get it done, 10-20-30 prepends are unlikely to help. > > > > In the above case, that long path is actually our best path. We > > localpref peering above transit. So, it doesn't matter how many > > prepends, they add, we're never going to not use this path if its > > available. We have transit paths to these routes that are only a single > > handful of ASNs long. > > > I think I understand the problem, and now I understand why prepends > didn't do much for me. Over the years, I tended two multi-homed sites. > In both cases, the two uplinks had different speeds. When I used > prepend to try to get the outside world to prefer the faster link, some > traffic was stubborn about coming in the slow one. > > Difference in speeds? In the first network it was 45 mbps and 10 mbps. > In the second network it was 16 mbps and 1.5 mbps. Both network owners > were too stingy at the time to opt for harmonized rates. > > Question: how could communities be used to "force" preference for one > uplink over another by the peers? I'm long past needing this, but > others might benefit. (And when you stop learning, you're dead.) > From lee at asgard.org Fri Jun 23 15:09:23 2017 From: lee at asgard.org (Lee Howard) Date: Fri, 23 Jun 2017 11:09:23 -0400 Subject: IPv6 traffic percentages? In-Reply-To: <1498114850.2003210.1017519880.0B632BC0@webmail.messagingengine.com> References: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> <1498114850.2003210.1017519880.0B632BC0@webmail.messagingengine.com> Message-ID: On 6/22/17, 3:00 AM, "NANOG on behalf of Radu-Adrian Feurdean" wrote: >On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote: >> >> On 18 June 2017 at 17:36, Radu-Adrian Feurdean > adrian.feurdean.net> wrote:>> so for the record, business customers are >>much more active in >>> *rejecting* IPv6, either explictely (they say they want it >>> disabled) or>> implicitly (they install their own router, not >>>configured for >>> IPv6). The>> bigger the business, the bigger the chance of rejection. >> >> >> Did they per chance state their reasons for rejecting it? > >Not explicitly. But when we get something like "turn off that IPv6 crap >!" we take it for: - they don't have a clearly defined need for it > - they don't know how to deal with it > - they don't want to deal with things they don't need (see the > irst point)... usually all of them at the same time. That is my experience, too. When I was in IT, my response was to block IPv6 at the firewall (until I learned my firewall was incapable of examining IPv6 packets and therefore allowed ALL IPv6; I wasn’t allowed to change firewalls so I used a router ACL to block it while I reviewed our IPv6 security policy and looked for another job). When I was at an ISP, we could route IPv6 to the customer, but until they enabled it, no traffic would follow. > >To make it short : education. And we as as small ISP we have neither the >resources, nor the motivation (because $$$ on the issue is negative) to >do it (the education). I think you’re talking about business education, not technical IPv6 education, right? I recently posted my suggested technical reading list: http://www.wleecoyote.com/blog/IPv6reading.html But I think you’re asking for a business education series that goes: 1. Enterprise business consideration of IPv6 a. It’s already on your network. All computers, tablets and phones have at least Link Local, and some set up tunnels. Plus, if your employees have dual-stack at home but single—stack VPN, you may not like your split tunnel. b. Lower latency. c. Using IPv6 in interesting ways, like Segment Routing, Terastream bit masking, IPv6 address as process ID. d. IPv4 runout doesn’t matter much to most enterprises. They only need a couple of addresses for new branch offices. Those enterprises who have their own IPv4 address block (from RIR, not ISP/LIR) should consider how much they could sell it for. At $15/address, a /16 approaches US$1 million, which is real money to most CTOs. http://www.wleecoyote.com/blog/2017prices.htm 2. Enterprise IPv6 implementation guidance a. https://tools.ietf.org/html/rfc7381 “Enterprise IPv6 Deployment Guidelines” b. Cost to Renumber and Sell IPv4 http://retevia.net/Downloads/EnterpriseRenumbering.pdf I’ll see if I can write up #1 into a single paper or blog post in the next few days. Anything else I should add? Lee > From rod.beck at unitedcablecompany.com Fri Jun 23 20:57:46 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 23 Jun 2017 20:57:46 +0000 Subject: IPv6 traffic percentages? In-Reply-To: References: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> <1498114850.2003210.1017519880.0B632BC0@webmail.messagingengine.com>, Message-ID: The RIPE lab tests don't indicate any compelling network performance edge for IPV6. https://labs.ripe.net/Members/gih/examining-ipv6-performance. Large businesses have huge sunk costs in their existing infrastructure. Top it off with conservative bureaucratic mentalities and it is pretty clear why they avoid IPV4. ________________________________ From: NANOG on behalf of Lee Howard Sent: Friday, June 23, 2017 5:09:23 PM To: Radu-Adrian Feurdean; Mukom Akong T. Cc: NANOG list Subject: Re: IPv6 traffic percentages? On 6/22/17, 3:00 AM, "NANOG on behalf of Radu-Adrian Feurdean" wrote: >On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote: >> >> On 18 June 2017 at 17:36, Radu-Adrian Feurdean > adrian.feurdean.net> wrote:>> so for the record, business customers are >>much more active in >>> *rejecting* IPv6, either explictely (they say they want it >>> disabled) or>> implicitly (they install their own router, not >>>configured for >>> IPv6). The>> bigger the business, the bigger the chance of rejection. >> >> >> Did they per chance state their reasons for rejecting it? > >Not explicitly. But when we get something like "turn off that IPv6 crap >!" we take it for: - they don't have a clearly defined need for it > - they don't know how to deal with it > - they don't want to deal with things they don't need (see the > irst point)... usually all of them at the same time. That is my experience, too. When I was in IT, my response was to block IPv6 at the firewall (until I learned my firewall was incapable of examining IPv6 packets and therefore allowed ALL IPv6; I wasn�t allowed to change firewalls so I used a router ACL to block it while I reviewed our IPv6 security policy and looked for another job). When I was at an ISP, we could route IPv6 to the customer, but until they enabled it, no traffic would follow. > >To make it short : education. And we as as small ISP we have neither the >resources, nor the motivation (because $$$ on the issue is negative) to >do it (the education). I think you�re talking about business education, not technical IPv6 education, right? I recently posted my suggested technical reading list: http://www.wleecoyote.com/blog/IPv6reading.html But I think you�re asking for a business education series that goes: 1. Enterprise business consideration of IPv6 a. It�s already on your network. All computers, tablets and phones have at least Link Local, and some set up tunnels. Plus, if your employees have dual-stack at home but single�stack VPN, you may not like your split tunnel. b. Lower latency. c. Using IPv6 in interesting ways, like Segment Routing, Terastream bit masking, IPv6 address as process ID. d. IPv4 runout doesn�t matter much to most enterprises. They only need a couple of addresses for new branch offices. Those enterprises who have their own IPv4 address block (from RIR, not ISP/LIR) should consider how much they could sell it for. At $15/address, a /16 approaches US$1 million, which is real money to most CTOs. http://www.wleecoyote.com/blog/2017prices.htm 2. Enterprise IPv6 implementation guidance a. https://tools.ietf.org/html/rfc7381 �Enterprise IPv6 Deployment Guidelines� b. Cost to Renumber and Sell IPv4 http://retevia.net/Downloads/EnterpriseRenumbering.pdf I�ll see if I can write up #1 into a single paper or blog post in the next few days. Anything else I should add? Lee > From nanog at jima.us Fri Jun 23 21:58:21 2017 From: nanog at jima.us (Jima) Date: Fri, 23 Jun 2017 15:58:21 -0600 Subject: IPv6 traffic percentages? In-Reply-To: References: <0476488F-754A-4788-B840-35FCA51E32C1@tum.de> <1497792970.1661747.1013143008.71099492@webmail.messagingengine.com> <1498114850.2003210.1017519880.0B632BC0@webmail.messagingengine.com> Message-ID: <096fe54f-366b-134b-e43e-24cea9f866ba@jima.us> On 2017-06-23 09:09, Lee Howard wrote: > But I think you’re asking for a business education series that goes: > 1. Enterprise business consideration of IPv6 > a. It’s already on your network. All computers, tablets and phones have > at least Link Local, and some set up tunnels. Plus, if your employees have > dual-stack at home but single—stack VPN, you may not like your split > tunnel. Speaking with my Enterprise Day Job hat on... I started doing analytics on IPv6 client support regarding a (currently IPv4-only) employee-facing web app my team hosts. Turns out that in 15% of connections with IPv6, the IPv4 is coming from a subsidiary VPN, but the IPv6 isn't VPN'd -- supporting your point. (That number may be artificially low, in that not all of our business units restrict the users' source IP.) > d. IPv4 runout doesn’t matter much to most enterprises. They only need > a couple of addresses for new branch offices. Those enterprises who have > their own IPv4 address block (from RIR, not ISP/LIR) should consider how > much they could sell it for. At $15/address, a /16 approaches US$1 > million, which is real money to most CTOs. When you get big enough (and go through enough mergers & acquisitions), RFC1918 runout becomes a serious, legitimate concern. That's been a big selling point for me. Jima From jwbensley at gmail.com Sat Jun 24 07:41:54 2017 From: jwbensley at gmail.com (James Bensley) Date: Sat, 24 Jun 2017 08:41:54 +0100 Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> <581B3C93-8208-44C0-85A0-3640B4301ACD@enta.net> Message-ID: On 23 Jun 2017 17:03, "Mel Beckman" wrote: James, The question is whether you would actually hear of any problems. Chances are that the problem would be experienced by somebody else, who has no idea that your filtering was causing it. -mel beckman Hi Mel, For us this the answer is almost definitely a yes. We are an MSP (managed service provider) as opportunities to a traditional ISP, so our customers know they can open a ticket with us for pretty much anything and we'll try and look into it. We have had some weird issues with far away sites, first line can't find any issue, it works it's way up to somebody who knows how to check if we would be filtering a route on our transit and peering sessions. Earlier when I said that care is required when filtering long AS_PATH routes or certain AS numbers, we looked at the BGP table to see exactly which routes we'd drop before hand and communicated out these changes. I think for an MSP this shouldn't be hard to implement and manage, I can appreciate for a "flat" ISP ("he's some transit, help yourself") it could be more challenging. In relation to the OPs question, long AS_PATH routes can be filtered I just wouldn't bother except for very long paths to drop as little as possible and be sure of whY you drop/filter. Cheers, James. From mel at beckman.org Sat Jun 24 12:10:54 2017 From: mel at beckman.org (Mel Beckman) Date: Sat, 24 Jun 2017 12:10:54 +0000 Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> <581B3C93-8208-44C0-85A0-3640B4301ACD@enta.net> , Message-ID: <32A6E5B8-28FC-4E8B-98FA-3DA1ED6DA615@beckman.org> James, By "experienced by someone else" I mean someone who is not one of your customers. The better strategy, I think, is to not filter long paths unless you have a reason to see their creating a problem. Otherwise you're just operating on superstition, no? -mel via cell > On Jun 24, 2017, at 12:42 AM, James Bensley wrote: > > On 23 Jun 2017 17:03, "Mel Beckman" wrote: > > James, > > The question is whether you would actually hear of any problems. Chances > are that the problem would be experienced by somebody else, who has no idea > that your filtering was causing it. > > -mel beckman > > > Hi Mel, > > For us this the answer is almost definitely a yes. We are an MSP (managed > service provider) as opportunities to a traditional ISP, so our customers > know they can open a ticket with us for pretty much anything and we'll try > and look into it. > > We have had some weird issues with far away sites, first line can't find > any issue, it works it's way up to somebody who knows how to check if we > would be filtering a route on our transit and peering sessions. > > Earlier when I said that care is required when filtering long AS_PATH > routes or certain AS numbers, we looked at the BGP table to see exactly > which routes we'd drop before hand and communicated out these changes. I > think for an MSP this shouldn't be hard to implement and manage, I can > appreciate for a "flat" ISP ("he's some transit, help yourself") it could > be more challenging. > > In relation to the OPs question, long AS_PATH routes can be filtered I just > wouldn't bother except for very long paths to drop as little as possible > and be sure of whY you drop/filter. > > Cheers, > James. From bruns at 2mbit.com Sat Jun 24 17:18:58 2017 From: bruns at 2mbit.com (Brielle) Date: Sat, 24 Jun 2017 11:18:58 -0600 Subject: Centurylink contact for Boise? Message-ID: <544178FB-5BA8-4A49-A6E1-8AABAFBCA75C@2mbit.com> Hey all, apologies for formatting since I'm on my iPhone. Is there anyone on list that happens to know a contact for CenturyLink who can help with some major network issues going on in Boise? Nearly every customer I have with a DSL line is reporting severe and inconsistent connectivity issues with Microsoft, Reddit, Adobe, and even my servers in Washington state off of Westin. Biggest problem is that for every customer it's a different set of issues even though they are off of the same central offices. One can't get to MS, another can, while another has the reverse issue with Reddit. Mostly seeing connection timeouts to various ports (TCP and UDP), but yet can still ping the hosts. From my own DSL, for example, I can't browse reddit from one IP, but works fine from the next IP in the same subnet. That other IP can't establish an IAX2 tunnel to my coloc in WA, but my LAN firewall can. Its driving me nuts. Any insight from a CL engineer would be much appreciated. Brielle Sent from my iPhone From jwbensley at gmail.com Sun Jun 25 11:31:33 2017 From: jwbensley at gmail.com (James Bensley) Date: Sun, 25 Jun 2017 12:31:33 +0100 Subject: Long AS Path In-Reply-To: <32A6E5B8-28FC-4E8B-98FA-3DA1ED6DA615@beckman.org> References: <20170621.095626.74671742.sthaug@nethelp.no> <581B3C93-8208-44C0-85A0-3640B4301ACD@enta.net> <32A6E5B8-28FC-4E8B-98FA-3DA1ED6DA615@beckman.org> Message-ID: On 24 June 2017 at 13:10, Mel Beckman wrote: > James, > > By "experienced by someone else" I mean someone who is not one of your customers. > > The better strategy, I think, is to not filter long paths unless you have a reason to see their creating a problem. Otherwise you're just operating on superstition, no? > > -mel via cell Hi Mel, I mean this as a rhetorical question as we could talk until the end of time about this; what is the difference between operating on superstition and trying to be pro-active? Both for me fall under the category of "risk management". Cheers, James. From hf0002+nanog at uah.edu Mon Jun 26 14:40:20 2017 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Mon, 26 Jun 2017 14:40:20 +0000 Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> <581B3C93-8208-44C0-85A0-3640B4301ACD@enta.net> <32A6E5B8-28FC-4E8B-98FA-3DA1ED6DA615@beckman.org> Message-ID: This could just be ignorance, but based on this thread, I'm not sure what risk we would be managing, as DFZ router operators, by filtering those paths. They seem silly, but harmless (similar to, for instance, painting a nyan cat on a graph by announcing prefixes at certain times). On Sun, Jun 25, 2017 at 6:32 AM James Bensley wrote: > On 24 June 2017 at 13:10, Mel Beckman wrote: > > James, > > > > By "experienced by someone else" I mean someone who is not one of your > customers. > > > > The better strategy, I think, is to not filter long paths unless you > have a reason to see their creating a problem. Otherwise you're just > operating on superstition, no? > > > > -mel via cell > > Hi Mel, > > I mean this as a rhetorical question as we could talk until the end of > time about this; what is the difference between operating on > superstition and trying to be pro-active? Both for me fall under the > category of "risk management". > > Cheers, > James. > -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From michael.hare at wisc.edu Mon Jun 26 15:08:52 2017 From: michael.hare at wisc.edu (Michael Hare) Date: Mon, 26 Jun 2017 15:08:52 +0000 Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> <581B3C93-8208-44C0-85A0-3640B4301ACD@enta.net> <32A6E5B8-28FC-4E8B-98FA-3DA1ED6DA615@beckman.org> Message-ID: Couldn't one make the same argument with respect to filtering private ASNs from the global table? Unlike filtering of RFC1918 and the like a private ASN in the path isn't likely to leak RFC1918 like traffic, yet I believe several major ISPs have done just that. This topic was discussed ~1 year ago on NANOG. I do filter private ASNs but have not yet filtered long AS paths. Before I did it I had to contact a major CDN because I would have dropped their route, in the end costing me money (choosing transit vs peering). In the end, it is indeed risk vs reward, with risk being undefined behavior. It's plausible to speculate that not every path length bug has been squashed (or might not be re-introduced). -Michael > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hunter > Fuller > Sent: Monday, June 26, 2017 9:40 AM > To: James Bensley ; nanog at nanog.org > Subject: Re: Long AS Path > > This could just be ignorance, but based on this thread, I'm not sure what > risk we would be managing, as DFZ router operators, by filtering those > paths. They seem silly, but harmless (similar to, for instance, painting a > nyan cat on a graph by announcing prefixes at certain times). > > On Sun, Jun 25, 2017 at 6:32 AM James Bensley > wrote: > > > On 24 June 2017 at 13:10, Mel Beckman wrote: > > > James, > > > > > > By "experienced by someone else" I mean someone who is not one of > your > > customers. > > > > > > The better strategy, I think, is to not filter long paths unless you > > have a reason to see their creating a problem. Otherwise you're just > > operating on superstition, no? > > > > > > -mel via cell > > > > Hi Mel, > > > > I mean this as a rhetorical question as we could talk until the end of > > time about this; what is the difference between operating on > > superstition and trying to be pro-active? Both for me fall under the > > category of "risk management". > > > > Cheers, > > James. > > > -- > > -- > Hunter Fuller > Network Engineer > VBH Annex B-5 > +1 256 824 5331 > > Office of Information Technology > The University of Alabama in Huntsville > Systems and Infrastructure From mel at beckman.org Mon Jun 26 16:27:39 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 26 Jun 2017 16:27:39 +0000 Subject: Long AS Path In-Reply-To: References: <20170621.095626.74671742.sthaug@nethelp.no> <581B3C93-8208-44C0-85A0-3640B4301ACD@enta.net> <32A6E5B8-28FC-4E8B-98FA-3DA1ED6DA615@beckman.org> , Message-ID: <5CC4BA8E-8FBF-4AD4-835D-2C06265CE502@beckman.org> Michael, Filtering private ASNs is actually part of the standard. It's intrinsic in the term "private ASN". A private ASN in the public routing table is a clear error, so filtering them is reasonable. Long AS paths are not a clear error.' I'm surprised nobody here who complains about long paths is has followed my suggestion: call the ASN operator and ask them why they do it, and report the results here. Until somebody does that, I don't see long path filtering as morally defensible :) -mel beckman > On Jun 26, 2017, at 8:09 AM, Michael Hare wrote: > > Couldn't one make the same argument with respect to filtering private ASNs from the global table? Unlike filtering of RFC1918 and the like a private ASN in the path isn't likely to leak RFC1918 like traffic, yet I believe several major ISPs have done just that. This topic was discussed ~1 year ago on NANOG. > > I do filter private ASNs but have not yet filtered long AS paths. Before I did it I had to contact a major CDN because I would have dropped their route, in the end costing me money (choosing transit vs peering). > > In the end, it is indeed risk vs reward, with risk being undefined behavior. It's plausible to speculate that not every path length bug has been squashed (or might not be re-introduced). > > -Michael > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hunter >> Fuller >> Sent: Monday, June 26, 2017 9:40 AM >> To: James Bensley ; nanog at nanog.org >> Subject: Re: Long AS Path >> >> This could just be ignorance, but based on this thread, I'm not sure what >> risk we would be managing, as DFZ router operators, by filtering those >> paths. They seem silly, but harmless (similar to, for instance, painting a >> nyan cat on a graph by announcing prefixes at certain times). >> >> On Sun, Jun 25, 2017 at 6:32 AM James Bensley >> wrote: >> >>>> On 24 June 2017 at 13:10, Mel Beckman wrote: >>>> James, >>>> >>>> By "experienced by someone else" I mean someone who is not one of >> your >>> customers. >>>> >>>> The better strategy, I think, is to not filter long paths unless you >>> have a reason to see their creating a problem. Otherwise you're just >>> operating on superstition, no? >>>> >>>> -mel via cell >>> >>> Hi Mel, >>> >>> I mean this as a rhetorical question as we could talk until the end of >>> time about this; what is the difference between operating on >>> superstition and trying to be pro-active? Both for me fall under the >>> category of "risk management". >>> >>> Cheers, >>> James. >> -- >> >> -- >> Hunter Fuller >> Network Engineer >> VBH Annex B-5 >> +1 256 824 5331 >> >> Office of Information Technology >> The University of Alabama in Huntsville >> Systems and Infrastructure From amos at oasis-tech.net Sun Jun 25 16:22:59 2017 From: amos at oasis-tech.net (Amos Rosenboim) Date: Sun, 25 Jun 2017 19:22:59 +0300 Subject: Netflix fast.com performance Message-ID: <94E77344-F7E8-4F27-8132-44CB506CD7BE@oasis-tech.net> Hello, Lately we have been troubleshooting complaints from customers of several ISPs about relatively low results when testing to Netflix's fast.com When we started troubleshooting we notice the following: 1. When the latency to the fast.com test server is ~70ms results are significantly lower than speedtest.net results or Google fiber results. 2. When latency to the fast.com server is low (10-20ms, over DSL link) the results are similar between speedtest.net and fast.com When looking at packet captures of the fast.com test we notice the following: 1. fast.com pushes traffic very aggressively: we have applied a shaper with CIR=100Mbps and 200ms and even 500ms queue limit (cisco jargon) and still noticed drops when performing fast.com tests. 2. Packets originated from fast.com do not have the tcp push (psh) flag on. 3. It seems that fast.com recovery from packet loss is not very good over high latency (~70ms). It seems to us that after a packet loss even the server reaches his cwnd and stops transmitting for relatively long periods. We are interested to know if anybody else experience similar behaviour (with similar latency) or have any other insights into this. If you would like to take a look at captures performed over 70ms latency please PM and I'll share the files. Regards Amos From mark.tinka at seacom.mu Mon Jun 26 16:38:16 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 26 Jun 2017 18:38:16 +0200 Subject: SAFNOG-3: Call for Papers Now Out! Message-ID: Hello all. It gives me great pleasure to announce that the SAFNOG-3 Call for Papers is now out. You may review the CfP and all relevant submission details at the link below: http://safnog.org/papers.html We are working hard to put together an exciting, educational, informative and memorable agenda for this year's meeting. We look forward to receiving your submissions, and seeing you in Durban for our next meeting. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From jerry at jtcloe.net Sun Jun 25 14:48:12 2017 From: jerry at jtcloe.net (=?utf-8?Q?Jerry_Cloe?=) Date: Sun, 25 Jun 2017 09:48:12 -0500 Subject: Long AS Path In-Reply-To: References: Message-ID: Superstition has no basis in reality (i.e. black cat walks past DC door) Pro-Active is based on experience and knowledge (i.e. when disk space is 90% full for a regularly growing volume, we need to clean or add more before it hits 100%)   I mean this as a rhetorical question as we could talk until the end of time about this; what is the difference between operating on superstition and trying to be pro-active? Both for me fall under the category of "risk management". Cheers, James. From jheitz at cisco.com Tue Jun 27 13:26:18 2017 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Tue, 27 Jun 2017 13:26:18 +0000 Subject: Long AS Path In-Reply-To: References: Message-ID: <4DF0ABDD-F5BD-4A1F-8AED-7F2529FFA5CE@cisco.com> The reason that a private ASN in the public routing table is an error is that the AS Path is used to prevent loops. You may have private AS 65000 in your organization and I may have another private AS 65000 in my organization. If my ASN 65000 is in the AS path of a route sent to you, then your AS 65000 will drop it, thinking it were looping back. BTW, this is different from a confederation member AS. Thanks, Jakob. > Date: Mon, 26 Jun 2017 16:27:39 +0000 > From: Mel Beckman > To: Michael Hare > Cc: Hunter Fuller , James Bensley > , "nanog at nanog.org" > Subject: Re: Long AS Path > Message-ID: <5CC4BA8E-8FBF-4AD4-835D-2C06265CE502 at beckman.org> > Content-Type: text/plain; charset="us-ascii" > > Michael, > > Filtering private ASNs is actually part of the standard. It's intrinsic in the term "private ASN". A private ASN in the public routing table is a clear error, so filtering them is reasonable. Long AS paths are not a clear error.' > > I'm surprised nobody here who complains about long paths is has followed my suggestion: call the ASN operator and ask them why they do it, and report the results here. > > Until somebody does that, I don't see long path filtering as morally defensible :) > > -mel beckman > >> On Jun 26, 2017, at 8:09 AM, Michael Hare wrote: >> >> Couldn't one make the same argument with respect to filtering private ASNs from the global table? Unlike filtering of RFC1918 and the like a private ASN in the path isn't likely to leak RFC1918 like traffic, yet I believe several major ISPs have done just that. This topic was discussed ~1 year ago on NANOG. >> >> I do filter private ASNs but have not yet filtered long AS paths. Before I did it I had to contact a major CDN because I would have dropped their route, in the end costing me money (choosing transit vs peering). From jim at reptiles.org Tue Jun 27 14:49:46 2017 From: jim at reptiles.org (Jim Mercer) Date: Tue, 27 Jun 2017 10:49:46 -0400 Subject: someone at chef.io ? Message-ID: <20170627144946.GA98828@reptiles.org> hi, can someone from chef.io reach out to me? seems we got blocked for downloads somehow. --jim -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" -- Hunter S. Thompson From KShah at primustel.ca Tue Jun 27 20:28:17 2017 From: KShah at primustel.ca (Krunal Shah) Date: Tue, 27 Jun 2017 20:28:17 +0000 Subject: Point 2 point IPs between ASes Message-ID: Hello, What subnet mask you are people using for point to point IPs between two ASes? Specially with IPv6, We have a transit provider who wants us to use /64 which does not make sense for this purpose. isn’t it recommended to use /127 as per RFC 6164 like /30 and /31 are common for IPv4. I was thinking, if someone is using RFC7404 for point to point IP between two ASes and establish BGP over link local addresses. This way you have your own IP space on your router and transit provider does not have to allocate IP space for point to point interface between two ASes. In traceroutes you would see only loopback IP address with GUA assigned from your allocated routable address space. Remotely DDoS to this link isn’t possible this way. Thoughts? [Description: cid:image010.png at 01D1ECB6.5D17D120] Krunal Shah Network Analyst, IP & Transport Network Engineering O: 416-855-1805 kshah at primustel.ca [Description: cid:image011.png at 01D1ECB6.5D17D120] [Description: cid:image012.png at 01D1ECB6.5D17D120] [Description: cid:image013.png at 01D1ECB6.5D17D120] [Description: cid:image014.png at 01D1ECB6.5D17D120] ________________________________ This electronic message contains information from Primus Management ULC ("PRIMUS") , which may be legally privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail (to the number or address above) immediately. Any views, opinions or advice expressed in this electronic message are not necessarily the views, opinions or advice of PRIMUS. It is the responsibility of the recipient to ensure that any attachments are virus free and PRIMUS bears no responsibility for any loss or damage arising in any way from the use thereof.The term "PRIMUS" includes its affiliates. ________________________________ Pour la version en français de ce message, veuillez voir http://www.primustel.ca/fr/legal/cs.htm From niels=nanog at bakker.net Tue Jun 27 20:34:30 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 27 Jun 2017 22:34:30 +0200 Subject: Point 2 point IPs between ASes In-Reply-To: References: Message-ID: <20170627203430.GL86663@excession.tpb.net> * KShah at primustel.ca (Krunal Shah) [Tue 27 Jun 2017, 22:28 CEST]: >What subnet mask you are people using for point to point IPs between >two ASes? Specially with IPv6, We have a transit provider who wants >us to use /64 which does not make sense for this purpose. isn’t it >recommended to use /127 as per RFC 6164 like /30 and /31 are common >for IPv4. Whatever you want. >I was thinking, if someone is using RFC7404 for point to point IP >between two ASes and establish BGP over link local addresses. This >way you have your own IP space on your router and transit provider >does not have to allocate IP space for point to point interface >between two ASes. In traceroutes you would see only loopback IP >address with GUA assigned from your allocated routable address >space. Remotely DDoS to this link isn’t possible this way. Thoughts? If you can protect the loopback IP from DDoS you can equally protect linknet IPs. -- Niels. From job at instituut.net Tue Jun 27 20:36:43 2017 From: job at instituut.net (Job Snijders) Date: Tue, 27 Jun 2017 20:36:43 +0000 Subject: Point 2 point IPs between ASes In-Reply-To: References: Message-ID: On Tue, 27 Jun 2017 at 22:29, Krunal Shah wrote: > Hello, > > What subnet mask you are people using for point to point IPs between two > ASes? Specially with IPv6, We have a transit provider who wants us to use > /64 which does not make sense for this purpose. isn’t it recommended to use > /127 as per RFC 6164 like /30 and /31 are common for IPv4. Yes, "longer than /64" subnets are fine for point2point. If the equipment on both sides supports RFC 6164 I'd use a /127, otherwise a /126. I was thinking, if someone is using RFC7404 for point to point IP between > two ASes and establish BGP over link local addresses. This way you have > your own IP space on your router and transit provider does not have to > allocate IP space for point to point interface between two ASes. In > traceroutes you would see only loopback IP address with GUA assigned from > your allocated routable address space. Remotely DDoS to this link isn’t > possible this way. Thoughts? I wouldn't use link-local in context of Inter-Domain Routing. Too hard to troubleshoot, many networks expect globally unique IP addresses for their BGP neighbors, you want to be able to call a NOC and have the IPs function as semaphore for the circuit ID. What you could do is set aside a block which you blackhole or tarpit through ingress ACLs, and use linknets from that "globally unusable ip space". Some providers can offer you a router2router linknet from such unreachable IP space so you don't have to set it apart. Kind regards, Job > From beecher at beecher.cc Wed Jun 28 12:20:57 2017 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 28 Jun 2017 08:20:57 -0400 Subject: Point 2 point IPs between ASes In-Reply-To: References: Message-ID: You should be using /126 or /127 for point to point links that touch external networks unless you like extraneous NS messages and full neighbor cache tables. :) On Tue, Jun 27, 2017 at 4:36 PM, Job Snijders wrote: > On Tue, 27 Jun 2017 at 22:29, Krunal Shah wrote: > > > Hello, > > > > What subnet mask you are people using for point to point IPs between two > > ASes? Specially with IPv6, We have a transit provider who wants us to use > > /64 which does not make sense for this purpose. isn’t it recommended to > use > > /127 as per RFC 6164 like /30 and /31 are common for IPv4. > > > > Yes, "longer than /64" subnets are fine for point2point. If the equipment > on both sides supports RFC 6164 I'd use a /127, otherwise a /126. > > > I was thinking, if someone is using RFC7404 for point to point IP between > > two ASes and establish BGP over link local addresses. This way you have > > your own IP space on your router and transit provider does not have to > > allocate IP space for point to point interface between two ASes. In > > traceroutes you would see only loopback IP address with GUA assigned from > > your allocated routable address space. Remotely DDoS to this link isn’t > > possible this way. Thoughts? > > > I wouldn't use link-local in context of Inter-Domain Routing. Too hard to > troubleshoot, many networks expect globally unique IP addresses for their > BGP neighbors, you want to be able to call a NOC and have the IPs function > as semaphore for the circuit ID. > > What you could do is set aside a block which you blackhole or tarpit > through ingress ACLs, and use linknets from that "globally unusable ip > space". Some providers can offer you a router2router linknet from such > unreachable IP space so you don't have to set it apart. > > Kind regards, > > Job > > > > From bill at herrin.us Wed Jun 28 15:03:01 2017 From: bill at herrin.us (William Herrin) Date: Wed, 28 Jun 2017 11:03:01 -0400 Subject: Point 2 point IPs between ASes In-Reply-To: References: Message-ID: Hello, The common recommendations for IPv6 point to point interface numbering are: /64 /124 /126 /127 /64: Advantages: conforms to IPv6 standard for a LAN link Disadvantages: DOS threats against this design. Looping on a true ptp circuit. Neighbor discovery issues. /124: Advantages: supports multiple routers on each end of the circuit. Conforms to nibble assignment boundary that helps keep address assignments clean and comprehensible. Disadvantages: ancient hardware that barely supports IPv6 may have trouble efficiently handling routes longer than /64. /126: Advantages: equivalent to an IPv4 /30 with exactly the same functionality. Disadvantages: equivalent to an IPv4 /30 with exactly the same functionality. /127: Advantages: saves that extra pair of IP addresses. Disadvantages: complicates configuration just to save two IPv6 addresses. Enhancements: For /124, /126 and /127: allocate all of your addresses for every router in the system from the same /64. Use router ACLs to control entry of packets directed to that /64. Nice clean way to stop hackers from poking at your routers. Regards, Bill Herrin On Tue, Jun 27, 2017 at 4:28 PM, Krunal Shah wrote: > Hello, > > What subnet mask you are people using for point to point IPs between two > ASes? Specially with IPv6, We have a transit provider who wants us to use > /64 which does not make sense for this purpose. isn’t it recommended to use > /127 as per RFC 6164 like /30 and /31 are common for IPv4. > > I was thinking, if someone is using RFC7404 for point to point IP between > two ASes and establish BGP over link local addresses. This way you have > your own IP space on your router and transit provider does not have to > allocate IP space for point to point interface between two ASes. In > traceroutes you would see only loopback IP address with GUA assigned from > your allocated routable address space. Remotely DDoS to this link isn’t > possible this way. Thoughts? > > > > [Description: cid:image010.png at 01D1ECB6.5D17D120] > > > > > > Krunal Shah > Network Analyst, IP & Transport Network Engineering > O: 416-855-1805 > kshah at primustel.ca > > > > > > [Description: cid:image011.png at 01D1ECB6.5D17D120] > [Description: cid:image012.png at 01D1ECB6.5D17D120] Primus4Business> [Description: cid:image013.png at 01D1ECB6.5D17D120] < > https://www.facebook.com/primusforbusiness> [Description: > cid:image014.png at 01D1ECB6.5D17D120] company/primus-telecommunications-canada-inc-> > > > > ________________________________ > > This electronic message contains information from Primus Management ULC > ("PRIMUS") , which may be legally privileged and confidential. The > information is intended to be for the use of the individual(s) or entity > named above. If you are not the intended recipient, be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic message in > error, please notify us by telephone or e-mail (to the number or address > above) immediately. Any views, opinions or advice expressed in this > electronic message are not necessarily the views, opinions or advice of > PRIMUS. It is the responsibility of the recipient to ensure that any > attachments are virus free and PRIMUS bears no responsibility for any loss > or damage arising in any way from the use thereof.The term "PRIMUS" > includes its affiliates. > > ________________________________ > Pour la version en français de ce message, veuillez voir > http://www.primustel.ca/fr/legal/cs.htm > -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From jamesb2147 at gmail.com Wed Jun 28 15:49:48 2017 From: jamesb2147 at gmail.com (Sean Hunter) Date: Wed, 28 Jun 2017 10:49:48 -0500 Subject: Internetpulse.net is dead Message-ID: Anyone know of a site with similar functionality? internetpulse.net redirects to Dynatrace homepage now. From baldur.norddahl at gmail.com Wed Jun 28 18:04:01 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 28 Jun 2017 20:04:01 +0200 Subject: Point 2 point IPs between ASes In-Reply-To: References: Message-ID: What subnet mask you are people using for point to point IPs between two ASes? Specially with IPv6, We have a transit provider who wants us to use /64 which does not make sense for this purpose. isn’t it recommended to use /127 as per RFC 6164 like /30 and /31 are common for IPv4. You can just ignore that and configure it as a /126 from your end. Does not matter if they configure their end as a /64 assuming the actual assigned addresses fit in a /126. Regards Baldur From josh at kyneticwifi.com Wed Jun 28 21:36:09 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Wed, 28 Jun 2017 16:36:09 -0500 Subject: Internetpulse.net is dead In-Reply-To: References: Message-ID: ... it might help explaining what the site did. - Josh On Jun 28, 2017 10:51 AM, "Sean Hunter" wrote: > Anyone know of a site with similar functionality? internetpulse.net > redirects to Dynatrace homepage now. > From jamesb2147 at gmail.com Wed Jun 28 22:18:45 2017 From: jamesb2147 at gmail.com (Sean Hunter) Date: Wed, 28 Jun 2017 17:18:45 -0500 Subject: Internetpulse.net is dead In-Reply-To: References: Message-ID: It displayed real-time(-ish) latency and packet loss between major networks. As companies were acquired, this became less useful, but it still had it moments. http://web.archive.org/web/20161003195519/http://internetpulse.com:80/ For the visually oriented, see the link above. On Wed, Jun 28, 2017 at 4:36 PM, Josh Reynolds wrote: > ... it might help explaining what the site did. > > - Josh > > On Jun 28, 2017 10:51 AM, "Sean Hunter" wrote: > >> Anyone know of a site with similar functionality? internetpulse.net >> redirects to Dynatrace homepage now. >> > From bill at herrin.us Wed Jun 28 22:44:08 2017 From: bill at herrin.us (William Herrin) Date: Wed, 28 Jun 2017 18:44:08 -0400 Subject: Point 2 point IPs between ASes In-Reply-To: <59541B05.4090002@nsc.liu.se> References: <59541B05.4090002@nsc.liu.se> Message-ID: On Wed, Jun 28, 2017 at 5:09 PM, Thomas Bellman wrote: > On 2017-06-28 17:03, William Herrin wrote: > > > The common recommendations for IPv6 point to point interface numbering > are: > > /64 > > /124 > > /126 > > /127 > > I thought the only allowed subnet prefix lengths for IPv6 were /64 and > /127. RFC 4291 states: > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > (and addresses starting with 000 are only used for special things, > like the localhost address ::1). And then RFC 6164 adds /127 to > the allowed prefix lengths. > > I know that many devices allow you to configure any subnet size, > but is there any RFC allowing you to use e.g. /124 or /126? > Hi Thomas, AFAICT, the IETF has not caught up with operations practice... and operations practice itself is still in flux. I do see some discussion of longer-than-/64 prefixes in RFC 7421. The difference between theory and practice? In theory, there is no difference. IPv6 overall is designed to support CIDR addressing at any netmask. Correct implementations may not assume that any given interface will host a /64. Some specific protocols (like SLAAC) intentionally do not work if the interface ID is not exactly 64 bits. Others become more difficult than necessary if the prefix is not on a nibble boundary (the /CIDR number is not evenly divisible by 4). In the mean time, the options that have come out of OPERATIONS activity for point to point connections have converged on the above 4. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From aaron1 at gvtc.com Thu Jun 29 00:01:18 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 28 Jun 2017 19:01:18 -0500 Subject: Point 2 point IPs between ASes In-Reply-To: References: Message-ID: <001f01d2f06a$d5d87ca0$818975e0$@gvtc.com> I think this is funny... I have (4) 10 gig internet connections and here's the maskings for my v6 dual stacking... /126 - telia /64 - att /112 - cogent /127 - twc/charter/spectrum - Aaron Gould From bill at herrin.us Thu Jun 29 00:32:57 2017 From: bill at herrin.us (William Herrin) Date: Wed, 28 Jun 2017 20:32:57 -0400 Subject: Point 2 point IPs between ASes In-Reply-To: <001f01d2f06a$d5d87ca0$818975e0$@gvtc.com> References: <001f01d2f06a$d5d87ca0$818975e0$@gvtc.com> Message-ID: On Wed, Jun 28, 2017 at 8:01 PM, Aaron Gould wrote: > I think this is funny... I have (4) 10 gig internet connections and here's > the maskings for my v6 dual stacking... > > /126 - telia > /64 - att > /112 - cogent > /127 - twc/charter/spectrum > 112... Could be worse I suppose. They could have picked 113. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From cma at cmadams.net Thu Jun 29 01:10:26 2017 From: cma at cmadams.net (Chris Adams) Date: Wed, 28 Jun 2017 20:10:26 -0500 Subject: Point 2 point IPs between ASes In-Reply-To: References: <001f01d2f06a$d5d87ca0$818975e0$@gvtc.com> Message-ID: <20170629011026.GA2340@cmadams.net> Once upon a time, William Herrin said: > 112... Could be worse I suppose. They could have picked 113. A /112 means you can always use ::1 and ::2 for you endpoints. Of course, you could allocate at /112 boundary and still use a /126 (or even a /127 and use ::0 and ::1). -- Chris Adams From olivier.benghozi at wifirst.fr Thu Jun 29 01:10:47 2017 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Thu, 29 Jun 2017 03:10:47 +0200 Subject: Point 2 point IPs between ASes In-Reply-To: References: <001f01d2f06a$d5d87ca0$818975e0$@gvtc.com> Message-ID: <0D3AAB86-C266-4E2E-BF10-6B61D5E53AE6@wifirst.fr> Well, /112 is not a stupid option (and is far smarter than /64): it contains the whole last nibble of an IPv6, that is x:x:x:x:x:x:x:1234. You always put 1 or 2 at the end, and if needed you are still able to address additional stuff would the point-to-point link become a LAN. And you don't throw away billions of addresses like with /64. > On 29 jun 2017 at 02:32, William Herrin wrote : > > On Wed, Jun 28, 2017 at 8:01 PM, Aaron Gould wrote: > >> I think this is funny... I have (4) 10 gig internet connections and here's >> the maskings for my v6 dual stacking... >> >> /126 - telia >> /64 - att >> /112 - cogent >> /127 - twc/charter/spectrum > > 112... Could be worse I suppose. They could have picked 113. From joelja at bogus.com Thu Jun 29 01:43:32 2017 From: joelja at bogus.com (joel jaeggli) Date: Wed, 28 Jun 2017 18:43:32 -0700 Subject: Point 2 point IPs between ASes In-Reply-To: <0D3AAB86-C266-4E2E-BF10-6B61D5E53AE6@wifirst.fr> References: <001f01d2f06a$d5d87ca0$818975e0$@gvtc.com> <0D3AAB86-C266-4E2E-BF10-6B61D5E53AE6@wifirst.fr> Message-ID: On 6/28/17 18:10, Olivier Benghozi wrote: > Well, /112 is not a stupid option (and is far smarter than /64): it contains the whole last nibble of an IPv6, that is x:x:x:x:x:x:x:1234. > You always put 1 or 2 at the end, and if needed you are still able to address additional stuff would the point-to-point link become a LAN. > And you don't throw away billions of addresses like with /64. If you were subnetting down from /64 for the purposes of preventing ndp exhaustion or to protect the control plane on either yours or your customers platforms then a /112 is pretty useless because 16 bits is harmful enough. https://tools.ietf.org/html/rfc6583 https://tools.ietf.org/html/rfc6164 >> On 29 jun 2017 at 02:32, William Herrin wrote : >> >> On Wed, Jun 28, 2017 at 8:01 PM, Aaron Gould wrote: >> >>> I think this is funny... I have (4) 10 gig internet connections and here's >>> the maskings for my v6 dual stacking... >>> >>> /126 - telia >>> /64 - att >>> /112 - cogent >>> /127 - twc/charter/spectrum >> 112... Could be worse I suppose. They could have picked 113. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From joelja at bogus.com Thu Jun 29 02:10:02 2017 From: joelja at bogus.com (joel jaeggli) Date: Wed, 28 Jun 2017 19:10:02 -0700 Subject: Point 2 point IPs between ASes In-Reply-To: References: <59541B05.4090002@nsc.liu.se> Message-ID: <484595ce-8b05-a0f5-16de-f861859901ba@bogus.com> On 6/28/17 15:44, William Herrin wrote: > On Wed, Jun 28, 2017 at 5:09 PM, Thomas Bellman wrote: > >> On 2017-06-28 17:03, William Herrin wrote: >> >>> The common recommendations for IPv6 point to point interface numbering >> are: >>> /64 >>> /124 >>> /126 >>> /127 >> I thought the only allowed subnet prefix lengths for IPv6 were /64 and >> /127. RFC 4291 states: >> >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long and to be >> constructed in Modified EUI-64 format. >> >> (and addresses starting with 000 are only used for special things, >> like the localhost address ::1). And then RFC 6164 adds /127 to >> the allowed prefix lengths. >> >> I know that many devices allow you to configure any subnet size, >> but is there any RFC allowing you to use e.g. /124 or /126? >> > Hi Thomas, > > AFAICT, the IETF has not caught up with operations practice... there's a certain amount of style drift, I think the rfc series actually captures quite a bit of it. > and > operations practice itself is still in flux. I do see some discussion of > longer-than-/64 prefixes in RFC 7421. I'm not so sure about that, While operators have a variety of preferences some of which I fix quixotic; which were formed as much as 2 decades ago. it's been about 6 years since we had a standards track consensus describing the rational for numbering point-to-point links out of /127s (6164). Which is long enough for text books to have been updated, silicon implemntations of tcams to use exact match instead of longest match lookups for your connected neighbor on a /127 and so on. likewise mitigations for ND exhaustion attacks exist even if they are not universally implemented or perfect so some if not all the motivation for short prefixes has been ameliorated. one can argue that concern in rfc3627 (subnet router anycast) is entirely irrelevant for point to point links (the rfc is now historic for that reason) which was the major motivation for /126 vs /127 14 years ago. in other news isps that apparently haven't run out of ipv4 addresses are still assigning me /30 point-to-point links. > The difference between theory and practice? In theory, there is no > difference. > > IPv6 overall is designed to support CIDR addressing at any netmask. Correct > implementations may not assume that any given interface will host a /64. > Some specific protocols (like SLAAC) intentionally do not work if the > interface ID is not exactly 64 bits. Others become more difficult than > necessary if the prefix is not on a nibble boundary (the /CIDR number is > not evenly divisible by 4). > > In the mean time, the options that have come out of OPERATIONS activity for > point to point connections have converged on the above 4. > > Regards, > Bill Herrin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From bill at herrin.us Thu Jun 29 03:26:20 2017 From: bill at herrin.us (William Herrin) Date: Wed, 28 Jun 2017 23:26:20 -0400 Subject: Point 2 point IPs between ASes In-Reply-To: <0D3AAB86-C266-4E2E-BF10-6B61D5E53AE6@wifirst.fr> References: <001f01d2f06a$d5d87ca0$818975e0$@gvtc.com> <0D3AAB86-C266-4E2E-BF10-6B61D5E53AE6@wifirst.fr> Message-ID: On Wed, Jun 28, 2017 at 9:10 PM, Olivier Benghozi < olivier.benghozi at wifirst.fr> wrote: > Well, /112 is not a stupid option (and is far smarter than /64): it > contains the whole last nibble of an IPv6, that is x:x:x:x:x:x:x:1234. > You always put 1 or 2 at the end, and if needed you are still able to > address additional stuff would the point-to-point link become a LAN. > And you don't throw away billions of addresses like with /64. > Hi Oliver, You can always put 1 and 2 at the end on a /124 as well and add additional devices. These are the same advantages of /124 over /126. And /124 doesn't suffer from ND exhaustion attacks like /112 might. The only thing /112 buys you (that I can see) is a single colon in front of the final digit. I don't see how /112 would be a good choice. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From aaron1 at gvtc.com Thu Jun 29 04:51:18 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 28 Jun 2017 23:51:18 -0500 Subject: Point 2 point IPs between ASes In-Reply-To: References: <001f01d2f06a$d5d87ca0$818975e0$@gvtc.com> Message-ID: <000201d2f093$590d0550$0b270ff0$@gvtc.com> Thanks Bill, I thought with ipv6 it was a sin to subnet on bit boundaries and not on nibble boundaries. Heck, I’m gonna do whatever it takes to NOT subnet on bits with my v6 deployment. Hopefully with v6, gone are the days of binary subnetting math. -Aaron Gould From: William Herrin [mailto:bill at herrin.us] Sent: Wednesday, June 28, 2017 7:33 PM To: Aaron Gould Cc: Tom Beecher ; Job Snijders ; nanog at nanog.org Subject: Re: Point 2 point IPs between ASes On Wed, Jun 28, 2017 at 8:01 PM, Aaron Gould > wrote: I think this is funny... I have (4) 10 gig internet connections and here's the maskings for my v6 dual stacking... /126 - telia /64 - att /112 - cogent /127 - twc/charter/spectrum 112... Could be worse I suppose. They could have picked 113. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From janusz at speedchecker.xyz Thu Jun 29 07:01:07 2017 From: janusz at speedchecker.xyz (Janusz Jezowicz) Date: Thu, 29 Jun 2017 09:01:07 +0200 Subject: Internetpulse.net is dead In-Reply-To: References: Message-ID: I guess one way is to compile list of Looking Glass servers on those providers and also list of IPs that belong to those and start pinging each other to produce the matrix. You can also try RIPE Atlas or www.maplatency.com. RIPE and Maplatency can be automated using API so the matrix could be built automatically. In any case you will need to find out destination IPs within the network so you have something to ping (that should not be that hard, you can use https://radar.tools.cdn77.com/ for that) Disclosure: I work for Speedchecker which created Maplatency On 29 June 2017 at 00:18, Sean Hunter wrote: > It displayed real-time(-ish) latency and packet loss between major > networks. As companies were acquired, this became less useful, but it still > had it moments. > > http://web.archive.org/web/20161003195519/http://internetpulse.com:80/ > > For the visually oriented, see the link above. > > On Wed, Jun 28, 2017 at 4:36 PM, Josh Reynolds > wrote: > > > ... it might help explaining what the site did. > > > > - Josh > > > > On Jun 28, 2017 10:51 AM, "Sean Hunter" wrote: > > > >> Anyone know of a site with similar functionality? internetpulse.net > >> redirects to Dynatrace homepage now. > >> > > > From bellman at nsc.liu.se Wed Jun 28 21:09:25 2017 From: bellman at nsc.liu.se (Thomas Bellman) Date: Wed, 28 Jun 2017 23:09:25 +0200 Subject: Point 2 point IPs between ASes In-Reply-To: References: Message-ID: <59541B05.4090002@nsc.liu.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2017-06-28 17:03, William Herrin wrote: > The common recommendations for IPv6 point to point interface numbering are: > > /64 > /124 > /126 > /127 I thought the only allowed subnet prefix lengths for IPv6 were /64 and /127. RFC 4291 states: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. (and addresses starting with 000 are only used for special things, like the localhost address ::1). And then RFC 6164 adds /127 to the allowed prefix lengths. I know that many devices allow you to configure any subnet size, but is there any RFC allowing you to use e.g. /124 or /126? /Bellman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJZVBsFAAoJEGqUdKqa3HTsoDEP/10rXGS7TN/3aEG+IfwyQ3bP +mvNu/uV8Jv8PGfXgjIdD8gr07MqxoGP0pLFB2bEGrQ9dLJVhkLIpksSx6Q6su3y Ym5wDpB/DZnQ1uESN69T4xJtt32Or6L7+/NhehnVfDvoHOd79t9sNuaOu+/z8c2K +OOyc8TwTX+HVhoGfHa4dG7BPh7rUgzZImuGsycpElbt4r75qByZyztPCgjWRTg1 f0/leuFVvIwTA5OY8ZX7WPzdLiOU3f0H6NlKKYZUSsZQCDQfp8DU2S85fj3ZWVB3 vRJKUT2hVF0/q13tK7C16QGpr28hue6xEnscE2GZ3xrjI1yteNZLvbRjQJbco8D0 Z8UHTiUSwdYZgKViVgmxFDS7mrTZCrwwrZMI44mPwub3txgLEEzXmkwMDSvRYVL9 9nAVzCvt3+QKrR1zNQD8ttt0Xg+QENTdTD0NI8iMMkFENXC82cuV1y3UnHYRORdJ r2Uupzps3eQlxa1Uk7SC4sDs17PmBEVpFCtbtEZjCFYdc3PlDmV6wu6/WuXutMox eVDTMgHN3m16ZOXY2U4V5PmW3xvqQ/J+vzE7WyKe5DP5bZPHlddupw4MPPz7+8IG 4O5wOqjAFX8HhNpPMZZjUHxrWvYLEYvGzn8GI06tLKb49+Wq3ux4i2HUUHm/jIf+ GMOQkPABxUntAaPjOzzX =IMMo -----END PGP SIGNATURE----- From kweller at omegasystemscorp.com Thu Jun 29 12:56:34 2017 From: kweller at omegasystemscorp.com (Kyle Weller) Date: Thu, 29 Jun 2017 12:56:34 +0000 Subject: Internetpulse.net is dead In-Reply-To: References: Message-ID: Good work, However the constant captcha sucks allot, can you add a few shorter frequencies? Maybe 1-10 seconds rather than one minute intervals? I'd also like to see perhaps a graph view of Comcast, Level3, Verizon, etc to see if any latency between networks perhaps done via traceroutes? Thanks, Kyle Weller -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Janusz Jezowicz Sent: Thursday, June 29, 2017 3:01 AM To: Sean Hunter Cc: NANOG Subject: Re: Internetpulse.net is dead I guess one way is to compile list of Looking Glass servers on those providers and also list of IPs that belong to those and start pinging each other to produce the matrix. You can also try RIPE Atlas or www.maplatency.com. RIPE and Maplatency can be automated using API so the matrix could be built automatically. In any case you will need to find out destination IPs within the network so you have something to ping (that should not be that hard, you can use https://linkprotect.cudasvc.com/url?a=https://radar.tools.cdn77.com/&c=E,1,b5YPgTjwBumoJT2-MEUXY-0vdnUzLi1Q6rZbQiGVvC1rN-v6lnxlIZGswzLS23K9C3NVDTHgvRkoVpx214iwp5yMZZ3JG9Vvi6nsQFibIxnI8HwTEYw,&typo=1 for that) Disclosure: I work for Speedchecker which created Maplatency On 29 June 2017 at 00:18, Sean Hunter wrote: > It displayed real-time(-ish) latency and packet loss between major > networks. As companies were acquired, this became less useful, but it > still had it moments. > > http://web.archive.org/web/20161003195519/http://internetpulse.com:80/ > > For the visually oriented, see the link above. > > On Wed, Jun 28, 2017 at 4:36 PM, Josh Reynolds > wrote: > > > ... it might help explaining what the site did. > > > > - Josh > > > > On Jun 28, 2017 10:51 AM, "Sean Hunter" wrote: > > > >> Anyone know of a site with similar functionality? > >> https://linkprotect.cudasvc.com/url?a=https://internetpulse.net&c=E > >> ,1,2FQrgejwwpolnJAgJOR0dOtA9XZN9ji6Cr9Y6EDOFw082geN5u8lDTpnKWS5BUR_ > >> jNxrU8yPHXoYo2aFCVldVlAAxBof8CdaFhLrgQ,,&typo=1 > >> redirects to Dynatrace homepage now. > >> > > > ________________________________ This electronic mail message and any attachments contain information which is (a) LEGALLY PRIVILEGED, PROPRIETARY AND CONFIDENTIAL IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) intended only for the use of certain intended recipients. If you are not the intended recipient, reading, copying, or distributing this message is prohibited. If you have received this electronic mail message in error, please contact us immediately at (610) 678-7002 and delete the message from your computer system. From kweller at omegasystemscorp.com Thu Jun 29 12:57:27 2017 From: kweller at omegasystemscorp.com (Kyle Weller) Date: Thu, 29 Jun 2017 12:57:27 +0000 Subject: Internetpulse.net is dead References: Message-ID: <85a331d7d3cc49b4b84f8f6950396a0e@OMEGA-PA-EXCH01.OmegaSystems.local> Also the dropdown for network, can you add search capability so no scrolling need? Looking good so far, I'll use this daily. Thanks, Kyle Weller Kyle Weller Quality Control Administrator Office 610.678.7002 | Service Desk 484.772.1110 Managed Services Cloud Services Disaster Recovery website | email | LinkedIn | Google + -----Original Message----- From: Kyle Weller Sent: Thursday, June 29, 2017 8:56 AM To: 'Janusz Jezowicz' ; Sean Hunter Cc: NANOG Subject: RE: Internetpulse.net is dead Good work, However the constant captcha sucks allot, can you add a few shorter frequencies? Maybe 1-10 seconds rather than one minute intervals? I'd also like to see perhaps a graph view of Comcast, Level3, Verizon, etc to see if any latency between networks perhaps done via traceroutes? Thanks, Kyle Weller -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Janusz Jezowicz Sent: Thursday, June 29, 2017 3:01 AM To: Sean Hunter Cc: NANOG Subject: Re: Internetpulse.net is dead I guess one way is to compile list of Looking Glass servers on those providers and also list of IPs that belong to those and start pinging each other to produce the matrix. You can also try RIPE Atlas or www.maplatency.com. RIPE and Maplatency can be automated using API so the matrix could be built automatically. In any case you will need to find out destination IPs within the network so you have something to ping (that should not be that hard, you can use https://linkprotect.cudasvc.com/url?a=https://radar.tools.cdn77.com/&c=E,1,b5YPgTjwBumoJT2-MEUXY-0vdnUzLi1Q6rZbQiGVvC1rN-v6lnxlIZGswzLS23K9C3NVDTHgvRkoVpx214iwp5yMZZ3JG9Vvi6nsQFibIxnI8HwTEYw,&typo=1 for that) Disclosure: I work for Speedchecker which created Maplatency On 29 June 2017 at 00:18, Sean Hunter wrote: > It displayed real-time(-ish) latency and packet loss between major > networks. As companies were acquired, this became less useful, but it > still had it moments. > > http://web.archive.org/web/20161003195519/http://internetpulse.com:80/ > > For the visually oriented, see the link above. > > On Wed, Jun 28, 2017 at 4:36 PM, Josh Reynolds > wrote: > > > ... it might help explaining what the site did. > > > > - Josh > > > > On Jun 28, 2017 10:51 AM, "Sean Hunter" wrote: > > > >> Anyone know of a site with similar functionality? > >> https://linkprotect.cudasvc.com/url?a=https://internetpulse.net&c=E > >> ,1,2FQrgejwwpolnJAgJOR0dOtA9XZN9ji6Cr9Y6EDOFw082geN5u8lDTpnKWS5BUR_ > >> jNxrU8yPHXoYo2aFCVldVlAAxBof8CdaFhLrgQ,,&typo=1 > >> redirects to Dynatrace homepage now. > >> > > > ________________________________ This electronic mail message and any attachments contain information which is (a) LEGALLY PRIVILEGED, PROPRIETARY AND CONFIDENTIAL IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) intended only for the use of certain intended recipients. If you are not the intended recipient, reading, copying, or distributing this message is prohibited. If you have received this electronic mail message in error, please contact us immediately at (610) 678-7002 and delete the message from your computer system. From pozar at lns.com Thu Jun 29 01:41:21 2017 From: pozar at lns.com (Tim Pozar) Date: Wed, 28 Jun 2017 18:41:21 -0700 Subject: Russian diplomats lingering near fiber optic cables In-Reply-To: References: <68977.1496415879@turing-police.cc.vt.edu> <7782.1496421991@turing-police.cc.vt.edu> <16678.1496428835@turing-police.cc.vt.edu> Message-ID: I pretended to be a Russian diplomat today. Tim On 6/3/17 12:13 PM, Matthew Petach wrote: > On Fri, Jun 2, 2017 at 11:40 AM, wrote: > [...] >> >> Well, I'd be willing to buy that logic, except the specific buildings called >> out look pretty damned big for just drying off a cable. For example, this >> is claimed to be the US landing point for TAT-14 - looks around 4K square feet? > > I think you might be off by an order of magnitude or two > on that. 4,000 sq ft is about the size of the guest bathroom > in Snowhorn's new house, isn't it? > > (well, OK, maybe a slight exaggeration... ;) > > Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Manchester_Cable_Station_sm.jp2 Type: image/jp2 Size: 94619 bytes Desc: not available URL: From job at ntt.net Thu Jun 29 15:06:30 2017 From: job at ntt.net (Job Snijders) Date: Thu, 29 Jun 2017 17:06:30 +0200 Subject: Point 2 point IPs between ASes In-Reply-To: <59541B05.4090002@nsc.liu.se> References: <59541B05.4090002@nsc.liu.se> Message-ID: <20170629150630.glfvte2ures27p2n@Vurt.local> On Wed, Jun 28, 2017 at 11:09:25PM +0200, Thomas Bellman wrote: > On 2017-06-28 17:03, William Herrin wrote: > > The common recommendations for IPv6 point to point interface numbering are: > > > > /64 > > /124 > > /126 > > /127 > > I thought the only allowed subnet prefix lengths for IPv6 were /64 and > /127. RFC 4291 states: > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > (and addresses starting with 000 are only used for special things, > like the localhost address ::1). And then RFC 6164 adds /127 to the > allowed prefix lengths. > > I know that many devices allow you to configure any subnet size, but > is there any RFC allowing you to use e.g. /124 or /126? Breaking the law! Some IETFers will come hunt you do, be aware! ;-) Here is some historical perspective looking at the IETF standarsd and current Internet-Drafts: RFC 3513 "only /64 is valid" RFC 3627 "don't use /127, use /126 if you must" RFC 4291 "reaffirming: only /64 is valid" RFC 6164 "a /127 is OK to use too" RFC 6583 "there are problems with /64" RFC 7421 "/64 is the best!" RFC 7608 "every prefix length must be forward-able" RFC 4291bis-07 "fine, /64 and /127 are valid, but nothing else!" draft-bourbaki-6man-classless-ipv6-00 "IPv6 is classless FFS" RFC 4291bis-08 "fine, /64 and /127 are valid, and anything defined in future standards, and anything configured manually" Quoting from 4291bis-08: """ Interface Identifiers are 64 bit long except if the first three bits of the address are 000, or when the addresses are manually configured, or by exceptions defined in standards track documents. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. An example of a standards track exception is [RFC6164] that standardises 127 bit prefixes on inter-router point-to-point links. Note: In the case of manual configuration, the Prefix and Interface Identifier can be any length as long as they add up to 128. """ source: https://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08.txt full file: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-08 So, what it boils down to: if you want to use SLAAC, you should use a /64, if you don't need SLAAC, do whatever makes sense for you. And never be greedy: give your end-users a /48, there is plenty of space to go around. Kind regards, Job From bill at herrin.us Thu Jun 29 15:44:32 2017 From: bill at herrin.us (William Herrin) Date: Thu, 29 Jun 2017 11:44:32 -0400 Subject: Point 2 point IPs between ASes In-Reply-To: <000201d2f093$590d0550$0b270ff0$@gvtc.com> References: <001f01d2f06a$d5d87ca0$818975e0$@gvtc.com> <000201d2f093$590d0550$0b270ff0$@gvtc.com> Message-ID: On Thu, Jun 29, 2017 at 12:51 AM, Aaron Gould wrote: > Thanks Bill, I thought with ipv6 it was a sin to subnet on bit boundaries > and not on nibble boundaries. > Hi Aaron, Not a sin but you're making more work for yourself if you subnet on other-than four-bit nibble boundaries. Each character in the hexadecimal printed version of the IPv6 address is 4 bits, aka 1 nibble. So subnetting on a nibble boundary means that each character in the address is either part of the network portion of the address or part of the host portion of the address, never both. Conveniently, IPv6 reverse DNS also delegates on the nibble boundary. Heck, I’m gonna do whatever it takes to NOT subnet on bits with my v6 > deployment. Hopefully with v6, gone are the days of binary subnetting math. > Good plan. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From streinerj at gmail.com Thu Jun 29 12:49:36 2017 From: streinerj at gmail.com (Justin M. Streiner) Date: Thu, 29 Jun 2017 08:49:36 -0400 (EDT) Subject: Point 2 point IPs between ASes In-Reply-To: References: <001f01d2f06a$d5d87ca0$818975e0$@gvtc.com> <000201d2f093$590d0550$0b270ff0$@gvtc.com> Message-ID: On Thu, 29 Jun 2017, William Herrin wrote: > Heck, I’m gonna do whatever it takes to NOT subnet on bits with my v6 >> deployment. Hopefully with v6, gone are the days of binary subnetting math. I hedged my bets when I laid out our v6 space at my previous $dayjob. We used /126s for point-to-point links, but carved out a /64 for each point-to-point link in our IPAM system. That way, if we ever encountered a device that wouldn't play nicely with a /126 on a point-to-point link, we could just change the mask to /64 (or something else, if the device requires a byte or nibble boundary) on the interface and any relevant ACLs and not have to re-provision addresses for the link. I seem to recall that our upstreams generally standardized on /126s for point-to-point interconnects to us. We had one interconnect that was a /64, but that also wasn't a point-to-point link. jms From math at sizone.org Thu Jun 29 23:01:44 2017 From: math at sizone.org (Ken Chase) Date: Thu, 29 Jun 2017 19:01:44 -0400 Subject: strange routing anomalies Message-ID: <20170629230144.GE30352@sizone.org> https://stat.ripe.net/widget/routing-history#w.resource=as15562&w.starttime=2017-01-15T00%3A00%3A00&w.endtime=2017-06-23T00%3A00%3A00&show=Maxmized :D Nice job, Job. /kc -- Ken Chase - math at sizone.org Guelph Canada From marka at isc.org Thu Jun 29 23:08:09 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 30 Jun 2017 09:08:09 +1000 Subject: Point 2 point IPs between ASes In-Reply-To: Your message of "Thu, 29 Jun 2017 17:06:30 +0200." <20170629150630.glfvte2ures27p2n@Vurt.local> References: <59541B05.4090002@nsc.liu.se> <20170629150630.glfvte2ures27p2n@Vurt.local> Message-ID: <20170629230809.B52527D38886@rock.dv.isc.org> In message <20170629150630.glfvte2ures27p2n at Vurt.local>, Job Snijders writes: > On Wed, Jun 28, 2017 at 11:09:25PM +0200, Thomas Bellman wrote: > > On 2017-06-28 17:03, William Herrin wrote: > > > The common recommendations for IPv6 point to point interface numbering are: > > > > > > /64 > > > /124 > > > /126 > > > /127 > > > > I thought the only allowed subnet prefix lengths for IPv6 were /64 and > > /127. RFC 4291 states: > > > > For all unicast addresses, except those that start with the binary > > value 000, Interface IDs are required to be 64 bits long and to be > > constructed in Modified EUI-64 format. > > > > (and addresses starting with 000 are only used for special things, > > like the localhost address ::1). And then RFC 6164 adds /127 to the > > allowed prefix lengths. > > > > I know that many devices allow you to configure any subnet size, but > > is there any RFC allowing you to use e.g. /124 or /126? > > Breaking the law! Some IETFers will come hunt you do, be aware! ;-) > > Here is some historical perspective looking at the IETF standarsd and > current Internet-Drafts: > > RFC 3513 "only /64 is valid" > RFC 3627 "don't use /127, use /126 if you must" > RFC 4291 "reaffirming: only /64 is valid" > RFC 6164 "a /127 is OK to use too" > RFC 6583 "there are problems with /64" > RFC 7421 "/64 is the best!" > RFC 7608 "every prefix length must be forward-able" > RFC 4291bis-07 "fine, /64 and /127 are valid, but nothing else!" > draft-bourbaki-6man-classless-ipv6-00 "IPv6 is classless FFS" > RFC 4291bis-08 "fine, /64 and /127 are valid, and anything defined in future standards, and anything configured manually" > > Quoting from 4291bis-08: > > """ > Interface Identifiers are 64 bit long except if the first three bits > of the address are 000, or when the addresses are manually > configured, or by exceptions defined in standards track documents. > The rationale for using 64 bit Interface Identifiers can be found in > [RFC7421]. An example of a standards track exception is [RFC6164] > that standardises 127 bit prefixes on inter-router point-to-point > links. > > Note: In the case of manual configuration, the Prefix and > Interface Identifier can be any length as long as they add up to > 128. > """ > source: https://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08.txt > full file: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-08 > > So, what it boils down to: if you want to use SLAAC, you should use a > /64, if you don't need SLAAC, do whatever makes sense for you. And never > be greedy: give your end-users a /48, there is plenty of space to go > around. And that should apply to cell phones as well. A single /64 from a ISP to a customer is a stop gap assignment. 3GPP supports DHCP-PD it should be enabled in the back ends. > Kind regards, > > Job -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jhellenthal at dataix.net Thu Jun 29 23:25:47 2017 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 29 Jun 2017 18:25:47 -0500 Subject: strange routing anomalies In-Reply-To: <20170629230144.GE30352@sizone.org> References: <20170629230144.GE30352@sizone.org> Message-ID: <767F51BE-1526-4B01-8F19-82CEFCCF2D47@DataIX.net> Hahahaha -- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN On Jun 29, 2017, at 18:01, Ken Chase wrote: https://stat.ripe.net/widget/routing-history#w.resource=as15562&w.starttime=2017-01-15T00%3A00%3A00&w.endtime=2017-06-23T00%3A00%3A00&show=Maxmized :D Nice job, Job. /kc -- Ken Chase - math at sizone.org Guelph Canada From randy at psg.com Fri Jun 30 01:01:17 2017 From: randy at psg.com (Randy Bush) Date: Fri, 30 Jun 2017 10:01:17 +0900 Subject: Point 2 point IPs between ASes In-Reply-To: References: Message-ID: > I wouldn't use link-local in context of Inter-Domain Routing. indeed randy From randy at psg.com Fri Jun 30 01:04:37 2017 From: randy at psg.com (Randy Bush) Date: Fri, 30 Jun 2017 10:04:37 +0900 Subject: Point 2 point IPs between ASes In-Reply-To: <20170629150630.glfvte2ures27p2n@Vurt.local> References: <59541B05.4090002@nsc.liu.se> <20170629150630.glfvte2ures27p2n@Vurt.local> Message-ID: > if you don't need SLAAC, do whatever makes sense for you. And never be > greedy: give your end-users a /48 i say give them a /129 just to piss off a certin bigot :) From liam at fedney.org Fri Jun 30 01:27:55 2017 From: liam at fedney.org (L Sean Kennedy) Date: Thu, 29 Jun 2017 21:27:55 -0400 Subject: [NANOG-announce] NANOG 71 Call for Presentations is Open Message-ID: NANOG Community, The NANOG Program Committee is excited to announce that we are now accepting proposals for all sessions at NANOG 71 in San Jose, CA, October 2-4 2017. Below is a summary of key details from the Call for Presentations from the NANOG 71 meeting page . We look forward to seeing you in San Jose! Sincerely, L Sean Kennedy NANOG Program Committee NANOG 71 Call for Presentations The North American Network Operators' Group (NANOG) will hold its 71st conference in San Jose, California. The conference takes place on October 2-4, 2017. The NANOG Program Committee seeks proposals for presentations, panels, tutorials, and track sessions for the NANOG 71 program. We welcome suggestions of potential speakers or new topic ideas. Presentations may cover technologies already deployed or soon-to-be deployed in the Internet. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations must not be promotional or discuss proprietary solutions. NANOG 71 submissions can be entered on the NANOG Program Committee Tool. How To Submit The primary speaker, moderator, or author should submit a presentation proposal and an abstract on the Program Committee Tool . - Select “Propose Talk” from the *Talks* menu - Select the NANOG 71 meeting in the *Meeting* menu - Select the appropriate *Session* the talk will be presented in (General Session 30-45 minutes; Tutorial 90-120 minutes; Track 90-120 minutes) - Provide the information requested below Upload draft slides as soon as possible so the Program Committee can understand the intended structure and level of detail covered by the talk. Draft slides are not required for a proposal to be initiated, but they are usually expected before the Program Committee can definitively accept a submission. The following information should be included in the proposal: - Author's name(s) - Professional or educational affiliation - A preferred contact email address - A preferred phone number for contact - Submission category (General Session, Panel, Tutorial, or Track) - Presentation title - Abstract - Slides in PowerPoint (preferred) or PDF format - Comments as desired including URL to materials or previous talk Timeline for submission and proposal review - Submitter enters abstract (and draft slides if possible) in Program Committee Tool . - Any time following Call for Presentations and prior to CFP deadline for slide submission - PC performs initial review and assigns a “Shepherd” to help develop the submission. - Within 2 weeks - Submitter develops draft slides of talk - Please submit initial draft slides early - Panel and Track submissions should provide topic list and intended/confirmed participants - PC reviews slides and continues to work with Submitter as needed to develop topic - Draft presentation slides should be submitted prior to published deadline for slides - PC accepts or declines submission - Agenda assembled and posted - Submitters notified If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the Program Committee , and a representative of the Program Committee will respond. Otherwise, submit your talk, keynote, track, or panel proposal to the Program Committee Tool without delay! We look forward to reviewing your submission. Key Dates for NANOG 71 Registration for NANOG 71 opens Thursday, 06/29/2017 Agenda Outline for NANOG 71 posted Thursday, 06/29/2017 CFP Deadline: Presentation Slides Due Monday, 07/24/2017 Topic List and NANOG Highlights Friday, 07/28/2017 Final presentation submission Monday, 09/25/2017 Lightning Talk submissions open Sunday, 10/1/2017 General presentation advice is provided with our “Guidelines for Presenting at a NANOG Meeting ”, "Present at a NANOG" and “Tips on Giving a Talk ”. The NANOG Program Committee seeks proposals for presentations, panels, tutorial sessions, and tracks in all areas of network operations, such as: - Network Connectivity, Interconnection, and Architecture - Network Management and Configuration including Automation - Network Performance, Measurement, and Telemetry - Data Center and Physical Plant including Cooling and Power Efficiency - Network Research - Internet Governance - Routing and Switching Protocols - Network Data and Control Plane Security - Optical and Transmission Technologies - Wireless Networks - DNS, Transport, and Applications - Network Operations and Engineering Professional Experiences Submissions are welcomed by and for network operators of all sizes. Presentations about difficult problems (and interesting solutions) that you encounter in the course of your job are encouraged. The NANOG registration fee is waived for: - General Session presentations: the conference registration fee will be waived for a maximum of one speaker. - General Session panels: conference registration fees will be waived for one panel moderator and all panelists. - Tracks: conference registration fees will be waived for one moderator. - Tutorials: conference registration fees will be waived for one instructor. -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From colinj at gt86car.org.uk Fri Jun 30 07:55:22 2017 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 30 Jun 2017 08:55:22 +0100 Subject: Fwd: Bonus support for Action for Children References: Message-ID: <549FB365-99B9-46E0-9A4C-33A8493BF5A3@gt86car.org.uk> excuse the subject, relevant as IT techies like this. > > Bonus support for Action for Children > A BT senior manager is donating half of his bonus to Action for Children’s Byte Night North West event and encouraging others to do the same. > Colin Johnston is an IT technical manager who has supported Action for Children for several years. This year he and hundreds of other executives will be sleeping out for a night on 6 October as part of the charity’s annual Byte Night event. As well as raising money by taking part in this, Colin has decided to also donate 50% of his bonus payment (£2,482.00 / 2 = £1241(donation amount)) this year to Action for Children. > Colin said, “Being involved for a while with Action for Children, I’ve got to know about the amazing work they do with children and young people and families. I’m happy to be in a position where I can help support their services by fundraising and donating. If people can’t take part in Byte Night then they can still help out by donating what they can – if other executives decided to also give half of their bonus to Action for Children, it would be a simple but really effective way of helping young people to have a brighter future.” > > Byte Night is Action for Children's biggest annual fundraiser; a national ‘sleep-out’ event. Each year, hundreds of like-minded people from the technology and business arena give up their beds for one night to help change the lives of vulnerable young people. It all began in 1998 when 30 individuals slept out in London and raised £35,000. Since then Byte Night has grown to 10 UK locations and over 1,200 people slept out in 2016. Byte Night is one of the UK’s top 17 mass participation charity events and is the largest charity sleep-out having raised over £9.6 million since the first event. Byte Night is celebrating its 20th anniversary this year and its fifth year in the North West. > Colin is a board member of the North West Byte Night event. > BT Volunteering is a very worthwhile endeavour. > > See mydonate page linked to Byte Night https://mydonate.bt.com/fundraisers/colinjohnston1 > > For more information go to www.bytenight.org.uk or to donate Text Byte17 and the amount to 70070. > > Colin > > Colin Johnston > IT Support Senior Professional, Core IT Infrastructure > BT Technology Service & Operations  | Tel: 01313001324  | MyProfile  | colin.johnstone at bt.com  | http://fixit.bt.com/ > > BT Group plc Registered office: 81 Newgate Street London EC1A 7AJ. Registered in England and Wales no. 4190816 This electronic message contains information from BT Group plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please delete it and notify me immediately by telephone or email. From bill at herrin.us Fri Jun 30 11:17:11 2017 From: bill at herrin.us (William Herrin) Date: Fri, 30 Jun 2017 07:17:11 -0400 Subject: Bonus support for Action for Children In-Reply-To: <549FB365-99B9-46E0-9A4C-33A8493BF5A3@gt86car.org.uk> References: <549FB365-99B9-46E0-9A4C-33A8493BF5A3@gt86car.org.uk> Message-ID: On Fri, Jun 30, 2017 at 3:55 AM, Colin Johnston wrote: > excuse the subject, relevant as IT techies like this. > Colin, Not only is your personal favorite charity in no way shape or form relevant to Internet routing, the UK branch of the charity you're trying to raise funds for is outside the geographical scope of this mailing list. But you already knew that when you decided to spam us. Which you've done three times now. You think "IT techies" like spam? That exceptions should be made for "good cause" spam? I respectfully disagree and would ask you to stop. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From aaron1 at gvtc.com Fri Jun 30 13:38:22 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 30 Jun 2017 08:38:22 -0500 Subject: Point 2 point IPs between ASes In-Reply-To: <20170629230809.B52527D38886@rock.dv.isc.org> References: <59541B05.4090002@nsc.liu.se> <20170629150630.glfvte2ures27p2n@Vurt.local> <20170629230809.B52527D38886@rock.dv.isc.org> Message-ID: <000c01d2f1a6$24f9edf0$6eedc9d0$@gvtc.com> Thanks Mark, I'm not much into the cellular realm other than Ethernet cell-backhaul, which isn't cell at all but rather just hauling Ethernet/vlan frames across my network as fast as I can :) ...so does what you said mean ipv6 prefixes are delegated to phones ? -Aaron Gould ---------------------------------------------------------------------------- ----------------------------------------------------------------- "And that should apply to cell phones as well. A single /64 from a ISP to a customer is a stop gap assignment. 3GPP supports DHCP-PD it should be enabled in the back ends." > Kind regards, > > Job -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bross at pobox.com Fri Jun 30 14:49:35 2017 From: bross at pobox.com (Brandon Ross) Date: Fri, 30 Jun 2017 10:49:35 -0400 (EDT) Subject: Fwd: Bonus support for Action for Children In-Reply-To: <549FB365-99B9-46E0-9A4C-33A8493BF5A3@gt86car.org.uk> References: <549FB365-99B9-46E0-9A4C-33A8493BF5A3@gt86car.org.uk> Message-ID: I get that it's a good cause, but this is off topic and doesn't belong on NANOG. If we allow everyone with a good cause to post to NANOG then we would be inundated with charity emails. On Fri, 30 Jun 2017, Colin Johnston wrote: > excuse the subject, relevant as IT techies like this. > >> >> Bonus support for Action for Children >> A BT senior manager is donating half of his bonus to Action for Children’s Byte Night North West event and encouraging others to do the same. >> Colin Johnston is an IT technical manager who has supported Action for Children for several years. This year he and hundreds of other executives will be sleeping out for a night on 6 October as part of the charity’s annual Byte Night event. As well as raising money by taking part in this, Colin has decided to also donate 50% of his bonus payment (£2,482.00 / 2 = £1241(donation amount)) this year to Action for Children. >> Colin said, “Being involved for a while with Action for Children, I’ve got to know about the amazing work they do with children and young people and families. I’m happy to be in a position where I can help support their services by fundraising and donating. If people can’t take part in Byte Night then they can still help out by donating what they can – if other executives decided to also give half of their bonus to Action for Children, it would be a simple but really effective way of helping young people to have a brighter future.” >> >> Byte Night is Action for Children's biggest annual fundraiser; a national ‘sleep-out’ event. Each year, hundreds of like-minded people from the technology and business arena give up their beds for one night to help change the lives of vulnerable young people. It all began in 1998 when 30 individuals slept out in London and raised £35,000. Since then Byte Night has grown to 10 UK locations and over 1,200 people slept out in 2016. Byte Night is one of the UK’s top 17 mass participation charity events and is the largest charity sleep-out having raised over £9.6 million since the first event. Byte Night is celebrating its 20th anniversary this year and its fifth year in the North West. >> Colin is a board member of the North West Byte Night event. >> BT Volunteering is a very worthwhile endeavour. >> >> See mydonate page linked to Byte Night https://mydonate.bt.com/fundraisers/colinjohnston1 >> >> For more information go to www.bytenight.org.uk or to donate Text Byte17 and the amount to 70070. >> >> Colin >> >> Colin Johnston >> IT Support Senior Professional, Core IT Infrastructure >> BT Technology Service & Operations  | Tel: 01313001324  | MyProfile  | colin.johnstone at bt.com  | http://fixit.bt.com/ >> >> BT Group plc Registered office: 81 Newgate Street London EC1A 7AJ. Registered in England and Wales no. 4190816 This electronic message contains information from BT Group plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please delete it and notify me immediately by telephone or email. > -- Brandon Ross Yahoo & AIM: 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 cscora at apnic.net Fri Jun 30 18:02:32 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Jul 2017 04:02:32 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170630180232.74D0CEA49@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 Jul, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 653102 Prefixes after maximum aggregation (per Origin AS): 254091 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 314847 Total ASes present in the Internet Routing Table: 57642 Prefixes per ASN: 11.33 Origin-only ASes present in the Internet Routing Table: 49881 Origin ASes announcing only one prefix: 21993 Transit ASes present in the Internet Routing Table: 7761 Transit-only ASes present in the Internet Routing Table: 230 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 63 Numnber of instances of unregistered ASNs: 67 Number of 32-bit ASNs allocated by the RIRs: 19273 Number of 32-bit ASNs visible in the Routing Table: 14977 Prefixes from 32-bit ASNs in the Routing Table: 61008 Number of bogon 32-bit ASNs visible in the Routing Table: 64 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 360 Number of addresses announced to Internet: 2848137828 Equivalent to 169 /8s, 195 /16s and 34 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 217503 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 179085 Total APNIC prefixes after maximum aggregation: 51339 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 178234 Unique aggregates announced from the APNIC address blocks: 73760 APNIC Region origin ASes present in the Internet Routing Table: 8213 APNIC Prefixes per ASN: 21.70 APNIC Region origin ASes announcing only one prefix: 2298 APNIC Region transit ASes present in the Internet Routing Table: 1158 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3052 Number of APNIC addresses announced to Internet: 763598436 Equivalent to 45 /8s, 131 /16s and 150 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 198988 Total ARIN prefixes after maximum aggregation: 94731 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 200843 Unique aggregates announced from the ARIN address blocks: 92112 ARIN Region origin ASes present in the Internet Routing Table: 17906 ARIN Prefixes per ASN: 11.22 ARIN Region origin ASes announcing only one prefix: 6620 ARIN Region transit ASes present in the Internet Routing Table: 1777 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2060 Number of ARIN addresses announced to Internet: 1108512928 Equivalent to 66 /8s, 18 /16s and 144 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 175225 Total RIPE prefixes after maximum aggregation: 85781 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 171043 Unique aggregates announced from the RIPE address blocks: 102902 RIPE Region origin ASes present in the Internet Routing Table: 24139 RIPE Prefixes per ASN: 7.09 RIPE Region origin ASes announcing only one prefix: 11100 RIPE Region transit ASes present in the Internet Routing Table: 3405 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5956 Number of RIPE addresses announced to Internet: 712116864 Equivalent to 42 /8s, 114 /16s and 10 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 82725 Total LACNIC prefixes after maximum aggregation: 18405 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 84002 Unique aggregates announced from the LACNIC address blocks: 38760 LACNIC Region origin ASes present in the Internet Routing Table: 6079 LACNIC Prefixes per ASN: 13.82 LACNIC Region origin ASes announcing only one prefix: 1648 LACNIC Region transit ASes present in the Internet Routing Table: 1119 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3592 Number of LACNIC addresses announced to Internet: 170756320 Equivalent to 10 /8s, 45 /16s and 136 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 16968 Total AfriNIC prefixes after maximum aggregation: 3779 AfriNIC Deaggregation factor: 4.49 Prefixes being announced from the AfriNIC address blocks: 18620 Unique aggregates announced from the AfriNIC address blocks: 6990 AfriNIC Region origin ASes present in the Internet Routing Table: 1042 AfriNIC Prefixes per ASN: 17.87 AfriNIC Region origin ASes announcing only one prefix: 326 AfriNIC Region transit ASes present in the Internet Routing Table: 204 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 317 Number of AfriNIC addresses announced to Internet: 92728832 Equivalent to 5 /8s, 134 /16s and 238 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5552 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3933 404 363 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2976 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2805 11134 756 KIXS-AS-KR Korea Telecom, KR 9829 2752 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2175 8699 34 CMNET-GD Guangdong Mobile Communication 4755 2088 422 222 TATACOMM-AS TATA Communications formerl 45899 2019 1415 109 VNPT-AS-VN VNPT Corp, VN 7552 1632 1104 73 VIETEL-AS-AP Viettel Corporation, VN 9498 1594 360 139 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3814 2953 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3411 1333 81 SHAW - Shaw Communications Inc., CA 18566 2179 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2064 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2010 2172 417 CHARTER-NET-HKY-NC - Charter Communicat 209 1825 5068 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1815 3696 586 AMAZON-02 - Amazon.com, Inc., US 30036 1795 325 309 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1695 854 231 ITCDELTA - Earthlink, Inc., US 701 1562 10560 631 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 2971 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2904 963 2090 AKAMAI-ASN1, US 34984 2000 328 417 TELLCOM-AS, TR 9121 1955 1691 17 TTNET, TR 12479 1614 1044 53 UNI2-AS, ES 13188 1602 100 55 TRIOLAN, UA 12389 1524 1408 626 ROSTELECOM-AS, RU 6849 1225 355 21 UKRTELNET, UA 8402 1123 544 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3541 544 185 Telmex Colombia S.A., CO 8151 2518 3404 576 Uninet S.A. de C.V., MX 11830 2089 369 57 Instituto Costarricense de Electricidad 7303 1550 1010 243 Telecom Argentina S.A., AR 6503 1541 437 53 Axtel, S.A.B. de C.V., MX 6147 1299 377 27 Telefonica del Peru S.A.A., PE 3816 1026 501 94 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 968 2301 177 CLARO S.A., BR 11172 915 126 82 Alestra, S. de R.L. de C.V., MX 18881 895 1052 23 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1254 398 48 LINKdotNET-AS, EG 37611 724 91 8 Afrihost, ZA 36903 711 357 129 MT-MPLS, MA 36992 643 1375 26 ETISALAT-MISR, EG 24835 499 850 15 RAYA-AS, EG 37492 407 320 75 ORANGE-, TN 29571 401 36 10 CITelecom-AS, CI 8452 358 1730 17 TE-AS TE-AS, EG 15399 353 35 7 WANANCHI-, KE 2018 300 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5552 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3933 404 363 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3814 2953 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3541 544 185 Telmex Colombia S.A., CO 6327 3411 1333 81 SHAW - Shaw Communications Inc., CA 39891 3338 187 22 ALJAWWALSTC-AS, SA 17974 2976 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 8551 2971 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2904 963 2090 AKAMAI-ASN1, US 4766 2805 11134 756 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3814 3653 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3933 3570 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3541 3356 Telmex Colombia S.A., CO 6327 3411 3330 SHAW - Shaw Communications Inc., CA 39891 3338 3316 ALJAWWALSTC-AS, SA 8551 2971 2931 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2976 2903 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9829 2752 2212 BSNL-NIB National Internet Backbone, IN 9808 2175 2141 CMNET-GD Guangdong Mobile Communication Co.Ltd. 18566 2179 2070 MEGAPATH5-US - MegaPath Corporation, 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 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65010 PRIVATE 46.56.192.0/21 42772 VELCOM-AS, BY 65010 PRIVATE 46.56.224.0/21 42772 VELCOM-AS, BY 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 23.226.112.0/20 62788 -Reserved AS-, ZZ 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:280 /13:545 /14:1049 /15:1846 /16:13473 /17:7631 /18:13434 /19:24639 /20:38561 /21:41217 /22:77596 /23:64333 /24:366107 /25:871 /26:604 /27:642 /28:35 /29:23 /30:18 /31:3 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3214 3411 SHAW - Shaw Communications Inc., CA 22773 2977 3814 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2898 3338 ALJAWWALSTC-AS, SA 8551 2436 2971 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2072 2179 MEGAPATH5-US - MegaPath Corporation, US 30036 1587 1795 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1479 2089 Instituto Costarricense de Electricidad y Telec 10620 1469 3541 Telmex Colombia S.A., CO 11492 1382 1532 CABLEONE - CABLE ONE, INC., US 6389 1371 2064 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1596 2:803 4:18 5:2432 6:34 8:1044 12:1833 13:123 14:1739 15:28 16:2 17:158 18:90 20:61 23:2384 24:1974 25:2 27:2454 31:1919 32:80 33:14 35:20 36:387 37:2347 38:1318 39:62 40:98 41:2928 42:485 43:1930 44:71 45:2848 46:2794 47:154 49:1236 50:985 51:18 52:830 54:363 55:6 56:4 57:42 58:1577 59:1053 60:388 61:1959 62:1604 63:1914 64:4587 65:2221 66:4566 67:2271 68:1244 69:3380 70:1149 71:586 72:2201 74:2692 75:387 76:423 77:1545 78:1457 79:2378 80:1404 81:1391 82:993 83:722 84:906 85:1748 86:481 87:1161 88:757 89:2102 90:175 91:6188 92:975 93:2384 94:2376 95:2683 96:628 97:353 98:1063 99:86 100:154 101:1201 103:15187 104:2961 105:182 106:508 107:1721 108:824 109:2863 110:1457 111:1725 112:1193 113:1251 114:1028 115:1721 116:1793 117:1701 118:2204 119:1608 120:1054 121:1111 122:2252 123:1831 124:1480 125:1888 128:774 129:652 130:434 131:1406 132:520 133:199 134:654 135:225 136:447 137:437 138:1933 139:490 140:394 141:600 142:766 143:893 144:796 145:182 146:1028 147:690 148:1446 149:579 150:705 151:973 152:694 153:304 154:776 155:753 156:610 157:649 158:450 159:1512 160:685 161:743 162:2530 163:535 164:804 165:1395 166:379 167:1244 168:2957 169:791 170:3454 171:318 172:1022 173:1947 174:811 175:750 176:1877 177:4080 178:2481 179:1180 180:2208 181:1881 182:2376 183:1000 184:866 185:10032 186:3207 187:2233 188:2709 189:1814 190:8252 191:1327 192:9499 193:5783 194:4682 195:3910 196:2080 197:1261 198:5500 199:5895 200:7456 201:4340 202:10368 203:10020 204:4486 205:2814 206:3016 207:3114 208:3985 209:3933 210:3974 211:2144 212:2855 213:2500 214:876 215:66 216:5771 217:2104 218:868 219:599 220:1692 221:931 222:781 223:1175 End of report From ggiesen+nanog at giesen.me Fri Jun 30 22:31:01 2017 From: ggiesen+nanog at giesen.me (=?utf-8?q?Gary_T=2E_Giesen?=) Date: Fri, 30 Jun 2017 18:31:01 -0400 Subject: Transit Providers in =?utf-8?q?Bracknell=2C?= UK Message-ID: <7d4f-5956d100-1-6ff39000@94221956> Can anyone recommend a transit provider in Bracknell, UK? Not too picky on requirements, but IPv6 is a must;  RTBH and good peering are a very good to have. We're looking to replace one of our current providers (Virgin Media - AS5089). I have no problem naming them as they treat prefix list updates like service changes (and charge £250 for the privilege). We gave in and paid it and and 2 weeks later they have still not processed the change. Cheers, GTG From bellman at nsc.liu.se Fri Jun 30 07:40:30 2017 From: bellman at nsc.liu.se (Thomas Bellman) Date: Fri, 30 Jun 2017 09:40:30 +0200 Subject: Point 2 point IPs between ASes In-Reply-To: <20170629150630.glfvte2ures27p2n@Vurt.local> References: <59541B05.4090002@nsc.liu.se> <20170629150630.glfvte2ures27p2n@Vurt.local> Message-ID: <5956006E.6050105@nsc.liu.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2017-06-29/17 17:06, Job Snijders wrote: > On Wed, Jun 28, 2017 at 11:09:25PM +0200, Thomas Bellman wrote: >> I know that many devices allow you to configure any subnet size, but >> is there any RFC allowing you to use e.g. /124 or /126? > Breaking the law! Some IETFers will come hunt you do, be aware! ;-) :-) But I figure if the standards disallow certain things, then there will likely be implementations that don't handle those things. You might need or want to interoperate with those, and when it is you that is not following the standards, you can't complain much to the other side. Of course, for a point-to-point link, it tends to be fairly easy to check with the other end what they support. And if they (or you) change equipment, then you will have a downtime for that link anyway and can change your addresses at the same time. Tends to be less easy for a network with multiple hosts. > Here is some historical perspective looking at the IETF standarsd and > current Internet-Drafts: > > RFC 3513 "only /64 is valid" > RFC 3627 "don't use /127, use /126 if you must" > RFC 4291 "reaffirming: only /64 is valid" > RFC 6164 "a /127 is OK to use too" > RFC 6583 "there are problems with /64" > RFC 7421 "/64 is the best!" > RFC 7608 "every prefix length must be forward-able" > RFC 4291bis-07 "fine, /64 and /127 are valid, but nothing else!" > draft-bourbaki-6man-classless-ipv6-00 "IPv6 is classless FFS" > RFC 4291bis-08 "fine, /64 and /127 are valid, and anything defined in future standards, and anything configured manually" > > Quoting from 4291bis-08: > > """ > Interface Identifiers are 64 bit long except if the first three bits > of the address are 000, or when the addresses are manually > configured, or by exceptions defined in standards track documents. > The rationale for using 64 bit Interface Identifiers can be found in > [RFC7421]. An example of a standards track exception is [RFC6164] > that standardises 127 bit prefixes on inter-router point-to-point > links. > > Note: In the case of manual configuration, the Prefix and > Interface Identifier can be any length as long as they add up to > 128. > """ > source: https://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08.txt > full file: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-08 Thanks for this information! /Bellman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJZVgBuAAoJEGqUdKqa3HTsGm8P/3mY5KPJ/dlKOVtbjz1DIBdU GKogsA3jAnysAOQJRyga4CJFN4wHmFRskbC9Vl5xLY2ihh2hATzZfLonozKaVd9/ m9QT8ObHf6XKO4euvKWdust4sZvV8Mw1upx5gokGWi/ciWvwWPy8WJ59ic6xengw 34Emmz8LMVUVq3uIZEyp7YWgc+yfeZFDJAnJbZNYXnQkQutyke/kR0SDCFtO7/nI ZtE4+e5I0jtlujXsfeSJtlJTbQ6smJMXEHZZMtwo6LiA0zyAbHvvKDmndo0NbA1P hARpN442QysjVE8amF8UeE9muDs90gitSo+c0n1QzMDm5tV8bG3Vo5gENQM5Amv7 9ovPt25efO3Lb6jEbeIZOjLRLNzVlaiavGwLUk8AgwAOaSkOXVhkMmp/Iqyp/lNx +bIHbimzi057Dw62e2NugQKaCnc4jgAfzzvicyOELdjU0yQy4p/uA89cJ7G5ycSG tQ0j/Xi39+MXwHGnRmJdwrXOAAkqoa4SYwAYAF0PymP+/4JrXilp6FkZkEXugpu7 9DqRfLB9nY4dKDysqlE9tGwBykeVvy44sd6AM/hKBrAVwnRGuXywFBXLetEaBCOp wcDbFEtUIOccEysNnfxDOt8btMtvsUUNUSMky0o2oqEQeWaaxXvVuMrUOoVbfFVW VWUBP2dPjOFy+KDwdD5R =qAKT -----END PGP SIGNATURE-----