From nik at neko.id.au Fri Jun 1 00:37:41 2018 From: nik at neko.id.au (Nikolas Geyer) Date: Fri, 1 Jun 2018 00:37:41 +0000 Subject: SoftLayer Contact Message-ID: <703AA50C-E8C4-4320-A3B2-29A36128BDEC@neko.id.au> Anybody from SoftLayer (AS36351) on list? You have been leaking 700,000+ routes to some AMSIX peers for a while now. Cheers, Nik. Sent from my iPhone From jared at puck.nether.net Fri Jun 1 00:43:06 2018 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 31 May 2018 20:43:06 -0400 Subject: SoftLayer Contact In-Reply-To: <703AA50C-E8C4-4320-A3B2-29A36128BDEC@neko.id.au> References: <703AA50C-E8C4-4320-A3B2-29A36128BDEC@neko.id.au> Message-ID: <55DB1A38-7C3B-418F-B79D-F605715203F9@puck.nether.net> We noticed this as well and sent peering@ a note. - Jared > On May 31, 2018, at 8:37 PM, Nikolas Geyer wrote: > > Anybody from SoftLayer (AS36351) on list? You have been leaking 700,000+ routes to some AMSIX peers for a while now. > > Cheers, > Nik. > > Sent from my iPhone From hank at efes.iucc.ac.il Fri Jun 1 04:56:19 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 1 Jun 2018 07:56:19 +0300 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> Message-ID: On 31/05/2018 21:44, John Peach wrote: > On 05/31/2018 02:37 PM, Dan Hollis wrote: >> On Thu, 31 May 2018, bzs at theworld.com wrote: >>> FWIW a German court has just ruled against ICANN's injunction and in >>> favor of Tucows/EPAG. >>>   https://www.icann.org/news/announcement-4-2018-05-30-en >> >> Welcome to contact-free whois? >> >> -Dan > > > Already been bitten by it and trying to get the contact info reinstated. > > > The entire whois debacle will only get resolved when some hackers attack www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the response they get will be "sorry, we can't determine who is attacking you since that contravenes GDPR", will the EU light bulb go on that something in GDPR needs to be tweaked. -Hank From jared at puck.nether.net Fri Jun 1 11:03:27 2018 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 1 Jun 2018 07:03:27 -0400 Subject: SoftLayer Contact In-Reply-To: <55DB1A38-7C3B-418F-B79D-F605715203F9@puck.nether.net> References: <703AA50C-E8C4-4320-A3B2-29A36128BDEC@neko.id.au> <55DB1A38-7C3B-418F-B79D-F605715203F9@puck.nether.net> Message-ID: I heard back and they corrected the problem. Reminder to keep your peering contacts handy :-) - Jared > On May 31, 2018, at 8:43 PM, Jared Mauch wrote: > > We noticed this as well and sent peering@ a note. > > - Jared > >> On May 31, 2018, at 8:37 PM, Nikolas Geyer wrote: >> >> Anybody from SoftLayer (AS36351) on list? You have been leaking 700,000+ routes to some AMSIX peers for a while now. >> >> Cheers, >> Nik. >> >> Sent from my iPhone > From niels=nanog at bakker.net Fri Jun 1 12:24:03 2018 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Fri, 1 Jun 2018 14:24:03 +0200 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> Message-ID: <20180601122403.GC34704@excession.tpb.net> * hank at efes.iucc.ac.il (Hank Nussbacher) [Fri 01 Jun 2018, 06:56 CEST]: >The entire whois debacle will only get resolved when some hackers attack >www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the >response they get will be "sorry, we can't determine who is attacking >you since that contravenes GDPR", will the EU light bulb go on that >something in GDPR needs to be tweaked. Please stop inciting lawbreaking, and stop spreading long debunked talking points. Both are really inappropriate for this list. -- Niels. From hank at efes.iucc.ac.il Fri Jun 1 12:47:21 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 1 Jun 2018 15:47:21 +0300 Subject: ICANN GDPR lawsuit In-Reply-To: <20180601122403.GC34704@excession.tpb.net> References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> Message-ID: <186c7ea4-91d8-e587-d71d-69f836e0ad68@efes.iucc.ac.il> On 01/06/2018 15:24, niels=nanog at bakker.net wrote: > * hank at efes.iucc.ac.il (Hank Nussbacher) [Fri 01 Jun 2018, 06:56 CEST]: >> The entire whois debacle will only get resolved when some hackers attack >> www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the >> response they get will be "sorry, we can't determine who is attacking >> you since that contravenes GDPR", will the EU light bulb go on that >> something in GDPR needs to be tweaked. > > Please stop inciting lawbreaking, and stop spreading long debunked > talking points.  Both are really inappropriate for this list. > > >     -- Niels. > The point was not to encourage law breaking.  Sorry if that what was perceived.  The point is that the people who designed GDPR did not take whois into consideration in the least.  And we  all will suffer because of that. -Hank From list at satchell.net Fri Jun 1 12:47:52 2018 From: list at satchell.net (Stephen Satchell) Date: Fri, 1 Jun 2018 05:47:52 -0700 Subject: ICANN GDPR lawsuit In-Reply-To: <20180601122403.GC34704@excession.tpb.net> References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> Message-ID: On 06/01/2018 05:24 AM, niels=nanog at bakker.net wrote: > * hank at efes.iucc.ac.il (Hank Nussbacher) [Fri 01 Jun 2018, 06:56 CEST]: >> The entire whois debacle will only get resolved when some hackers attack >> www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the >> response they get will be "sorry, we can't determine who is attacking >> you since that contravenes GDPR", will the EU light bulb go on that >> something in GDPR needs to be tweaked. > > Please stop inciting lawbreaking, and stop spreading long debunked > talking points.  Both are really inappropriate for this list. OK, then let's talk about something that IS appropriate for this list. How does your shop, Niels, go about making contact with an operator that is hijacking one of your netblocks, or is doing something weird with routing that is causing your customers problems, or has broken BGP? I will say right now that in large shops, the owner is NOT the right contact. In fact, if things are broken enough you may not be able to send email to the owner -- he could be isolated. The registration authorities want the owner contact for legal reasons. We poor sods in the trenches need tech contacts, preferably contacts with clue. In other words, how do you do your job in light of the GDPR restrictions on accessing contact information for other network operators? Please be specific. A lot of NOC policies and procedures will need to be updated. Right now my policies and procedures book says to use WHOIS. What needs to change? From john-nanog at peachfamily.net Fri Jun 1 13:53:10 2018 From: john-nanog at peachfamily.net (John Peach) Date: Fri, 1 Jun 2018 09:53:10 -0400 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> Message-ID: <2b1bfac3-9934-a579-6529-701379244fb5@peachfamily.net> On 06/01/2018 08:47 AM, Stephen Satchell wrote: > On 06/01/2018 05:24 AM, niels=nanog at bakker.net wrote: >> * hank at efes.iucc.ac.il (Hank Nussbacher) [Fri 01 Jun 2018, 06:56 CEST]: >>> The entire whois debacle will only get resolved when some hackers attack >>> www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the >>> response they get will be "sorry, we can't determine who is attacking >>> you since that contravenes GDPR", will the EU light bulb go on that >>> something in GDPR needs to be tweaked. >> >> Please stop inciting lawbreaking, and stop spreading long debunked >> talking points.  Both are really inappropriate for this list. > > OK, then let's talk about something that IS appropriate for this list. > How does your shop, Niels, go about making contact with an operator that > is hijacking one of your netblocks, or is doing something weird with > routing that is causing your customers problems, or has broken BGP? > > I will say right now that in large shops, the owner is NOT the right > contact. In fact, if things are broken enough you may not be able to > send email to the owner -- he could be isolated. The registration > authorities want the owner contact for legal reasons. We poor sods in > the trenches need tech contacts, preferably contacts with clue. > > In other words, how do you do your job in light of the GDPR restrictions > on accessing contact information for other network operators? > > Please be specific. A lot of NOC policies and procedures will need to > be updated. > > Right now my policies and procedures book says to use WHOIS. What needs > to change? > $dayjob has approaching 800 domains registered, of which a handful are set up for email and the hostmaster address was on only one of those. We only discovered the problem when a certificate authority attempted to contact us for one of the other domains. At that point I found that Network Solutions had removed all our contact information and trying to find someone with a clue at NetSol is nigh on impossible. -- John PGP Public Key: 412934AC From niels=nanog at bakker.net Fri Jun 1 14:21:36 2018 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Fri, 1 Jun 2018 16:21:36 +0200 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> Message-ID: <20180601142136.GD34704@excession.tpb.net> * list at satchell.net (Stephen Satchell) [Fri 01 Jun 2018, 14:51 CEST]: >How does your shop, Niels, go about making contact with an operator >that is hijacking one of your netblocks, or is doing something weird >with routing that is causing your customers problems, or has broken >BGP? The same as we do now, by posting on NANOG "Can someone from ASx / largetelco.com contact me offlist?" -- Niels. From mark.tinka at seacom.mu Fri Jun 1 14:51:28 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 1 Jun 2018 16:51:28 +0200 Subject: SoftLayer Contact In-Reply-To: References: <703AA50C-E8C4-4320-A3B2-29A36128BDEC@neko.id.au> <55DB1A38-7C3B-418F-B79D-F605715203F9@puck.nether.net> Message-ID: <999b8468-c6ff-7f91-694d-b49fe09258f5@seacom.mu> On 1/Jun/18 13:03, Jared Mauch wrote: > I heard back and they corrected the problem. > > Reminder to keep your peering contacts handy :-) And that max-prefix song :-)... Mark. From bill at herrin.us Fri Jun 1 15:23:53 2018 From: bill at herrin.us (William Herrin) Date: Fri, 1 Jun 2018 11:23:53 -0400 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> Message-ID: On Fri, Jun 1, 2018 at 8:47 AM, Stephen Satchell wrote: > In other words, how do you do your job in light of the GDPR restrictions > on accessing contact information for other network operators? > > Please be specific. A lot of NOC policies and procedures will need to > be updated. Publish role accounts in whois instead of personal information? Sorry, I don't mean to break up an energetic tirade but a phone number is not PII when it's attached to "hostmaster" instead of "John Doe". You and I like knowing that there's a specific person there and it certainly helps when auditing public policy compliance but as a technical matter contact doesn't have to work that way. I noticed that Namecheap solved their GDPR problem by simply making their "WhoisGuard" product free. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From C-Mack.McBride at charter.com Fri Jun 1 16:37:29 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Fri, 1 Jun 2018 16:37:29 +0000 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> Message-ID: <1d864a4451534592b97b77991c8bb03a@SC58MEXGP032.CORP.CHARTERCOM.com> The whois guard solution seems workable where the registrar just forwards information. It would be nice if there were corporate phone numbers as GDPR doesn't apply to corporations. For routing whois information there aren't going to be many individuals and it would seem that the corporations who employee individuals should be the ones protecting those individuals work emails by providing a generic contact email forward. Which is good practice anyway since people leave and go on vacation and problems still happen. And the routing whois information is a lot more relevant to most of us here. Of course anyone posting to a public list should be aware that their email address is part of that information. Which is particularly relevant to this list. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin Sent: Friday, June 01, 2018 9:24 AM To: list at satchell.net Cc: nanog at nanog.org Subject: Re: ICANN GDPR lawsuit On Fri, Jun 1, 2018 at 8:47 AM, Stephen Satchell wrote: > In other words, how do you do your job in light of the GDPR > restrictions on accessing contact information for other network operators? > > Please be specific. A lot of NOC policies and procedures will need to > be updated. Publish role accounts in whois instead of personal information? Sorry, I don't mean to break up an energetic tirade but a phone number is not PII when it's attached to "hostmaster" instead of "John Doe". You and I like knowing that there's a specific person there and it certainly helps when auditing public policy compliance but as a technical matter contact doesn't have to work that way. I noticed that Namecheap solved their GDPR problem by simply making their "WhoisGuard" product free. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From cscora at apnic.net Fri Jun 1 18:03:02 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Jun 2018 04:03:02 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180601180302.3155AC450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Jun, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 702696 Prefixes after maximum aggregation (per Origin AS): 269990 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 337923 Total ASes present in the Internet Routing Table: 60877 Prefixes per ASN: 11.54 Origin-only ASes present in the Internet Routing Table: 52561 Origin ASes announcing only one prefix: 22956 Transit ASes present in the Internet Routing Table: 8316 Transit-only ASes present in the Internet Routing Table: 278 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 30 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 50 Number of instances of unregistered ASNs: 50 Number of 32-bit ASNs allocated by the RIRs: 22804 Number of 32-bit ASNs visible in the Routing Table: 18382 Prefixes from 32-bit ASNs in the Routing Table: 76690 Number of bogon 32-bit ASNs visible in the Routing Table: 15 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 261 Number of addresses announced to Internet: 2860375619 Equivalent to 170 /8s, 125 /16s and 222 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 234878 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 191697 Total APNIC prefixes after maximum aggregation: 54440 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 190523 Unique aggregates announced from the APNIC address blocks: 78035 APNIC Region origin ASes present in the Internet Routing Table: 8841 APNIC Prefixes per ASN: 21.55 APNIC Region origin ASes announcing only one prefix: 2475 APNIC Region transit ASes present in the Internet Routing Table: 1329 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3821 Number of APNIC addresses announced to Internet: 767462658 Equivalent to 45 /8s, 190 /16s and 141 /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: 209013 Total ARIN prefixes after maximum aggregation: 99347 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209718 Unique aggregates announced from the ARIN address blocks: 99231 ARIN Region origin ASes present in the Internet Routing Table: 18196 ARIN Prefixes per ASN: 11.53 ARIN Region origin ASes announcing only one prefix: 6726 ARIN Region transit ASes present in the Internet Routing Table: 1805 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2354 Number of ARIN addresses announced to Internet: 1105775648 Equivalent to 65 /8s, 232 /16s and 204 /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: 192114 Total RIPE prefixes after maximum aggregation: 92247 RIPE Deaggregation factor: 2.08 Prefixes being announced from the RIPE address blocks: 188106 Unique aggregates announced from the RIPE address blocks: 111657 RIPE Region origin ASes present in the Internet Routing Table: 25194 RIPE Prefixes per ASN: 7.47 RIPE Region origin ASes announcing only one prefix: 11377 RIPE Region transit ASes present in the Internet Routing Table: 3516 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7048 Number of RIPE addresses announced to Internet: 715829632 Equivalent to 42 /8s, 170 /16s and 177 /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: 90965 Total LACNIC prefixes after maximum aggregation: 19927 LACNIC Deaggregation factor: 4.56 Prefixes being announced from the LACNIC address blocks: 92410 Unique aggregates announced from the LACNIC address blocks: 41070 LACNIC Region origin ASes present in the Internet Routing Table: 7184 LACNIC Prefixes per ASN: 12.86 LACNIC Region origin ASes announcing only one prefix: 1992 LACNIC Region transit ASes present in the Internet Routing Table: 1322 Average LACNIC Region AS path length visible: 4.6 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4730 Number of LACNIC addresses announced to Internet: 172429728 Equivalent to 10 /8s, 71 /16s and 17 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 18855 Total AfriNIC prefixes after maximum aggregation: 3984 AfriNIC Deaggregation factor: 4.73 Prefixes being announced from the AfriNIC address blocks: 21678 Unique aggregates announced from the AfriNIC address blocks: 7703 AfriNIC Region origin ASes present in the Internet Routing Table: 1154 AfriNIC Prefixes per ASN: 18.79 AfriNIC Region origin ASes announcing only one prefix: 385 AfriNIC Region transit ASes present in the Internet Routing Table: 233 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 429 Number of AfriNIC addresses announced to Internet: 98440704 Equivalent to 5 /8s, 222 /16s and 22 /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 5424 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4409 419 435 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2868 1154 79 VIETEL-AS-AP Viettel Group, VN 4766 2846 11133 757 KIXS-AS-KR Korea Telecom, KR 9829 2812 1498 543 BSNL-NIB National Internet Backbone, IN 9394 2541 4923 26 CTTNET China TieTong Telecommunications 45899 2495 1586 162 VNPT-AS-VN VNPT Corp, VN 17974 2217 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2207 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2104 417 206 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3431 1324 85 SHAW - Shaw Communications Inc., CA 22773 3298 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2201 245 409 CABLEONE - CABLE ONE, INC., US 18566 2171 405 109 MEGAPATH5-US - MegaPath Corporation, US 16509 2134 4705 669 AMAZON-02 - Amazon.com, Inc., US 20115 2106 2536 466 CHARTER-NET-HKY-NC - Charter Communicat 209 1985 5070 605 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1985 342 175 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 1850 916 1325 AKAMAI-AS - Akamai Technologies, Inc., 7018 1722 20200 1262 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4230 1518 540 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2842 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2618 679 1922 AKAMAI-ASN1, US 34984 2031 335 494 TELLCOM-AS, TR 12389 2012 1877 707 ROSTELECOM-AS, RU 9121 1889 1692 19 TTNET, TR 13188 1609 100 43 TRIOLAN, UA 8402 1267 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1101 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 8151 4967 3309 582 Uninet S.A. de C.V., MX 10620 3599 541 248 Telmex Colombia S.A., CO 11830 2647 369 77 Instituto Costarricense de Electricidad 6503 1640 443 60 Axtel, S.A.B. de C.V., MX 7303 1516 1027 189 Telecom Argentina S.A., AR 28573 1031 2253 173 CLARO S.A., BR 3816 1008 505 130 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 993 377 31 Telefonica del Peru S.A.A., PE 11172 927 126 85 Alestra, S. de R.L. de C.V., MX 18881 911 1078 30 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 1038 396 48 LINKdotNET-AS, EG 37611 852 107 9 Afrihost, ZA 36903 739 371 140 MT-MPLS, MA 36992 711 1412 43 ETISALAT-MISR, EG 8452 680 1730 18 TE-AS TE-AS, EG 24835 634 786 17 RAYA-AS, EG 37492 466 470 57 ORANGE-, TN 29571 455 68 11 ORANGE-COTE-IVOIRE, CI 37342 378 32 1 MOVITEL, MZ 23889 363 103 14 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5424 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4967 3309 582 Uninet S.A. de C.V., MX 7545 4409 419 435 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 4230 1518 540 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3599 541 248 Telmex Colombia S.A., CO 6327 3431 1324 85 SHAW - Shaw Communications Inc., CA 22773 3298 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2868 1154 79 VIETEL-AS-AP Viettel Group, VN 4766 2846 11133 757 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 8151 4967 4385 Uninet S.A. de C.V., MX 7545 4409 3974 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 12479 4230 3690 UNI2-AS, ES 10620 3599 3351 Telmex Colombia S.A., CO 6327 3431 3346 SHAW - Shaw Communications Inc., CA 22773 3298 3151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2842 2799 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2868 2789 VIETEL-AS-AP Viettel Group, VN 11830 2647 2570 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 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 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 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ 41.76.143.0/24 37500 -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:14 /9:11 /10:37 /11:100 /12:290 /13:565 /14:1094 /15:1903 /16:13379 /17:7909 /18:13677 /19:25154 /20:39315 /21:45543 /22:87266 /23:70831 /24:393396 /25:828 /26:627 /27:628 /28:36 /29:20 /30:17 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3218 3431 SHAW - Shaw Communications Inc., CA 12479 3023 4230 UNI2-AS, ES 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2553 3298 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2304 2842 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2064 2171 MEGAPATH5-US - MegaPath Corporation, US 11830 1995 2647 Instituto Costarricense de Electricidad y Telec 11492 1942 2201 CABLEONE - CABLE ONE, INC., US 30036 1736 1985 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1612 3599 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1586 2:854 4:19 5:2828 6:66 7:1 8:1123 9:1 12:1860 13:189 14:1747 15:28 16:3 17:208 18:56 20:49 21:8 23:2639 24:2225 25:2 27:2359 31:1995 32:92 35:27 36:508 37:2744 38:1468 39:264 40:121 41:3226 42:594 43:1938 44:118 45:4645 46:3038 47:199 49:1324 50:1058 51:314 52:1050 54:369 55:3 56:12 57:41 58:1615 59:1005 60:434 61:2166 62:1844 63:1797 64:5032 65:2220 66:4693 67:2435 68:1161 69:3203 70:1143 71:566 72:2103 74:2733 75:414 76:453 77:1522 78:1712 79:1828 80:1508 81:1400 82:1094 83:775 84:1095 85:2052 86:575 87:1321 88:928 89:2354 90:213 91:6354 92:1203 93:2369 94:2401 95:2828 96:731 97:356 98:947 99:133 100:83 101:1276 102:66 103:17829 104:3619 105:240 106:622 107:1894 108:700 109:3463 110:1636 111:1778 112:1264 113:1255 114:1120 115:1641 116:1652 117:1730 118:2151 119:1662 120:978 121:1051 122:2444 123:1793 124:1429 125:1900 128:1034 129:647 130:458 131:1590 132:665 133:196 134:1025 135:226 136:480 137:561 138:1976 139:602 140:403 141:712 142:821 143:1002 144:799 145:464 146:1194 147:734 148:1636 149:740 150:727 151:1059 152:783 153:312 154:1096 155:763 156:994 157:796 158:655 159:1738 160:968 161:776 162:2586 163:571 164:1057 165:1472 166:458 167:1414 168:3068 169:802 170:3722 171:437 172:1072 173:2007 174:910 175:776 176:1993 177:3969 178:2503 179:1232 180:2223 181:2237 182:2367 183:1180 184:1022 185:13540 186:3631 187:2374 188:2849 189:2079 190:8129 191:1422 192:9836 193:5960 194:4810 195:3983 196:2588 197:1530 198:5527 199:5938 200:7392 201:5032 202:10474 203:10204 204:4572 205:2889 206:3108 207:3195 208:4005 209:3959 210:4044 211:2106 212:3048 213:2745 214:972 215:61 216:5966 217:2132 218:909 219:627 220:1772 221:988 222:1026 223:1273 End of report From list at satchell.net Fri Jun 1 19:00:28 2018 From: list at satchell.net (Stephen Satchell) Date: Fri, 1 Jun 2018 12:00:28 -0700 Subject: ICANN GDPR lawsuit In-Reply-To: <1d864a4451534592b97b77991c8bb03a@SC58MEXGP032.CORP.CHARTERCOM.com> References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <1d864a4451534592b97b77991c8bb03a@SC58MEXGP032.CORP.CHARTERCOM.com> Message-ID: <180a1ea1-18f7-0c7c-fe31-735e6f04800a@satchell.net> On 06/01/2018 09:37 AM, McBride, Mack wrote: > For routing whois information there aren't going to be many individuals and it would seem > that the corporations who employee individuals should be the ones protecting those individuals > work emails by providing a generic contact email forward. Which is good practice anyway > since people leave and go on vacation and problems still happen. > And the routing whois information is a lot more relevant to most of us here. +1 Perhaps the Right Thing(SM) to do is to update the best practices documents regarding role e-mail accounts for network operators. 1. Add "networkmaster at example.com" to the list of required role accounts. 2. Require that e-mail sent to role "networkmaster at example.com" be accessible in some way by all technical people for the network in question. This can be done using a ticket system, or a simple mail exploder. 3. Require that e-mail sent to role account "abuse at example.com" by accessible in some way by all members of the abuse desk. This can be done using a ticket system, or a simple mail exploder. 4. Require the WHOIS information specify exactly these role accounts for TECH and ABUSE, not a person. This gets around the GDPR requirements while maintaining the usefulness of the WHOIS without having to go through an intermediate party or web site. ICANN may want to consider this idea when adjusting its contracts with registrars to eliminate GDPR exposure. From eric.kuhnke at gmail.com Sat Jun 2 01:11:56 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 1 Jun 2018 18:11:56 -0700 Subject: SIP fax sending software? In-Reply-To: References: Message-ID: I would recommend simply outsourcing it to voip.ms for $2 a month. Port your fax DID to them. Incoming fax arrive as PDF in your choice of email inbox. You can send outbound fax from a predefined list of your own email addresses, destination to fax at voip.ms. Put the destination phone number in the subject line, attach the document to be faxed as a PDF. There is also an https web portal for uploading documents to be faxed, there is no tacky addition of advertisement. https://wiki.voip.ms/article/Virtual_Fax On Wed, May 30, 2018 at 1:13 PM, John R. Levine wrote: > Can anyone recommend software that sends faxes over SIP? I have plenty of > inbound fax to email services, but now and then I need to send a reply and > it looks tacky to use one of the free web ones that put an ad on it. > > I know that if I wanted to pay $15/mo there are lots of lovely services > but we're taking about one fax a month, maybe, here. > > Ideally it'd take a postscript or PDF or Word document and a phone number > and fax it to that number. I have Ubuntu, FreeBSD, and MacOS boxes. Any > suggestions? > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > From cloos at jhcloos.com Sat Jun 2 18:57:17 2018 From: cloos at jhcloos.com (James Cloos) Date: Sat, 02 Jun 2018 14:57:17 -0400 Subject: SIP fax sending software? In-Reply-To: (John R. Levine's message of "30 May 2018 16:13:25 -0400") References: Message-ID: >>>>> "JL" == John R Levine writes: JL> Can anyone recommend software that sends faxes over SIP? I've had good luck using asterisk's res_fax_spandsp, sending to twilio (which supports t38). Freeswitch's t38 support also is said to work well. Hylafax, iaxmodem and asterisk has worked well for mulaw faxing, provided a low-jitter path to the pstn provider, but lately I've been using the above path. Of course that is probably only one fax every few months. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From maxtul at netassist.ua Sun Jun 3 16:05:11 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 3 Jun 2018 19:05:11 +0300 Subject: SIP fax sending software? In-Reply-To: References: Message-ID: <25c2b297-6d33-7af0-f115-721c106578da@netassist.ua> Hi All, Looking for similar, but other one. Have Asterisk with E1 connection to PSTN (not VoIP). Is there some software to let it work as a fax and modem? 30.05.18 23:13, John R. Levine пише: > Can anyone recommend software that sends faxes over SIP?  I have plenty > of inbound fax to email services, but now and then I need to send a > reply and it looks tacky to use one of the free web ones that put an ad > on it. > > I know that if I wanted to pay $15/mo there are lots of lovely services > but we're taking about one fax a month, maybe, here. > > Ideally it'd take a postscript or PDF or Word document and a phone > number and fax it to that number.  I have Ubuntu, FreeBSD, and MacOS > boxes.  Any suggestions? > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > From sethm at rollernet.us Sun Jun 3 17:29:31 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 3 Jun 2018 10:29:31 -0700 Subject: SIP fax sending software? In-Reply-To: <25c2b297-6d33-7af0-f115-721c106578da@netassist.ua> References: <25c2b297-6d33-7af0-f115-721c106578da@netassist.ua> Message-ID: <387af1b5-17a9-412e-cb95-1bc2189051bf@rollernet.us> On 6/3/18 9:05 AM, Max Tulyev wrote: > Hi All, > > Looking for similar, but other one. > > Have Asterisk with E1 connection to PSTN (not VoIP). Is there some > software to let it work as a fax and modem? iaxmodem From rjoffe at centergate.com Sun Jun 3 21:17:07 2018 From: rjoffe at centergate.com (Rodney Joffe) Date: Sun, 3 Jun 2018 17:17:07 -0400 Subject: ICANN GDPR lawsuit In-Reply-To: <20180601142136.GD34704@excession.tpb.net> References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> Message-ID: <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> > On Jun 1, 2018, at 10:21 AM, niels=nanog at bakker.net wrote: > > * list at satchell.net (Stephen Satchell) [Fri 01 Jun 2018, 14:51 CEST]: >> How does your shop, Niels, go about making contact with an operator that is hijacking one of your netblocks, or is doing something weird with routing that is causing your customers problems, or has broken BGP? > > The same as we do now, by posting on NANOG "Can someone from ASx / largetelco.com contact me offlist?” Seriously? You’ve been around long enough to know thats a bull$&^% answer. Feel free to look through the archives of *this* list and look at how many times some $random handle at some $random privacy protected or generic domain asks for someone from $bignetwork to contact them about a network problem. Take you for example. You’ve been around for at least 15-20 years that I recall. But I bet you that 80% of the people on NANOG have *no* idea who you are or who you work for, and given the “useful" information on your website, an op would have to take the time to google you - which is way above the threshold of effort most people would take. And that preassumes that the ops from the tiny little network leaking your routes is actually a) subscribed here, and b) monitoring or filtering appropriately. And before you talk about the fact you stated “ largetelco(dot)com” I would bet that there are large telco’s who don’t have op’s like us who waste their time on NANOG. So, instead of the suggestion you provided, do you have any other suggestions that are useful? I’m asking seriously, because I really do see this as a problem we all have to be able to solve as operators. I believe this is absolutely on-topic for one of the NANOG lists because this is a 100% operational problem, that has appears to have as its only GDPR acceptable solution alternative, following a manual/email thread from *your* next hop network, requesting contacts/intros all the way down to the dumba$$ BGP speaking edge network with a part-time routing guy/antenna installer. /rlj From cloos at jhcloos.com Mon Jun 4 00:18:08 2018 From: cloos at jhcloos.com (James Cloos) Date: Sun, 03 Jun 2018 20:18:08 -0400 Subject: SIP fax sending software? In-Reply-To: <25c2b297-6d33-7af0-f115-721c106578da@netassist.ua> (Max Tulyev's message of "Sun, 3 Jun 2018 19:05:11 +0300") References: <25c2b297-6d33-7af0-f115-721c106578da@netassist.ua> Message-ID: >>>>> "MT" == Max Tulyev writes: MT> Have Asterisk with E1 connection to PSTN (not VoIP). Is there some MT> software to let it work as a fax and modem? For that, as Seth said, use iaxmodem. And use hylafax to feed iaxmodem. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From owen at delong.com Mon Jun 4 03:59:59 2018 From: owen at delong.com (Owen DeLong) Date: Sun, 3 Jun 2018 20:59:59 -0700 Subject: ICANN GDPR lawsuit In-Reply-To: <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> Message-ID: <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> > On Jun 3, 2018, at 14:17 , Rodney Joffe wrote: > > > >> On Jun 1, 2018, at 10:21 AM, niels=nanog at bakker.net wrote: >> >> * list at satchell.net (Stephen Satchell) [Fri 01 Jun 2018, 14:51 CEST]: >>> How does your shop, Niels, go about making contact with an operator that is hijacking one of your netblocks, or is doing something weird with routing that is causing your customers problems, or has broken BGP? >> >> The same as we do now, by posting on NANOG "Can someone from ASx / largetelco.com contact me offlist?” > > Seriously? You’ve been around long enough to know thats a bull$&^% answer. > > Feel free to look through the archives of *this* list and look at how many times some $random handle at some $random privacy protected or generic domain asks for someone from $bignetwork to contact them about a network problem. > > Take you for example. You’ve been around for at least 15-20 years that I recall. But I bet you that 80% of the people on NANOG have *no* idea who you are or who you work for, and given the “useful" information on your website, an op would have to take the time to google you - which is way above the threshold of effort most people would take. > > And that preassumes that the ops from the tiny little network leaking your routes is actually a) subscribed here, and b) monitoring or filtering appropriately. And before you talk about the fact you stated “ largetelco(dot)com” I would bet that there are large telco’s who don’t have op’s like us who waste their time on NANOG. > > So, instead of the suggestion you provided, do you have any other suggestions that are useful? I’m asking seriously, because I really do see this as a problem we all have to be able to solve as operators. I believe this is absolutely on-topic for one of the NANOG lists because this is a 100% operational problem, that has appears to have as its only GDPR acceptable solution alternative, following a manual/email thread from *your* next hop network, requesting contacts/intros all the way down to the dumba$$ BGP speaking edge network with a part-time routing guy/antenna installer. > > /rlj > Yeah, what Niels is really leaving out here is the open question of whether or not GDPR will eventually lead to the destruction of Peering DB. Owen From karim.adel at gmail.com Mon Jun 4 05:41:25 2018 From: karim.adel at gmail.com (Kasper Adel) Date: Sun, 3 Jun 2018 22:41:25 -0700 Subject: Broadcom vs Mellanox based platforms Message-ID: Hello I’m asked to evaluate switching platforms that has different forwarding chips but the same OS. Assuming these vendors give the same SDK and similar documentation/support, then what would be comparison points to consider, other than the obvious (price, features, bps, pps). I’m thinking, how do i validate their claims about capability to do leaf/spine arch, ToR/Gateways, telemetry, serviceability, facilities to troubleshoot packet drops or FIB programming misses, hidden tools...etc It would be great if anyonw can give some thoughts around it, specially if you have tried one or both. Thanks Kim From baldur.norddahl at gmail.com Mon Jun 4 05:44:35 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 4 Jun 2018 07:44:35 +0200 Subject: ICANN GDPR lawsuit In-Reply-To: <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> Message-ID: > > > > Yeah, what Niels is really leaving out here is the open question of > whether or not GDPR will eventually lead to the destruction of Peering DB. > > Owen > Of course it will not. We just need to accept that only roles not people are published. Those people will change job anyway and nobody updates whois. GDPR does not apply to companies, so you can still publish the owner of domains and IP prefixes as company names with contact information. Regards Baldur > From karim.adel at gmail.com Mon Jun 4 05:45:29 2018 From: karim.adel at gmail.com (Kasper Adel) Date: Sun, 3 Jun 2018 22:45:29 -0700 Subject: Intel DPDK vs Broadcom/Mellanox SDK Message-ID: Hi Anothe email thread to get some guidance on points to consider when comparing new platforms that advocate using DPDK as the hardware acceleration SDK vs the broadcom/mellanox. The DPDK ones claim enhanced performance but every time i ask questions, i get the logical and typical answer of “it depends” Thx Kim From C-Mack.McBride at charter.com Mon Jun 4 15:19:29 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Mon, 4 Jun 2018 15:19:29 +0000 Subject: ICANN GDPR lawsuit In-Reply-To: <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> Message-ID: If they are hijacking a netblock, it is safe to assume they will also hijack an ASN. The best method of dealing with hijacking is still deaggregation and contacting Upstreams providers from a registered whois address which should be a role account. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rodney Joffe Sent: Sunday, June 03, 2018 3:17 PM To: NANOG Subject: Re: ICANN GDPR lawsuit > On Jun 1, 2018, at 10:21 AM, niels=nanog at bakker.net wrote: > > * list at satchell.net (Stephen Satchell) [Fri 01 Jun 2018, 14:51 CEST]: >> How does your shop, Niels, go about making contact with an operator that is hijacking one of your netblocks, or is doing something weird with routing that is causing your customers problems, or has broken BGP? > > The same as we do now, by posting on NANOG "Can someone from ASx / largetelco.com contact me offlist?” Seriously? You’ve been around long enough to know thats a bull$&^% answer. Feel free to look through the archives of *this* list and look at how many times some $random handle at some $random privacy protected or generic domain asks for someone from $bignetwork to contact them about a network problem. Take you for example. You’ve been around for at least 15-20 years that I recall. But I bet you that 80% of the people on NANOG have *no* idea who you are or who you work for, and given the “useful" information on your website, an op would have to take the time to google you - which is way above the threshold of effort most people would take. And that preassumes that the ops from the tiny little network leaking your routes is actually a) subscribed here, and b) monitoring or filtering appropriately. And before you talk about the fact you stated “ largetelco(dot)com” I would bet that there are large telco’s who don’t have op’s like us who waste their time on NANOG. So, instead of the suggestion you provided, do you have any other suggestions that are useful? I’m asking seriously, because I really do see this as a problem we all have to be able to solve as operators. I believe this is absolutely on-topic for one of the NANOG lists because this is a 100% operational problem, that has appears to have as its only GDPR acceptable solution alternative, following a manual/email thread from *your* next hop network, requesting contacts/intros all the way down to the dumba$$ BGP speaking edge network with a part-time routing guy/antenna installer. /rlj E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From C-Mack.McBride at charter.com Mon Jun 4 15:29:51 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Mon, 4 Jun 2018 15:29:51 +0000 Subject: ICANN GDPR lawsuit In-Reply-To: <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> Message-ID: GDPR doesn't play well with directory listing services. BUT since providing contact information is exactly what a directory listing service does, It is safe to assume that this is 'essential' under GDPR. Ie. Unlike the US, an EU judge would find it silly that you signed up for a directory listing Service and were upset they listed your contact information. Similarly keeping contact Information of entities you have an ongoing peering relationship with would be essential. In physical terms, a milk delivery company has to keep track of its customers addresses and Billing information in order to deliver the milk and bill the customers. GDPR doesn't want individuals information collected or retained that isn't essential to providing services, nor can you share that information without permission unless it is essential. Obviously that is a one run-on sentence over simplification of a regulation that could take many volumes to fully decipher. Unlike the US, EU law is based on fairness and reasonableness so generally their society is not as litigious. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong Sent: Sunday, June 03, 2018 10:00 PM To: Rodney Joffe Cc: NANOG Subject: Re: ICANN GDPR lawsuit > On Jun 3, 2018, at 14:17 , Rodney Joffe wrote: > > > >> On Jun 1, 2018, at 10:21 AM, niels=nanog at bakker.net wrote: >> >> * list at satchell.net (Stephen Satchell) [Fri 01 Jun 2018, 14:51 CEST]: >>> How does your shop, Niels, go about making contact with an operator that is hijacking one of your netblocks, or is doing something weird with routing that is causing your customers problems, or has broken BGP? >> >> The same as we do now, by posting on NANOG "Can someone from ASx / largetelco.com contact me offlist?” > > Seriously? You’ve been around long enough to know thats a bull$&^% answer. > > Feel free to look through the archives of *this* list and look at how many times some $random handle at some $random privacy protected or generic domain asks for someone from $bignetwork to contact them about a network problem. > > Take you for example. You’ve been around for at least 15-20 years that I recall. But I bet you that 80% of the people on NANOG have *no* idea who you are or who you work for, and given the “useful" information on your website, an op would have to take the time to google you - which is way above the threshold of effort most people would take. > > And that preassumes that the ops from the tiny little network leaking your routes is actually a) subscribed here, and b) monitoring or filtering appropriately. And before you talk about the fact you stated “ largetelco(dot)com” I would bet that there are large telco’s who don’t have op’s like us who waste their time on NANOG. > > So, instead of the suggestion you provided, do you have any other suggestions that are useful? I’m asking seriously, because I really do see this as a problem we all have to be able to solve as operators. I believe this is absolutely on-topic for one of the NANOG lists because this is a 100% operational problem, that has appears to have as its only GDPR acceptable solution alternative, following a manual/email thread from *your* next hop network, requesting contacts/intros all the way down to the dumba$$ BGP speaking edge network with a part-time routing guy/antenna installer. > > /rlj > Yeah, what Niels is really leaving out here is the open question of whether or not GDPR will eventually lead to the destruction of Peering DB. Owen E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From C-Mack.McBride at charter.com Mon Jun 4 15:38:59 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Mon, 4 Jun 2018 15:38:59 +0000 Subject: Intel DPDK vs Broadcom/Mellanox SDK In-Reply-To: References: Message-ID: Use the package that corresponds to the chipset in your equipment. Ie. Broadcom/Mellanox chips use that SDK. Intel chips use DPDK. With white box switches using Broadcom chips you will run into issues If you don't use the Broadcom SDK. Obviously your mileage will vary based on the actual application. If it isn't a hardware switch and is CPU based like a home router, then there are a lot more factors and the CPU factors may outweigh the chipset factors. You may want to look at a list related to home routers for more guidance. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kasper Adel Sent: Sunday, June 03, 2018 11:45 PM To: NANOG list Subject: Intel DPDK vs Broadcom/Mellanox SDK Hi Anothe email thread to get some guidance on points to consider when comparing new platforms that advocate using DPDK as the hardware acceleration SDK vs the broadcom/mellanox. The DPDK ones claim enhanced performance but every time i ask questions, i get the logical and typical answer of “it depends” Thx Kim E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From bygg at cafax.se Mon Jun 4 18:24:07 2018 From: bygg at cafax.se (Johnny Eriksson) Date: Mon, 4 Jun 2018 18:24:07 WET DST Subject: ICANN GDPR lawsuit In-Reply-To: Your message of Fri, 1 Jun 2018 07:56:19 +0300 Message-ID: Hank Nussbacher wrote: > The entire whois debacle will only get resolved when some hackers attack > www.eugdpr.org, ec.europa.eu and some other key .eu sites.  When the > response they get will be "sorry, we can't determine who is attacking > you since that contravenes GDPR", will the EU light bulb go on that > something in GDPR needs to be tweaked. You seem to assume that said light bulb does in fact exist. > -Hank --Johnny /\_/\ ( *.* ) > ^ < From cgrundemann at gmail.com Mon Jun 4 16:24:27 2018 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 4 Jun 2018 12:24:27 -0400 Subject: Broadcom vs Mellanox based platforms In-Reply-To: References: Message-ID: Mellanox commissioned a report along these lines from Tolly in 2016: https://www.mellanox.com/related-docs/tolly/tolly-report-performance-evaluation-2016-march.pdf Obviously a grain of salt is needed with any commissioned study - but it will at least point you to some tests and methodologies that you can use... On Mon, Jun 4, 2018 at 1:41 AM, Kasper Adel wrote: > Hello > > I’m asked to evaluate switching platforms that has different forwarding > chips but the same OS. > > Assuming these vendors give the same SDK and similar documentation/support, > then what would be comparison points to consider, other than the obvious > (price, features, bps, pps). > > I’m thinking, how do i validate their claims about capability to do > leaf/spine arch, ToR/Gateways, telemetry, serviceability, facilities to > troubleshoot packet drops or FIB programming misses, hidden tools...etc > > It would be great if anyonw can give some thoughts around it, specially if > you have tried one or both. > > Thanks > Kim > -- @ChrisGrundemann http://chrisgrundemann.com From C-Mack.McBride at charter.com Mon Jun 4 16:30:18 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Mon, 4 Jun 2018 16:30:18 +0000 Subject: ICANN GDPR lawsuit In-Reply-To: References: Your message of Fri, 1 Jun 2018 07:56:19 +0300 Message-ID: That would be real time information involving 'essential' activities. GDPR would not prevent determining the source of an attack. GDPR specifically doesn't protect anyone involved in criminal activity nor contradict any regulatory requirement (which covers cyber attacks). Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Johnny Eriksson Sent: Monday, June 04, 2018 12:24 PM To: nanog at nanog.org Subject: Re: ICANN GDPR lawsuit Hank Nussbacher wrote: > The entire whois debacle will only get resolved when some hackers > attack www.eugdpr.org, ec.europa.eu and some other key .eu sites.  > When the response they get will be "sorry, we can't determine who is > attacking you since that contravenes GDPR", will the EU light bulb go > on that something in GDPR needs to be tweaked. You seem to assume that said light bulb does in fact exist. > -Hank --Johnny /\_/\ ( *.* ) > ^ < E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From tom at ninjabadger.net Mon Jun 4 17:23:00 2018 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 4 Jun 2018 18:23:00 +0100 Subject: Broadcom vs Mellanox based platforms In-Reply-To: References: Message-ID: On 04/06/18 06:41, Kasper Adel wrote: > I’m thinking, how do i validate their claims about capability to do > leaf/spine arch, ToR/Gateways, telemetry, serviceability, facilities to > troubleshoot packet drops or FIB programming misses, hidden tools...etc I'd start with a software vendor that supports both. The Cumulus Linux docs are pretty good, and available online: https://docs.cumulusnetworks.com/display/DOCS Caveats for Mellanox Spectrum, and various Broadcom ASICs, are usually listed in boxouts where appropriate. There's a whole page on *tested* scales. The software vendors are the ones that get access to the people at both companies that /really/ know where the limitations are, so you're more likely to find the best information dealing with one of them. HTH, -- Tom From baldur.norddahl at gmail.com Mon Jun 4 18:40:01 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 4 Jun 2018 20:40:01 +0200 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> Message-ID: man. 4. jun. 2018 17.31 skrev McBride, Mack : > GDPR doesn't play well with directory listing services. > BUT since providing contact information is exactly what a directory > listing service does, > It is safe to assume that this is 'essential' under GDPR. > No it is very clear that publishing private information about individuals is in fact not necessary to assign netblocks and domains to companies. It is a little less clear when the ressource is assigned to an individual. But considering there already exist privacy options for domains, the same solutions could be implemented for other ressource types. Regards Baldur Regards Baldur From owen at delong.com Mon Jun 4 18:58:22 2018 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2018 11:58:22 -0700 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> Message-ID: > On Jun 3, 2018, at 22:44 , Baldur Norddahl wrote: > >> >> >> >> Yeah, what Niels is really leaving out here is the open question of >> whether or not GDPR will eventually lead to the destruction of Peering DB. >> >> Owen >> > > > Of course it will not. We just need to accept that only roles not people > are published. Those people will change job anyway and nobody updates whois. > > GDPR does not apply to companies, so you can still publish the owner of > domains and IP prefixes as company names with contact information. > > Regards > > Baldur > >> Much of the information in Peering DB is people. In fact, IIRC, peering DB doesn’t really have “role” accounts. Peering DB is unrelated to whois. Owen From owen at delong.com Mon Jun 4 19:06:27 2018 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2018 12:06:27 -0700 Subject: ICANN GDPR lawsuit In-Reply-To: References: Message-ID: <60013E56-0F51-44E3-9A80-5A49E0BB6394@delong.com> That’s a wonderful theory. However, in practice, it’s a bit different. GDPR eliminates or at the very least complicates the maintenance of directory services. If past experience is any guide, once something becomes sufficiently difficult to maintain while complying with regulation, said thing eventually ceases to exist at least in any meaningful or useful form. It is not at all unlikely that this will be the inevitable consequence of GDPR when it comes to whois and thus, it is not at all unlikely that the scenario Hank described may be an (admittedly unintended, but very likely) outcome of GDPR. Owen > On Jun 4, 2018, at 09:30 , McBride, Mack wrote: > > That would be real time information involving 'essential' activities. > GDPR would not prevent determining the source of an attack. > GDPR specifically doesn't protect anyone involved in criminal activity > nor contradict any regulatory requirement (which covers cyber attacks). > > Mack > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Johnny Eriksson > Sent: Monday, June 04, 2018 12:24 PM > To: nanog at nanog.org > Subject: Re: ICANN GDPR lawsuit > > Hank Nussbacher wrote: > >> The entire whois debacle will only get resolved when some hackers >> attack www.eugdpr.org, ec.europa.eu and some other key .eu sites. >> When the response they get will be "sorry, we can't determine who is >> attacking you since that contravenes GDPR", will the EU light bulb go >> on that something in GDPR needs to be tweaked. > > You seem to assume that said light bulb does in fact exist. > >> -Hank > > --Johnny > > /\_/\ > ( *.* ) >> ^ < > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. > From nick at foobar.org Mon Jun 4 19:25:03 2018 From: nick at foobar.org (Nick Hilliard) Date: Mon, 4 Jun 2018 20:25:03 +0100 Subject: Broadcom vs Mellanox based platforms In-Reply-To: References: Message-ID: Kasper Adel wrote on 04/06/2018 06:41: > Assuming these vendors give the same SDK and similar documentation/support, > then what would be comparison points to consider, other than the obvious > (price, features, bps, pps). power draw. Depending on your hosting costs, the differences in power draw between each chipset may impact the total cost of ownership over the accounting depreciation period of the kit. It's worth measuring and putting into your costs analysis. Nick From rubensk at gmail.com Mon Jun 4 19:32:39 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 4 Jun 2018 16:32:39 -0300 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> Message-ID: On Fri, Jun 1, 2018 at 1:56 AM, Hank Nussbacher wrote: > On 31/05/2018 21:44, John Peach wrote: > > On 05/31/2018 02:37 PM, Dan Hollis wrote: > >> On Thu, 31 May 2018, bzs at theworld.com wrote: > >>> FWIW a German court has just ruled against ICANN's injunction and in > >>> favor of Tucows/EPAG. > >>> https://www.icann.org/news/announcement-4-2018-05-30-en > >> > >> Welcome to contact-free whois? > >> > >> -Dan > > > > > > Already been bitten by it and trying to get the contact info reinstated. > > > > > > > The entire whois debacle will only get resolved when some hackers attack > www.eugdpr.org, ec.europa.eu and some other key .eu sites. When the > response they get will be "sorry, we can't determine who is attacking > you since that contravenes GDPR", will the EU light bulb go on that > something in GDPR needs to be tweaked. > Usually, identifying attackers at other online services is a duty on RIR directories, and even the RIPE one is not suffering that many changes due to GDPR. Also, GDPR doesn't prevent law enforcement access. Rubens From baldur.norddahl at gmail.com Mon Jun 4 19:44:46 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 4 Jun 2018 21:44:46 +0200 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> Message-ID: man. 4. jun. 2018 20.58 skrev Owen DeLong : > > > Much of the information in Peering DB is people. In fact, IIRC, peering DB > doesn’t really have “role” accounts. > > Peering DB is unrelated to whois. > > Owen > No actually I just checked and peeringdb has none of my personal information. It has the phone number and email address for our NOC. This is just company info and does not go to a specific person. As long that is an option, peeringdb can also allow people to publish their direct contact information. It is true opt in when the alternative works just as well. Do not make more of it than needs to be. Regards Baldur > From baldur.norddahl at gmail.com Mon Jun 4 19:51:07 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 4 Jun 2018 21:51:07 +0200 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> Message-ID: man. 4. jun. 2018 20.56 skrev Daniel Corbe : > > It occurs to me that operators might want to opt-in to have their data > published through PeeringDB. From a purely pragmatic standpoint, I won’t > peer with anyone I can’t reach out to and if you don’t have a 24/7 NOC > chances are good that you’re going to get depeered the first time there’s > a > technical issue and I can’t reach you for help. > > An academic exercise, for sure. But one that would render this line of > thinking rather moot. > If it is a true 24/7 NOC you can not possibly expect a specific person to answer the call. It will be whoever is on duty or on call at that time. You do not need a name. Just the number and the email address. And that is exactly what many operators put into peeringdb as is. No changes needed. Regards Baldur From C-Mack.McBride at charter.com Mon Jun 4 20:10:03 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Mon, 4 Jun 2018 20:10:03 +0000 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> Message-ID: <69e1181bdab448e580bff568d0d5ea29@SC58MEXGP032.CORP.CHARTERCOM.com> Peering DB is also a directory service. The only 'service' they provide is to distribute contact information. Therefor maintaining and distributing information is in fact 'essential'. Further, Peering DB make it easy to remove contact information. The difference in legal systems makes Peering DB a very low risk in the EU. Whois is more 'at risk' because it doesn't require individual information to maintain a net block. BUT, most whois can be handled by role accounts and privacy guard services. Best practice is to use role accounts. Privacy guard deals with the now rare condition where a net block is owned by an individual. Most domain name services have provided a privacy guard option for years. Most network providers simply want an email address that works. I don't really care if it is joe or the purple people eater as long as it gets a response from an intelligent entity that can fix a routing issue. For this purpose a level 1 tech capable of escalating an issue counts as an intelligent entity. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong Sent: Monday, June 04, 2018 12:58 PM To: Baldur Norddahl Cc: nanog at nanog.org Subject: Re: ICANN GDPR lawsuit > On Jun 3, 2018, at 22:44 , Baldur Norddahl wrote: > >> >> >> >> Yeah, what Niels is really leaving out here is the open question of >> whether or not GDPR will eventually lead to the destruction of Peering DB. >> >> Owen >> > > > Of course it will not. We just need to accept that only roles not > people are published. Those people will change job anyway and nobody updates whois. > > GDPR does not apply to companies, so you can still publish the owner > of domains and IP prefixes as company names with contact information. > > Regards > > Baldur > >> Much of the information in Peering DB is people. In fact, IIRC, peering DB doesn’t really have “role” accounts. Peering DB is unrelated to whois. Owen E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From randy at psg.com Tue Jun 5 00:01:13 2018 From: randy at psg.com (Randy Bush) Date: Mon, 04 Jun 2018 17:01:13 -0700 Subject: ICANN GDPR lawsuit In-Reply-To: Message-ID: once upon a time, when one received what had yet to be called spam, or logs showed an attack, one wrote to the owner of the source ip to tell them their system had been hacked. dunno about everyone else, but i stopped doing that sometime in the '80s. randy _ //` `\ _,-"\% // /``\`\ ~^~ >__^ |% // / } `\`\ ) )%// / } } }`\`\ / (%/`/.\_/\_/\_/\`/ ( ` `-._` \ , ( \ _`-.__.-%> /_`\ \ `\ \." `-..- ` ``` /_/`"-=-``/_/ ``` ``` From goemon at sasami.anime.net Tue Jun 5 00:34:29 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Mon, 4 Jun 2018 17:34:29 -0700 (PDT) Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> Message-ID: On Mon, 4 Jun 2018, Rubens Kuhl wrote: > On Fri, Jun 1, 2018 at 1:56 AM, Hank Nussbacher > wrote: > Usually, identifying attackers at other online services is a duty on RIR > directories, and even the RIPE one is not suffering that many changes due > to GDPR. > > Also, GDPR doesn't prevent law enforcement access. It might be desirable to provide enough contact information to mitigate issues before it has to end up in the hands of law enforcement. black hats and bullet proof hosting are definitely going to enjoy using gdpr to hide behind though. -Dan From rubensk at gmail.com Tue Jun 5 00:44:46 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 4 Jun 2018 21:44:46 -0300 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> Message-ID: On Mon, Jun 4, 2018 at 9:34 PM, Dan Hollis wrote: > On Mon, 4 Jun 2018, Rubens Kuhl wrote: > >> On Fri, Jun 1, 2018 at 1:56 AM, Hank Nussbacher >> wrote: >> Usually, identifying attackers at other online services is a duty on RIR >> directories, and even the RIPE one is not suffering that many changes due >> to GDPR. >> >> Also, GDPR doesn't prevent law enforcement access. >> > > It might be desirable to provide enough contact information to mitigate > issues before it has to end up in the hands of law enforcement. > Specifically on gTLD domains GDPR effects, domain contacts will still be reachable thru a web-form or short-term anonymised email. European ccTLDs adopted a myriad of solutions but they usually trend towards maintaining reachability somehow. > black hats and bullet proof hosting are definitely going to enjoy using > gdpr to hide behind though. Like they already do signing up for domain privacy services ? Currently, only the poor criminals or the newbie ones do not elect privacy when registering domains. Rubens From bzs at theworld.com Tue Jun 5 00:52:05 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Mon, 4 Jun 2018 20:52:05 -0400 Subject: ICANN GDPR lawsuit In-Reply-To: References: Message-ID: <23317.57013.588636.222627@gargle.gargle.HOWL> On June 4, 2018 at 17:01 randy at psg.com (Randy Bush) wrote: > once upon a time, when one received what had yet to be called spam, or > logs showed an attack, one wrote to the owner of the source ip to tell > them their system had been hacked. dunno about everyone else, but i > stopped doing that sometime in the '80s. I remember one night, early 1990s, watching keystrokes of a guy who'd gotten into one of our systems and realized I knew the owner of the system he was coming in from, a name most of you would recognize, so called him at home at like 2AM which was appreciated. ISTR that was the guy who was actually typing VMS commands to a unix shell which is why I wasn't all that concerned, other than the holes he'd used to get a shell prompt which is what I was trying to track down. -- -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 ahebert at pubnix.net Tue Jun 5 13:48:20 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 5 Jun 2018 09:48:20 -0400 Subject: BGP Hijack/Sickness with AS4637 - Case closed In-Reply-To: <20180531183636.GD75485@vurt.meerval.net> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> <20180531141541.GA75485@vurt.meerval.net> <0f9f25af-2aeb-b782-f270-c48c8b05260d@pubnix.net> <20180531144006.GB75485@vurt.meerval.net> <20180531183636.GD75485@vurt.meerval.net> Message-ID:     Hi,     Looks like it was a RIB<->FIB bug in part.     How: BGP Optimizator maybe a culprit, but without insights from ColoAU it is hard to say.     Thank to Job, Mark, Tracey for their time. ----- 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 05/31/18 14:36, Job Snijders wrote: > On Thu, May 31, 2018 at 02:40:06PM +0000, Job Snijders wrote: >> Upon further inspection, it seems more likely that the bgp optimiser is >> in ColoAU's network. Given the scale of AS 4637, if it were deployed >> inside Telstra I'd expect more problem reports. AS 4637 may actually >> just be an innocent bystander. >> >> It is interesting to note that the /23 only appears on their Sydney >> based routers on https://lg.coloau.com.au/ >> >> Is ColoAU's refusal to cooperate a matter of misunderstanding? Perhaps >> you should just straight up ask whether they use any type of "network >> optimisation" appliance. > I found a few more interesting routes inside ColoAU's looking glass: > > 128.10.4.0/24 - AS_PATH 63956 4637 3257 29909 16532 16532 16532 16532 > (should be 128.10.0.0/16 originated by AS 17, Purdue > University) > > 192.54.130.0/24 - AS path: 135069 9439 > (does not exist in the DFZ, a peering lan prefix? a typo?) > > 67.215.73.0/24 - AS path: 2764 1221 36692 > (does not exist in the DFZ, a peering lan prefix? a typo?) > > ColoAU propagated the above routes to their transit customers, so the > 128.10.4.0/24 and 18.29.238.0/23 announcements definitely count as BGP > hijacks with fabricated an AS_PATH. > > Kind regards, > > Job > From brad at coloau.com.au Fri Jun 1 02:56:22 2018 From: brad at coloau.com.au (Brad Hooper) Date: Fri, 1 Jun 2018 14:56:22 +1200 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: <20180531183636.GD75485@vurt.meerval.net> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> <20180531141541.GA75485@vurt.meerval.net> <0f9f25af-2aeb-b782-f270-c48c8b05260d@pubnix.net> <20180531144006.GB75485@vurt.meerval.net> <20180531183636.GD75485@vurt.meerval.net> Message-ID: Hello, Just to clear up a few things. We are not running any route optimization software (ever). The reason we "refused" to help is because we were not going to contact our transit providers NOC regarding other parties routes, even if we did they wouldn't be of assistance. We are purely passing on the routes we receive from our transit providers to our customers. We are not modifying the routes in any way shape or form. We incest routes from a lot of transit providers and send most of the data to route views (As do a number of our customers) which is why this route was seen from us. I have completed a soft clear on our BGP session towards AS4637 and the route still exists. Sorry we can't be of assistance in this case but this is fully out of our control. xxxx at re0-cr1.ty8.ty.jp> show route 128.10.4.0/24 detail vrf-international.inet.0: 696465 destinations, 1194388 routes (696461 active, 0 holddown, 4 hidden) 128.10.4.0/24 (1 entry, 1 announced)         *BGP    Preference: 170/-101                 Next hop type: Router, Next hop index: 790                 Address: 0xff29810                 Next-hop reference count: 1279932                 Source: 202.127.69.33                 Next hop: 202.127.69.33 via ae0.401, selected                 Session Id: 0x181                 State:                 Peer AS:  4637                 Age: 2w4d 11:08:17                 Validation State: unverified                 Task: BGP_4637.202.127.69.33                 Announcement bits (4): 1-KRT 2-BGP Route Target 5-BGP_RT_Background 6-Resolve tree 6                 AS path: 4637 3257 29909 16532 16532 16532 16532 I                 Communities: 4637:32031 4637:32314 4637:32504 4637:60952                 Accepted                 Localpref: 100                 Router ID: 202.84.219.12 Regards, Brad ColoAU (AS63956) Colocation Australia Pty Ltd Brad Hooper / Network Architect brad at coloau.com.au / +61 7 3106 3810 Colocation Australia Pty Ltd http://coloau.com.au Facebook Twitter skype On 01/06/18 06:36, Job Snijders wrote: > On Thu, May 31, 2018 at 02:40:06PM +0000, Job Snijders wrote: >> Upon further inspection, it seems more likely that the bgp optimiser is >> in ColoAU's network. Given the scale of AS 4637, if it were deployed >> inside Telstra I'd expect more problem reports. AS 4637 may actually >> just be an innocent bystander. >> >> It is interesting to note that the /23 only appears on their Sydney >> based routers on https://lg.coloau.com.au/ >> >> Is ColoAU's refusal to cooperate a matter of misunderstanding? Perhaps >> you should just straight up ask whether they use any type of "network >> optimisation" appliance. > I found a few more interesting routes inside ColoAU's looking glass: > > 128.10.4.0/24 - AS_PATH 63956 4637 3257 29909 16532 16532 16532 16532 > (should be 128.10.0.0/16 originated by AS 17, Purdue > University) > > 192.54.130.0/24 - AS path: 135069 9439 > (does not exist in the DFZ, a peering lan prefix? a typo?) > > 67.215.73.0/24 - AS path: 2764 1221 36692 > (does not exist in the DFZ, a peering lan prefix? a typo?) > > ColoAU propagated the above routes to their transit customers, so the > 128.10.4.0/24 and 18.29.238.0/23 announcements definitely count as BGP > hijacks with fabricated an AS_PATH. > > Kind regards, > > Job From ff at ozog.com Mon Jun 4 08:33:32 2018 From: ff at ozog.com (ff at ozog.com) Date: Mon, 04 Jun 2018 10:33:32 +0200 Subject: Broadcom vs Mellanox based platforms In-Reply-To: References: Message-ID: <7b119a9bd2454729422c3584c5cb825c@ozog.com> Hi Kim, I'll share key learnings about since I started to work on high speed software networking in 2006, when everyone was laughing at me becaused I claimed to achieve 10Gbps networking with a CPU. CPU is less important than memory/QPI On x86 memory subsytem include things like Cache Boxes, Home Agent, DRAM controllers... Home Agent is reponsible to know on which CPU node is a cacheline. So it can become a centralized bottleneck.... DRAM controllers have a queue of pending DRAM requests (instruction pipeline, data prefetch, data...). QPI routing may also severely impact performance. I remember using a 4 socket system that was half the performance of a 2 socket system because of either bad QPI routing programing by the BIOS or a hardware issue. An order of magnitude to keep in mind is that at 100Gbps, each 64-byte packet and each associated 64-byte used metadata cacheline is consuming roughly a full DRAM channel. As an example and not counting application data to be leveraged (FIB, DNS database...) a 100Gbps DPDK bridging application requires 3 memory channels per port (to reach line rate if the IO allows it)... There is a lot more to say but I let you do your own research ;-) BTW, why would you want to do 100GBps line rate (or very close to it)? To ensure that each node has the capacity to resist a DDoS attack powered by DPDK/ODP/native "applications". PCI is your ennemy (or not that a good friend) PCI chipset behavior is complex. The typical payload on x86 is 256bytes. So I assumed that using a 1KB max payload to support the average 670 byte internet packet size would give better results... But no, early DMA transaction acknowledgement is disabled if payload not 256 so it dropped performance significantly. You may have an embedded switch on the NIC. So you think that offloading will give you a benefit. Yes at low speed but you can't build a 50Gbps service chain because most of the NIC are on PCI x8 Gen3 slots which is limited to 50Gbps BW. So the conclusion is: don't try to understand those limits, create a testbed that really mimics the target "size" and topology of your use case and measure. Don't do tests at 10Gbps if your target is 100Gbps. Starting at 50Gbps you will be bumping on PCI DMA transaction rate barrier. Unless you have a smart IO model (multiple packets per DMA transaction - see Netcope for instance) supported in zero-copy by the SDK architecture you won't reach line rate or be able to have an application (zero-copy of data or metadata reduction can save a DRAM channel for application at this "speed"). I think (but not sure) you can squeeze two packets in a buffer with Mellanox cards: that can be instrumental in reaching 50Gbps line rate but I don't know if DPDK supports this feature. Don't do pps at the switch level if your target is fast VM application behavior. Measuring that a software switch can do 10Gbps line rate with 64 byte packets does not help at all to predict TCP application performance in a VM. Factors such as GRO/GSO support are more important as limiting factor is TCP window opening. I measured web traffic over IPSec links between VMs. The key performance factor was latency of the switching/IPsec combo: if latency is above a certain level, TCP window of the endpoints does not open and the in-between software switches become under-utilized. My vision is that if you use a hardware specific SDK to build your hardware specific application, you will get the best of the hardware. The gains can range from 30% to 100% depending on HW, so it is not negligible (you may have to prove this assertion ;-). One major reason being the ability to use the exact sotfware metadata which may become a single cache line or even no software metadata at all as you could leverage the hardware descriptor directly. The other reason is to leverage the native IO model for the device which DPDK may not support. The price to pay is hardware or vendor dependence. FF PS1: You may want to clarify your search: you haven't stated if your interest is L2 switch or L3 switch, if you consider baremetal switching, container or VM switching. If you want L3 then you probably want to focus on VPP, Contrail or Snabb rather than the low level packet io frameworks. With latest Intel AVF technology, DPDK is almost irrelevant for VPP and actually slows things down with the same hardware (Intel XL 710 card) AAdditionally, the kernel community is working on AF_XDP which may be relevant for your case. PS2: I am not sure NANOG is the best list to discuss the technical details you want. That said, it may be the best place to discuss the use cases or realistic testbed setup. On 04.06.2018 07:41, Kasper Adel wrote: > Hello > > I’m asked to evaluate switching platforms that has different forwarding > chips but the same OS. > > Assuming these vendors give the same SDK and similar > documentation/support, > then what would be comparison points to consider, other than the > obvious > (price, features, bps, pps). > > I’m thinking, how do i validate their claims about capability to do > leaf/spine arch, ToR/Gateways, telemetry, serviceability, facilities to > troubleshoot packet drops or FIB programming misses, hidden tools...etc > > It would be great if anyonw can give some thoughts around it, specially > if > you have tried one or both. > > Thanks > Kim From jean.delestre at gmail.com Mon Jun 4 15:24:14 2018 From: jean.delestre at gmail.com (Jean Delestre) Date: Mon, 4 Jun 2018 17:24:14 +0200 Subject: Broadcom vs Mellanox based platforms In-Reply-To: References: Message-ID: Hello Not sure how to compare but i'd be very interested in the result of your work ! Le lun. 4 juin 2018 à 07:43, Kasper Adel a écrit : > Hello > > I’m asked to evaluate switching platforms that has different forwarding > chips but the same OS. > > Assuming these vendors give the same SDK and similar documentation/support, > then what would be comparison points to consider, other than the obvious > (price, features, bps, pps). > > I’m thinking, how do i validate their claims about capability to do > leaf/spine arch, ToR/Gateways, telemetry, serviceability, facilities to > troubleshoot packet drops or FIB programming misses, hidden tools...etc > > It would be great if anyonw can give some thoughts around it, specially if > you have tried one or both. > > Thanks > Kim > From dcorbe at hammerfiber.com Mon Jun 4 18:56:27 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Mon, 4 Jun 2018 14:56:27 -0400 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> Message-ID: at 2:40 PM, Baldur Norddahl wrote: > man. 4. jun. 2018 17.31 skrev McBride, Mack : > >> GDPR doesn't play well with directory listing services. >> BUT since providing contact information is exactly what a directory >> listing service does, >> It is safe to assume that this is 'essential' under GDPR. > > No it is very clear that publishing private information about individuals > is in fact not necessary to assign netblocks and domains to companies. > > It is a little less clear when the ressource is assigned to an individual. > But considering there already exist privacy options for domains, the same > solutions could be implemented for other ressource types. > It occurs to me that operators might want to opt-in to have their data published through PeeringDB. From a purely pragmatic standpoint, I won’t peer with anyone I can’t reach out to and if you don’t have a 24/7 NOC chances are good that you’re going to get depeered the first time there’s a technical issue and I can’t reach you for help. An academic exercise, for sure. But one that would render this line of thinking rather moot. From coutant at stg-interactive.com Tue Jun 5 12:57:16 2018 From: coutant at stg-interactive.com (Sylvain COUTANT) Date: Tue, 5 Jun 2018 14:57:16 +0200 Subject: Broadcom vs Mellanox based platforms In-Reply-To: References: Message-ID: <2a60f384-c3fd-aa0a-4184-2e8c71ad115d@stg-interactive.com> On 06/04/2018 07:41 AM, Kasper Adel wrote: > Hello > > I’m asked to evaluate switching platforms that has different forwarding > chips but the same OS. > > Assuming these vendors give the same SDK and similar documentation/support, > then what would be comparison points to consider, other than the obvious > (price, features, bps, pps). Not willing to troll too much, but ... beside price, the main difference is about disclosed chips specs. Broadcom gives marketings specs (basic features, bps, pps) only. Chipset documentation is disclosed only to some partners and is under NDA. Mellanox is open about specs, afaik drivers are open source, etc. Mellanox' commissioned study stated in another reply is a good starting point. Think what you want about the results, but without public specs from Broadcom, people have to expriment to understand and find out how their silicon work. And where are the (undisclosed) limits. Good luck with this if you expect predictable results under load ... /Sylvain. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mehmet at akcin.net Tue Jun 5 18:47:08 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 5 Jun 2018 11:47:08 -0700 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: thank you very much to so many people who have reached out providing leads , made introductions and followed up offering help. I wanted to update the list with the progress we have made so far. 1) We've identified several datacenter facilities where networks are commonly present and diverse from each other with some additional network assets. We will soon be touring these facilities. 2) We've talked to backbone and transit providers and got incredible deals for this market & caribbean 3) We've engaged few "core" Content networks and asked them to join our initiative (Great interest here but we need more.) 4) Last but not least, we need some people on the island for bootstrapping and ongoing support of the IX and the members (this is a challenge, I will personally work on resolving by spending 2 weeks in August in Puerto Rico both searching & interviewing candidates. 5) We were offered some hardware donations but they are fairly old, and we are looking for modernish IX equipment that are easy to setup & manage. If anyone has suggestions please do let me know, I am thinking about just buying some stuff from Ebay :-) Anyway, I will be at NANOG Denver and if anyone is interested in speaking in person please feel free to setup time to discuss this https://calendly.com/akcin On Sun, Sep 3, 2017 at 9:28 PM, Joly MacFie wrote: > Looking forward to updating https://en.wikipedia. > org/wiki/Internet_Exchange_of_Puerto_Rico :) > > > >> >>> We are hoping the relaunch to happen sometime in 2018. Thanks in >> advance >> >>> hope to share more info and traffic data sometime , soon. Watch this >> space! >> >>> >> >>> Mehmet >> >>> >> >> >> >> -- >> --------------------------------------------------------------- >> Joly MacFie 218 565 9365 Skype:punkcast >> -------------------------------------------------------------- >> - >> > From mehmet at akcin.net Tue Jun 5 19:03:07 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 5 Jun 2018 12:03:07 -0700 Subject: Subsea availability In-Reply-To: <20180522182848.6292a82f@riri.DEF.witbe.net> References: <20180522182848.6292a82f@riri.DEF.witbe.net> Message-ID: I wanted to give a little update on this project, Thanks to data made available by Telegeography on Github we have made some great progress. you can visit https://goo.gl/QK6pga to see the map available with all subsea cables that exists. Currently we are working with subsea providers to receive emails to a specific email address regarding outages and then parse this email in a way to update color of the cable on the map. There are MANY challenges to this but we believe we will over come those challenges with collaboration and coordination. I have reached out to several subsea cable operators asking them to help provide data but so far let's say, I am not as luck as I thought I would be. Anyway , I plan to tackle some of the challenges (parsing emails, updating map via code and other methods of intake) in upcoming NANOG Denver Hackathon. I am intentionally taking the route of email notifications because those can be tailored to ensure the outage is from 1 Cable Landing Station to another Cable Landing Station. If you have suggestions please let me know. Best regards On Tue, May 22, 2018 at 9:28 AM, Paul Rolland (ポール・ロラン) wrote: > Hello, > > On Tue, 22 May 2018 06:35:12 +0100 > Martin Hepworth wrote: > > > I'll put this as a starter > > > > http://submarine-cable-map-2018.telegeography.com/ > > This one is rather cool too: > http://he.net/3d-map/ > > Paul > > -- > > Paul Rolland E-Mail : rol(at)witbe.net > CTO - Witbe.net SA Tel. +33 (0)1 47 67 77 77 > Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 > F-92057 Paris La Defense RIPE : PR12-RIPE > > LinkedIn : http://www.linkedin.com/in/paulrolland > Skype : rollandpaul > > "I worry about my child and the Internet all the time, even though she's > too young to have logged on yet. Here's what I worry about. I worry that 10 > or 15 years from now, she will come to me and say 'Daddy, where were you > when they took freedom of the press away from the Internet?'" > --Mike Godwin, Electronic Frontier Foundation > > > From C-Mack.McBride at charter.com Tue Jun 5 19:31:38 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Tue, 5 Jun 2018 19:31:38 +0000 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> Message-ID: <5726f24d9afc47278e3e6f2ed382964e@SC58MEXGP032.CORP.CHARTERCOM.com> PeeringDB is already 100% opt-in. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Corbe Sent: Monday, June 04, 2018 12:56 PM To: Baldur Norddahl Cc: nanog at nanog.org Subject: Re: ICANN GDPR lawsuit at 2:40 PM, Baldur Norddahl wrote: > man. 4. jun. 2018 17.31 skrev McBride, Mack : > >> GDPR doesn't play well with directory listing services. >> BUT since providing contact information is exactly what a directory >> listing service does, It is safe to assume that this is 'essential' >> under GDPR. > > No it is very clear that publishing private information about > individuals is in fact not necessary to assign netblocks and domains to companies. > > It is a little less clear when the ressource is assigned to an individual. > But considering there already exist privacy options for domains, the > same solutions could be implemented for other ressource types. > It occurs to me that operators might want to opt-in to have their data published through PeeringDB. From a purely pragmatic standpoint, I won’t peer with anyone I can’t reach out to and if you don’t have a 24/7 NOC chances are good that you’re going to get depeered the first time there’s a technical issue and I can’t reach you for help. An academic exercise, for sure. But one that would render this line of thinking rather moot. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From rubensk at gmail.com Tue Jun 5 19:41:26 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 5 Jun 2018 16:41:26 -0300 Subject: ICANN GDPR lawsuit In-Reply-To: <5726f24d9afc47278e3e6f2ed382964e@SC58MEXGP032.CORP.CHARTERCOM.com> References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> <5726f24d9afc47278e3e6f2ed382964e@SC58MEXGP032.CORP.CHARTERCOM.com> Message-ID: On Tue, Jun 5, 2018 at 4:31 PM, McBride, Mack wrote: > PeeringDB is already 100% opt-in. > Domain registration is also opt-in, and still registrars, registries and ICANN have to change things to comply with GDPR. Rubens From C-Mack.McBride at charter.com Tue Jun 5 19:48:38 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Tue, 5 Jun 2018 19:48:38 +0000 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> <20180601122403.GC34704@excession.tpb.net> <20180601142136.GD34704@excession.tpb.net> <87DC5D2B-DBE1-4BEB-955F-700B620D7715@centergate.com> <2340C367-1FE4-4C56-9304-DF5AD12889DB@delong.com> <5726f24d9afc47278e3e6f2ed382964e@SC58MEXGP032.CORP.CHARTERCOM.com> Message-ID: <2e73cc005d41425eb095301aeb8f9a4c@SC58MEXGP032.CORP.CHARTERCOM.com> There is a major difference between a directory listing service where the primary goal is to advertise potentially protected information and a domain registration or net block registration where the information is secondary and its dissemination is not what you are actually requesting. Remember peering DB has a sole purpose of disseminating names, phone numbers and email addresses. Mack From: Rubens Kuhl [mailto:rubensk at gmail.com] Sent: Tuesday, June 05, 2018 1:41 PM To: McBride, Mack Cc: Daniel Corbe ; Baldur Norddahl ; nanog at nanog.org Subject: Re: ICANN GDPR lawsuit On Tue, Jun 5, 2018 at 4:31 PM, McBride, Mack > wrote: PeeringDB is already 100% opt-in. Domain registration is also opt-in, and still registrars, registries and ICANN have to change things to comply with GDPR. Rubens E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From pete at ots.utsystem.edu Tue Jun 5 19:57:25 2018 From: pete at ots.utsystem.edu (Mitcheltree, Harold B) Date: Tue, 5 Jun 2018 19:57:25 +0000 Subject: 3rd party QSFP-100G-LR4-S for Cisco In-Reply-To: References: Message-ID: FS.COM --Pete ________________________________ From: NANOG on behalf of Ryugo Kikuchi Sent: Tuesday, May 29, 2018 7:48:16 AM To: nanog at nanog.org Subject: 3rd party QSFP-100G-LR4-S for Cisco Hey all, Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" for Cisco ASR and Nexus? Cisco's original 100G SFP costs us an arm and a leg, so we want to try to use 3rd party 100g SFP. But we are not sure which manufacturer's SFP is reliable or has good performance. Does anyone have experience? Many thanks, Roy From karim.adel at gmail.com Wed Jun 6 01:26:30 2018 From: karim.adel at gmail.com (Kasper Adel) Date: Tue, 5 Jun 2018 18:26:30 -0700 Subject: VPP-based router vs Hardware assisted ones Message-ID: Hi Ross Did you make a decision to take that direction after reviewing ‘open networking’ platforms like cumulus and pica8? Are you trying to use the full routing table? ~kim On Thursday, May 24, 2018, Ross Tajvar wrote: > Hi all, > > Has anyone had any luck building their own routers on common compute (x86) > with VPP? I'm considering it as I'm looking for a cheap, fast peering > router. I haven't seen much written about that type of solution so I was > wondering if anyone here has experience to share. > > Thanks, > Ross > From karim.adel at gmail.com Wed Jun 6 01:31:25 2018 From: karim.adel at gmail.com (Kasper Adel) Date: Tue, 5 Jun 2018 18:31:25 -0700 Subject: Intel DPDK vs Broadcom/Mellanox SDK In-Reply-To: References: Message-ID: Can you please provide examples on issues that you highlighted with broadcom? Are you saying i may not see the same with mellanox? Thanks On Monday, June 4, 2018, McBride, Mack wrote: > Use the package that corresponds to the chipset in your equipment. > Ie. Broadcom/Mellanox chips use that SDK. Intel chips use DPDK. > With white box switches using Broadcom chips you will run into issues > If you don't use the Broadcom SDK. Obviously your mileage will vary > based on the actual application. If it isn't a hardware switch and is CPU > based > like a home router, then there are a lot more factors and the CPU factors > may > outweigh the chipset factors. You may want to look at a list related to > home > routers for more guidance. > > Mack > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kasper Adel > Sent: Sunday, June 03, 2018 11:45 PM > To: NANOG list > Subject: Intel DPDK vs Broadcom/Mellanox SDK > > Hi > > Anothe email thread to get some guidance on points to consider when > comparing new platforms that advocate using DPDK as the hardware > acceleration SDK vs the broadcom/mellanox. > > The DPDK ones claim enhanced performance but every time i ask questions, i > get the logical and typical answer of “it depends” > > Thx > Kim > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended > solely for the addressee(s) and may contain confidential and/or legally > privileged information. If you are not the intended recipient of this > message or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message > and any attachments. If you are not the intended recipient, you are > notified that any use, dissemination, distribution, copying, or storage of > this message or any attachment is strictly prohibited. > From hank at efes.iucc.ac.il Wed Jun 6 05:01:35 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 6 Jun 2018 08:01:35 +0300 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> Message-ID: <980518d4-22cb-6cec-11dc-8407445b1127@efes.iucc.ac.il> On 31/05/2018 08:14, Badiei, Farzaneh wrote: Gotta love the EU logic: https://inews.co.uk/news/uk/gdpr-eu-commission-not-compliant/ The European Commission is not GDPR compliant even though it was responsible for the new GDPR law "The European Commission has insisted it is *not subject to the strict new data protection law* that it has imposed across Europe after it was revealed the personal information of hundreds of people had been leaked on its website. " -Hank > And here is the court decision, https://www.icann.org/en/system/files/files/litigation-icann-v-epag-request-court-order-prelim-injunction-redacted-30may18-en.pdf > > > gotta love the German wisdom: > > > The Application for preliminary injunction of May 25, 2018 is rejected at the expense of the Applicant. > > > "Insofar as the Applicant bases its claim to relief on a parallel of the so-called "WHOIS" system to international agreements on trade mark registers, the Chamber is unable to follow this. The legal basis for the trademark registers on the basis of international agreements is missing in relation to the "WHOIS" service claimed by the Applicant. The fundamental comparability of the respective general need for protection does not change this." > > From hank at efes.iucc.ac.il Wed Jun 6 05:10:58 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 6 Jun 2018 08:10:58 +0300 Subject: Bezeq Internet (IL) around? In-Reply-To: <6E523F23-433F-4D15-9E2A-417281AA4761@theo-voss.de> References: <20180524162028.GC1007@anx-nb3810.local> <6E523F23-433F-4D15-9E2A-417281AA4761@theo-voss.de> Message-ID: On 27/05/2018 17:32, Theo Voss wrote: There are basically two colo sites available in the Tel Aviv area: Med-1 - https://www.medone.co.il/en/ Bezeqint - https://www.bezeqint.net/english/carrier-wholesale-services/data-center-and-dr/jaffa-data-center The first is run by a company that doesn't provide any sort of transit - just data center.  The second is run by a company that can also sell you transit. There are only 4 companies in Israel that can provide carrier services: Bezeqint HOT - http://www.hot.net.il/heb/English/ Partner - No English site Cellcom - No English site At Med-1 you can buy transit from any of the 4 listed above.  At the Bezeqint site they only allow Bezeqint circuits so you are limited to only one carrier. If you need contacts at any of the companies, drop me an email and I'll send you email contacts at each of the companies. -Hank > Hi all, > > is there anyone from an Israeli ISP other than Bezeq around who is capable of providing colocation/transit in Tel Aviv? > > Best regards, > Theo Voss > > Am 24.05.18, 18:23 schrieb "NANOG im Auftrag von Elmar K. Bins" : > > Hi Bezeq people, > > I hope you're subscribed here, I could use your immediate help, probably > leading to a contract... > > Yours, > Elmar. > > > From elmi at 4ever.de Wed Jun 6 09:52:03 2018 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 6 Jun 2018 11:52:03 +0200 Subject: Bezeq Internet (IL) around? In-Reply-To: References: <20180524162028.GC1007@anx-nb3810.local> <6E523F23-433F-4D15-9E2A-417281AA4761@theo-voss.de> Message-ID: <20180606095203.GC954@anx-nb3810.anexia.local> Re Hank, thank you for the comprehensive info, this kind of help is why I still consider NANOG a very good community and this mailing list one of the major tools of the network business. Not to even mention the really nice people that hang out here. Thanks again, Elmar. hank at efes.iucc.ac.il (Hank Nussbacher) wrote: > On 27/05/2018 17:32, Theo Voss wrote: > > There are basically two colo sites available in the Tel Aviv area: > > Med-1 - https://www.medone.co.il/en/ > Bezeqint - > https://www.bezeqint.net/english/carrier-wholesale-services/data-center-and-dr/jaffa-data-center > > The first is run by a company that doesn't provide any sort of transit - > just data center.  > The second is run by a company that can also sell you transit. > > There are only 4 companies in Israel that can provide carrier services: > Bezeqint > HOT - http://www.hot.net.il/heb/English/ > Partner - No English site > Cellcom - No English site > > At Med-1 you can buy transit from any of the 4 listed above.  > At the Bezeqint site they only allow Bezeqint circuits so you are > limited to only one carrier. > > If you need contacts at any of the companies, drop me an email and I'll > send you email contacts at each of the companies. > > -Hank From tom at ninjabadger.net Wed Jun 6 11:04:55 2018 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 06 Jun 2018 12:04:55 +0100 Subject: 3rd party QSFP-100G-LR4-S for Cisco In-Reply-To: References: Message-ID: <4f941a53edecff423b241506b71d53d9@ninjabadger.net> On 2018-05-29 13:48, Ryugo Kikuchi wrote: > Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" > for > Cisco ASR and Nexus? > > Cisco's original 100G SFP costs us an arm and a leg, so we want to try > to > use 3rd party 100g SFP. > But we are not sure which manufacturer's SFP is reliable or has good > performance. FlexOptix (.net) are an excellent third-party provider for your first foray into non-vendor optics. Tom From mike.meredith at port.ac.uk Wed Jun 6 12:01:13 2018 From: mike.meredith at port.ac.uk (Mike Meredith) Date: Wed, 6 Jun 2018 13:01:13 +0100 Subject: ICANN GDPR lawsuit In-Reply-To: <980518d4-22cb-6cec-11dc-8407445b1127@efes.iucc.ac.il> References: <20180531031609.81E8D277440B@ary.qy> <980518d4-22cb-6cec-11dc-8407445b1127@efes.iucc.ac.il> Message-ID: <20180606130113.48b240ac@scrofula.eps.is.port.ac.uk> On Wed, 6 Jun 2018 08:01:35 +0300, Hank Nussbacher may have written: > "The European Commission has insisted it is *not subject to the strict > new data protection law* that it has imposed across Europe after it was > revealed the personal information of hundreds of people had been leaked > on its website. " Neglecting where it goes on to say "it would be subject to a new law that “mirrors” GDPR which will come into effect in the autumn.". -- Mike Meredith, University of Portsmouth Hostmaster, Security, and Chief Systems Engineer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From khomyakov.andrey at gmail.com Wed Jun 6 14:30:10 2018 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Wed, 6 Jun 2018 16:30:10 +0200 Subject: 3rd party QSFP-100G-LR4-S for Cisco In-Reply-To: <4f941a53edecff423b241506b71d53d9@ninjabadger.net> References: <4f941a53edecff423b241506b71d53d9@ninjabadger.net> Message-ID: We've been quite happy with https://www.osihardware.com The customer service is outstanding. --Andrey On Wed, Jun 6, 2018 at 1:04 PM, Tom Hill wrote: > On 2018-05-29 13:48, Ryugo Kikuchi wrote: > >> Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" for >> Cisco ASR and Nexus? >> >> Cisco's original 100G SFP costs us an arm and a leg, so we want to try to >> use 3rd party 100g SFP. >> But we are not sure which manufacturer's SFP is reliable or has good >> performance. >> > > > FlexOptix (.net) are an excellent third-party provider for your first > foray into non-vendor optics. > > Tom > From Brian at ampr.org Wed Jun 6 15:25:32 2018 From: Brian at ampr.org (Brian Kantor) Date: Wed, 6 Jun 2018 08:25:32 -0700 Subject: NTIA: Should the IANA Stewardship Transition be "unwound?" Message-ID: <20180606152532.GA86195@meow.BKantor.net> The US NTIA (National Telecommunications and Information Administration) has published an inquiry as to whether its transfer of stewardship of IANA to ICANN in 2016 should be "unwound." They are requesting comments from interested parties to be sent to them by early July. Quoting _The Register_: "The US government has formally asked whether it should reassert its control of the internet's administrative functions, effectively reversing a handover to non-profit organization ICANN two years ago." http://www.theregister.co.uk/2018/06/05/us_government_icann_iana/ and https://regmedia.co.uk/2018/06/05/ntia-internet-policy-noi-jun18.pdf - Brian From C-Mack.McBride at charter.com Wed Jun 6 15:34:11 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Wed, 6 Jun 2018 15:34:11 +0000 Subject: Intel DPDK vs Broadcom/Mellanox SDK In-Reply-To: References: Message-ID: The Broadcom chips have some quirks that the Broadcom SDK handles and the DPDK does not. Specifically related around port hang up after port flaps. I am certain each chipset has quirks that are best handled by their SDK. The vendor specific SDK is always going to work better with a their specific chipset. That is just a given based on the vendor understanding their own chipset better. But again for software switching other factors apply. Mack From: Kasper Adel [mailto:karim.adel at gmail.com] Sent: Tuesday, June 05, 2018 7:31 PM To: McBride, Mack Cc: NANOG list Subject: Re: Intel DPDK vs Broadcom/Mellanox SDK Can you please provide examples on issues that you highlighted with broadcom? Are you saying i may not see the same with mellanox? Thanks On Monday, June 4, 2018, McBride, Mack > wrote: Use the package that corresponds to the chipset in your equipment. Ie. Broadcom/Mellanox chips use that SDK. Intel chips use DPDK. With white box switches using Broadcom chips you will run into issues If you don't use the Broadcom SDK. Obviously your mileage will vary based on the actual application. If it isn't a hardware switch and is CPU based like a home router, then there are a lot more factors and the CPU factors may outweigh the chipset factors. You may want to look at a list related to home routers for more guidance. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kasper Adel Sent: Sunday, June 03, 2018 11:45 PM To: NANOG list > Subject: Intel DPDK vs Broadcom/Mellanox SDK Hi Anothe email thread to get some guidance on points to consider when comparing new platforms that advocate using DPDK as the hardware acceleration SDK vs the broadcom/mellanox. The DPDK ones claim enhanced performance but every time i ask questions, i get the logical and typical answer of “it depends” Thx Kim E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From lobna_gouda at hotmail.com Wed Jun 6 15:56:00 2018 From: lobna_gouda at hotmail.com (lobna gouda) Date: Wed, 6 Jun 2018 15:56:00 +0000 Subject: Intel DPDK vs Broadcom/Mellanox SDK In-Reply-To: References: , Message-ID: I might be running into this late. Yet we had a team that did performance tests for some of their virtualization services and ended up replacing intel cards with Mellanox. Not sure about the details of the testd though Brgds, LG ________________________________ From: NANOG on behalf of McBride, Mack Sent: Wednesday, June 6, 2018 11:34 AM To: Kasper Adel Cc: NANOG list Subject: RE: Intel DPDK vs Broadcom/Mellanox SDK The Broadcom chips have some quirks that the Broadcom SDK handles and the DPDK does not. Specifically related around port hang up after port flaps. I am certain each chipset has quirks that are best handled by their SDK. The vendor specific SDK is always going to work better with a their specific chipset. That is just a given based on the vendor understanding their own chipset better. But again for software switching other factors apply. Mack From: Kasper Adel [mailto:karim.adel at gmail.com] Sent: Tuesday, June 05, 2018 7:31 PM To: McBride, Mack Cc: NANOG list Subject: Re: Intel DPDK vs Broadcom/Mellanox SDK Can you please provide examples on issues that you highlighted with broadcom? Are you saying i may not see the same with mellanox? Thanks On Monday, June 4, 2018, McBride, Mack > wrote: Use the package that corresponds to the chipset in your equipment. Ie. Broadcom/Mellanox chips use that SDK. Intel chips use DPDK. With white box switches using Broadcom chips you will run into issues If you don't use the Broadcom SDK. Obviously your mileage will vary based on the actual application. If it isn't a hardware switch and is CPU based like a home router, then there are a lot more factors and the CPU factors may outweigh the chipset factors. You may want to look at a list related to home routers for more guidance. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kasper Adel Sent: Sunday, June 03, 2018 11:45 PM To: NANOG list > Subject: Intel DPDK vs Broadcom/Mellanox SDK Hi Anothe email thread to get some guidance on points to consider when comparing new platforms that advocate using DPDK as the hardware acceleration SDK vs the broadcom/mellanox. The DPDK ones claim enhanced performance but every time i ask questions, i get the logical and typical answer of “it depends” Thx Kim E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From bill at herrin.us Wed Jun 6 16:00:54 2018 From: bill at herrin.us (William Herrin) Date: Wed, 6 Jun 2018 12:00:54 -0400 Subject: NTIA: Should the IANA Stewardship Transition be "unwound?" In-Reply-To: <20180606152532.GA86195@meow.BKantor.net> References: <20180606152532.GA86195@meow.BKantor.net> Message-ID: On Wed, Jun 6, 2018 at 11:25 AM, Brian Kantor wrote: > The US NTIA (National Telecommunications and Information Administration) > has published an inquiry as to whether its transfer of stewardship of > IANA to ICANN in 2016 should be "unwound." They are requesting comments > from interested parties to be sent to them by early July. > > Quoting _The Register_: > > "The US government has formally asked whether it should reassert > its control of the internet's administrative functions, effectively > reversing a handover to non-profit organization ICANN two years ago." > > http://www.theregister.co.uk/2018/06/05/us_government_icann_iana/ "should Uncle Sam regain ultimate control of IANA – the ICANN department that oversees the planet's domain-name system, IP address allocation, and network protocol number assignments?" IANA is the Internet Assigned NUMBERS Authority. AFAIK, it does not have stewardship over the domain-name system. ICANN also does domains but not the IANA part. NTIA seems confused about this too: the notice describes privatization of the DNS happening in 2016. -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From owen at delong.com Wed Jun 6 16:14:34 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Jun 2018 09:14:34 -0700 Subject: NTIA: Should the IANA Stewardship Transition be "unwound?" In-Reply-To: <20180606152532.GA86195@meow.BKantor.net> References: <20180606152532.GA86195@meow.BKantor.net> Message-ID: <69A2631E-7AAE-405A-90D4-6202042BACF5@delong.com> OK, so looking at the actual notice in the Federal Register (Volume 83, Number 108, Tuesday, June 5, 2018), the notice is quite lengthy and covers a wide ranging set of topics. The question about unwinding the stewardship transition is a single list item in a rather large list of items which list is only subsection II of a 4-section series of areas of inquiry: II. Multistakeholder Approach to Internet Governance A. Does the multistakeholder approach continue to support an environment for the internet to grow and thrive? If so, why? If not, why not? B. Are there public policy areas in which the multistakeholder approach works best? If yes, what are those areas and why? Are there areas in which the multistakeholder approach does not work effectively? If there are, what are those areas and why? C. Are the existing accountability structures within multistakeholder internet governance sufficient? If not, why not? What improvements can be made? D. Should the IANA Stewardship Transition be unwound? If yes, why and how? If not, why not? E. What should be NTIA’s priorities within ICANN and the GAC? F. Are there any other DNS related activities NTIA should pursue? If yes, please describe. G. Are there barriers to engagement at the IGF? If so, how can we lower these barriers? H. Are there improvements that can be made to the IGF’s structure, organization, planning processes, or intercessional work programs? If so, what are they? I. What, if any, action can NTIA take to help raise awareness about the IGF and foster stakeholder engagement? J. What role should multilateral organizations play in internet governance? The ones I find most amusing are G, H, and I, which apparently presume that the IGF is a somehow meaningful construct with credibility or ability to accomplish anything at all. Owen > On Jun 6, 2018, at 08:25 , Brian Kantor wrote: > > The US NTIA (National Telecommunications and Information Administration) > has published an inquiry as to whether its transfer of stewardship of > IANA to ICANN in 2016 should be "unwound." They are requesting comments > from interested parties to be sent to them by early July. > > Quoting _The Register_: > > "The US government has formally asked whether it should reassert > its control of the internet's administrative functions, effectively > reversing a handover to non-profit organization ICANN two years ago." > > http://www.theregister.co.uk/2018/06/05/us_government_icann_iana/ > > and > > https://regmedia.co.uk/2018/06/05/ntia-internet-policy-noi-jun18.pdf > > - Brian From shawnritchie at gmail.com Wed Jun 6 16:57:48 2018 From: shawnritchie at gmail.com (Shawn Ritchie) Date: Wed, 6 Jun 2018 11:57:48 -0500 Subject: 3rd party QSFP-100G-LR4-S for Cisco In-Reply-To: References: <4f941a53edecff423b241506b71d53d9@ninjabadger.net> Message-ID: I can second OSI, been using them for years for Juni and Cisco-compatible optics and they've been absolutely fine. On Wed, Jun 6, 2018 at 9:31 AM Andrey Khomyakov wrote: > We've been quite happy with https://www.osihardware.com > The customer service is outstanding. > > > --Andrey > > On Wed, Jun 6, 2018 at 1:04 PM, Tom Hill wrote: > > > On 2018-05-29 13:48, Ryugo Kikuchi wrote: > > > >> Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" > for > >> Cisco ASR and Nexus? > >> > >> Cisco's original 100G SFP costs us an arm and a leg, so we want to try > to > >> use 3rd party 100g SFP. > >> But we are not sure which manufacturer's SFP is reliable or has good > >> performance. > >> > > > > > > FlexOptix (.net) are an excellent third-party provider for your first > > foray into non-vendor optics. > > > > Tom > > > -- Shawn From anthony at fms.io Tue Jun 5 21:05:58 2018 From: anthony at fms.io (Anthony Leto) Date: Tue, 5 Jun 2018 21:05:58 +0000 Subject: Satelite Internet Provider In-Reply-To: References: Message-ID: <53022ddf-8064-481b-b6c0-9e6eba1fdefa@email.android.com> I know a while ago MTN had spot beams out that way. I don't know if they are still around these days or if they are still covering there. On Jun 5, 2018 19:39, "Ing. Edwin Salazar via NANOG" wrote: Hi, I would like to know if anyone knows any satellite internet provider for the Galapagos Islands in Ecuador that I can contact? Best regards, Edwin Salazar. From phil.lavin at cloudcall.com Tue Jun 5 21:40:00 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Tue, 5 Jun 2018 21:40:00 +0000 Subject: 3rd party QSFP-100G-LR4-S for Cisco In-Reply-To: References: , Message-ID: <90C0F7F2-0B3B-4BAD-8026-C3B42212A7EA@cloudcall.com> I concur. Never bought Cisco 100G from them but the quality of the Juniper optics and other ancillary fibre stuff is great. > On 5 Jun 2018, at 20:58, Mitcheltree, Harold B wrote: > > FS.COM > > > --Pete > > ________________________________ > From: NANOG on behalf of Ryugo Kikuchi > Sent: Tuesday, May 29, 2018 7:48:16 AM > To: nanog at nanog.org > Subject: 3rd party QSFP-100G-LR4-S for Cisco > > Hey all, > > Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" for > Cisco ASR and Nexus? > > Cisco's original 100G SFP costs us an arm and a leg, so we want to try to > use 3rd party 100g SFP. > But we are not sure which manufacturer's SFP is reliable or has good > performance. > > Does anyone have experience? > > Many thanks, > > Roy From michel.py at tsisemi.com Wed Jun 6 17:11:39 2018 From: michel.py at tsisemi.com (Michel Py) Date: Wed, 6 Jun 2018 17:11:39 +0000 Subject: 3rd party QSFP-100G-LR4-S for Cisco In-Reply-To: <4f941a53edecff423b241506b71d53d9@ninjabadger.net> References: <4f941a53edecff423b241506b71d53d9@ninjabadger.net> Message-ID: <2766d68995d140c5a5509150b852eb96@CRA110.am.necel.com> > Ryugo Kikuchi wrote: > Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" for Cisco ASR and Nexus? > Cisco's original 100G SFP costs us an arm and a leg, so we want to try to use 3rd party 100g SFP. > But we are not sure which manufacturer's SFP is reliable or has good performance. Try this one. I never ordered that particular model, but they are my prefered vendor for optics and cables. Happy with the company. https://www.fs.com/products/48355.html Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From ross at tajvar.io Wed Jun 6 03:29:19 2018 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 5 Jun 2018 23:29:19 -0400 Subject: VPP-based router vs Hardware assisted ones In-Reply-To: References: Message-ID: I haven't necessarily decided to take this direction, I just want to know what the state of the platform is. I have not reviewed cumulus or pica8, though I have heard of cumulus. Yes, in some cases I would like to take a full table. On Tue, Jun 5, 2018 at 9:26 PM, Kasper Adel wrote: > Hi Ross > > Did you make a decision to take that direction after reviewing ‘open > networking’ platforms like cumulus and pica8? > > Are you trying to use the full routing table? > > ~kim > > On Thursday, May 24, 2018, Ross Tajvar wrote: > >> Hi all, >> >> Has anyone had any luck building their own routers on common compute (x86) >> with VPP? I'm considering it as I'm looking for a cheap, fast peering >> router. I haven't seen much written about that type of solution so I was >> wondering if anyone here has experience to share. >> >> Thanks, >> Ross >> > From eric at lumaoptics.net Thu Jun 7 02:56:36 2018 From: eric at lumaoptics.net (Eric Litvin) Date: Wed, 6 Jun 2018 19:56:36 -0700 Subject: 3rd party QSFP-100G-LR4-S for Cisco In-Reply-To: References: Message-ID: <7D816844-545C-4F77-ADAF-3DFC106B4383@lumaoptics.net> Hi Ryugo, I’m Eric Litvin, CEO of Luma Optics. We sell 1000s of 100G LR4. Our price is $800.00 ( yes it’s true $800.00 for 100G-LR4). We can do this because we buy 1000s of LR4 at a time and do big volumes. Ours are open eeprom and we provide a device for free that enables you to flash the firmware and turn up the part in any network environment. I’ve been a Nanog member for a long time and have many member references if you’d like to consider us. Cheers, Eric Litvin Sent from my iPhone > On May 29, 2018, at 5:48 AM, Ryugo Kikuchi wrote: > > Hey all, > > Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" for > Cisco ASR and Nexus? > > Cisco's original 100G SFP costs us an arm and a leg, so we want to try to > use 3rd party 100g SFP. > But we are not sure which manufacturer's SFP is reliable or has good > performance. > > Does anyone have experience? > > Many thanks, > > Roy From michaelolusegunrufai at gmail.com Thu Jun 7 08:57:26 2018 From: michaelolusegunrufai at gmail.com (segs) Date: Thu, 7 Jun 2018 09:57:26 +0100 Subject: Application or Software to detect or Block unmanaged swicthes Message-ID: Hello All, Please I have a very interesting scenario that I am on the lookout for a solution for, We have instances where the network team of my company bypass controls and processes when adding new switches to the network. The right parameters that are required to be configured on the switches inorder for the NAC solution deployed to have full visibility into end points that connects to such switches are not usually configured. This poses a problem for the security team as they dont have visibility into such devices that connect to such switches on the NAC solution, the network guys usually connect the new switches to the trunk port and they have access to all VLANs. Is there a solution that can detect new or unmanaged switches on the network, and block such devices or if there is a solution that block users that connect to unmanaged switches on the network even if those users have domain PCs. Anticipating your speedy response. Thank You! From nick at foobar.org Thu Jun 7 09:01:24 2018 From: nick at foobar.org (Nick Hilliard) Date: Thu, 7 Jun 2018 10:01:24 +0100 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: References: Message-ID: <91f326ba-183d-4146-4740-484ab2b696d3@foobar.org> segs wrote on 07/06/2018 09:57: > Is there a solution that can detect new or unmanaged switches on the > network, and block such devices or if there is a solution that block users > that connect to unmanaged switches on the network even if those users have > domain PCs. this is really an enterprise question, but 802.1x should do the trick, or static MAC ACLs on your network edge ports. Nick From mark.tinka at seacom.mu Thu Jun 7 10:07:58 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 7 Jun 2018 12:07:58 +0200 Subject: Subsea availability In-Reply-To: References: <20180522182848.6292a82f@riri.DEF.witbe.net> Message-ID: On 5/Jun/18 21:03, Mehmet Akcin wrote: > I have reached out to several subsea cable operators asking > them to help provide data but so far let's say, I am not as luck as I > thought I would be. Cable system operators are typically not keen to share this kind of information, for any reason, as I'm sure you're finding out :-)... Mark. From mysidia at gmail.com Thu Jun 7 10:27:00 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 7 Jun 2018 05:27:00 -0500 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: References: Message-ID: On Thu, Jun 7, 2018 at 3:57 AM, segs wrote: [snip] > Please I have a very interesting scenario that I am on the lookout for a > solution for, We have instances where the network team of my company bypass > controls and processes when adding new switches to the network. The NETWORK management team of your own company? The answer is adequate change controls, policy, procedures, technical auditing (Such as logging of all CLI commands), and mandatory training with clearly-communicated in advance severe consequences for violators of the compulsory security policy that all switches must be of X type and configured according to Y process before being connected to the network, signed off by management. There are technical controls that can be implemented to help prevent/ mitigate end users from attaching an unauthorized switch to a normal access port, But as you mention... clearly an employee on the NETWORKING team can likely just configure a port as Trunk and circumvent any technical protections. Two methods that could effectively prevent End Users (not Network/IT team) from connecting unmanaged switches would be: * Port-security feature common on many managed switches that allow you to limit the number of MAC Addresses that can use a port to 1 or given number of MAC addresses. (Use a short MAC address aging time such as 30 seconds to allow people to unplug and plug a different device in, but a low MAC address account and Err-Disable violation to kill the port if a Switch is connected) * 802.1x Wired Port Security - More detailed system that requires a PKI + RADIUS server infrastructure and authentication by every client to every port. -- -JH From matt at conundrum.com Thu Jun 7 11:36:16 2018 From: matt at conundrum.com (Matthew Pounsett) Date: Thu, 7 Jun 2018 07:36:16 -0400 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: References: Message-ID: On 7 June 2018 at 04:57, segs wrote: > Hello All, > > Please I have a very interesting scenario that I am on the lookout for a > solution for, We have instances where the network team of my company bypass > controls and processes when adding new switches to the network. > > To put a finer point on things others have already said: If you have employees with enable on your networking gear not following policies and procedures, that is a management problem, not a technical one. There's nothing you can do to prevent someone who admin's a network device from changing its configuration. The various ways the company can handle this is by training, clearly defined *and communicated* policies, and eventually by discipline if necessary. If the company is unwilling or unable to enforce reasonable policy on its employees then my recommendation would be to find a new company. From jhellenthal at dataix.net Thu Jun 7 11:54:12 2018 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Thu, 7 Jun 2018 06:54:12 -0500 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: References: Message-ID: As someone already stated the obvious answers, the slightly more difficult route to be getting a count of allowed devices and MAC addresses, then moving forward with something like ansible to poll the count of MAC’s on any given port ... of number higher than what’s allowed, suspend the port and send a notification to the appropriate parties. All in all though sounds like a really brash thing to do to your network team and will generally know and have a very good reason for doing so... but not all situations are created equally so good luck. -- The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jun 7, 2018, at 03:57, segs wrote: > > Hello All, > > Please I have a very interesting scenario that I am on the lookout for a > solution for, We have instances where the network team of my company bypass > controls and processes when adding new switches to the network. > > The right parameters that are required to be configured on the switches > inorder for the NAC solution deployed to have full visibility into end > points that connects to such switches are not usually configured. > > This poses a problem for the security team as they dont have visibility > into such devices that connect to such switches on the NAC solution, the > network guys usually connect the new switches to the trunk port and they > have access to all VLANs. > > Is there a solution that can detect new or unmanaged switches on the > network, and block such devices or if there is a solution that block users > that connect to unmanaged switches on the network even if those users have > domain PCs. > > Anticipating your speedy response. > > Thank You! From mel at beckman.org Thu Jun 7 14:16:25 2018 From: mel at beckman.org (Mel Beckman) Date: Thu, 7 Jun 2018 14:16:25 +0000 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: References: , Message-ID: <668BA2A6-EE2F-4F25-9A2F-B3B6DBFCA1C4@beckman.org> When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, which has a Layer-2 collection feature that identifies the number and MACs of devices on any given switch port. We export this list and cull out all the known managed switch links. Anything remaining that has more than one MAC per port is a potential violation that we can readily inspect. It’s not perfect, because an unmanaged switch might only have one device connected, in which case it wont be detected. You can also get false positives from hosts running virtualization, if the v-kernel generates synthetic MAC addresses. But it’s amazing how many times we find unmanaged switches squirreled away under desks or in ceilings. -mel > On Jun 7, 2018, at 4:54 AM, Jason Hellenthal wrote: > > As someone already stated the obvious answers, the slightly more difficult route to be getting a count of allowed devices and MAC addresses, then moving forward with something like ansible to poll the count of MAC’s on any given port ... of number higher than what’s allowed, suspend the port and send a notification to the appropriate parties. > > > All in all though sounds like a really brash thing to do to your network team and will generally know and have a very good reason for doing so... but not all situations are created equally so good luck. > > > -- > > The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > >> On Jun 7, 2018, at 03:57, segs wrote: >> >> Hello All, >> >> Please I have a very interesting scenario that I am on the lookout for a >> solution for, We have instances where the network team of my company bypass >> controls and processes when adding new switches to the network. >> >> The right parameters that are required to be configured on the switches >> inorder for the NAC solution deployed to have full visibility into end >> points that connects to such switches are not usually configured. >> >> This poses a problem for the security team as they dont have visibility >> into such devices that connect to such switches on the NAC solution, the >> network guys usually connect the new switches to the trunk port and they >> have access to all VLANs. >> >> Is there a solution that can detect new or unmanaged switches on the >> network, and block such devices or if there is a solution that block users >> that connect to unmanaged switches on the network even if those users have >> domain PCs. >> >> Anticipating your speedy response. >> >> Thank You! From 4500811 at gmail.com Thu Jun 7 00:21:45 2018 From: 4500811 at gmail.com (Alex S.) Date: Wed, 6 Jun 2018 20:21:45 -0400 Subject: 3rd party QSFP-100G-LR4-S for Cisco In-Reply-To: References: Message-ID: Axiom Used variety of their sfps, twinax cables etc. Been rock solid On Tue, Jun 5, 2018 at 14:42 Ryugo Kikuchi wrote: > Hey all, > > Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" for > Cisco ASR and Nexus? > > Cisco's original 100G SFP costs us an arm and a leg, so we want to try to > use 3rd party 100g SFP. > But we are not sure which manufacturer's SFP is reliable or has good > performance. > > Does anyone have experience? > > Many thanks, > > Roy > From eric at ipergy.net Thu Jun 7 06:16:04 2018 From: eric at ipergy.net (Eric Loos) Date: Thu, 7 Jun 2018 08:16:04 +0200 Subject: VPOP/Equipment rental contacts for any DC of IX.br / PTT.br Fortaleza Message-ID: <62AD7494-66AC-445E-ACE2-3961522E14DC@ipergy.net> Hi Everyone, Does anyone know whom could help me get a conversion done from STM-1 to Ethernet at any DC which has a IX.br presence in Fortaleza? Please contact me off-list, thanks! (yes I already tried ix.br contacts, no joy) Kind regards, Eric Loos From itayf at io-sat.com Thu Jun 7 05:35:49 2018 From: itayf at io-sat.com (Itay Fisher) Date: Thu, 7 Jun 2018 05:35:49 +0000 Subject: FW: Satelite Internet Provider In-Reply-To: References: , Message-ID: Dear Edwin, IO-SAT is a Vsat internet provider for both fixed and maritime purposes. Please share with us what exactly do you need and the estimate capacity you are looking for. Regards , Itay Fisher [Description: 250x100] www.io-sat.com +972 537755134 Phone.: +972 772201298 email: itayf at io-sat.com iosat Support: Telephone: +972-3-9784270 Internal Extension: 550003 Emergency Tel: +44-19-23381108 Email: support at io-sat.com ---------- Forwarded message ---------- From: Ing. Edwin Salazar via NANOG > Date: Mon, May 28, 2018 at 12:28 PM Subject: Satelite Internet Provider To: nanog at nanog.org Hi, I would like to know if anyone knows any satellite internet provider for the Galapagos Islands in Ecuador that I can contact? Best regards, Edwin Salazar. From keith at contoocook.net Thu Jun 7 12:29:22 2018 From: keith at contoocook.net (keith at contoocook.net) Date: Thu, 7 Jun 2018 08:29:22 -0400 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: References: Message-ID: <1412a21a-0965-451c-8670-2dd0d93d58b4.maildroid@localhost> In my previous life, we used a nac appliance from Bradford Networks whereby the mac address of every device needed to be registered or the switch port it was plugged into would be disabled. This kept spurious devices from appearing on the network and worked quite well. Cheers, Keith Sent from my android device. -----Original Message----- From: Jason Hellenthal To: segs Cc: nanog at nanog.org Sent: Thu, 07 Jun 2018 7:54 Subject: Re: Application or Software to detect or Block unmanaged swicthes As someone already stated the obvious answers, the slightly more difficult route to be getting a count of allowed devices and MAC addresses, then moving forward with something like ansible to poll the count of MAC’s on any given port ... of number higher than what’s allowed, suspend the port and send a notification to the appropriate parties. All in all though sounds like a really brash thing to do to your network team and will generally know and have a very good reason for doing so... but not all situations are created equally so good luck. -- The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jun 7, 2018, at 03:57, segs wrote: > > Hello All, > > Please I have a very interesting scenario that I am on the lookout for a > solution for, We have instances where the network team of my company bypass > controls and processes when adding new switches to the network. > > The right parameters that are required to be configured on the switches > inorder for the NAC solution deployed to have full visibility into end > points that connects to such switches are not usually configured. > > This poses a problem for the security team as they dont have visibility > into such devices that connect to such switches on the NAC solution, the > network guys usually connect the new switches to the trunk port and they > have access to all VLANs. > > Is there a solution that can detect new or unmanaged switches on the > network, and block such devices or if there is a solution that block users > that connect to unmanaged switches on the network even if those users have > domain PCs. > > Anticipating your speedy response. > > Thank You! From harbor235 at gmail.com Thu Jun 7 15:31:15 2018 From: harbor235 at gmail.com (harbor235) Date: Thu, 7 Jun 2018 11:31:15 -0400 Subject: broken DNS Message-ID: I was hoping for some DNS wisdom, would a change in a SOA record cause a DNSSEC broken trust chain? incorrect RRSIG? Mike From maxtul at netassist.ua Thu Jun 7 15:45:44 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 7 Jun 2018 18:45:44 +0300 Subject: FW: Satelite Internet Provider In-Reply-To: References: Message-ID: <09ceb06d-f230-59a3-5c02-a48c50ca6670@netassist.ua> Uses Yamal 402 Russian (spy)service ;) 07.06.18 08:35, Itay Fisher пише: > Dear Edwin, > > IO-SAT is a Vsat internet provider for both fixed and maritime purposes. > Please share with us what exactly do you need and the estimate capacity you are looking for. > > > Regards , > Itay Fisher > [Description: 250x100] > www.io-sat.com > > +972 537755134 > Phone.: +972 772201298 > email: itayf at io-sat.com > > > > iosat Support: > Telephone: +972-3-9784270 > Internal Extension: 550003 > Emergency Tel: +44-19-23381108 > Email: support at io-sat.com > > > > > > > > > ---------- Forwarded message ---------- > From: Ing. Edwin Salazar via NANOG > > Date: Mon, May 28, 2018 at 12:28 PM > Subject: Satelite Internet Provider > To: nanog at nanog.org > > > Hi, > > I would like to know if anyone knows any satellite internet provider for the Galapagos Islands in Ecuador that I can contact? > > Best regards, > Edwin Salazar. > > From bortzmeyer at nic.fr Thu Jun 7 15:46:09 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 7 Jun 2018 17:46:09 +0200 Subject: broken DNS In-Reply-To: References: Message-ID: <20180607154608.v52ae4rwqt3wpu3g@nic.fr> On Thu, Jun 07, 2018 at 11:31:15AM -0400, harbor235 wrote a message of 5 lines which said: > I was hoping for some DNS wisdom, Then this is more a dns-operations mailing list issue. > would a change in a SOA record cause a > DNSSEC broken trust chain? incorrect RRSIG? No. The SOA record is not part of the trust chain (unless of course it is the record you query). From rubensk at gmail.com Thu Jun 7 16:14:30 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 7 Jun 2018 13:14:30 -0300 Subject: VPOP/Equipment rental contacts for any DC of IX.br / PTT.br Fortaleza In-Reply-To: <62AD7494-66AC-445E-ACE2-3961522E14DC@ipergy.net> References: <62AD7494-66AC-445E-ACE2-3961522E14DC@ipergy.net> Message-ID: If you think the DC itself will be able to help, the contacts for DCs in IX.br @ Fortaleza are: http://ix.br/adesao/ce Of the listed DCs, Eletronet is the more likely to have STM-1 gear, since they used STM-n in their fiber ring for a long time. Globenet connection to IX.br is still under construction, so they are not listed above; US at globenet.net is their US office e-mail address. I'll send privately the contact of a local Fortaleza network consultant. Rubens On Thu, Jun 7, 2018 at 11:57 AM Eric Loos wrote: > Hi Everyone, > > Does anyone know whom could help me get a conversion done from STM-1 to > Ethernet at any DC which has a IX.br presence in > Fortaleza? > > Please contact me off-list, thanks! > > (yes I already tried ix.br contacts, no joy) > > Kind regards, > > Eric Loos From edwin.salazar at wifitelecom.ec Thu Jun 7 16:14:34 2018 From: edwin.salazar at wifitelecom.ec (Ing. Edwin Salazar) Date: Thu, 7 Jun 2018 10:14:34 -0600 Subject: Satelite Internet Provider In-Reply-To: <09ceb06d-f230-59a3-5c02-a48c50ca6670@netassist.ua> References: <09ceb06d-f230-59a3-5c02-a48c50ca6670@netassist.ua> Message-ID: <7A740D0A-18A0-4503-A768-B25C76630D30@wifitelecom.ec> Dear Itay, We need 35M capacity in one of the Galapagos Islands in Ecuador Saludos cordiales, Edwin Salazar. Cel: +593 993-080208 edwin.salazar at wifitelecom.ec > On Jun 7, 2018, at 09:45, Max Tulyev wrote: > > Uses Yamal 402 Russian (spy)service ;) > > 07.06.18 08:35, Itay Fisher пише: >> Dear Edwin, >> >> IO-SAT is a Vsat internet provider for both fixed and maritime purposes. >> Please share with us what exactly do you need and the estimate capacity you are looking for. >> >> >> Regards , >> Itay Fisher >> [Description: 250x100] >> www.io-sat.com >> >> +972 537755134 >> Phone.: +972 772201298 >> email: itayf at io-sat.com >> >> >> >> iosat Support: >> Telephone: +972-3-9784270 >> Internal Extension: 550003 >> Emergency Tel: +44-19-23381108 >> Email: support at io-sat.com >> >> >> >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: Ing. Edwin Salazar via NANOG > >> Date: Mon, May 28, 2018 at 12:28 PM >> Subject: Satelite Internet Provider >> To: nanog at nanog.org >> >> >> Hi, >> >> I would like to know if anyone knows any satellite internet provider for the Galapagos Islands in Ecuador that I can contact? >> >> Best regards, >> Edwin Salazar. >> >> From kshymkiw at gmail.com Thu Jun 7 16:26:57 2018 From: kshymkiw at gmail.com (Kevin Shymkiw) Date: Thu, 7 Jun 2018 08:26:57 -0800 Subject: Satelite Internet Provider In-Reply-To: References: Message-ID: Edwin, You could try Isotropic - https://isosat.net/ We have used them in several remote locations and have had great luck with them. Kevin On Mon, May 28, 2018 at 8:28 AM, Ing. Edwin Salazar via NANOG < nanog at nanog.org> wrote: > Hi, > > I would like to know if anyone knows any satellite internet provider for > the Galapagos Islands in Ecuador that I can contact? > > Best regards, > Edwin Salazar. From spoofer-info at caida.org Fri Jun 8 17:00:02 2018 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Fri, 8 Jun 2018 10:00:02 -0700 Subject: Spoofer Report for NANOG for May 2018 Message-ID: <201806081700.w58H02tw083994@fro.caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during May 2018: ASN Name Fixed-By 11232 MIDCO-NET 2018-05-14 11796 AIRSTREAMCOMM-NET 2018-05-22 577 BACOM 2018-05-25 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during May 2018: ASN Name First-Spoofed Last-Spoofed 3356 LEVEL3 2016-03-06 2018-05-15 577 BACOM 2016-03-09 2018-05-17 7922 COMCAST-7922 2016-06-04 2018-05-14 7029 WINDSTREAM 2016-06-21 2018-05-09 2828 XO-AS15 2016-07-27 2018-05-30 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-05-31 6128 CABLE-NET-1 2016-09-03 2018-05-26 20412 CLARITY-TELECOM 2016-09-30 2018-05-30 20001 ROADRUNNER-WEST 2016-10-08 2018-05-09 6181 FUSE-NET 2016-10-10 2018-05-31 15305 SYRINGANETWORKS 2016-10-21 2018-05-16 25787 ROWE-NETWORKS 2016-10-21 2018-05-28 11427 SCRR-11427 2016-10-21 2018-05-19 174 COGENT-174 2016-10-21 2018-05-29 271 BCNET 2016-10-24 2018-05-30 20082 ABSNOC1 2016-10-27 2018-05-02 32440 LONI 2016-11-03 2018-05-31 33182 DimeNOC 2016-11-08 2018-05-30 12083 WOW-INTERNET 2016-11-09 2018-05-31 5056 AUREON-5056 2016-11-10 2018-05-30 1403 EBOX 2016-11-12 2018-05-26 20105 URICHMOND 2016-11-15 2018-05-29 54858 AS-SBI 2016-12-25 2018-05-23 2152 CSUNET-NW 2017-02-02 2018-05-31 21832 KELLINCOM-1 2017-02-03 2018-05-30 18451 LESNET 2017-02-22 2018-05-03 7122 MTS-ASN 2017-05-16 2018-05-19 6461 ZAYO-6461 2017-06-21 2018-05-16 26253 SCINTERNET 2017-06-30 2018-05-31 26793 ICS-LLC 2017-08-16 2018-05-03 63296 AMARILLO-WIRELESS 2017-09-01 2018-05-30 7233 YAHOO-US 2017-09-07 2018-05-31 33523 ROWANUNIVERSITY 2017-10-29 2018-05-12 546 PARSONS-PGS-1 2017-11-20 2018-05-07 54540 INCERO 2018-01-15 2018-05-30 12222 AKAMAI 2018-02-14 2018-05-28 55236 CBC 2018-03-03 2018-05-24 3257 GTT-BACKBONE 2018-03-06 2018-05-28 29384 Qatar-Foundation 2018-03-08 2018-05-28 23148 TERRENAP 2018-03-15 2018-05-30 226 LOS-NETTOS 2018-03-26 2018-05-29 15176 AS-INOC 2018-04-09 2018-05-16 20009 WADSNET 2018-04-13 2018-05-30 4201 ORST 2018-04-19 2018-05-30 11827 WSU 2018-04-19 2018-05-31 31863 DACEN-2 2018-04-26 2018-05-04 15301 IOVATION 2018-05-02 2018-05-03 19016 WCG 2018-05-19 2018-05-19 122 U-PGH-NET 2018-05-19 2018-05-19 21949 BEANFIELD 2018-05-21 2018-05-21 40764 DNA-DKLB 2018-05-29 2018-05-29 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From karim.adel at gmail.com Fri Jun 8 17:21:55 2018 From: karim.adel at gmail.com (Kasper Adel) Date: Fri, 8 Jun 2018 10:21:55 -0700 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: <1412a21a-0965-451c-8670-2dd0d93d58b4.maildroid@localhost> References: <1412a21a-0965-451c-8670-2dd0d93d58b4.maildroid@localhost> Message-ID: I guess you can do that and more with a linux based switch like cumulus and pica8. They allow you to do all sorts of things like that because they are open. On Thursday, June 7, 2018, wrote: > In my previous life, we used a nac appliance from Bradford Networks > whereby the mac address of every device needed to be registered or the > switch port it was plugged into would be disabled. > This kept spurious devices from appearing on the network and worked quite > well. > Cheers, Keith > > Sent from my android device. > > -----Original Message----- > From: Jason Hellenthal > To: segs > Cc: nanog at nanog.org > Sent: Thu, 07 Jun 2018 7:54 > Subject: Re: Application or Software to detect or Block unmanaged swicthes > > As someone already stated the obvious answers, the slightly more difficult > route to be getting a count of allowed devices and MAC addresses, then > moving forward with something like ansible to poll the count of MAC’s on > any given port ... of number higher than what’s allowed, suspend the port > and send a notification to the appropriate parties. > > > All in all though sounds like a really brash thing to do to your network > team and will generally know and have a very good reason for doing so... > but not all situations are created equally so good luck. > > > -- > > The fact that there's a highway to Hell but only a stairway to Heaven says > a lot about anticipated traffic volume. > > > On Jun 7, 2018, at 03:57, segs wrote: > > > > Hello All, > > > > Please I have a very interesting scenario that I am on the lookout for a > > solution for, We have instances where the network team of my company > bypass > > controls and processes when adding new switches to the network. > > > > The right parameters that are required to be configured on the switches > > inorder for the NAC solution deployed to have full visibility into end > > points that connects to such switches are not usually configured. > > > > This poses a problem for the security team as they dont have visibility > > into such devices that connect to such switches on the NAC solution, the > > network guys usually connect the new switches to the trunk port and they > > have access to all VLANs. > > > > Is there a solution that can detect new or unmanaged switches on the > > network, and block such devices or if there is a solution that block > users > > that connect to unmanaged switches on the network even if those users > have > > domain PCs. > > > > Anticipating your speedy response. > > > > Thank You! > From dhubbard at dino.hostasaurus.com Fri Jun 8 17:32:09 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 8 Jun 2018 17:32:09 +0000 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: <668BA2A6-EE2F-4F25-9A2F-B3B6DBFCA1C4@beckman.org> References: <668BA2A6-EE2F-4F25-9A2F-B3B6DBFCA1C4@beckman.org> Message-ID: <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> This thread has piqued my curiosity on whether there'd be a way to detect a rogue access point, or proxy server with an inside and outside interface? Let's just say 802.1x is in place too to make it more interesting. For example, could employee X, who doesn't want their department to be back billed for more switch ports, go and get some reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth to the physical network using their credentials? They then let their staff wifi into it and the traffic is NAT'd. I'm sure anyone in a university setting has encountered this. Obviously policy can forbid, but any way to detect it other than seeing traffic patterns on a port not match historical once the other users have been combined onto it, or those other users' ports go down? David On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" wrote: When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, which has a Layer-2 collection feature that identifies the number and MACs of devices on any given switch port. We export this list and cull out all the known managed switch links. Anything remaining that has more than one MAC per port is a potential violation that we can readily inspect. It’s not perfect, because an unmanaged switch might only have one device connected, in which case it wont be detected. You can also get false positives from hosts running virtualization, if the v-kernel generates synthetic MAC addresses. But it’s amazing how many times we find unmanaged switches squirreled away under desks or in ceilings. -mel > On Jun 7, 2018, at 4:54 AM, Jason Hellenthal wrote: > > As someone already stated the obvious answers, the slightly more difficult route to be getting a count of allowed devices and MAC addresses, then moving forward with something like ansible to poll the count of MAC’s on any given port ... of number higher than what’s allowed, suspend the port and send a notification to the appropriate parties. > > > All in all though sounds like a really brash thing to do to your network team and will generally know and have a very good reason for doing so... but not all situations are created equally so good luck. > > > -- > > The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > >> On Jun 7, 2018, at 03:57, segs wrote: >> >> Hello All, >> >> Please I have a very interesting scenario that I am on the lookout for a >> solution for, We have instances where the network team of my company bypass >> controls and processes when adding new switches to the network. >> >> The right parameters that are required to be configured on the switches >> inorder for the NAC solution deployed to have full visibility into end >> points that connects to such switches are not usually configured. >> >> This poses a problem for the security team as they dont have visibility >> into such devices that connect to such switches on the NAC solution, the >> network guys usually connect the new switches to the trunk port and they >> have access to all VLANs. >> >> Is there a solution that can detect new or unmanaged switches on the >> network, and block such devices or if there is a solution that block users >> that connect to unmanaged switches on the network even if those users have >> domain PCs. >> >> Anticipating your speedy response. >> >> Thank You! From cscora at apnic.net Fri Jun 8 18:03:09 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Jun 2018 04:03:09 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180608180309.B2F5BC450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Jun, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 703944 Prefixes after maximum aggregation (per Origin AS): 270298 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 337366 Total ASes present in the Internet Routing Table: 60965 Prefixes per ASN: 11.55 Origin-only ASes present in the Internet Routing Table: 52613 Origin ASes announcing only one prefix: 22991 Transit ASes present in the Internet Routing Table: 8352 Transit-only ASes present in the Internet Routing Table: 280 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 30 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 73 Number of instances of unregistered ASNs: 73 Number of 32-bit ASNs allocated by the RIRs: 22870 Number of 32-bit ASNs visible in the Routing Table: 18455 Prefixes from 32-bit ASNs in the Routing Table: 76985 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 254 Number of addresses announced to Internet: 2858854723 Equivalent to 170 /8s, 102 /16s and 169 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 235189 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 192144 Total APNIC prefixes after maximum aggregation: 54502 APNIC Deaggregation factor: 3.53 Prefixes being announced from the APNIC address blocks: 190877 Unique aggregates announced from the APNIC address blocks: 77709 APNIC Region origin ASes present in the Internet Routing Table: 8863 APNIC Prefixes per ASN: 21.54 APNIC Region origin ASes announcing only one prefix: 2487 APNIC Region transit ASes present in the Internet Routing Table: 1340 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3835 Number of APNIC addresses announced to Internet: 767495938 Equivalent to 45 /8s, 191 /16s and 15 /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: 209136 Total ARIN prefixes after maximum aggregation: 99495 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209874 Unique aggregates announced from the ARIN address blocks: 99071 ARIN Region origin ASes present in the Internet Routing Table: 18200 ARIN Prefixes per ASN: 11.53 ARIN Region origin ASes announcing only one prefix: 6727 ARIN Region transit ASes present in the Internet Routing Table: 1812 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2360 Number of ARIN addresses announced to Internet: 1104150304 Equivalent to 65 /8s, 207 /16s and 255 /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: 192454 Total RIPE prefixes after maximum aggregation: 92303 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 188510 Unique aggregates announced from the RIPE address blocks: 111882 RIPE Region origin ASes present in the Internet Routing Table: 25225 RIPE Prefixes per ASN: 7.47 RIPE Region origin ASes announcing only one prefix: 11386 RIPE Region transit ASes present in the Internet Routing Table: 3515 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7074 Number of RIPE addresses announced to Internet: 716001408 Equivalent to 42 /8s, 173 /16s and 80 /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: 91138 Total LACNIC prefixes after maximum aggregation: 19938 LACNIC Deaggregation factor: 4.57 Prefixes being announced from the LACNIC address blocks: 92568 Unique aggregates announced from the LACNIC address blocks: 40818 LACNIC Region origin ASes present in the Internet Routing Table: 7207 LACNIC Prefixes per ASN: 12.84 LACNIC Region origin ASes announcing only one prefix: 2006 LACNIC Region transit ASes present in the Internet Routing Table: 1342 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4754 Number of LACNIC addresses announced to Internet: 172420000 Equivalent to 10 /8s, 70 /16s and 235 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 18998 Total AfriNIC prefixes after maximum aggregation: 4006 AfriNIC Deaggregation factor: 4.74 Prefixes being announced from the AfriNIC address blocks: 21861 Unique aggregates announced from the AfriNIC address blocks: 7662 AfriNIC Region origin ASes present in the Internet Routing Table: 1158 AfriNIC Prefixes per ASN: 18.88 AfriNIC Region origin ASes announcing only one prefix: 385 AfriNIC Region transit ASes present in the Internet Routing Table: 231 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 432 Number of AfriNIC addresses announced to Internet: 98352640 Equivalent to 5 /8s, 220 /16s and 190 /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 5423 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4405 419 434 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2867 1154 76 VIETEL-AS-AP Viettel Group, VN 4766 2846 11134 761 KIXS-AS-KR Korea Telecom, KR 9829 2803 1497 543 BSNL-NIB National Internet Backbone, IN 45899 2554 1598 162 VNPT-AS-VN VNPT Corp, VN 9394 2538 4907 31 CTTNET China TieTong Telecommunications 17974 2219 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2209 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2104 417 206 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3459 1324 85 SHAW - Shaw Communications Inc., CA 22773 3280 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2193 237 450 CABLEONE - CABLE ONE, INC., US 18566 2170 405 109 MEGAPATH5-US - MegaPath Corporation, US 16509 2136 4706 674 AMAZON-02 - Amazon.com, Inc., US 20115 2105 2553 467 CHARTER-NET-HKY-NC - Charter Communicat 209 2006 5070 608 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1986 342 169 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 1889 938 1349 AKAMAI-AS - Akamai Technologies, Inc., 7018 1732 20202 1271 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4240 1517 544 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2817 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2586 658 1897 AKAMAI-ASN1, US 34984 2026 335 496 TELLCOM-AS, TR 12389 2012 1877 707 ROSTELECOM-AS, RU 9121 1887 1692 19 TTNET, TR 13188 1609 100 43 TRIOLAN, UA 8402 1258 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 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 8151 4973 3305 583 Uninet S.A. de C.V., MX 10620 3588 541 254 Telmex Colombia S.A., CO 11830 2650 369 77 Instituto Costarricense de Electricidad 6503 1640 443 60 Axtel, S.A.B. de C.V., MX 7303 1516 1027 189 Telecom Argentina S.A., AR 28573 1031 2241 176 CLARO S.A., BR 3816 1009 505 130 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 932 377 31 Telefonica del Peru S.A.A., PE 11172 926 126 85 Alestra, S. de R.L. de C.V., MX 18881 911 1078 30 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 1172 396 48 LINKdotNET-AS, EG 37611 857 107 9 Afrihost, ZA 36903 735 369 146 MT-MPLS, MA 36992 723 1412 41 ETISALAT-MISR, EG 8452 671 1730 18 TE-AS TE-AS, EG 24835 607 818 18 RAYA-AS, EG 37492 467 470 57 ORANGE-, TN 29571 455 68 11 ORANGE-COTE-IVOIRE, CI 37342 378 32 1 MOVITEL, MZ 15399 369 35 7 WANANCHI-, KE 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 5423 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4973 3305 583 Uninet S.A. de C.V., MX 7545 4405 419 434 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 4240 1517 544 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3588 541 254 Telmex Colombia S.A., CO 6327 3459 1324 85 SHAW - Shaw Communications Inc., CA 22773 3280 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2867 1154 76 VIETEL-AS-AP Viettel Group, VN 4766 2846 11134 761 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 8151 4973 4390 Uninet S.A. de C.V., MX 7545 4405 3971 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 12479 4240 3696 UNI2-AS, ES 6327 3459 3374 SHAW - Shaw Communications Inc., CA 10620 3588 3334 Telmex Colombia S.A., CO 22773 3280 3133 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2867 2791 VIETEL-AS-AP Viettel Group, VN 8551 2817 2774 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2650 2573 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 65456 PRIVATE 31.171.126.0/23 199311 AZRT-LX Local Internet Exchang 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65000 PRIVATE 95.179.2.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.3.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.69.0/24 65001 -Private Use AS-, ZZ 65000 PRIVATE 95.179.70.0/24 65001 -Private Use AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ 41.76.143.0/24 37500 -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:14 /9:11 /10:37 /11:99 /12:290 /13:567 /14:1097 /15:1901 /16:13371 /17:7931 /18:13755 /19:25307 /20:39368 /21:45518 /22:87459 /23:71110 /24:393881 /25:828 /26:632 /27:636 /28:36 /29:20 /30:17 /31:4 /32:55 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3246 3459 SHAW - Shaw Communications Inc., CA 12479 3027 4240 UNI2-AS, ES 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2543 3280 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2279 2817 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2063 2170 MEGAPATH5-US - MegaPath Corporation, US 11830 1998 2650 Instituto Costarricense de Electricidad y Telec 11492 1910 2193 CABLEONE - CABLE ONE, INC., US 30036 1738 1986 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1612 3588 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1643 2:858 4:19 5:2808 6:66 7:1 8:1119 12:1863 13:194 14:1757 15:28 16:3 17:210 18:55 20:49 21:8 23:2643 24:2229 25:2 27:2376 31:1989 32:92 35:27 36:512 37:2756 38:1477 39:265 40:121 41:3219 42:681 43:1923 44:118 45:4689 46:3042 47:200 49:1326 50:1056 51:314 52:1050 54:369 55:2 56:12 57:40 58:1620 59:999 60:428 61:2161 62:1835 63:1792 64:5032 65:2210 66:4679 67:2443 68:1166 69:3221 70:1152 71:566 72:2115 74:2734 75:419 76:454 77:1559 78:1709 79:1812 80:1517 81:1389 82:1093 83:771 84:1080 85:2044 86:577 87:1312 88:926 89:2341 90:214 91:6386 92:1206 93:2368 94:2395 95:2835 96:730 97:358 98:946 99:133 100:83 101:1277 102:79 103:17862 104:3619 105:243 106:632 107:1897 108:686 109:3451 110:1640 111:1778 112:1269 113:1279 114:1131 115:1645 116:1637 117:1730 118:2159 119:1665 120:975 121:1050 122:2444 123:1772 124:1436 125:1899 128:1026 129:656 130:450 131:1592 132:678 133:196 134:1025 135:258 136:500 137:560 138:1970 139:610 140:406 141:725 142:829 143:1010 144:805 145:479 146:1196 147:730 148:1636 149:765 150:732 151:1060 152:784 153:312 154:1100 155:766 156:1031 157:802 158:658 159:1738 160:1001 161:781 162:2583 163:583 164:1059 165:1476 166:462 167:1285 168:3064 169:830 170:3732 171:440 172:1087 173:2010 174:905 175:779 176:1997 177:4028 178:2505 179:1215 180:2225 181:2246 182:2368 183:1181 184:1024 185:13565 186:3620 187:2375 188:2841 189:2096 190:8122 191:1404 192:9829 193:5966 194:4842 195:3984 196:2551 197:1558 198:5521 199:5917 200:7367 201:5020 202:10458 203:10197 204:4577 205:2892 206:3110 207:3176 208:4018 209:3978 210:4054 211:2107 212:3046 213:2732 214:968 215:59 216:5971 217:2129 218:912 219:627 220:1768 221:989 222:1022 223:1286 End of report From eric.kuhnke at gmail.com Fri Jun 8 18:14:59 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 8 Jun 2018 11:14:59 -0700 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> References: <668BA2A6-EE2F-4F25-9A2F-B3B6DBFCA1C4@beckman.org> <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> Message-ID: This is one of the reasons why large organizations, such as the ones you describe, have both portable spectrum analyzers (covering the 2400 range and 5150-5850 MHz 802.11(whatever) bands), and also ability to hunt for MAC addresses of wifi devices that don't match known centrally managed APs. Even if somebody sets up to not broadcast the SSID, the MAC will still be there and can be recognized as an unknown device, then physically triangulated upon for its OSI layer 1 location, with RSSI/RSL level and a portable spectrum analyzer with directional yagi antenna. On Fri, Jun 8, 2018 at 10:32 AM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > This thread has piqued my curiosity on whether there'd be a way to detect > a rogue access point, or proxy server with an inside and outside > interface? Let's just say 802.1x is in place too to make it more > interesting. For example, could employee X, who doesn't want their > department to be back billed for more switch ports, go and get some > reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth > to the physical network using their credentials? They then let their staff > wifi into it and the traffic is NAT'd. I'm sure anyone in a university > setting has encountered this. Obviously policy can forbid, but any way to > detect it other than seeing traffic patterns on a port not match historical > once the other users have been combined onto it, or those other users' > ports go down? > > David > > > On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" < > nanog-bounces at nanog.org on behalf of mel at beckman.org> wrote: > > When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, > which has a Layer-2 collection feature that identifies the number and MACs > of devices on any given switch port. We export this list and cull out all > the known managed switch links. Anything remaining that has more than one > MAC per port is a potential violation that we can readily inspect. It’s not > perfect, because an unmanaged switch might only have one device connected, > in which case it wont be detected. You can also get false positives from > hosts running virtualization, if the v-kernel generates synthetic MAC > addresses. But it’s amazing how many times we find unmanaged switches > squirreled away under desks or in ceilings. > > -mel > > > On Jun 7, 2018, at 4:54 AM, Jason Hellenthal > wrote: > > > > As someone already stated the obvious answers, the slightly more > difficult route to be getting a count of allowed devices and MAC addresses, > then moving forward with something like ansible to poll the count of MAC’s > on any given port ... of number higher than what’s allowed, suspend the > port and send a notification to the appropriate parties. > > > > > > All in all though sounds like a really brash thing to do to your > network team and will generally know and have a very good reason for doing > so... but not all situations are created equally so good luck. > > > > > > -- > > > > The fact that there's a highway to Hell but only a stairway to > Heaven says a lot about anticipated traffic volume. > > > >> On Jun 7, 2018, at 03:57, segs > wrote: > >> > >> Hello All, > >> > >> Please I have a very interesting scenario that I am on the lookout > for a > >> solution for, We have instances where the network team of my > company bypass > >> controls and processes when adding new switches to the network. > >> > >> The right parameters that are required to be configured on the > switches > >> inorder for the NAC solution deployed to have full visibility into > end > >> points that connects to such switches are not usually configured. > >> > >> This poses a problem for the security team as they dont have > visibility > >> into such devices that connect to such switches on the NAC > solution, the > >> network guys usually connect the new switches to the trunk port and > they > >> have access to all VLANs. > >> > >> Is there a solution that can detect new or unmanaged switches on the > >> network, and block such devices or if there is a solution that > block users > >> that connect to unmanaged switches on the network even if those > users have > >> domain PCs. > >> > >> Anticipating your speedy response. > >> > >> Thank You! > > > From owen at delong.com Fri Jun 8 18:20:47 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Jun 2018 11:20:47 -0700 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> References: <668BA2A6-EE2F-4F25-9A2F-B3B6DBFCA1C4@beckman.org> <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> Message-ID: <05D01F63-5F55-4CF0-B15D-DA4EDAA524D8@delong.com> There are a few options. 1. Most likely it will leak information (STUN, NAT-PMP, etc.). 2. You could look obvious signs of NATted traffic. (e.g. re-use of the same source port number to different destinations from the box, etc.) 3. You can look at the TTL or Hop-Count on packets coming out of the box. Most NAT routers (I believe DD-WRT included, IIRC) do still decrement the TTL/Hop-Count (v4/v6) when passing the packet. 4. NMAP the device… DD-WRT will usually look strikingly different from most desktop hosts. I’m sure there are other ways, but those are the first 4 that spring to mind. Each could be defeated by a particularly careful/clever implementer, but in an enterprise, usually it makes little sense to go to that much trouble to violate policy. Universities are an exception as that’s a whole different set of equations on risk/benefit. Owen > On Jun 8, 2018, at 10:32 , David Hubbard wrote: > > This thread has piqued my curiosity on whether there'd be a way to detect a rogue access point, or proxy server with an inside and outside interface? Let's just say 802.1x is in place too to make it more interesting. For example, could employee X, who doesn't want their department to be back billed for more switch ports, go and get some reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth to the physical network using their credentials? They then let their staff wifi into it and the traffic is NAT'd. I'm sure anyone in a university setting has encountered this. Obviously policy can forbid, but any way to detect it other than seeing traffic patterns on a port not match historical once the other users have been combined onto it, or those other users' ports go down? > > David > > > On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" wrote: > > When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, which has a Layer-2 collection feature that identifies the number and MACs of devices on any given switch port. We export this list and cull out all the known managed switch links. Anything remaining that has more than one MAC per port is a potential violation that we can readily inspect. It’s not perfect, because an unmanaged switch might only have one device connected, in which case it wont be detected. You can also get false positives from hosts running virtualization, if the v-kernel generates synthetic MAC addresses. But it’s amazing how many times we find unmanaged switches squirreled away under desks or in ceilings. > > -mel > >> On Jun 7, 2018, at 4:54 AM, Jason Hellenthal wrote: >> >> As someone already stated the obvious answers, the slightly more difficult route to be getting a count of allowed devices and MAC addresses, then moving forward with something like ansible to poll the count of MAC’s on any given port ... of number higher than what’s allowed, suspend the port and send a notification to the appropriate parties. >> >> >> All in all though sounds like a really brash thing to do to your network team and will generally know and have a very good reason for doing so... but not all situations are created equally so good luck. >> >> >> -- >> >> The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. >> >>> On Jun 7, 2018, at 03:57, segs wrote: >>> >>> Hello All, >>> >>> Please I have a very interesting scenario that I am on the lookout for a >>> solution for, We have instances where the network team of my company bypass >>> controls and processes when adding new switches to the network. >>> >>> The right parameters that are required to be configured on the switches >>> inorder for the NAC solution deployed to have full visibility into end >>> points that connects to such switches are not usually configured. >>> >>> This poses a problem for the security team as they dont have visibility >>> into such devices that connect to such switches on the NAC solution, the >>> network guys usually connect the new switches to the trunk port and they >>> have access to all VLANs. >>> >>> Is there a solution that can detect new or unmanaged switches on the >>> network, and block such devices or if there is a solution that block users >>> that connect to unmanaged switches on the network even if those users have >>> domain PCs. >>> >>> Anticipating your speedy response. >>> >>> Thank You! > > From mel at beckman.org Fri Jun 8 18:24:06 2018 From: mel at beckman.org (Mel Beckman) Date: Fri, 8 Jun 2018 18:24:06 +0000 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: References: <668BA2A6-EE2F-4F25-9A2F-B3B6DBFCA1C4@beckman.org> <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> Message-ID: <4218F565-5E4C-4B49-BB38-20621E92741D@beckman.org> Enterprise WiFi systems, such as those by HPE (Aruba) and Cisco, have built-in rogue detection including integrated spectrum analysis. Every AP becomes a spectrum analyzer, so the WiFi controller can detect rogue APs, identify whether or not they’re physically connected to your network, and then even tell you the switch and port they’re plugged into. You can disable that port to kill the rogue’s network access, then follow that cable to the interloper. We use a 2’ pipe wrench for enforcement :) -mel > On Jun 8, 2018, at 11:14 AM, Eric Kuhnke wrote: > > This is one of the reasons why large organizations, such as the ones you > describe, have both portable spectrum analyzers (covering the 2400 range > and 5150-5850 MHz 802.11(whatever) bands), and also ability to hunt for MAC > addresses of wifi devices that don't match known centrally managed APs. > Even if somebody sets up to not broadcast the SSID, the MAC will still be > there and can be recognized as an unknown device, then physically > triangulated upon for its OSI layer 1 location, with RSSI/RSL level and a > portable spectrum analyzer with directional yagi antenna. > > > > On Fri, Jun 8, 2018 at 10:32 AM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > >> This thread has piqued my curiosity on whether there'd be a way to detect >> a rogue access point, or proxy server with an inside and outside >> interface? Let's just say 802.1x is in place too to make it more >> interesting. For example, could employee X, who doesn't want their >> department to be back billed for more switch ports, go and get some >> reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth >> to the physical network using their credentials? They then let their staff >> wifi into it and the traffic is NAT'd. I'm sure anyone in a university >> setting has encountered this. Obviously policy can forbid, but any way to >> detect it other than seeing traffic patterns on a port not match historical >> once the other users have been combined onto it, or those other users' >> ports go down? >> >> David >> >> >> On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" < >> nanog-bounces at nanog.org on behalf of mel at beckman.org> wrote: >> >> When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, >> which has a Layer-2 collection feature that identifies the number and MACs >> of devices on any given switch port. We export this list and cull out all >> the known managed switch links. Anything remaining that has more than one >> MAC per port is a potential violation that we can readily inspect. It’s not >> perfect, because an unmanaged switch might only have one device connected, >> in which case it wont be detected. You can also get false positives from >> hosts running virtualization, if the v-kernel generates synthetic MAC >> addresses. But it’s amazing how many times we find unmanaged switches >> squirreled away under desks or in ceilings. >> >> -mel >> >>> On Jun 7, 2018, at 4:54 AM, Jason Hellenthal >> wrote: >>> >>> As someone already stated the obvious answers, the slightly more >> difficult route to be getting a count of allowed devices and MAC addresses, >> then moving forward with something like ansible to poll the count of MAC’s >> on any given port ... of number higher than what’s allowed, suspend the >> port and send a notification to the appropriate parties. >>> >>> >>> All in all though sounds like a really brash thing to do to your >> network team and will generally know and have a very good reason for doing >> so... but not all situations are created equally so good luck. >>> >>> >>> -- >>> >>> The fact that there's a highway to Hell but only a stairway to >> Heaven says a lot about anticipated traffic volume. >>> >>>> On Jun 7, 2018, at 03:57, segs >> wrote: >>>> >>>> Hello All, >>>> >>>> Please I have a very interesting scenario that I am on the lookout >> for a >>>> solution for, We have instances where the network team of my >> company bypass >>>> controls and processes when adding new switches to the network. >>>> >>>> The right parameters that are required to be configured on the >> switches >>>> inorder for the NAC solution deployed to have full visibility into >> end >>>> points that connects to such switches are not usually configured. >>>> >>>> This poses a problem for the security team as they dont have >> visibility >>>> into such devices that connect to such switches on the NAC >> solution, the >>>> network guys usually connect the new switches to the trunk port and >> they >>>> have access to all VLANs. >>>> >>>> Is there a solution that can detect new or unmanaged switches on the >>>> network, and block such devices or if there is a solution that >> block users >>>> that connect to unmanaged switches on the network even if those >> users have >>>> domain PCs. >>>> >>>> Anticipating your speedy response. >>>> >>>> Thank You! >> >> >> From cjwolff at nola.gov Fri Jun 8 19:03:26 2018 From: cjwolff at nola.gov (Christopher J. Wolff) Date: Fri, 8 Jun 2018 19:03:26 +0000 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: References: Message-ID: <47F264CE123954429FC99B9E768819F29A851FF2@CNO-XCH03.cityofno.com> Cisco ISE will accomplish this. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of segs Sent: Thursday, June 7, 2018 3:57 AM To: nanog at nanog.org Subject: Application or Software to detect or Block unmanaged swicthes Hello All, Please I have a very interesting scenario that I am on the lookout for a solution for, We have instances where the network team of my company bypass controls and processes when adding new switches to the network. The right parameters that are required to be configured on the switches inorder for the NAC solution deployed to have full visibility into end points that connects to such switches are not usually configured. This poses a problem for the security team as they dont have visibility into such devices that connect to such switches on the NAC solution, the network guys usually connect the new switches to the trunk port and they have access to all VLANs. Is there a solution that can detect new or unmanaged switches on the network, and block such devices or if there is a solution that block users that connect to unmanaged switches on the network even if those users have domain PCs. Anticipating your speedy response. Thank You! From alan.buxey at gmail.com Fri Jun 8 19:12:12 2018 From: alan.buxey at gmail.com (Alan Buxey) Date: Fri, 8 Jun 2018 20:12:12 +0100 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: References: Message-ID: as already said - this can be covered with adequate processes and management (even so far as, not doing your job right? time for HR...). however, there are many ways to ensure that random ports arent doing anything other than what they should be doing - most of these are L2 security features - port-security, BPDUGAURD, default vlan pruning, along with other protections such as DHCP snooping etc. however, if its the network team doing this - then they could just turn those things off anyway - so you need to also ensure all managed switch configs have their configs audited and checked - grabbed by SNMP and checked/audited against known template etc etc. if a switch cannot be audited then disconnect its uplink..... but then your end users/customers no longer have connections - which is why its really down to management processes. WHY are they doing this? there could be other reasons why due process isnt being followed other than eg incompetence, malice, laziness etc alan From cjwolff at nola.gov Fri Jun 8 19:19:09 2018 From: cjwolff at nola.gov (Christopher J. Wolff) Date: Fri, 8 Jun 2018 19:19:09 +0000 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> References: <668BA2A6-EE2F-4F25-9A2F-B3B6DBFCA1C4@beckman.org> <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> Message-ID: <47F264CE123954429FC99B9E768819F29A8520EE@CNO-XCH03.cityofno.com> David, If you are using a product like ISE/Forescout you could set up multiple layers of device identification prior to network authorization. For example, a user would need to spoof the results of a legitimate device to match the results of: -NMAP scan -Domain machine/user Auth -OID/MAC etc It's simply a matter of dissecting the signatures of legitimate devices to the finest level of granularity and denying everything else. Best, Christopher -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hubbard Sent: Friday, June 8, 2018 12:32 PM To: nanog at nanog.org Subject: Re: Application or Software to detect or Block unmanaged swicthes This thread has piqued my curiosity on whether there'd be a way to detect a rogue access point, or proxy server with an inside and outside interface? Let's just say 802.1x is in place too to make it more interesting. For example, could employee X, who doesn't want their department to be back billed for more switch ports, go and get some reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth to the physical network using their credentials? They then let their staff wifi into it and the traffic is NAT'd. I'm sure anyone in a university setting has encountered this. Obviously policy can forbid, but any way to detect it other than seeing traffic patterns on a port not match historical once the other users have been combined onto it, or those other users' ports go down? David On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" wrote: When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, which has a Layer-2 collection feature that identifies the number and MACs of devices on any given switch port. We export this list and cull out all the known managed switch links. Anything remaining that has more than one MAC per port is a potential violation that we can readily inspect. It’s not perfect, because an unmanaged switch might only have one device connected, in which case it wont be detected. You can also get false positives from hosts running virtualization, if the v-kernel generates synthetic MAC addresses. But it’s amazing how many times we find unmanaged switches squirreled away under desks or in ceilings. -mel > On Jun 7, 2018, at 4:54 AM, Jason Hellenthal wrote: > > As someone already stated the obvious answers, the slightly more difficult route to be getting a count of allowed devices and MAC addresses, then moving forward with something like ansible to poll the count of MAC’s on any given port ... of number higher than what’s allowed, suspend the port and send a notification to the appropriate parties. > > > All in all though sounds like a really brash thing to do to your network team and will generally know and have a very good reason for doing so... but not all situations are created equally so good luck. > > > -- > > The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > >> On Jun 7, 2018, at 03:57, segs wrote: >> >> Hello All, >> >> Please I have a very interesting scenario that I am on the lookout for a >> solution for, We have instances where the network team of my company bypass >> controls and processes when adding new switches to the network. >> >> The right parameters that are required to be configured on the switches >> inorder for the NAC solution deployed to have full visibility into end >> points that connects to such switches are not usually configured. >> >> This poses a problem for the security team as they dont have visibility >> into such devices that connect to such switches on the NAC solution, the >> network guys usually connect the new switches to the trunk port and they >> have access to all VLANs. >> >> Is there a solution that can detect new or unmanaged switches on the >> network, and block such devices or if there is a solution that block users >> that connect to unmanaged switches on the network even if those users have >> domain PCs. >> >> Anticipating your speedy response. >> >> Thank You! From karim.adel at gmail.com Fri Jun 8 19:20:57 2018 From: karim.adel at gmail.com (Kasper Adel) Date: Fri, 8 Jun 2018 12:20:57 -0700 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> References: <668BA2A6-EE2F-4F25-9A2F-B3B6DBFCA1C4@beckman.org> <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> Message-ID: How about some scripts around fail2ban, if the same account logs in multiple times, its banning time. Kasper On Friday, June 8, 2018, David Hubbard wrote: > This thread has piqued my curiosity on whether there'd be a way to detect > a rogue access point, or proxy server with an inside and outside > interface? Let's just say 802.1x is in place too to make it more > interesting. For example, could employee X, who doesn't want their > department to be back billed for more switch ports, go and get some > reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth > to the physical network using their credentials? They then let their staff > wifi into it and the traffic is NAT'd. I'm sure anyone in a university > setting has encountered this. Obviously policy can forbid, but any way to > detect it other than seeing traffic patterns on a port not match historical > once the other users have been combined onto it, or those other users' > ports go down? > > David > > > On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" < > nanog-bounces at nanog.org on behalf of mel at beckman.org> wrote: > > When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, > which has a Layer-2 collection feature that identifies the number and MACs > of devices on any given switch port. We export this list and cull out all > the known managed switch links. Anything remaining that has more than one > MAC per port is a potential violation that we can readily inspect. It’s not > perfect, because an unmanaged switch might only have one device connected, > in which case it wont be detected. You can also get false positives from > hosts running virtualization, if the v-kernel generates synthetic MAC > addresses. But it’s amazing how many times we find unmanaged switches > squirreled away under desks or in ceilings. > > -mel > > > On Jun 7, 2018, at 4:54 AM, Jason Hellenthal > wrote: > > > > As someone already stated the obvious answers, the slightly more > difficult route to be getting a count of allowed devices and MAC addresses, > then moving forward with something like ansible to poll the count of MAC’s > on any given port ... of number higher than what’s allowed, suspend the > port and send a notification to the appropriate parties. > > > > > > All in all though sounds like a really brash thing to do to your > network team and will generally know and have a very good reason for doing > so... but not all situations are created equally so good luck. > > > > > > -- > > > > The fact that there's a highway to Hell but only a stairway to > Heaven says a lot about anticipated traffic volume. > > > >> On Jun 7, 2018, at 03:57, segs > wrote: > >> > >> Hello All, > >> > >> Please I have a very interesting scenario that I am on the lookout > for a > >> solution for, We have instances where the network team of my > company bypass > >> controls and processes when adding new switches to the network. > >> > >> The right parameters that are required to be configured on the > switches > >> inorder for the NAC solution deployed to have full visibility into > end > >> points that connects to such switches are not usually configured. > >> > >> This poses a problem for the security team as they dont have > visibility > >> into such devices that connect to such switches on the NAC > solution, the > >> network guys usually connect the new switches to the trunk port and > they > >> have access to all VLANs. > >> > >> Is there a solution that can detect new or unmanaged switches on the > >> network, and block such devices or if there is a solution that > block users > >> that connect to unmanaged switches on the network even if those > users have > >> domain PCs. > >> > >> Anticipating your speedy response. > >> > >> Thank You! > > > From ben at 6by7.net Fri Jun 8 19:28:33 2018 From: ben at 6by7.net (Ben Cannon) Date: Fri, 8 Jun 2018 12:28:33 -0700 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: References: <668BA2A6-EE2F-4F25-9A2F-B3B6DBFCA1C4@beckman.org> <7CD37DD3-8A75-4A01-BB8C-494E36C48103@dino.hostasaurus.com> Message-ID: <062E6E90-609B-4050-968A-F84A3BF9AFC3@6by7.net> I’ve got an easy way to do this, I confiscate ‘em ;) As others have said, this is a management problem. Untrustworthy parties shouldn’t have physical access to your trunk ports. That said Layer 2 MAC ACLs should block everything and allow only your switches. Also do you have lit trunk ports just floating in space? You shouldn’t... From stano at imaginesoftware.com Fri Jun 8 18:17:54 2018 From: stano at imaginesoftware.com (Stan Ouchakov) Date: Fri, 8 Jun 2018 18:17:54 +0000 Subject: Need /24 (arin) asap Message-ID: Hi, Can anyone recommend transfer market brokers for ipv4 addresses? Need clean /24 asap. ARIN's waiting list is too long... Thanks! -Stan From gary at lsu.edu Fri Jun 8 18:45:45 2018 From: gary at lsu.edu (Gary A Mumphrey) Date: Fri, 8 Jun 2018 18:45:45 +0000 Subject: Carrier Ethernet Interoperability between Juniper and Ciena Message-ID: Hi All, Anyone out there creating carrier Ethernet services terminating services on one end with Juniper and the other end with Ciena? The particular Juniper platforms we are looking at are the ACX5000 series and/or MX204. We already deliver an end-to-end Ciena solution for our customers with their CES (3000/5000) platform. Thanks. Gary Mumphrey Network Engineer, LONI gary at lsu.edu 225-578-1995 From brad at persius.net Fri Jun 8 23:30:04 2018 From: brad at persius.net (Brad) Date: Fri, 08 Jun 2018 17:30:04 -0600 Subject: Application or Software to detect or Block unmanaged swicthes In-Reply-To: <062E6E90-609B-4050-968A-F84A3BF9AFC3@6by7.net> Message-ID: <20180608233009.52C2680320@mail.alphavpn.com> I like the idea of using a quarantine network by default with a captive portal assistant to permit certain levels of access if needed.. fairly easy to setup on LAN and WiFi networks with no problem.  Just depends on what you are trying to secure- easy to set up audits with MAC tables and SNMP data either way. Brad -------- Original message --------From: Ben Cannon Date: 6/8/18 13:28 (GMT-07:00) To: Kasper Adel Cc: nanog at nanog.org Subject: Re: Application or Software to detect or Block unmanaged swicthes I’ve got an easy way to do this, I confiscate ‘em ;) As others have said, this is a management problem.  Untrustworthy parties shouldn’t have physical access to your trunk ports. That said Layer 2 MAC ACLs should block everything and allow only your switches. Also do you have lit trunk ports just floating in space?   You shouldn’t... From nicotine at warningg.com Sun Jun 10 15:57:09 2018 From: nicotine at warningg.com (Brandon Ewing) Date: Sun, 10 Jun 2018 10:57:09 -0500 Subject: AT&T Res Fiber Chicago contact? Message-ID: <20180610155709.GI22280@radiological.warningg.com> Howdy, I've been struggling for a few weeks trying to identify whom to speak to at AT&T regarding pre-wiring of fiber in our small (6 unit) HOA. I know the fiber is on the pole (it lists our address as in the service area), but I cannot get the service installed without impinging on other units. I'd like to work through the HOA to set up a new easement alongside the existing phone and cable currently running through all the units, but have not had any success with the multi-family unit form at AT&T (I think it's designed for large apartment buildings), or through the customer support apparatus. Seeing as how my current choices are bonded aDSL and Comcast, adding a 3rd party would be extremely advantageous to the HOA and provide turnkey access to the rest of the residents. If someone knows someone at AT&T who could assist, I would be extremely appreciative. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Tyler at tgconrad.com Sun Jun 10 16:06:22 2018 From: Tyler at tgconrad.com (Tyler Conrad) Date: Sun, 10 Jun 2018 09:06:22 -0700 Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: I’ve bought through ipv4marketgroup in the past. Easy to work with, but you’ll want to do your own scans of the address space to make sure it hasn’t been burned yet. On Sun, Jun 10, 2018 at 08:43 Stan Ouchakov wrote: > Hi, > > Can anyone recommend transfer market brokers for ipv4 addresses? Need > clean /24 asap. ARIN's waiting list is too long... > > Thanks! > > > -Stan > > From merculiani at gmail.com Sun Jun 10 16:08:07 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Sun, 10 Jun 2018 12:08:07 -0400 Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: Are you using it to help roll out IPv6? (i.e. dual stack is pretty much mandatory) 4-10 space is "free", but I wouldn't test your luck by just using the space like any regular allocation, plus it's just bad karma to use that space outside of it's noble intention. https://www.arin.net/knowledge/ip_blocks.html If that's not your intent, you can pretty easily purchase a block for about $5k US from Hilco Streambank, assuming you have pre-approval from ARIN for a transfer. -Matt On Sun, Jun 10, 2018, 11:43 Stan Ouchakov wrote: > Hi, > > Can anyone recommend transfer market brokers for ipv4 addresses? Need > clean /24 asap. ARIN's waiting list is too long... > > Thanks! > > > -Stan > > From nanog at ics-il.net Sun Jun 10 16:11:25 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 10 Jun 2018 11:11:25 -0500 (CDT) Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: <477579035.4413.1528647083837.JavaMail.mhammett@ThunderFuck> Unfortunately, for an eyeball network, you don't have a good way of knowing that ahead of time without actually using it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Matt Erculiani" To: "Stan Ouchakov" Cc: nanog at nanog.org Sent: Sunday, June 10, 2018 11:08:07 AM Subject: Re: Need /24 (arin) asap Are you using it to help roll out IPv6? (i.e. dual stack is pretty much mandatory) 4-10 space is "free", but I wouldn't test your luck by just using the space like any regular allocation, plus it's just bad karma to use that space outside of it's noble intention. https://www.arin.net/knowledge/ip_blocks.html If that's not your intent, you can pretty easily purchase a block for about $5k US from Hilco Streambank, assuming you have pre-approval from ARIN for a transfer. -Matt On Sun, Jun 10, 2018, 11:43 Stan Ouchakov wrote: > Hi, > > Can anyone recommend transfer market brokers for ipv4 addresses? Need > clean /24 asap. ARIN's waiting list is too long... > > Thanks! > > > -Stan > > From mike.lyon at gmail.com Sun Jun 10 20:48:55 2018 From: mike.lyon at gmail.com (Mike Lyon) Date: Sun, 10 Jun 2018 13:48:55 -0700 Subject: What are people using for IPAM these days? Message-ID: Title says it all... Currently using IPPlan, but it is kinda antiquated.. Thanks, Mike -- Mike Lyon mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From xenith at xenith.org Sun Jun 10 20:56:14 2018 From: xenith at xenith.org (Justin Seabrook-Rocha) Date: Sun, 10 Jun 2018 13:56:14 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: <3A774817-CAAB-41B5-BFC7-1386CBFDFA34@xenith.org> Netbox (https://github.com/digitalocean/netbox ) is our choice. Can be completely API driven, has a lot of DCIM type functionality as well. Justin Seabrook-Rocha -- Xenith || xenith at xenith.org || http://xenith.org/ > On Jun 10, 2018, at 13:48, Mike Lyon wrote: > > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > Thanks, > Mike > > -- > Mike Lyon > mike.lyon at gmail.com > http://www.linkedin.com/in/mlyon From job at instituut.net Sun Jun 10 20:56:35 2018 From: job at instituut.net (Job Snijders) Date: Sun, 10 Jun 2018 20:56:35 +0000 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: Hey Mike, On Sun, Jun 10, 2018 at 8:48 PM, Mike Lyon wrote: > Title says it all... Currently using IPPlan, but it is kinda antiquated.. This is always a good thing to review every 2-3 years or so. My current favorites in the open source world are: Netbox - https://github.com/digitalocean/netbox NIPAP - http://spritelink.github.io/NIPAP/ ed - http://man.openbsd.org/ed ;-) Give a few of the IPAMs out there a chance and just see which one suits your operational procedures best! (Though, using a spreadsheet file on a shared network drive is still not recommended.) Kind regards, Job From sam.oduor at gmail.com Sun Jun 10 20:58:10 2018 From: sam.oduor at gmail.com (Sam Oduor) Date: Sun, 10 Jun 2018 23:58:10 +0300 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: Many options available - 1. DNSBOX - does IPAM, DHCP and DNS Management, thinking of those RDNS. 2. Infloblox - relatively same as (1) difference being cost 3. A couple of open source vendors - netbox, phpIPAM, List never runs out - Solarwinds too has an IPAM feature. On Sun, Jun 10, 2018 at 11:48 PM, Mike Lyon wrote: > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > Thanks, > Mike > > -- > Mike Lyon > mike.lyon at gmail.com > http://www.linkedin.com/in/mlyon > -- Samson Oduor From jamann at mt.gov Sun Jun 10 21:04:15 2018 From: jamann at mt.gov (Mann, Jason) Date: Sun, 10 Jun 2018 21:04:15 +0000 Subject: What are people using for IPAM these days? In-Reply-To: <3A774817-CAAB-41B5-BFC7-1386CBFDFA34@xenith.org> References: , <3A774817-CAAB-41B5-BFC7-1386CBFDFA34@xenith.org> Message-ID: <1528664656676.36558@mt.gov> We use InfoBlox for IPAM but we also use InfoBlox for DHCP and DNS ________________________________________ From: NANOG on behalf of Justin Seabrook-Rocha Sent: Sunday, June 10, 2018 2:56 PM To: Mike Lyon Cc: NANOG Subject: Re: What are people using for IPAM these days? Netbox (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdigitalocean%2Fnetbox&data=02%7C01%7Cjamann%40mt.gov%7C4261548f80004456897b08d5cf14f3d8%7C07a94c98f30f4abbbd7ed63f8720dc02%7C0%7C1%7C636642611262992679&sdata=RRaNVW3sWTYFDsVR8V5hdDd7EXde1TOq1KEBbUCM3yY%3D&reserved=0 ) is our choice. Can be completely API driven, has a lot of DCIM type functionality as well. Justin Seabrook-Rocha -- Xenith || xenith at xenith.org || https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fxenith.org%2F&data=02%7C01%7Cjamann%40mt.gov%7C4261548f80004456897b08d5cf14f3d8%7C07a94c98f30f4abbbd7ed63f8720dc02%7C0%7C1%7C636642611262992679&sdata=z8YXxkOu0LJiT87cpasl4sxDMFnFHHRG5nac0ahw81Q%3D&reserved=0 > On Jun 10, 2018, at 13:48, Mike Lyon wrote: > > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > Thanks, > Mike > > -- > Mike Lyon > mike.lyon at gmail.com > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fmlyon&data=02%7C01%7Cjamann%40mt.gov%7C4261548f80004456897b08d5cf14f3d8%7C07a94c98f30f4abbbd7ed63f8720dc02%7C0%7C0%7C636642611262992679&sdata=gdmyj77gPSxkoEuynj%2Bhq9WVc9SEWb57%2F1USsBxPW9M%3D&reserved=0 From askoorb+nanog at gmail.com Sun Jun 10 21:08:23 2018 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Sun, 10 Jun 2018 22:08:23 +0100 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: On Sun, 10 Jun 2018 at 21:50, Mike Lyon wrote: > > Title says it all... Currently using IPPlan, but it is kinda antiquated.. I am told by someone who has used it that Diamond IP is fantastic (https://www.globalservices.bt.com/btfederal/en/products/diamondip). But good luck getting your jaw off the floor after they tell you the price. Alex From jordi.palet at consulintel.es Sun Jun 10 21:36:45 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 10 Jun 2018 23:36:45 +0200 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: <93C3D7DD-E6CC-42FA-936F-E4D562804F37@consulintel.es> One more open source option: https://www.gestioip.net/ Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Job Snijders Fecha: domingo, 10 de junio de 2018, 23:01 Para: Mike Lyon CC: NANOG Asunto: Re: What are people using for IPAM these days? Hey Mike, On Sun, Jun 10, 2018 at 8:48 PM, Mike Lyon wrote: > Title says it all... Currently using IPPlan, but it is kinda antiquated.. This is always a good thing to review every 2-3 years or so. My current favorites in the open source world are: Netbox - https://github.com/digitalocean/netbox NIPAP - http://spritelink.github.io/NIPAP/ ed - http://man.openbsd.org/ed ;-) Give a few of the IPAMs out there a chance and just see which one suits your operational procedures best! (Though, using a spreadsheet file on a shared network drive is still not recommended.) Kind regards, Job ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From saku at ytti.fi Mon Jun 11 09:43:37 2018 From: saku at ytti.fi (Saku Ytti) Date: Mon, 11 Jun 2018 12:43:37 +0300 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: On 10 June 2018 at 23:56, Job Snijders wrote: > Netbox - https://github.com/digitalocean/netbox > NIPAP - http://spritelink.github.io/NIPAP/ > ed - http://man.openbsd.org/ed ;-) I think lot of these are missed opportunities. There shouldn't really be IPAM, there should number management system, where number presentation, range and such are plugins. So IPv4, IPv6 are just small plugins to the generic system. Just the same you could add RT, RD, VLAN, Interface, PseudowireID, PVC etc allocator as separate plugin, fully leveraging the generic infrastructure and UX. Over time the plugin infra would be extended, and as API/UX gains features, all number systems get them for free. -- ++ytti From krux702 at gmail.com Mon Jun 11 12:18:25 2018 From: krux702 at gmail.com (krux) Date: Mon, 11 Jun 2018 05:18:25 -0700 Subject: What are people using for IPAM these days? In-Reply-To: <3A774817-CAAB-41B5-BFC7-1386CBFDFA34@xenith.org> References: <3A774817-CAAB-41B5-BFC7-1386CBFDFA34@xenith.org> Message-ID: +1 for Netbox. On Sun, Jun 10, 2018 at 1:56 PM, Justin Seabrook-Rocha wrote: > Netbox (https://github.com/digitalocean/netbox digitalocean/netbox>) is our choice. Can be completely API driven, has a > lot of DCIM type functionality as well. > > Justin Seabrook-Rocha > -- > Xenith || xenith at xenith.org || http://xenith.org/ > > > > > On Jun 10, 2018, at 13:48, Mike Lyon wrote: > > > > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > > > Thanks, > > Mike > > > > -- > > Mike Lyon > > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > > -- perl -e 's++=END;++y(;-P)}\n?k++=;<+xru}?print:??;' From hannigan at gmail.com Mon Jun 11 12:51:40 2018 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 11 Jun 2018 08:51:40 -0400 Subject: What are people using for IPAM these days? In-Reply-To: <93C3D7DD-E6CC-42FA-936F-E4D562804F37@consulintel.es> References: <93C3D7DD-E6CC-42FA-936F-E4D562804F37@consulintel.es> Message-ID: Literally for years, I managed a /9 and a v6 /26 in a text file checked into a vanilla source code control system. Sophistication need depends on your frequency of updates, dynamic allocations and regulatory needs ( read RIR). For low turn over assignments, you may not need much. The options Job and Jordi point to are good. The open source options are always a go to IMHO. YMMV. Best Regards, -M< On Sun, Jun 10, 2018 at 17:38 JORDI PALET MARTINEZ via NANOG < nanog at nanog.org> wrote: > One more open source option: > > https://www.gestioip.net/ > > > Regards, > Jordi > > > > -----Mensaje original----- > De: NANOG en nombre de Job Snijders < > job at instituut.net> > Fecha: domingo, 10 de junio de 2018, 23:01 > Para: Mike Lyon > CC: NANOG > Asunto: Re: What are people using for IPAM these days? > > Hey Mike, > > On Sun, Jun 10, 2018 at 8:48 PM, Mike Lyon > wrote: > > Title says it all... Currently using IPPlan, but it is kinda > antiquated.. > > This is always a good thing to review every 2-3 years or so. > > My current favorites in the open source world are: > > Netbox - https://github.com/digitalocean/netbox > NIPAP - http://spritelink.github.io/NIPAP/ > ed - http://man.openbsd.org/ed ;-) > > Give a few of the IPAMs out there a chance and just see which one > suits your operational procedures best! (Though, using a spreadsheet > file on a shared network drive is still not recommended.) > > Kind regards, > > Job > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > From dcorbe at hammerfiber.com Sun Jun 10 16:20:45 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Sun, 10 Jun 2018 12:20:45 -0400 Subject: Need /24 (arin) asap In-Reply-To: <477579035.4413.1528647083837.JavaMail.mhammett@ThunderFuck> References: <477579035.4413.1528647083837.JavaMail.mhammett@ThunderFuck> Message-ID: <79EB7A0A-7C0D-46D2-BE47-8BD92C71A34D@hammerfiber.com> at 12:11 PM, Mike Hammett wrote: > Unfortunately, for an eyeball network, you don't have a good way of > knowing that ahead of time without actually using it. > > Very true. We got lucky with our transfer block. A /21 from Dupont’s address space that was never even announced before. But as always, YMMV. From ringostarr0706 at gmail.com Sun Jun 10 16:58:06 2018 From: ringostarr0706 at gmail.com (Ryugo Kikuchi) Date: Mon, 11 Jun 2018 01:58:06 +0900 Subject: 3rd party QSFP-100G-LR4-S for Cisco In-Reply-To: <7D816844-545C-4F77-ADAF-3DFC106B4383@lumaoptics.net> References: <7D816844-545C-4F77-ADAF-3DFC106B4383@lumaoptics.net> Message-ID: Thank all guys who responded me, It was really helpful for us, and we will pick up some models and try to evaluate those. Probably OSI, FS.COM, FlexOptics, and Finisar will be candidates, of course, other models sound great though. Thanks, Roy On 7 June 2018 at 11:56, Eric Litvin wrote: > Hi Ryugo, > > I’m Eric Litvin, CEO of Luma Optics. We sell 1000s of 100G LR4. Our price > is $800.00 ( yes it’s true $800.00 for 100G-LR4). We can do this because > we buy 1000s of LR4 at a time and do big volumes. Ours are open eeprom and > we provide a device for free that enables you to flash the firmware and > turn up the part in any network environment. I’ve been a Nanog member for > a long time and have many member references if you’d like to consider us. > > Cheers, > > Eric Litvin > > Sent from my iPhone > > > On May 29, 2018, at 5:48 AM, Ryugo Kikuchi > wrote: > > > > Hey all, > > > > Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" for > > Cisco ASR and Nexus? > > > > Cisco's original 100G SFP costs us an arm and a leg, so we want to try to > > use 3rd party 100g SFP. > > But we are not sure which manufacturer's SFP is reliable or has good > > performance. > > > > Does anyone have experience? > > > > Many thanks, > > > > Roy > From 4500811 at gmail.com Sun Jun 10 20:59:26 2018 From: 4500811 at gmail.com (Alex S.) Date: Sun, 10 Jun 2018 16:59:26 -0400 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: Solarwinds IPAM is our choice primarily since we use their other suites/modules already On Sun, Jun 10, 2018 at 16:50 Mike Lyon wrote: > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > Thanks, > Mike > > -- > Mike Lyon > mike.lyon at gmail.com > http://www.linkedin.com/in/mlyon > From dcorbe at hammerfiber.com Sun Jun 10 21:38:30 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Sun, 10 Jun 2018 17:38:30 -0400 Subject: What are people using for IPAM these days? In-Reply-To: <3A774817-CAAB-41B5-BFC7-1386CBFDFA34@xenith.org> References: <3A774817-CAAB-41B5-BFC7-1386CBFDFA34@xenith.org> Message-ID: <1C2DDFF0-19F0-49B0-90FD-7D8F869417E6@hammerfiber.com> +1 for Netbox. at 4:56 PM, Justin Seabrook-Rocha wrote: > Netbox (https://github.com/digitalocean/netbox > ) is our choice. Can be > completely API driven, has a lot of DCIM type functionality as well. > > Justin Seabrook-Rocha > -- > Xenith || xenith at xenith.org || http://xenith.org/ > > > >> On Jun 10, 2018, at 13:48, Mike Lyon wrote: >> >> Title says it all... Currently using IPPlan, but it is kinda antiquated.. >> >> Thanks, >> Mike >> >> -- >> Mike Lyon >> mike.lyon at gmail.com >> http://www.linkedin.com/in/mlyon From dermot.williams at imaginegroup.ie Sun Jun 10 22:04:16 2018 From: dermot.williams at imaginegroup.ie (Dermot Williams) Date: Sun, 10 Jun 2018 23:04:16 +0100 Subject: What are people using for IPAM these days? In-Reply-To: <93C3D7DD-E6CC-42FA-936F-E4D562804F37@consulintel.es> References: <93C3D7DD-E6CC-42FA-936F-E4D562804F37@consulintel.es> Message-ID: <1528667343.local-6c68ee1b-f3a6-v1.2.1-7e7447b6@getmailspring.com> Finding a decent, maintained IPAM is one thing, but migrating is another - do any of these have an easy path from IPPlan? Thanks --- Dermot Williams Imagine Communications Group Ltd. On Jun 10 2018, at 10:36 pm, JORDI PALET MARTINEZ via NANOG wrote: > > One more open source option: > https://www.gestioip.net/ > > Regards, > Jordi > > > > -----Mensaje original----- > De: NANOG en nombre de Job Snijders > Fecha: domingo, 10 de junio de 2018, 23:01 > Para: Mike Lyon > CC: NANOG > Asunto: Re: What are people using for IPAM these days? > > Hey Mike, > On Sun, Jun 10, 2018 at 8:48 PM, Mike Lyon wrote: > > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > This is always a good thing to review every 2-3 years or so. > My current favorites in the open source world are: > Netbox - https://github.com/digitalocean/netbox > NIPAP - http://spritelink.github.io/NIPAP/ > ed - http://man.openbsd.org/ed ;-) > > Give a few of the IPAMs out there a chance and just see which one > suits your operational procedures best! (Though, using a spreadsheet > file on a shared network drive is still not recommended.) > > Kind regards, > Job > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From Steve.Mikulasik at civeo.com Mon Jun 11 14:07:49 2018 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Mon, 11 Jun 2018 14:07:49 +0000 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: PHPIpam, but I do find there to be a lack of current documentation. From bryan at shout.net Mon Jun 11 14:30:30 2018 From: bryan at shout.net (Bryan Holloway) Date: Mon, 11 Jun 2018 09:30:30 -0500 Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: <400c8465-767d-c0d9-e293-10289567868c@shout.net> We've had good results working with Addrex. I would still strongly recommend you do your due diligence for "cleanliness". On 6/8/18 1:17 PM, Stan Ouchakov wrote: > Hi, > > Can anyone recommend transfer market brokers for ipv4 addresses? Need clean /24 asap. ARIN's waiting list is too long... > > Thanks! > > > -Stan > From stano at imaginesoftware.com Mon Jun 11 14:32:30 2018 From: stano at imaginesoftware.com (Stan Ouchakov) Date: Mon, 11 Jun 2018 14:32:30 +0000 Subject: Need /24 (arin) asap In-Reply-To: <400c8465-767d-c0d9-e293-10289567868c@shout.net> References: <400c8465-767d-c0d9-e293-10289567868c@shout.net> Message-ID: <8fdb387f0b5f4457ad32afc90be876c3@imaginesoftware.com> Hi Bryan and all, Could you please recommend few places or vendors to check on cleanliness? Thanks! -Stan 646-827-4466 -----Original Message----- From: Bryan Holloway Sent: Monday, June 11, 2018 10:31 AM To: Stan Ouchakov ; nanog at nanog.org Subject: Re: Need /24 (arin) asap We've had good results working with Addrex. I would still strongly recommend you do your due diligence for "cleanliness". On 6/8/18 1:17 PM, Stan Ouchakov wrote: > Hi, > > Can anyone recommend transfer market brokers for ipv4 addresses? Need clean /24 asap. ARIN's waiting list is too long... > > Thanks! > > > -Stan > From owen at delong.com Mon Jun 11 14:45:21 2018 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Jun 2018 07:45:21 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: I find lots of people are using either 6connect or InfoBlox. YMMV. Both have good IPv6 support. Owen > On Jun 11, 2018, at 07:07 , Steve Mikulasik wrote: > > PHPIpam, but I do find there to be a lack of current documentation. From cb.list6 at gmail.com Mon Jun 11 15:21:48 2018 From: cb.list6 at gmail.com (Ca By) Date: Mon, 11 Jun 2018 08:21:48 -0700 Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov wrote: > Hi, > > Can anyone recommend transfer market brokers for ipv4 addresses? Need > clean /24 asap. ARIN's waiting list is too long... > > Thanks! > > > -Stan > > Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6 https://code.facebook.com/posts/635039943508824/how-ipv6-deployment-is-growing-in-u-s-and-other-countries/ And Akaimai reports 80% of mobiles https://blogs.akamai.com/2018/06/six-years-since-world-ipv6-launch-entering-the-majority-phases.html And they both report ipv6 is faster / better. From C-Mack.McBride at charter.com Mon Jun 11 15:25:19 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Mon, 11 Jun 2018 15:25:19 +0000 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: <4c1b1904fe124398bab9b5168540f7dd@SC58MEXGP032.CORP.CHARTERCOM.com> Using BT Diamond IPControl. For a larger provider with a lot of blocks and multiple groups using IP space you can't beat it. It has a lot of enterprise features that others lack such as automation call-outs and overlapping space allocations. If you can afford it, you will not go wrong. It really is the great. I have also worked with spreadsheets, homegrown systems, 6connect and a few others. If you are managing more than a thousand IPs allocations spreadsheets are not manageable for IPv4. Structured IPv6 can be managed out of spreadsheets with little to no issues well beyond that since it is structured. 6connect is better than infoblox in my opinion but everyone has a different style of IP management. If you are going for free or low cost there are plenty out there but they don't have the features of more expensive options. +1 for a generic number management system, but I haven't seen such a thing. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong Sent: Monday, June 11, 2018 8:45 AM To: Steve Mikulasik Cc: NANOG Subject: Re: What are people using for IPAM these days? I find lots of people are using either 6connect or InfoBlox. YMMV. Both have good IPv6 support. Owen > On Jun 11, 2018, at 07:07 , Steve Mikulasik wrote: > > PHPIpam, but I do find there to be a lack of current documentation. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From bryan at shout.net Mon Jun 11 15:41:51 2018 From: bryan at shout.net (Bryan Holloway) Date: Mon, 11 Jun 2018 10:41:51 -0500 Subject: Need /24 (arin) asap In-Reply-To: <8fdb387f0b5f4457ad32afc90be876c3@imaginesoftware.com> References: <400c8465-767d-c0d9-e293-10289567868c@shout.net> <8fdb387f0b5f4457ad32afc90be876c3@imaginesoftware.com> Message-ID: https://www.talosintelligence.com/reputation_center ... is a good place to start. Be sure to see who the previous owner was, and where, etc. ... You can spot-check the various RBLs to see if any particular IPs are black-listed. http://www.anti-abuse.org/multi-rbl-check/ On 6/11/18 9:32 AM, Stan Ouchakov wrote: > Hi Bryan and all, > > Could you please recommend few places or vendors to check on cleanliness? > > Thanks! > > -Stan > 646-827-4466 > > > -----Original Message----- > From: Bryan Holloway > Sent: Monday, June 11, 2018 10:31 AM > To: Stan Ouchakov ; nanog at nanog.org > Subject: Re: Need /24 (arin) asap > > We've had good results working with Addrex. > > I would still strongly recommend you do your due diligence for "cleanliness". > > > On 6/8/18 1:17 PM, Stan Ouchakov wrote: >> Hi, >> >> Can anyone recommend transfer market brokers for ipv4 addresses? Need clean /24 asap. ARIN's waiting list is too long... >> >> Thanks! >> >> >> -Stan >> From emille at abccommunications.com Mon Jun 11 16:05:27 2018 From: emille at abccommunications.com (Emille Blanc) Date: Mon, 11 Jun 2018 09:05:27 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D6B672CB5@exchange> +1 for PHPIPAM. It's incredibly easy to modify and follow the code, and very lightweight. The simple import and export options make managing large blocks very easy for us. https://phpipam.net/ -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Mikulasik Sent: Monday, June 11, 2018 7:08 AM To: Mike Lyon; NANOG Subject: RE: What are people using for IPAM these days? PHPIpam, but I do find there to be a lack of current documentation. From michael at wi-fiber.io Mon Jun 11 16:27:04 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Mon, 11 Jun 2018 10:27:04 -0600 Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: For an eyeball network, you cannot count on an IPv6 only network. Because all of your "customers" will complain because they can't get to hulu, or any other ipv4 only eyeball service. You still need the ipv4s to operate a proper network, and good luck figuring out which services are blacklisting your new /24 because the ipv4 space used to be a VPN provider, and the "in" thing to do for these services is to block VPNs. On 11 June 2018 at 09:21, Ca By wrote: > On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov > wrote: > > > Hi, > > > > Can anyone recommend transfer market brokers for ipv4 addresses? Need > > clean /24 asap. ARIN's waiting list is too long... > > > > Thanks! > > > > > > -Stan > > > > Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6 > > https://code.facebook.com/posts/635039943508824/how- > ipv6-deployment-is-growing-in-u-s-and-other-countries/ > > > And Akaimai reports 80% of mobiles > > https://blogs.akamai.com/2018/06/six-years-since-world-ipv6- > launch-entering-the-majority-phases.html > > > And they both report ipv6 is faster / better. > From patrick at ianai.net Mon Jun 11 16:31:36 2018 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 Jun 2018 12:31:36 -0400 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: While there are many good options, I prefer 6Connect personally. Lots of hooks to let you automate things (not just which device has which IP address, much more), cheap as hell, and support is unbeatable. -- TTFN, patrick > On Jun 11, 2018, at 10:45, Owen DeLong wrote: > > I find lots of people are using either 6connect or InfoBlox. > > YMMV. Both have good IPv6 support. > > Owen > > >> On Jun 11, 2018, at 07:07 , Steve Mikulasik wrote: >> >> PHPIpam, but I do find there to be a lack of current documentation. From valdis.kletnieks at vt.edu Mon Jun 11 16:42:50 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 11 Jun 2018 12:42:50 -0400 Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: <30492.1528735370@turing-police.cc.vt.edu> On Mon, 11 Jun 2018 10:27:04 -0600, Michael Crapse said: > For an eyeball network, you cannot count on an IPv6 only network. Because > all of your "customers" will complain because they can't get to hulu, or > any other ipv4 only eyeball service. You still need the ipv4s to operate a > proper network, and good luck figuring out which services are blacklisting > your new /24 because the ipv4 space used to be a VPN provider, and the "in" > thing to do for these services is to block VPNs. Of course, figuring out how to run dual-stack for those eyeballs is still a net win - because every content that *does* do IPv6 is that many fewer packets that you have to cram through that CGNAT. (My laptop currently has a global IPv6 address and a CGNAT'ed IPv4 address. In the last 3 hours, I've moved 90G on IPv4, and 322G on IPv6.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From cb.list6 at gmail.com Mon Jun 11 16:50:55 2018 From: cb.list6 at gmail.com (Ca By) Date: Mon, 11 Jun 2018 09:50:55 -0700 Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: On Mon, Jun 11, 2018 at 9:27 AM, Michael Crapse wrote: > For an eyeball network, you cannot count on an IPv6 only network. Because > all of your "customers" will complain because they can't get to hulu, or > any other ipv4 only eyeball service. You still need the ipv4s to operate a > proper network, and good luck figuring out which services are blacklisting > your new /24 because the ipv4 space used to be a VPN provider, and the "in" > thing to do for these services is to block VPNs. > There are many IPv6-only eyeball networks. Definitely many examples in wireless (T-Mobile, Sprint, BT ) and wireline (DT with DS-Lite in Germany, Orange Poland ...) and even more where IPv4 NAT44 + IPv6 is used. Just saying, having ipv6 hedges a lot of risk associate with blacklisting and translation related overhead and potentially scale and cost of IPv4 addresses. > > > On 11 June 2018 at 09:21, Ca By wrote: > >> On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov >> wrote: >> >> > Hi, >> > >> > Can anyone recommend transfer market brokers for ipv4 addresses? Need >> > clean /24 asap. ARIN's waiting list is too long... >> > >> > Thanks! >> > >> > >> > -Stan >> > >> > Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6 >> >> https://code.facebook.com/posts/635039943508824/how-ipv6- >> deployment-is-growing-in-u-s-and-other-countries/ >> >> >> And Akaimai reports 80% of mobiles >> >> https://blogs.akamai.com/2018/06/six-years-since-world-ipv6- >> launch-entering-the-majority-phases.html >> >> >> And they both report ipv6 is faster / better. >> > > From michael at wi-fiber.io Mon Jun 11 16:56:45 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Mon, 11 Jun 2018 10:56:45 -0600 Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: Never do i suggest to not have ipv6! Simply that no matter what, You still have to traverse to ipv4 when you exit your ipv6 network onto ipv4 only services. What IPv4 addresses are you going to use for the NAT64, or 464xlat, or even the business customers that require static IPv4 addresses? Someone made a statement that getting more ipv6 would solve OP's problem of finding more clean ipv4 space On 11 June 2018 at 10:50, Ca By wrote: > > > On Mon, Jun 11, 2018 at 9:27 AM, Michael Crapse > wrote: > >> For an eyeball network, you cannot count on an IPv6 only network. Because >> all of your "customers" will complain because they can't get to hulu, or >> any other ipv4 only eyeball service. You still need the ipv4s to operate a >> proper network, and good luck figuring out which services are blacklisting >> your new /24 because the ipv4 space used to be a VPN provider, and the "in" >> thing to do for these services is to block VPNs. >> > > There are many IPv6-only eyeball networks. Definitely many examples in > wireless (T-Mobile, Sprint, BT ) and wireline (DT with DS-Lite in Germany, > Orange Poland ...) and even more where IPv4 NAT44 + IPv6 is used. Just > saying, having ipv6 hedges a lot of risk associate with blacklisting and > translation related overhead and potentially scale and cost of IPv4 > addresses. > > >> >> >> On 11 June 2018 at 09:21, Ca By wrote: >> >>> On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov >> > >>> wrote: >>> >>> > Hi, >>> > >>> > Can anyone recommend transfer market brokers for ipv4 addresses? Need >>> > clean /24 asap. ARIN's waiting list is too long... >>> > >>> > Thanks! >>> > >>> > >>> > -Stan >>> > >>> > Meanwhile, FB reports that 75% of mobiles in the USA reach them via >>> ipv6 >>> >>> https://code.facebook.com/posts/635039943508824/how-ipv6-dep >>> loyment-is-growing-in-u-s-and-other-countries/ >>> >>> >>> And Akaimai reports 80% of mobiles >>> >>> https://blogs.akamai.com/2018/06/six-years-since-world-ipv6- >>> launch-entering-the-majority-phases.html >>> >>> >>> And they both report ipv6 is faster / better. >>> >> >> > From nanog at ics-il.net Mon Jun 11 16:58:25 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 11 Jun 2018 11:58:25 -0500 (CDT) Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: <1980367315.5048.1528736301769.JavaMail.mhammett@ThunderFuck> *nods* Having v6 does solve a lot, but the ones that are difficult to work with in v4 are still using v4, so you still have problems. I think those experiences are ones felt only by small to medium service providers. Large carriers, academia, hosting\datacenter, etc. don't really have those problems. They do have different problems, but they're fairly well known problems with processes laid out on how to deal with it. See my thread from a few weeks ago calling on people doing IP reputation or any sort of geolocation, filtering, blocking, etc. being more transparent. There are ISPs that have tried everything short of driving to the content provider's location and demanding resolution. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ca By" To: "Michael Crapse" Cc: nanog at nanog.org Sent: Monday, June 11, 2018 11:50:55 AM Subject: Re: Need /24 (arin) asap On Mon, Jun 11, 2018 at 9:27 AM, Michael Crapse wrote: > For an eyeball network, you cannot count on an IPv6 only network. Because > all of your "customers" will complain because they can't get to hulu, or > any other ipv4 only eyeball service. You still need the ipv4s to operate a > proper network, and good luck figuring out which services are blacklisting > your new /24 because the ipv4 space used to be a VPN provider, and the "in" > thing to do for these services is to block VPNs. > There are many IPv6-only eyeball networks. Definitely many examples in wireless (T-Mobile, Sprint, BT ) and wireline (DT with DS-Lite in Germany, Orange Poland ...) and even more where IPv4 NAT44 + IPv6 is used. Just saying, having ipv6 hedges a lot of risk associate with blacklisting and translation related overhead and potentially scale and cost of IPv4 addresses. > > > On 11 June 2018 at 09:21, Ca By wrote: > >> On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov >> wrote: >> >> > Hi, >> > >> > Can anyone recommend transfer market brokers for ipv4 addresses? Need >> > clean /24 asap. ARIN's waiting list is too long... >> > >> > Thanks! >> > >> > >> > -Stan >> > >> > Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6 >> >> https://code.facebook.com/posts/635039943508824/how-ipv6- >> deployment-is-growing-in-u-s-and-other-countries/ >> >> >> And Akaimai reports 80% of mobiles >> >> https://blogs.akamai.com/2018/06/six-years-since-world-ipv6- >> launch-entering-the-majority-phases.html >> >> >> And they both report ipv6 is faster / better. >> > > From C-Mack.McBride at charter.com Mon Jun 11 17:19:02 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Mon, 11 Jun 2018 17:19:02 +0000 Subject: Need /24 (arin) asap In-Reply-To: <1980367315.5048.1528736301769.JavaMail.mhammett@ThunderFuck> References: <1980367315.5048.1528736301769.JavaMail.mhammett@ThunderFuck> Message-ID: <0fc52d6357b84df48242d8f207d95fc1@SC58MEXGP032.CORP.CHARTERCOM.com> Large providers still have to deal with geolocation, ip reputation etc. We just have to deal with it on an exponentially larger scale. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Monday, June 11, 2018 10:58 AM Cc: nanog at nanog.org Subject: Re: Need /24 (arin) asap *nods* Having v6 does solve a lot, but the ones that are difficult to work with in v4 are still using v4, so you still have problems. I think those experiences are ones felt only by small to medium service providers. Large carriers, academia, hosting\datacenter, etc. don't really have those problems. They do have different problems, but they're fairly well known problems with processes laid out on how to deal with it. See my thread from a few weeks ago calling on people doing IP reputation or any sort of geolocation, filtering, blocking, etc. being more transparent. There are ISPs that have tried everything short of driving to the content provider's location and demanding resolution. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ca By" To: "Michael Crapse" Cc: nanog at nanog.org Sent: Monday, June 11, 2018 11:50:55 AM Subject: Re: Need /24 (arin) asap On Mon, Jun 11, 2018 at 9:27 AM, Michael Crapse wrote: > For an eyeball network, you cannot count on an IPv6 only network. > Because all of your "customers" will complain because they can't get > to hulu, or any other ipv4 only eyeball service. You still need the > ipv4s to operate a proper network, and good luck figuring out which > services are blacklisting your new /24 because the ipv4 space used to be a VPN provider, and the "in" > thing to do for these services is to block VPNs. > There are many IPv6-only eyeball networks. Definitely many examples in wireless (T-Mobile, Sprint, BT ) and wireline (DT with DS-Lite in Germany, Orange Poland ...) and even more where IPv4 NAT44 + IPv6 is used. Just saying, having ipv6 hedges a lot of risk associate with blacklisting and translation related overhead and potentially scale and cost of IPv4 addresses. > > > On 11 June 2018 at 09:21, Ca By wrote: > >> On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov >> wrote: >> >> > Hi, >> > >> > Can anyone recommend transfer market brokers for ipv4 addresses? Need >> > clean /24 asap. ARIN's waiting list is too long... >> > >> > Thanks! >> > >> > >> > -Stan >> > >> > Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6 >> >> https://code.facebook.com/posts/635039943508824/how-ipv6- >> deployment-is-growing-in-u-s-and-other-countries/ >> >> >> And Akaimai reports 80% of mobiles >> >> https://blogs.akamai.com/2018/06/six-years-since-world-ipv6- >> launch-entering-the-majority-phases.html >> >> >> And they both report ipv6 is faster / better. >> > > E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From nanog at ics-il.net Mon Jun 11 17:22:57 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 11 Jun 2018 12:22:57 -0500 (CDT) Subject: Need /24 (arin) asap In-Reply-To: <0fc52d6357b84df48242d8f207d95fc1@SC58MEXGP032.CORP.CHARTERCOM.com> References: <1980367315.5048.1528736301769.JavaMail.mhammett@ThunderFuck> <0fc52d6357b84df48242d8f207d95fc1@SC58MEXGP032.CORP.CHARTERCOM.com> Message-ID: <1789334271.5098.1528737776079.JavaMail.mhammett@ThunderFuck> True, but a call or e-mail from Charter (to Hulu or whomever is being obstinate this week) is more like to get treated expeditiously than Main Street ISP. I should have restricted that to eyeballs. Big eyeballs are likely in yet another imaginary category. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mack McBride" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Monday, June 11, 2018 12:19:02 PM Subject: RE: Need /24 (arin) asap Large providers still have to deal with geolocation, ip reputation etc. We just have to deal with it on an exponentially larger scale. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Monday, June 11, 2018 10:58 AM Cc: nanog at nanog.org Subject: Re: Need /24 (arin) asap *nods* Having v6 does solve a lot, but the ones that are difficult to work with in v4 are still using v4, so you still have problems. I think those experiences are ones felt only by small to medium service providers. Large carriers, academia, hosting\datacenter, etc. don't really have those problems. They do have different problems, but they're fairly well known problems with processes laid out on how to deal with it. See my thread from a few weeks ago calling on people doing IP reputation or any sort of geolocation, filtering, blocking, etc. being more transparent. There are ISPs that have tried everything short of driving to the content provider's location and demanding resolution. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ca By" To: "Michael Crapse" Cc: nanog at nanog.org Sent: Monday, June 11, 2018 11:50:55 AM Subject: Re: Need /24 (arin) asap On Mon, Jun 11, 2018 at 9:27 AM, Michael Crapse wrote: > For an eyeball network, you cannot count on an IPv6 only network. > Because all of your "customers" will complain because they can't get > to hulu, or any other ipv4 only eyeball service. You still need the > ipv4s to operate a proper network, and good luck figuring out which > services are blacklisting your new /24 because the ipv4 space used to be a VPN provider, and the "in" > thing to do for these services is to block VPNs. > There are many IPv6-only eyeball networks. Definitely many examples in wireless (T-Mobile, Sprint, BT ) and wireline (DT with DS-Lite in Germany, Orange Poland ...) and even more where IPv4 NAT44 + IPv6 is used. Just saying, having ipv6 hedges a lot of risk associate with blacklisting and translation related overhead and potentially scale and cost of IPv4 addresses. > > > On 11 June 2018 at 09:21, Ca By wrote: > >> On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov >> wrote: >> >> > Hi, >> > >> > Can anyone recommend transfer market brokers for ipv4 addresses? Need >> > clean /24 asap. ARIN's waiting list is too long... >> > >> > Thanks! >> > >> > >> > -Stan >> > >> > Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6 >> >> https://code.facebook.com/posts/635039943508824/how-ipv6- >> deployment-is-growing-in-u-s-and-other-countries/ >> >> >> And Akaimai reports 80% of mobiles >> >> https://blogs.akamai.com/2018/06/six-years-since-world-ipv6- >> launch-entering-the-majority-phases.html >> >> >> And they both report ipv6 is faster / better. >> > > E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From brett at the-watsons.org Mon Jun 11 19:18:46 2018 From: brett at the-watsons.org (Brett Watson) Date: Mon, 11 Jun 2018 12:18:46 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: <3FFB413D-660C-4595-B6B3-D88E4656D775@the-watsons.org> > On Jun 11, 2018, at 9:31 AM, Patrick W. Gilmore wrote: > > While there are many good options, I prefer 6Connect personally. Lots of hooks to let you automate things (not just which device has which IP address, much more), cheap as hell, and support is unbeatable. Indeed, 6connect is awesome. Infoblox is great but in this forum, I doubt anyone will be using the DNS/DHCP and threat feed components of the platform (it’s not built for very large provider space). -b From surfer at mauigateway.com Mon Jun 11 20:40:06 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 11 Jun 2018 13:40:06 -0700 Subject: What are people using for IPAM these days? Message-ID: <20180611134006.D25631A5@m0117567.ppops.net> --- C-Mack.McBride at charter.com wrote: From: "McBride, Mack" If you are managing more than a thousand IPs allocations spreadsheets are not manageable for IPv4. ----------------------------------------- I managed a /15, two /16s and several /24s (so, well over a quarter million IPs) on a spreadsheet for years. So, that's an 'it depends' answer. scott From azahed at gmail.com Mon Jun 11 20:26:21 2018 From: azahed at gmail.com (Aref Z) Date: Mon, 11 Jun 2018 16:26:21 -0400 Subject: What are people using for IPAM these days? In-Reply-To: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D6B672CB5@exchange> References: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D6B672CB5@exchange> Message-ID: +1 for phpipam here as well. Allows decent amount of customization as well since code is opensource. Used it in production for managing heavy amount of provisioning/testing. Integrates with pdns well if required. On Mon, Jun 11, 2018 at 12:07 PM Emille Blanc wrote: > +1 for PHPIPAM. > It's incredibly easy to modify and follow the code, and very lightweight. > The simple import and export options make managing large blocks very easy > for us. > > https://phpipam.net/ > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Mikulasik > Sent: Monday, June 11, 2018 7:08 AM > To: Mike Lyon; NANOG > Subject: RE: What are people using for IPAM these days? > > PHPIpam, but I do find there to be a lack of current documentation. > From ipgoddess at gmail.com Mon Jun 11 20:27:18 2018 From: ipgoddess at gmail.com (Stacy Hughes) Date: Mon, 11 Jun 2018 13:27:18 -0700 Subject: What are people using for IPAM these days? In-Reply-To: <3FFB413D-660C-4595-B6B3-D88E4656D775@the-watsons.org> References: <3FFB413D-660C-4595-B6B3-D88E4656D775@the-watsons.org> Message-ID: <52E03A62-4EC6-4B14-9182-46B03D78FE1F@gmail.com> I prefer 6Connect's ProVision tool as well. https://www.6connect.com/ipam/ You can't beat it for ease of import, and management of your space. Emphasis on ease and also accuracy. The filtering options allow for faster lookups and add/delete customers and interfaces, very important when one is dealing with a global network. Check it out! Stacy IP Goddess :) > On Jun 11, 2018, at 12:18 PM, Brett Watson wrote: > > >> On Jun 11, 2018, at 9:31 AM, Patrick W. Gilmore wrote: >> >> While there are many good options, I prefer 6Connect personally. Lots of hooks to let you automate things (not just which device has which IP address, much more), cheap as hell, and support is unbeatable. > > Indeed, 6connect is awesome. Infoblox is great but in this forum, I doubt anyone will be using the DNS/DHCP and threat feed components of the platform (it’s not built for very large provider space). > > -b From surfer at mauigateway.com Mon Jun 11 21:16:56 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 11 Jun 2018 14:16:56 -0700 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap Message-ID: <20180611141656.D25636BB@m0117567.ppops.net> --- cb.list6 at gmail.com wrote: From: Ca By > Meanwhile, FB reports that 75% of mobiles in the USA > reach them via ipv6 > > And Akaimai reports 80% of mobiles And they both report ipv6 is faster / better. ---------------------------------------- Hmm... Faster and better? The links seem to be an IPv6 cheerleader write up. I looked at the URLs and the URLs one pointed to and pulled out everything related to IPv6 being faster/better. Akamai URL: "For dual-stacked hostnames we typically see higher average estimated throughput over IPv6 than over IPv4. Some of this may be due to IPv6-connected users being correlated with better connectivity, but over half of dual-stacked hostnames (weighted by daily bytes delivered) have IPv6 estimated throughput at least 50% faster than IPv4, and 90% of these hostnames have the IPv6 estimated throughput at least 10% faster than IPv4." FB URL: "People using Facebook services typically see better performance over IPv6..." and it points to https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board which says: "We’ve long been anticipating the exhaustion of IPv in favor of the speed and performance benefits of IPv6." "We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6." I'd sure like to see how they came up with these numbers in a technically oriented paper. There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols. scott From matt at netfire.net Mon Jun 11 21:22:10 2018 From: matt at netfire.net (Matt Harris) Date: Mon, 11 Jun 2018 16:22:10 -0500 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <20180611141656.D25636BB@m0117567.ppops.net> References: <20180611141656.D25636BB@m0117567.ppops.net> Message-ID: On Mon, Jun 11, 2018 at 4:16 PM, Scott Weeks wrote: > Hmm... Faster and better? > > The links seem to be an IPv6 cheerleader write up. > I looked at the URLs and the URLs one pointed to and > pulled out everything related to IPv6 being > faster/better. > > Is it possible that simply having a much smaller routing table overall in terms of sheer number of prefixes in the DFZ has a positive performance impact on passing packets, which coupled with the fact that implementations may be routed better/more efficiently due to a lack of "legacy cruft" creates a better experience for many packets? Just a theory/hypothesis with no data to back it up. From job at instituut.net Mon Jun 11 21:28:16 2018 From: job at instituut.net (Job Snijders) Date: Mon, 11 Jun 2018 21:28:16 +0000 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> Message-ID: I suspect that this may not be an apples to apples comparison. Perhaps lack of IPv6 is more prevalent in rural areas with poorer connectivity to the rest of the Internet? Perhaps both these CDNs serve content for different types of devices over the different AFIs (maybe old mediaboxes with a slow cpu prefer IPv4?). Perhaps networks that deploy IPv6 are more likely to allow and accommodate on-net caches? I theorize that the described speed difference between IPv4 and IPv6 is an artifact of how the data is analysed rather than an architectural speed difference between the protocols themselves. Kind regards, Job From rubensk at gmail.com Mon Jun 11 21:34:58 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 11 Jun 2018 18:34:58 -0300 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> Message-ID: On Mon, Jun 11, 2018 at 6:29 PM Job Snijders wrote: > I suspect that this may not be an apples to apples comparison. > > Perhaps lack of IPv6 is more prevalent in rural areas with poorer > connectivity to the rest of the Internet? Perhaps both these CDNs > serve content for different types of devices over the different AFIs > (maybe old mediaboxes with a slow cpu prefer IPv4?). Perhaps networks > that deploy IPv6 are more likely to allow and accommodate on-net > caches? > > I theorize that the described speed difference between IPv4 and IPv6 > is an artifact of how the data is analysed rather than an > architectural speed difference between the protocols themselves. > > Besides the data bias that could indeed exist, I noticed many deployed traffic shapers not supporting IPV6, and imagine that some traffic engineering is currently being focused on IPv4 traffic. So even the protocol themselves having comparable performance, IPv6 bandwidth could be smoother than IPv4 bandwidth for some users. Perhaps instead of looking at global averages, we could look at speed comparison for dual-stacked users, like in how many of them see better or worse performance with v4/v6. Rubens From cb.list6 at gmail.com Mon Jun 11 22:03:30 2018 From: cb.list6 at gmail.com (Ca By) Date: Mon, 11 Jun 2018 15:03:30 -0700 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> Message-ID: On Mon, Jun 11, 2018 at 2:29 PM Job Snijders wrote: > I suspect that this may not be an apples to apples comparison. > > Perhaps lack of IPv6 is more prevalent in rural areas with poorer > connectivity to the rest of the Internet? Perhaps both these CDNs > serve content for different types of devices over the different AFIs > (maybe old mediaboxes with a slow cpu prefer IPv4?). Perhaps networks > that deploy IPv6 are more likely to allow and accommodate on-net > caches? > > I theorize that the described speed difference between IPv4 and IPv6 > is an artifact of how the data is analysed rather than an > architectural speed difference between the protocols themselves. > > Kind regards, > > Job A similar take, is that big eyeballs (tmobile, comcast, sprint, att, verizon wireless) and big content (goog, fb, akamai, netflix) are ipv6. Whats left on ipv4 is the long tail of people asking for help on how to buy a /24 > From kmedcalf at dessus.com Mon Jun 11 22:05:25 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 11 Jun 2018 16:05:25 -0600 Subject: Need /24 (arin) asap In-Reply-To: Message-ID: Neither seem to work without disabling security first. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bryan >Holloway >Sent: Monday, 11 June, 2018 09:42 >To: Stan Ouchakov; nanog at nanog.org >Subject: Re: Need /24 (arin) asap > >https://www.talosintelligence.com/reputation_center > >... is a good place to start. > >Be sure to see who the previous owner was, and where, etc. ... > >You can spot-check the various RBLs to see if any particular IPs are >black-listed. > >http://www.anti-abuse.org/multi-rbl-check/ > > >On 6/11/18 9:32 AM, Stan Ouchakov wrote: >> Hi Bryan and all, >> >> Could you please recommend few places or vendors to check on >cleanliness? >> >> Thanks! >> >> -Stan >> 646-827-4466 >> >> >> -----Original Message----- >> From: Bryan Holloway >> Sent: Monday, June 11, 2018 10:31 AM >> To: Stan Ouchakov ; nanog at nanog.org >> Subject: Re: Need /24 (arin) asap >> >> We've had good results working with Addrex. >> >> I would still strongly recommend you do your due diligence for >"cleanliness". >> >> >> On 6/8/18 1:17 PM, Stan Ouchakov wrote: >>> Hi, >>> >>> Can anyone recommend transfer market brokers for ipv4 addresses? >Need clean /24 asap. ARIN's waiting list is too long... >>> >>> Thanks! >>> >>> >>> -Stan >>> From job at instituut.net Mon Jun 11 22:08:18 2018 From: job at instituut.net (Job Snijders) Date: Mon, 11 Jun 2018 22:08:18 +0000 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> Message-ID: On Mon, Jun 11, 2018 at 10:03 PM, Ca By wrote: > A similar take, is that big eyeballs (tmobile, comcast, sprint, att, verizon > wireless) and big content (goog, fb, akamai, netflix) are ipv6. Whats left > on ipv4 is the long tail of people asking for help on how to buy a /24 Joking aside, I suspect that what's left is on the long tail is actually long haul traffic. I'm not aware of any transit provider reporting anything close to the numbers that the CDNs observe in terms of IPv4 / IPv6 percentage split. I posit that the more miles a packet has to travel, the more likely it is to be an IPv4 packet. Kind regards, Job From matt at netfire.net Mon Jun 11 22:10:08 2018 From: matt at netfire.net (Matt Harris) Date: Mon, 11 Jun 2018 17:10:08 -0500 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> Message-ID: On Mon, Jun 11, 2018 at 5:03 PM, Ca By wrote: > > A similar take, is that big eyeballs (tmobile, comcast, sprint, att, > verizon wireless) > There're a lot of big eyeball networks missing from that list. Spectrum biz class, no IPv6, for one. And some big "content"-ish ones, too. Google's cloud service, for example? No IPv6 for VMs you lease from them. And some of the biggest "web hosting providers" in the world still don't have IPv6 deployed, and they host millions if not billions of sites which, individually, have very little traffic, but in aggregate amount to a fair bit. From joelm at bigleaf.net Mon Jun 11 22:15:47 2018 From: joelm at bigleaf.net (Joel Mulkey) Date: Mon, 11 Jun 2018 22:15:47 +0000 Subject: Need /24 (arin) asap In-Reply-To: <8fdb387f0b5f4457ad32afc90be876c3@imaginesoftware.com> References: <400c8465-767d-c0d9-e293-10289567868c@shout.net> <8fdb387f0b5f4457ad32afc90be876c3@imaginesoftware.com> Message-ID: A couple of suggestions on "cleanliness" checking: -Here's a link to a quick-n-dirty Python script I made to check against a bunch of DNS blacklists: https://bigleafnetworks.box.com/s/ru1lsad2y9yom6q57bok2e3vlyxux2g5 -We once got caught after buying a "clean" block that was (unknowingly to us) on an old un-maintained blocklist called iblocklist. You can search that list here: https://www.iblocklist.com/search.php. They didn't respond to any contact attempts, and yet a number of carriers and hosts out there use those blocklists. In the end we had to re-purpose that block for internal use only and re-number a few customers. Joel Mulkey Founder and CEO Bigleaf Networks - Cloud-first SD-WAN www.bigleaf.net On Jun 11, 2018, at 7:32 AM, Stan Ouchakov > wrote: Hi Bryan and all, Could you please recommend few places or vendors to check on cleanliness? Thanks! -Stan 646-827-4466 -----Original Message----- From: Bryan Holloway > Sent: Monday, June 11, 2018 10:31 AM To: Stan Ouchakov >; nanog at nanog.org Subject: Re: Need /24 (arin) asap We've had good results working with Addrex. I would still strongly recommend you do your due diligence for "cleanliness". On 6/8/18 1:17 PM, Stan Ouchakov wrote: Hi, Can anyone recommend transfer market brokers for ipv4 addresses? Need clean /24 asap. ARIN's waiting list is too long... Thanks! -Stan From jsklein at gmail.com Mon Jun 11 22:19:07 2018 From: jsklein at gmail.com (j k) Date: Mon, 11 Jun 2018 18:19:07 -0400 Subject: Google Email Contact --- security issue Message-ID: Can anyone send me a contact to Gmail security --- off list? Found something bad, that need to be resolved. Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 From nanog at namor.ca Mon Jun 11 22:41:37 2018 From: nanog at namor.ca (J) Date: Mon, 11 Jun 2018 17:41:37 -0500 Subject: What are people using for IPAM these days? In-Reply-To: <1528667343.local-6c68ee1b-f3a6-v1.2.1-7e7447b6@getmailspring.com> References: <93C3D7DD-E6CC-42FA-936F-E4D562804F37@consulintel.es> <1528667343.local-6c68ee1b-f3a6-v1.2.1-7e7447b6@getmailspring.com> Message-ID: <163f1030841.c1c99c1870957.914662921534077797@namor.ca> I was hoping this would get answered more, too. I did a migration to Infoblox from ipplan, just by trawling the database, and figuring out some basic associations, but it heavily depends on how the data was entered, and there's several gotchas anyway. I was hoping there was something more direct. ---- On Sun, 10 Jun 2018 17:04:16 -0500 Dermot Williams <dermot.williams at imaginegroup.ie> wrote ---- Finding a decent, maintained IPAM is one thing, but migrating is another - do any of these have an easy path from IPPlan? Thanks --- Dermot Williams Imagine Communications Group Ltd. On Jun 10 2018, at 10:36 pm, JORDI PALET MARTINEZ via NANOG <nanog at nanog.org> wrote: > > One more open source option: > https://www.gestioip.net/ > > Regards, > Jordi > > > > -----Mensaje original----- > De: NANOG <nanog-bounces at nanog.org> en nombre de Job Snijders <job at instituut.net> > Fecha: domingo, 10 de junio de 2018, 23:01 > Para: Mike Lyon <mike.lyon at gmail.com> > CC: NANOG <nanog at nanog.org> > Asunto: Re: What are people using for IPAM these days? > > Hey Mike, > On Sun, Jun 10, 2018 at 8:48 PM, Mike Lyon <mike.lyon at gmail.com> wrote: > > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > This is always a good thing to review every 2-3 years or so. > My current favorites in the open source world are: > Netbox - https://github.com/digitalocean/netbox > NIPAP - http://spritelink.github.io/NIPAP/ > ed - http://man.openbsd.org/ed ;-) > > Give a few of the IPAMs out there a chance and just see which one > suits your operational procedures best! (Though, using a spreadsheet > file on a shared network drive is still not recommended.) > > Kind regards, > Job > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From brett at the-watsons.org Mon Jun 11 22:45:53 2018 From: brett at the-watsons.org (Brett Watson) Date: Mon, 11 Jun 2018 15:45:53 -0700 Subject: What are people using for IPAM these days? In-Reply-To: <163f1030841.c1c99c1870957.914662921534077797@namor.ca> References: <93C3D7DD-E6CC-42FA-936F-E4D562804F37@consulintel.es> <1528667343.local-6c68ee1b-f3a6-v1.2.1-7e7447b6@getmailspring.com> <163f1030841.c1c99c1870957.914662921534077797@namor.ca> Message-ID: It’s some blood, sweat, and tears. I helped on a migration from IPPlan to Infoblox for a Fortune 5 company years ago, and it was a LOT of data, and it was painful. Lots of CSV exports and scripts to do conversions to get data in a state where it could be imported to Infoblox properly. Ok, it wasn’t *that* horrible but it was a bit of a heavy lift. There’s no magic “import” button. -b > On Jun 11, 2018, at 3:41 PM, J wrote: > > I was hoping this would get answered more, too. > > > > I did a migration to Infoblox from ipplan, just by trawling the database, and figuring out some basic associations, but it heavily depends on how the data was entered, and there's several gotchas anyway. I was hoping there was something more direct. > > > ---- On Sun, 10 Jun 2018 17:04:16 -0500 Dermot Williams <dermot.williams at imaginegroup.ie > wrote ---- > > > > > Finding a decent, maintained IPAM is one thing, but migrating is another - do any of these have an easy path from IPPlan? > > > > Thanks > > --- > > Dermot Williams > > Imagine Communications Group Ltd. > > > > On Jun 10 2018, at 10:36 pm, JORDI PALET MARTINEZ via NANOG <nanog at nanog.org> wrote: > > > > > > One more open source option: > > > https://www.gestioip.net/ > > > > > > Regards, > > > Jordi > > > > > > > > > > > > -----Mensaje original----- > > > De: NANOG <nanog-bounces at nanog.org > en nombre de Job Snijders <job at instituut.net > > > > Fecha: domingo, 10 de junio de 2018, 23:01 > > > Para: Mike Lyon <mike.lyon at gmail.com > > > > CC: NANOG <nanog at nanog.org > > > > Asunto: Re: What are people using for IPAM these days? > > > > > > Hey Mike, > > > On Sun, Jun 10, 2018 at 8:48 PM, Mike Lyon <mike.lyon at gmail.com> wrote: > > > > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > > > > > This is always a good thing to review every 2-3 years or so. > > > My current favorites in the open source world are: > > > Netbox - https://github.com/digitalocean/netbox > > > NIPAP - http://spritelink.github.io/NIPAP/ > > > ed - http://man.openbsd.org/ed ;-) > > > > > > Give a few of the IPAMs out there a chance and just see which one > > > suits your operational procedures best! (Though, using a spreadsheet > > > file on a shared network drive is still not recommended.) > > > > > > Kind regards, > > > Job > > > > > > > > > > > > ********************************************** > > > IPv4 is over > > > Are you ready for the new Internet ? > > > http://www.consulintel.es > > > The IPv6 Company > > > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From cb.list6 at gmail.com Tue Jun 12 00:01:24 2018 From: cb.list6 at gmail.com (Ca By) Date: Mon, 11 Jun 2018 17:01:24 -0700 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> Message-ID: On Mon, Jun 11, 2018 at 3:08 PM Job Snijders wrote: > On Mon, Jun 11, 2018 at 10:03 PM, Ca By wrote: > > A similar take, is that big eyeballs (tmobile, comcast, sprint, att, > verizon > > wireless) and big content (goog, fb, akamai, netflix) are ipv6. Whats > left > > on ipv4 is the long tail of people asking for help on how to buy a /24 > > Joking aside, I suspect that what's left is on the long tail is > actually long haul traffic. I'm not aware of any transit provider > reporting anything close to the numbers that the CDNs observe in terms > of IPv4 / IPv6 percentage split. > > I posit that the more miles a packet has to travel, the more likely it > is to be an IPv4 packet. Related. The more miles the traffic travels the more likely it is the long tail ipv4 15% of internet that is not the wales : google, fb, netflix, apple, akamai ... and i will even throw in cloudflare. I hear transit is dead https://blog.apnic.net/2016/10/28/the-death-of-transit/ > > Kind regards, > > Job > From job at instituut.net Tue Jun 12 00:07:34 2018 From: job at instituut.net (Job Snijders) Date: Tue, 12 Jun 2018 00:07:34 +0000 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> Message-ID: <20180612000734.GL50997@vurt.meerval.net> On Mon, Jun 11, 2018 at 05:01:24PM -0700, Ca By wrote: > > I posit that the more miles a packet has to travel, the more likely > > it is to be an IPv4 packet. > > Related. The more miles the traffic travels the more likely it is the > long tail ipv4 15% of internet that is not the wales : google, fb, > netflix, apple, akamai ... and i will even throw in cloudflare. > > I hear transit is dead Well, be that as it may, I'm still going to go to work tomorrow ;-) - Job From C-Mack.McBride at charter.com Tue Jun 12 15:13:49 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Tue, 12 Jun 2018 15:13:49 +0000 Subject: What are people using for IPAM these days? In-Reply-To: <20180611134006.D25631A5@m0117567.ppops.net> References: <20180611134006.D25631A5@m0117567.ppops.net> Message-ID: Allocations, not IPs. And yes if they are reasonably static an excel spreadsheet can go higher. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces+c-mack.mcbride=charter.com at nanog.org] On Behalf Of Scott Weeks Sent: Monday, June 11, 2018 2:40 PM To: nanog at nanog.org Subject: RE: What are people using for IPAM these days? --- C-Mack.McBride at charter.com wrote: From: "McBride, Mack" If you are managing more than a thousand IPs allocations spreadsheets are not manageable for IPv4. ----------------------------------------- I managed a /15, two /16s and several /24s (so, well over a quarter million IPs) on a spreadsheet for years. So, that's an 'it depends' answer. scott E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From ipgoddess at gmail.com Tue Jun 12 15:43:02 2018 From: ipgoddess at gmail.com (Stacy Hughes) Date: Tue, 12 Jun 2018 08:43:02 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: <20180611134006.D25631A5@m0117567.ppops.net> Message-ID: <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> If you start with Excel, down Will It Scale Road, you will be sorry, so very sorry. Especially when it comes to v6. Stacy > On Jun 12, 2018, at 8:13 AM, McBride, Mack wrote: > > Allocations, not IPs. And yes if they are reasonably static an excel spreadsheet can go higher. > > Mack > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+c-mack.mcbride=charter.com at nanog.org] On Behalf Of Scott Weeks > Sent: Monday, June 11, 2018 2:40 PM > To: nanog at nanog.org > Subject: RE: What are people using for IPAM these days? > > > > --- C-Mack.McBride at charter.com wrote: > From: "McBride, Mack" > > If you are managing more than a thousand IPs allocations spreadsheets are not manageable for IPv4. > ----------------------------------------- > > > > I managed a /15, two /16s and several /24s (so, well > over a quarter million IPs) on a spreadsheet for years. > So, that's an 'it depends' answer. > > scott > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From C-Mack.McBride at charter.com Tue Jun 12 17:17:52 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Tue, 12 Jun 2018 17:17:52 +0000 Subject: What are people using for IPAM these days? In-Reply-To: <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> Message-ID: <268c60b55fb94d8584fc8350c50c50d7@SC58MEXGP032.CORP.CHARTERCOM.com> Excel does not go down 'Will It Scale Road'. It ignores the stop light and crashes at 'Two People Editing Lane'. Mack -----Original Message----- From: Stacy Hughes [mailto:ipgoddess at gmail.com] Sent: Tuesday, June 12, 2018 9:43 AM To: McBride, Mack Cc: surfer at mauigateway.com; nanog at nanog.org Subject: Re: What are people using for IPAM these days? If you start with Excel, down Will It Scale Road, you will be sorry, so very sorry. Especially when it comes to v6. Stacy > On Jun 12, 2018, at 8:13 AM, McBride, Mack wrote: > > Allocations, not IPs. And yes if they are reasonably static an excel spreadsheet can go higher. > > Mack > > -----Original Message----- > From: NANOG > [mailto:nanog-bounces+c-mack.mcbride=charter.com at nanog.org] On Behalf > Of Scott Weeks > Sent: Monday, June 11, 2018 2:40 PM > To: nanog at nanog.org > Subject: RE: What are people using for IPAM these days? > > > > --- C-Mack.McBride at charter.com wrote: > From: "McBride, Mack" > > If you are managing more than a thousand IPs allocations spreadsheets are not manageable for IPv4. > ----------------------------------------- > > > > I managed a /15, two /16s and several /24s (so, well over a quarter > million IPs) on a spreadsheet for years. > So, that's an 'it depends' answer. > > scott > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From ahebert at pubnix.net Tue Jun 12 18:19:36 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 12 Jun 2018 14:19:36 -0400 Subject: What are people using for IPAM these days? In-Reply-To: <268c60b55fb94d8584fc8350c50c50d7@SC58MEXGP032.CORP.CHARTERCOM.com> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <268c60b55fb94d8584fc8350c50c50d7@SC58MEXGP032.CORP.CHARTERCOM.com> Message-ID: <092f2bdd-95b6-39af-d8e9-18fa522b9298@pubnix.net>     Google Docs =D     (Just to be annoying). ----- 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/12/18 13:17, McBride, Mack wrote: > Excel does not go down 'Will It Scale Road'. > It ignores the stop light and crashes at 'Two People Editing Lane'. > > Mack > > -----Original Message----- > From: Stacy Hughes [mailto:ipgoddess at gmail.com] > Sent: Tuesday, June 12, 2018 9:43 AM > To: McBride, Mack > Cc: surfer at mauigateway.com; nanog at nanog.org > Subject: Re: What are people using for IPAM these days? > > If you start with Excel, down Will It Scale Road, you will be sorry, so very sorry. Especially when it comes to v6. > Stacy > >> On Jun 12, 2018, at 8:13 AM, McBride, Mack wrote: >> >> Allocations, not IPs. And yes if they are reasonably static an excel spreadsheet can go higher. >> >> Mack >> >> -----Original Message----- >> From: NANOG >> [mailto:nanog-bounces+c-mack.mcbride=charter.com at nanog.org] On Behalf >> Of Scott Weeks >> Sent: Monday, June 11, 2018 2:40 PM >> To: nanog at nanog.org >> Subject: RE: What are people using for IPAM these days? >> >> >> >> --- C-Mack.McBride at charter.com wrote: >> From: "McBride, Mack" >> >> If you are managing more than a thousand IPs allocations spreadsheets are not manageable for IPv4. >> ----------------------------------------- >> >> >> >> I managed a /15, two /16s and several /24s (so, well over a quarter >> million IPs) on a spreadsheet for years. >> So, that's an 'it depends' answer. >> >> scott >> E-MAIL CONFIDENTIALITY NOTICE: >> The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. > > From randy at psg.com Tue Jun 12 18:41:34 2018 From: randy at psg.com (Randy Bush) Date: Tue, 12 Jun 2018 11:41:34 -0700 Subject: What are people using for IPAM these days? In-Reply-To: <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> Message-ID: > If you start with Excel, down Will It Scale Road, you will be sorry, > so very sorry. Especially when it comes to v6. emacs! From C-Mack.McBride at charter.com Tue Jun 12 18:41:42 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Tue, 12 Jun 2018 18:41:42 +0000 Subject: What are people using for IPAM these days? In-Reply-To: <092f2bdd-95b6-39af-d8e9-18fa522b9298@pubnix.net> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <268c60b55fb94d8584fc8350c50c50d7@SC58MEXGP032.CORP.CHARTERCOM.com> <092f2bdd-95b6-39af-d8e9-18fa522b9298@pubnix.net> Message-ID: Better than excel at "Two People Editing Lane" Mack -----Original Message----- From: NANOG [mailto:nanog-bounces+c-mack.mcbride=charter.com at nanog.org] On Behalf Of Alain Hebert Sent: Tuesday, June 12, 2018 12:20 PM To: nanog at nanog.org Subject: Re: What are people using for IPAM these days?     Google Docs =D     (Just to be annoying). ----- 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/12/18 13:17, McBride, Mack wrote: > Excel does not go down 'Will It Scale Road'. > It ignores the stop light and crashes at 'Two People Editing Lane'. > > Mack > > -----Original Message----- > From: Stacy Hughes [mailto:ipgoddess at gmail.com] > Sent: Tuesday, June 12, 2018 9:43 AM > To: McBride, Mack > Cc: surfer at mauigateway.com; nanog at nanog.org > Subject: Re: What are people using for IPAM these days? > > If you start with Excel, down Will It Scale Road, you will be sorry, so very sorry. Especially when it comes to v6. > Stacy > >> On Jun 12, 2018, at 8:13 AM, McBride, Mack wrote: >> >> Allocations, not IPs. And yes if they are reasonably static an excel spreadsheet can go higher. >> >> Mack >> >> -----Original Message----- >> From: NANOG >> [mailto:nanog-bounces+c-mack.mcbride=charter.com at nanog.org] On Behalf >> Of Scott Weeks >> Sent: Monday, June 11, 2018 2:40 PM >> To: nanog at nanog.org >> Subject: RE: What are people using for IPAM these days? >> >> >> >> --- C-Mack.McBride at charter.com wrote: >> From: "McBride, Mack" >> >> If you are managing more than a thousand IPs allocations spreadsheets are not manageable for IPv4. >> ----------------------------------------- >> >> >> >> I managed a /15, two /16s and several /24s (so, well over a quarter >> million IPs) on a spreadsheet for years. >> So, that's an 'it depends' answer. >> >> scott >> E-MAIL CONFIDENTIALITY NOTICE: >> The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. > > E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From cma at cmadams.net Tue Jun 12 18:52:05 2018 From: cma at cmadams.net (Chris Adams) Date: Tue, 12 Jun 2018 13:52:05 -0500 Subject: What are people using for IPAM these days? In-Reply-To: References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> Message-ID: <20180612185205.GB18754@cmadams.net> Once upon a time, Randy Bush said: > > If you start with Excel, down Will It Scale Road, you will be sorry, > > so very sorry. Especially when it comes to v6. > > emacs! vim! -- Chris Adams From surfer at mauigateway.com Tue Jun 12 20:10:51 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 12 Jun 2018 13:10:51 -0700 Subject: TEST Help? TEST Message-ID: <20180612131051.D2564BE5@m0117567.ppops.net> Apologies for the noise. Please hit delete... Once again I am not able to send email to the list and have either been moderated off again (for some mistake or some unknown reason why) or something else is going on. Sent email to admins@, but no response, so this is just a test to see if anything gets through. scott From bryan at shout.net Tue Jun 12 23:29:12 2018 From: bryan at shout.net (Bryan Holloway) Date: Tue, 12 Jun 2018 18:29:12 -0500 Subject: What are people using for IPAM these days? In-Reply-To: <20180612185205.GB18754@cmadams.net> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> Message-ID: On 6/12/18 1:52 PM, Chris Adams wrote: > Once upon a time, Randy Bush said: >>> If you start with Excel, down Will It Scale Road, you will be sorry, >>> so very sorry. Especially when it comes to v6. >> >> emacs! > > vim! > ed! From Brian at ampr.org Tue Jun 12 23:56:06 2018 From: Brian at ampr.org (Brian Kantor) Date: Tue, 12 Jun 2018 16:56:06 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> Message-ID: <20180612235606.GA15010@meow.BKantor.net> On Tue, Jun 12, 2018 at 06:29:12PM -0500, Bryan Holloway wrote: > On 6/12/18 1:52 PM, Chris Adams wrote: > > Once upon a time, Randy Bush said: > >>> If you start with Excel, down Will It Scale Road, you will be sorry, > >>> so very sorry. Especially when it comes to v6. > >> > >> emacs! > > > > vim! > > > > ed! TECO! From surfer at mauigateway.com Wed Jun 13 00:01:55 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 12 Jun 2018 17:01:55 -0700 Subject: What are people using for IPAM these days? Message-ID: <20180612170155.D256444B@m0117567.ppops.net> --- C-Mack.McBride at charter.com wrote: From: "McBride, Mack" If you are managing more than a thousand IPs allocations spreadsheets are not manageable for IPv4. ----------------------------------------- --------------------------------- I managed a /15, two /16s and several /24s (so, well over a quarter million IPs) on a spreadsheet for years. So, that's an 'it depends' answer. ---------------------------------- --- C-Mack.McBride at charter.com wrote: From: "McBride, Mack" Allocations, not IPs. And yes if they are reasonably static an excel spreadsheet can go higher. --------------------------------- Yes, an "it depends" answer. But I was well in excess of 1000 IPs. Sure everyone's correct on the limits in a rapidly growing company with lots of churn, but I was responding to the "If you are managing more than a thousand IPs allocations spreadsheets are not manageable for IPv4" comment. scott From surfer at mauigateway.com Wed Jun 13 00:16:56 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 12 Jun 2018 17:16:56 -0700 Subject: FWIW... Re: TEST Help? TEST Message-ID: <20180612171656.D25644D7@m0117567.ppops.net> On 06/12/2018 01:10 PM, Scott Weeks wrote: > > > Apologies for the noise. Please hit delete... ---------------------------------------- Turns out that it's only the "Re: IPv6 faster/better proof?" thread I can't reply to. I still can't. All I wanted to say was: --- cb.list6 at gmail.com wrote: From: Ca By I hear transit is dead https://blog.apnic.net/2016/10/28/the-death-of-transit/ -------------------------------------------- Funny that he also seems to take indirect aim at IPv6: "In this case, then in such a collection of service cones, is there any residual value in a globally consistent address space? If all the traffic flows are constrained to sit within each service cone, then the residual addressing requirement is at best a requirement to uniquely distinguish end points just within the scope of the cone without any particular requirement for network-wide uniqueness " That seems to point to John Day's architecture; RINA: https://www.slideshare.net/ictpristine/rina-introduction-part-i scott From randy at psg.com Wed Jun 13 00:23:14 2018 From: randy at psg.com (Randy Bush) Date: Tue, 12 Jun 2018 17:23:14 -0700 Subject: What are people using for IPAM these days? In-Reply-To: <20180612235606.GA15010@meow.BKantor.net> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> Message-ID: >>> Once upon a time, Randy Bush said: >>>>> If you start with Excel, down Will It Scale Road, you will be sorry, >>>>> so very sorry. Especially when it comes to v6. >>>> >>>> emacs! >>> >>> vim! >>> >> >> ed! > > TECO! cat From valdis.kletnieks at vt.edu Wed Jun 13 03:26:28 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 12 Jun 2018 23:26:28 -0400 Subject: What are people using for IPAM these days? In-Reply-To: References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> Message-ID: <160020.1528860388@turing-police.cc.vt.edu> On Tue, 12 Jun 2018 17:23:14 -0700, Randy Bush said: > >>>> emacs! > >>> vim! > >> ed! > > TECO! > cat IBM 029. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From list at satchell.net Wed Jun 13 03:36:01 2018 From: list at satchell.net (Stephen Satchell) Date: Tue, 12 Jun 2018 20:36:01 -0700 Subject: What are people using for IPAM these days? In-Reply-To: <160020.1528860388@turing-police.cc.vt.edu> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> <160020.1528860388@turing-police.cc.vt.edu> Message-ID: <3f2ed6e8-7fb5-a3b9-807b-8f69975f88ef@satchell.net> On 06/12/2018 08:26 PM, valdis.kletnieks at vt.edu wrote: >>>>>> emacs! >>>>> vim! >>>> ed! >>> TECO! >> cat > IBM 029. Youngster. IBM 026. From rjoffe at centergate.com Wed Jun 13 03:43:07 2018 From: rjoffe at centergate.com (Rodney Joffe) Date: Tue, 12 Jun 2018 20:43:07 -0700 Subject: What are people using for IPAM these days? In-Reply-To: <3f2ed6e8-7fb5-a3b9-807b-8f69975f88ef@satchell.net> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> <160020.1528860388@turing-police.cc.vt.edu> <3f2ed6e8-7fb5-a3b9-807b-8f69975f88ef@satchell.net> Message-ID: > On Jun 12, 2018, at 8:36 PM, Stephen Satchell wrote: > > On 06/12/2018 08:26 PM, valdis.kletnieks at vt.edu wrote: >>>>>>> emacs! >>>>>> vim! >>>>> ed! >>>> TECO! >>> cat >> IBM 029. > > Youngster. IBM 026. Infants! Hollerith (IBM Type 1). I still own it. From mike.lyon at gmail.com Wed Jun 13 04:14:17 2018 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Tue, 12 Jun 2018 21:14:17 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> <160020.1528860388@turing-police.cc.vt.edu> <3f2ed6e8-7fb5-a3b9-807b-8f69975f88ef@satchell.net> Message-ID: <69A429ED-2671-4B67-BDA3-6E894413E0F1@gmail.com> Thank you everyone for all of your input. I’ve decided to use a papyrus scroll with kosher ink for my IPAM. I’ll let y’all know how it goes. Thanks again. -Mike > On Jun 12, 2018, at 20:43, Rodney Joffe wrote: > > > >> On Jun 12, 2018, at 8:36 PM, Stephen Satchell wrote: >> >> On 06/12/2018 08:26 PM, valdis.kletnieks at vt.edu wrote: >>>>>>>> emacs! >>>>>>> vim! >>>>>> ed! >>>>> TECO! >>>> cat >>> IBM 029. >> >> Youngster. IBM 026. > > Infants! Hollerith (IBM Type 1). I still own it. From niels=nanog at bakker.net Wed Jun 13 07:01:10 2018 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Wed, 13 Jun 2018 09:01:10 +0200 Subject: FWIW... Re: TEST Help? TEST In-Reply-To: <20180612171656.D25644D7@m0117567.ppops.net> References: <20180612171656.D25644D7@m0117567.ppops.net> Message-ID: <20180613070110.GE34704@excession.tpb.net> * surfer at mauigateway.com (Scott Weeks) [Wed 13 Jun 2018, 02:17 CEST]: >Turns out that it's only the "Re: IPv6 >faster/better proof?" thread I can't reply to. >I still can't. All I wanted to say was: Then perhaps that thread was killed by the moderators. Please heed the list charter. Also, please get a mail client that generates proper In-Reply-To headers and knows how to quote... it's 2018. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From list-nanog2 at dragon.net Wed Jun 13 12:54:19 2018 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Wed, 13 Jun 2018 06:54:19 -0600 Subject: What are people using for IPAM these days? In-Reply-To: <160020.1528860388@turing-police.cc.vt.edu> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> <160020.1528860388@turing-police.cc.vt.edu> Message-ID: <20180613125419.6C1FA7F0CC2@fafnir.remote.dragon.net> >>>>> emacs! >>>> vim! >>> ed! >> TECO! > cat IPAM? Meh. Why bother? It's all there in your router/switch configs if you need to check it. From C-Mack.McBride at charter.com Wed Jun 13 15:10:50 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Wed, 13 Jun 2018 15:10:50 +0000 Subject: What are people using for IPAM these days? In-Reply-To: <20180613125419.6C1FA7F0CC2@fafnir.remote.dragon.net> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> <160020.1528860388@turing-police.cc.vt.edu> <20180613125419.6C1FA7F0CC2@fafnir.remote.dragon.net> Message-ID: <7ac5febaabde4d26af44f4d71b21c84d@SC58MEXGP032.CORP.CHARTERCOM.com> Stone tablets are far superior when using rfc2549 networks. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Ebersman Sent: Wednesday, June 13, 2018 6:54 AM To: North American Network Operators' Group Subject: Re: What are people using for IPAM these days? >>>>> emacs! >>>> vim! >>> ed! >> TECO! > cat IPAM? Meh. Why bother? It's all there in your router/switch configs if you need to check it. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From jwbensley at gmail.com Wed Jun 13 16:40:22 2018 From: jwbensley at gmail.com (James Bensley) Date: Wed, 13 Jun 2018 17:40:22 +0100 Subject: What are people using for IPAM these days? In-Reply-To: <20180613125419.6C1FA7F0CC2@fafnir.remote.dragon.net> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> <160020.1528860388@turing-police.cc.vt.edu> <20180613125419.6C1FA7F0CC2@fafnir.remote.dragon.net> Message-ID: On 13 June 2018 at 13:54, Paul Ebersman wrote: > IPAM? Meh. > > Why bother? So true - when customers want their IP details why should I, the person they are paying to track this information, spend time looking-up the info they reqeust?! I normally set them up with a login to the core and tell them "look it up yourself you lazy git!". For those that actually believe in "IPAMs" - this is misnomer phrase these days (has been for ages). If you want to do stuff at scale you need a "number" tracking system or "abstract resource that is being 0 and 4096 or between 1 and 65535" etc. We assign VLANs, stacks of VLANs, MPLS labels, stacks of MPLS labels, IPv4 addresses, IPv6 addresses, VPN IDs (pseudowires, VPLS etc.), route targets, route distinguishers, ASNs, logical interface IDs, physical interfaces, and so on. They are all finite resources in the network and all "just numbers". I have made many experiances of people putting a lot of effort into tracking IP addresses only and none of other stuff. I don't know why more people aren't asking for recommendations for a "resource tracker" [1]. Cheers, James. [1] Resource tracker != CMDB. From randy at psg.com Wed Jun 13 18:25:47 2018 From: randy at psg.com (Randy Bush) Date: Wed, 13 Jun 2018 11:25:47 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> <160020.1528860388@turing-police.cc.vt.edu> <3f2ed6e8-7fb5-a3b9-807b-8f69975f88ef@satchell.net> Message-ID: >>>>>>>> emacs! >>>>>>> vim! >>>>>> ed! >>>>> TECO! >>>> cat >>> IBM 029. >> Youngster. IBM 026. > Infants! Hollerith (IBM Type 1). I still own it. but i actually do use emacs From Brian at ampr.org Wed Jun 13 18:38:18 2018 From: Brian at ampr.org (Brian Kantor) Date: Wed, 13 Jun 2018 11:38:18 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> <160020.1528860388@turing-police.cc.vt.edu> <3f2ed6e8-7fb5-a3b9-807b-8f69975f88ef@satchell.net> Message-ID: <20180613183818.GB18830@meow.BKantor.net> On Wed, Jun 13, 2018 at 11:25:47AM -0700, Randy Bush wrote: > >>>>>>>> emacs! > >>>>>>> vim! > >>>>>> ed! > >>>>> TECO! > >>>> cat > >>> IBM 029. > >> Youngster. IBM 026. > > Infants! Hollerith (IBM Type 1). I still own it. > > but i actually do use emacs For IP address management, I use a homebrew Perl web application that is a front end to a postgres database and allows entry, update, deletion and display. There is a 'C' program which acts as a back end, and builds the Bind zone files and the dhcp table from the contents of the database when there is a change in the DB, as sampled every 15 minutes. There is also a batch update program to make multiple changes to the database when that becomes necessary. - Brian From dovid at telecurve.com Wed Jun 13 22:22:54 2018 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 13 Jun 2018 18:22:54 -0400 Subject: Fraud Dept. Contact at T-Mobile Message-ID: Does anyone have a contact and TMobiles Telco fraud department? From cb.list6 at gmail.com Wed Jun 13 22:31:48 2018 From: cb.list6 at gmail.com (Ca By) Date: Wed, 13 Jun 2018 15:31:48 -0700 Subject: Fraud Dept. Contact at T-Mobile In-Reply-To: References: Message-ID: On Wed, Jun 13, 2018 at 3:26 PM Dovid Bender wrote: > Does anyone have a contact and TMobiles Telco fraud department? > abuse at t-mobile.com From jeremy at vcn.com Wed Jun 13 22:38:29 2018 From: jeremy at vcn.com (Jeremy Malli) Date: Wed, 13 Jun 2018 15:38:29 -0700 Subject: What are people using for IPAM these days? In-Reply-To: <20180613183818.GB18830@meow.BKantor.net> References: <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> <160020.1528860388@turing-police.cc.vt.edu> <3f2ed6e8-7fb5-a3b9-807b-8f69975f88ef@satchell.net> <20180613183818.GB18830@meow.BKantor.net> Message-ID: <560ADC1C-7F44-48E9-89E6-211284A7DC17@vcn.com> PHP/Mysql app we wrote a while back for this purpose. Support v4/v6 and we like it :) https://github.com/seankndy/subnetsmngr Jeremy > On Jun 13, 2018, at 11:38 AM, Brian Kantor > wrote: > > On Wed, Jun 13, 2018 at 11:25:47AM -0700, Randy Bush wrote: >>>>>>>>>> emacs! >>>>>>>>> vim! >>>>>>>> ed! >>>>>>> TECO! >>>>>> cat >>>>> IBM 029. >>>> Youngster. IBM 026. >>> Infants! Hollerith (IBM Type 1). I still own it. >> >> but i actually do use emacs > > For IP address management, I use a homebrew Perl web application > that is a front end to a postgres database and allows entry, update, > deletion and display. There is a 'C' program which acts as a back > end, and builds the Bind zone files and the dhcp table from the > contents of the database when there is a change in the DB, as sampled > every 15 minutes. There is also a batch update program to make > multiple changes to the database when that becomes necessary. > - Brian > From eric.kuhnke at gmail.com Wed Jun 13 22:48:34 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 13 Jun 2018 15:48:34 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: Either phpipam or nipap. Both use fairly standard database backends and db schema (usually something as simple as mariadb listenong on localhost only, on the same VM that is the apache2 or nginx + php stack), allowing you to scale up to external tools that do read only queries of the IP database for other purposes. On Sun, Jun 10, 2018 at 1:48 PM, Mike Lyon wrote: > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > Thanks, > Mike > > -- > Mike Lyon > mike.lyon at gmail.com > http://www.linkedin.com/in/mlyon > From surfer at mauigateway.com Wed Jun 13 23:08:24 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 13 Jun 2018 16:08:24 -0700 Subject: FWIW... Re: TEST Help? TEST Message-ID: <20180613160824.D25698C7@m0117567.ppops.net> --- niels=nanog at bakker.net wrote: From: niels=nanog at bakker.net Then perhaps that thread was killed by the moderators. Please heed the list charter. Also, please get a mail client that generates proper In-Reply-To headers and knows how to quote... it's 2018. ----------------------------------------- Don't they tell us if the thread is moderated? Or, do they kill it silently? re: "Please heed the list charter" You mean the one written in clay tablets or: >>>>>>>> emacs! >>>>>>> vim! >>>>>> ed! >>>>> TECO! >>>> cat >>> IBM 029. >> Youngster. IBM 026. > Infants! Hollerith (IBM Type 1). I still own it. There's room for a certain amount of fun here. scott From randy at psg.com Thu Jun 14 00:37:42 2018 From: randy at psg.com (Randy Bush) Date: Wed, 13 Jun 2018 17:37:42 -0700 Subject: Fraud Dept. Contact at T-Mobile In-Reply-To: References: Message-ID: >> Does anyone have a contact and TMobiles Telco fraud department? > abuse at t-mobile.com rofl! From Bryan at bryanfields.net Thu Jun 14 00:44:49 2018 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 13 Jun 2018 20:44:49 -0400 Subject: FWIW... Re: TEST Help? TEST In-Reply-To: <20180613070110.GE34704@excession.tpb.net> References: <20180612171656.D25644D7@m0117567.ppops.net> <20180613070110.GE34704@excession.tpb.net> Message-ID: <5170645d-05a5-3af0-46e5-52dcfc8a50a3@bryanfields.net> On 6/13/18 3:01 AM, niels=nanog at bakker.net wrote: > Also, please get a mail client that generates proper In-Reply-To > headers and knows how to quote... it's 2018. +1 -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From bill at herrin.us Thu Jun 14 01:34:26 2018 From: bill at herrin.us (William Herrin) Date: Wed, 13 Jun 2018 21:34:26 -0400 Subject: FWIW... Re: TEST Help? TEST In-Reply-To: <20180613070110.GE34704@excession.tpb.net> References: <20180612171656.D25644D7@m0117567.ppops.net> <20180613070110.GE34704@excession.tpb.net> Message-ID: On Wed, Jun 13, 2018 at 3:01 AM, wrote: > Also, please get a mail client that generates proper In-Reply-To headers and > knows how to quote... it's 2018. Not even Google with all their brains on tap has mastered the latter half of that request. Why gmail can't manage to wrap your paragraphs and insert greater than signs in front of each word-wrapped line escapes me. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From eric.kuhnke at gmail.com Thu Jun 14 04:59:37 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 13 Jun 2018 21:59:37 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: That is very interesting, scrolling down a bit for the screenshots/examples, it's one of the few IP address management systems that also addresses the OSI layer 1 location/position/racking of equipment. Tools like phpipam only go as far as VLAN assignment. Logical that they built that feature in, considering the hosting/colo/dedicated server ISP it originated at. On Wed, Jun 13, 2018 at 5:29 PM, Jay Christopher < jaychristopher327 at gmail.com> wrote: > Not sure I've seen it mentioned, so will throw NetBox into the mix. > > https://github.com/digitalocean/netbox > > - jay > > On Wed, Jun 13, 2018 at 3:50 PM Eric Kuhnke wrote: > >> Either phpipam or nipap. >> >> Both use fairly standard database backends and db schema (usually >> something >> as simple as mariadb listenong on localhost only, on the same VM that is >> the apache2 or nginx + php stack), allowing you to scale up to external >> tools that do read only queries of the IP database for other purposes. >> >> On Sun, Jun 10, 2018 at 1:48 PM, Mike Lyon wrote: >> >> > Title says it all... Currently using IPPlan, but it is kinda >> antiquated.. >> > >> > Thanks, >> > Mike >> > >> > -- >> > Mike Lyon >> > mike.lyon at gmail.com >> > http://www.linkedin.com/in/mlyon >> > >> > -- > - Jay C. > From james.voip at gmail.com Thu Jun 14 18:56:09 2018 From: james.voip at gmail.com (james jones) Date: Thu, 14 Jun 2018 14:56:09 -0400 Subject: BGP in a containers Message-ID: I am working on an personal experiment and was wondering what is the best option for running BGP in a docker base container. I have seen a lot blogs and docs referencing Quagga. I just want to make sure I am not over looking any other options before I dive in. Any thoughts or suggestions? -James From bruns at 2mbit.com Thu Jun 14 19:00:20 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 14 Jun 2018 13:00:20 -0600 Subject: BGP in a containers In-Reply-To: References: Message-ID: <7abba5dc-dd92-baa3-a6f3-d08f42e19025@2mbit.com> On 6/14/2018 12:56 PM, james jones wrote: > I am working on an personal experiment and was wondering what is the best > option for running BGP in a docker base container. I have seen a lot blogs > and docs referencing Quagga. I just want to make sure I am not over looking > any other options before I dive in. Any thoughts or suggestions? > > -James > *twitches* Please don't let this be an actual thing with something as critical as BGP. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From dovid at telecurve.com Thu Jun 14 19:03:21 2018 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 14 Jun 2018 15:03:21 -0400 Subject: BGP in a containers In-Reply-To: <7abba5dc-dd92-baa3-a6f3-d08f42e19025@2mbit.com> References: <7abba5dc-dd92-baa3-a6f3-d08f42e19025@2mbit.com> Message-ID: I know of a telco that has been doing this it helps them be able to move around containers and not have constantly configure IP's on servers. On Thu, Jun 14, 2018 at 3:00 PM, Brielle Bruns wrote: > On 6/14/2018 12:56 PM, james jones wrote: > >> I am working on an personal experiment and was wondering what is the best >> option for running BGP in a docker base container. I have seen a lot blogs >> and docs referencing Quagga. I just want to make sure I am not over >> looking >> any other options before I dive in. Any thoughts or suggestions? >> >> -James >> >> > *twitches* > > Please don't let this be an actual thing with something as critical as BGP. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From lists at benappy.com Thu Jun 14 19:05:43 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Thu, 14 Jun 2018 21:05:43 +0200 Subject: BGP in a containers In-Reply-To: References: Message-ID: <81534112-AD52-403E-94C9-73C35ED5B847@benappy.com> > On 14 Jun 2018, at 20:56, james jones wrote: > > I am working on an personal experiment and was wondering what is the best > option for running BGP in a docker base container. I have seen a lot blogs > and docs referencing Quagga. I just want to make sure I am not over looking > any other options before I dive in. Any thoughts or suggestions? I guess / hope what you’re trying to achieve is to announce services from the containers using BGP. If this is the case, what you’re looking for is called exabgp. ic From michael at wi-fiber.io Thu Jun 14 19:05:58 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Thu, 14 Jun 2018 13:05:58 -0600 Subject: BGP in a containers In-Reply-To: <7abba5dc-dd92-baa3-a6f3-d08f42e19025@2mbit.com> References: <7abba5dc-dd92-baa3-a6f3-d08f42e19025@2mbit.com> Message-ID: I agree, i hope that this is for testing/testbench purposes only, or only running iBGP, as no one in the world would like for you to be running a public BGP through a docker instance. On 14 June 2018 at 13:00, Brielle Bruns wrote: > On 6/14/2018 12:56 PM, james jones wrote: > >> I am working on an personal experiment and was wondering what is the best >> option for running BGP in a docker base container. I have seen a lot blogs >> and docs referencing Quagga. I just want to make sure I am not over >> looking >> any other options before I dive in. Any thoughts or suggestions? >> >> -James >> >> > *twitches* > > Please don't let this be an actual thing with something as critical as BGP. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From swhyte at gmail.com Thu Jun 14 19:06:35 2018 From: swhyte at gmail.com (Scott Whyte) Date: Thu, 14 Jun 2018 12:06:35 -0700 Subject: BGP in a containers In-Reply-To: References: Message-ID: On 6/14/18 11:56 AM, james jones wrote: > I am working on an personal experiment and was wondering what is the best > option for running BGP in a docker base container. I have seen a lot blogs > and docs referencing Quagga. I just want to make sure I am not over looking > any other options before I dive in. Any thoughts or suggestions? https://docs.cumulusnetworks.com/display/HOSTPACK/Configuring+FRRouting+on+the+Host > > -James > From james.voip at gmail.com Thu Jun 14 19:07:35 2018 From: james.voip at gmail.com (james jones) Date: Thu, 14 Jun 2018 15:07:35 -0400 Subject: BGP in a containers In-Reply-To: <81534112-AD52-403E-94C9-73C35ED5B847@benappy.com> References: <81534112-AD52-403E-94C9-73C35ED5B847@benappy.com> Message-ID: Yes, that's it. On Thu, Jun 14, 2018 at 3:05 PM Michel 'ic' Luczak wrote: > > > On 14 Jun 2018, at 20:56, james jones wrote: > > > > I am working on an personal experiment and was wondering what is the best > > option for running BGP in a docker base container. I have seen a lot > blogs > > and docs referencing Quagga. I just want to make sure I am not over > looking > > any other options before I dive in. Any thoughts or suggestions? > > I guess / hope what you’re trying to achieve is to announce services from > the containers using BGP. If this is the case, what you’re looking for is > called exabgp. > > ic > > > From maxtul at netassist.ua Thu Jun 14 19:10:42 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 14 Jun 2018 22:10:42 +0300 Subject: BGP in a containers In-Reply-To: References: Message-ID: <75f50987-58f3-902d-9af1-47d162ecc26f@netassist.ua> bird is better than quagga! (runs away) ;) 14.06.18 21:56, james jones пише: > I am working on an personal experiment and was wondering what is the best > option for running BGP in a docker base container. I have seen a lot blogs > and docs referencing Quagga. I just want to make sure I am not over looking > any other options before I dive in. Any thoughts or suggestions? > > -James > From jk at ip-clear.de Thu Jun 14 19:09:32 2018 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Thu, 14 Jun 2018 21:09:32 +0200 Subject: BGP in a containers In-Reply-To: References: Message-ID: Have a peak at https://osrg.github.io/gobgp/ and https://github.com/osrg/dockerfiles On 14 Jun 2018, at 20:56, james jones wrote: > I am working on an personal experiment and was wondering what is the best > option for running BGP in a docker base container. I have seen a lot blogs > and docs referencing Quagga. I just want to make sure I am not over looking > any other options before I dive in. Any thoughts or suggestions? > > -James From morrowc.lists at gmail.com Thu Jun 14 19:10:18 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 14 Jun 2018 15:10:18 -0400 Subject: BGP in a containers In-Reply-To: References: <7abba5dc-dd92-baa3-a6f3-d08f42e19025@2mbit.com> Message-ID: there's actually a not insignificant part of the 'network device' world which is in fact just really a container and "quagga" (or similar). James, do you care about being close to a 'cisco like' config world? (quagga) more programmatic? (exa-bgp, gobgp .. a few others) something else? On Thu, Jun 14, 2018 at 3:05 PM Dovid Bender wrote: > I know of a telco that has been doing this it helps them be able to move > around containers and not have constantly configure IP's on servers. > > > > On Thu, Jun 14, 2018 at 3:00 PM, Brielle Bruns wrote: > > > On 6/14/2018 12:56 PM, james jones wrote: > > > >> I am working on an personal experiment and was wondering what is the > best > >> option for running BGP in a docker base container. I have seen a lot > blogs > >> and docs referencing Quagga. I just want to make sure I am not over > >> looking > >> any other options before I dive in. Any thoughts or suggestions? > >> > >> -James > >> > >> > > *twitches* > > > > Please don't let this be an actual thing with something as critical as > BGP. > > > > -- > > Brielle Bruns > > The Summit Open Source Development Group > > http://www.sosdg.org / http://www.ahbl.org > > > From petrus.lt at gmail.com Thu Jun 14 19:12:39 2018 From: petrus.lt at gmail.com (Pierre Emeriaud) Date: Thu, 14 Jun 2018 21:12:39 +0200 Subject: BGP in a containers In-Reply-To: References: Message-ID: 2018-06-14 20:56 GMT+02:00 james jones : > I am working on an personal experiment and was wondering what is the best > option for running BGP in a docker base container. I have seen a lot blogs > and docs referencing Quagga. I just want to make sure I am not over looking > any other options before I dive in. Any thoughts or suggestions? If this is to run bgp to the ToR, this is a nice way do have redundant paths to a server. Exabgp is a nice tool for this, and a colleague of mine developed 'bagpipe' (https://github.com/Orange-OpenSource/bagpipe-bgp) for this, now part of openstack (https://github.com/openstack/networking-bagpipe) but still usable as a standalone daemon. From hugo at slabnet.com Thu Jun 14 19:14:04 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 14 Jun 2018 12:14:04 -0700 Subject: BGP in a containers In-Reply-To: References: <7abba5dc-dd92-baa3-a6f3-d08f42e19025@2mbit.com> Message-ID: <20180614191404.GA12279@bamboo.slabnet.com> This is generally in the context of routing-on-the-host setups. We're using BIRD for that in a kubernetes deployment. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Thu 2018-Jun-14 13:05:58 -0600, Michael Crapse wrote: >I agree, i hope that this is for testing/testbench purposes only, or only >running iBGP, as no one in the world would like for you to be running a >public BGP through a docker instance. > >On 14 June 2018 at 13:00, Brielle Bruns wrote: > >> On 6/14/2018 12:56 PM, james jones wrote: >> >>> I am working on an personal experiment and was wondering what is the best >>> option for running BGP in a docker base container. I have seen a lot blogs >>> and docs referencing Quagga. I just want to make sure I am not over >>> looking >>> any other options before I dive in. Any thoughts or suggestions? >>> >>> -James >>> >>> >> *twitches* >> >> Please don't let this be an actual thing with something as critical as BGP. >> >> -- >> Brielle Bruns >> The Summit Open Source Development Group >> http://www.sosdg.org / http://www.ahbl.org >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From hugo at slabnet.com Thu Jun 14 19:23:55 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 14 Jun 2018 12:23:55 -0700 Subject: BGP in a containers In-Reply-To: References: <81534112-AD52-403E-94C9-73C35ED5B847@benappy.com> Message-ID: <20180614192355.GB12279@bamboo.slabnet.com> re: Exa: Our use case was both on exporting service IPs as well as receiving routes from ToRs. Exa is more geared towards the former than the latter. Rather then working on getting imports and route installation through Exa, we found it simpler with BIRD exporting the service IP from it bound to a loopback to run local healthchecks on the nodes and then have them yank the service IP from the loopback on failing healthchecks in order to stop exporting. But, YMMV etc. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Thu 2018-Jun-14 15:07:35 -0400, james jones wrote: >Yes, that's it. > >On Thu, Jun 14, 2018 at 3:05 PM Michel 'ic' Luczak >wrote: > >> >> > On 14 Jun 2018, at 20:56, james jones wrote: >> > >> > I am working on an personal experiment and was wondering what is the best >> > option for running BGP in a docker base container. I have seen a lot >> blogs >> > and docs referencing Quagga. I just want to make sure I am not over >> looking >> > any other options before I dive in. Any thoughts or suggestions? >> >> I guess / hope what you’re trying to achieve is to announce services from >> the containers using BGP. If this is the case, what you’re looking for is >> called exabgp. >> >> ic >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bcj at lunix.dk Tue Jun 12 18:47:36 2018 From: bcj at lunix.dk (Brian Jeggesen) Date: Tue, 12 Jun 2018 20:47:36 +0200 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: Check out TIPP; http://tipp.tobez.org /Brian søn. 10. jun. 2018 kl. 22.51 skrev Mike Lyon : > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > Thanks, > Mike > > -- > Mike Lyon > mike.lyon at gmail.com > http://www.linkedin.com/in/mlyon > From branto at branto.com Tue Jun 12 22:41:54 2018 From: branto at branto.com (Brant Ian Stevens) Date: Tue, 12 Jun 2018 18:41:54 -0400 Subject: What are people using for IPAM these days? In-Reply-To: <20180612185205.GB18754@cmadams.net> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> Message-ID: <4db96a4a-a739-52e6-5f5a-340e02e9f97a@branto.com> sorry, but nano4lyfe! On 6/12/18 2:52 PM, Chris Adams wrote: > Once upon a time, Randy Bush said: >>> If you start with Excel, down Will It Scale Road, you will be sorry, >>> so very sorry. Especially when it comes to v6. >> emacs! > vim! From epagan47 at gmail.com Tue Jun 12 22:50:01 2018 From: epagan47 at gmail.com (Estevan Pagan) Date: Tue, 12 Jun 2018 15:50:01 -0700 Subject: What are people using for IPAM these days? In-Reply-To: <20180612185205.GB18754@cmadams.net> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> Message-ID: Device42. https://www.device42.com/ On Tue, Jun 12, 2018 at 11:53 AM Chris Adams wrote: > Once upon a time, Randy Bush said: > > > If you start with Excel, down Will It Scale Road, you will be sorry, > > > so very sorry. Especially when it comes to v6. > > > > emacs! > > vim! > -- > Chris Adams > From Ryan.Kearney at carespot.com Wed Jun 13 03:43:04 2018 From: Ryan.Kearney at carespot.com (Ryan Kearney) Date: Wed, 13 Jun 2018 03:43:04 +0000 Subject: What are people using for IPAM these days? In-Reply-To: <3f2ed6e8-7fb5-a3b9-807b-8f69975f88ef@satchell.net> References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> <20180612235606.GA15010@meow.BKantor.net> <160020.1528860388@turing-police.cc.vt.edu>, <3f2ed6e8-7fb5-a3b9-807b-8f69975f88ef@satchell.net> Message-ID: Can we please stop spamming the list with this crap now? > On Jun 12, 2018, at 10:37 PM, Stephen Satchell wrote: > > On 06/12/2018 08:26 PM, valdis.kletnieks at vt.edu wrote: >>>>>>> emacs! >>>>>> vim! >>>>> ed! >>>> TECO! >>> cat >> IBM 029. > > Youngster. IBM 026. From lee.howard at retevia.net Wed Jun 13 11:44:05 2018 From: lee.howard at retevia.net (Lee Howard) Date: Wed, 13 Jun 2018 07:44:05 -0400 Subject: Need /24 (arin) asap In-Reply-To: References: Message-ID: Assuming IPv6+translation, yes, you need IPv4 addresses of Good Repute for the outside; that might requiring constant monitoring, and notifying various content that it's shared address space. It's the same operational problem as CGNAT44, but reduced because half (or more) of your traffic is using unshared IPv6. Among other things, that means you don't need as many IPv4 addresses. "But wait!" you say, because you're clever, "The original poster only wanted a /24. Surely you're not saying you could put less than a /24 outside your CGN (44 or 64) and have it routed?" Maybe the /28 is part of your larger aggregate. Or maybe it's a shared translator, handling, say, eight small companies who only need a /28 each. And yes, you want very careful reputation monitoring in that case, and maybe some effort to prevent things that get one placed on Lists of Addresses of Ill Repute. Sales pitch available on demand. Lee Howard Retevia.net On 06/11/2018 12:56 PM, Michael Crapse wrote: > Never do i suggest to not have ipv6! Simply that no matter what, You still > have to traverse to ipv4 when you exit your ipv6 network onto ipv4 only > services. What IPv4 addresses are you going to use for the NAT64, or > 464xlat, or even the business customers that require static IPv4 addresses? > Someone made a statement that getting more ipv6 would solve OP's problem of > finding more clean ipv4 space > > > On 11 June 2018 at 10:50, Ca By wrote: > >> >> On Mon, Jun 11, 2018 at 9:27 AM, Michael Crapse >> wrote: >> >>> For an eyeball network, you cannot count on an IPv6 only network. Because >>> all of your "customers" will complain because they can't get to hulu, or >>> any other ipv4 only eyeball service. You still need the ipv4s to operate a >>> proper network, and good luck figuring out which services are blacklisting >>> your new /24 because the ipv4 space used to be a VPN provider, and the "in" >>> thing to do for these services is to block VPNs. >>> >> There are many IPv6-only eyeball networks. Definitely many examples in >> wireless (T-Mobile, Sprint, BT ) and wireline (DT with DS-Lite in Germany, >> Orange Poland ...) and even more where IPv4 NAT44 + IPv6 is used. Just >> saying, having ipv6 hedges a lot of risk associate with blacklisting and >> translation related overhead and potentially scale and cost of IPv4 >> addresses. >> >> >>> >>> On 11 June 2018 at 09:21, Ca By wrote: >>> >>>> On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov >>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Can anyone recommend transfer market brokers for ipv4 addresses? Need >>>>> clean /24 asap. ARIN's waiting list is too long... >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> -Stan >>>>> >>>>> Meanwhile, FB reports that 75% of mobiles in the USA reach them via >>>> ipv6 >>>> >>>> https://code.facebook.com/posts/635039943508824/how-ipv6-dep >>>> loyment-is-growing-in-u-s-and-other-countries/ >>>> >>>> >>>> And Akaimai reports 80% of mobiles >>>> >>>> https://blogs.akamai.com/2018/06/six-years-since-world-ipv6- >>>> launch-entering-the-majority-phases.html >>>> >>>> >>>> And they both report ipv6 is faster / better. >>>> >>> From lee.howard at retevia.net Wed Jun 13 11:46:31 2018 From: lee.howard at retevia.net (Lee Howard) Date: Wed, 13 Jun 2018 07:46:31 -0400 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <20180611141656.D25636BB@m0117567.ppops.net> References: <20180611141656.D25636BB@m0117567.ppops.net> Message-ID: <9e2c59eb-2b9a-b68e-76c5-e60531c9a499@retevia.net> On 06/11/2018 05:16 PM, Scott Weeks wrote: > > --- cb.list6 at gmail.com wrote: > From: Ca By > >> Meanwhile, FB reports that 75% of mobiles in the USA >> reach them via ipv6 >> >> And Akaimai reports 80% of mobiles > And they both report ipv6 is faster / better. > ---------------------------------------- Let me grab a few more for you: https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html https://blogs.akamai.com/2016/10/ipv6-at-akamai-edge-2016.html https://www.theregister.co.uk/2016/07/28/ipv6_now_faster_a_fifth_of_the_time which cites an academic paper http://dl.acm.org/citation.cfm?doid=2959424.2959429 by Vaibhav Bajpai and Jürgen Schönwälder https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-kahn/ https://community.infoblox.com/t5/IPv6-CoE-Blog/Can-IPv6-Rally-Be-Faster-than-IPv4-Part-1/ba-p/6419 https://www.nanog.org/meetings/abstract?id=2281 > I'd sure like to see how they came up with these > numbers in a technically oriented paper. Most of the above links explain how they got the numbers. Facebook, in particular, did A/B testing using Mobile Proxygen, which is to say that they configured their mobile app to report performance over both IPv4 and IPv6 from the same handset at the same time. Others, including APNIC's https://stats.labs.apnic.net/v6perf have a browser fetch two objects with unique URLs, one from an IPv4-only server and one from an IPv6-only server, and compare them. >   There > should be no difference, except for no CGN or Happy > Eyeballs working better or something similar.  Am I > missing something?  Same routers; same links; same > RTTs; same interrupt times on servers; same etc, etc > for both protocols. From time to time somebody says, "Okay, maybe it works in practice, but does it work in *theory*?" Busy engineers hardly ever investigate things going inexplicably right. My hypothesis is that the observed difference in performance relates to how mobile networks deploy their transition mechanisms. Those with a dual-stack APN take a native path for IPv6, while using a CGN path for IPv4, which, combined with the Happy Eyeballs head start, might add 501microseconds, which is a ms, which is 15% of 7ms. Those with an IPv6-only APN use a native path for IPv6, while using either a NAT64 for IPv4 (identical performance to CGN) or 464xlat, which requires translation both in the handset and the NAT64; handsets may not be optimized for header translation. However, I have a dozen other hypotheses, and the few experiments I've been able to run have not confirmed any hypothesis. For instance, when one protocol is faster than another on a landline network, hop count is not a correlation (therefore, shorter paths, traffic engineering, etc., are not involved). Lee > > Hmm... Faster and better? > > The links seem to be an IPv6 cheerleader write up. > I looked at the URLs and the URLs one pointed to and > pulled out everything related to IPv6 being > faster/better. > > > Akamai URL: > > "For dual-stacked hostnames we typically see higher > average estimated throughput over IPv6 than over IPv4. > Some of this may be due to IPv6-connected users being > correlated with better connectivity, but over half of > dual-stacked hostnames (weighted by daily bytes > delivered) have IPv6 estimated throughput at least 50% > faster than IPv4, and 90% of these hostnames have the > IPv6 estimated throughput at least 10% faster than > IPv4." > > > > FB URL: > > "People using Facebook services typically see better > performance over IPv6..." > > and it points to > https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board > which says: > > "We’ve long been anticipating the exhaustion of IPv > in favor of the speed and performance benefits of > IPv6." > > "We’ve observed that accessing Facebook can be 10-15 > percent faster over IPv6." > > > I'd sure like to see how they came up with these > numbers in a technically oriented paper. There > should be no difference, except for no CGN or Happy > Eyeballs working better or something similar. Am I > missing something? Same routers; same links; same > RTTs; same interrupt times on servers; same etc, etc > for both protocols. > > scott From luca at digitalocean.com Wed Jun 13 23:26:24 2018 From: luca at digitalocean.com (Luca Salvatore) Date: Wed, 13 Jun 2018 18:26:24 -0500 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: Netbox. Open source IPAM and DCIM built by DigitalOcean https://github.com/digitalocean/netbox On Wed, Jun 13, 2018 at 5:50 PM Eric Kuhnke wrote: > Either phpipam or nipap. > > Both use fairly standard database backends and db schema (usually something > as simple as mariadb listenong on localhost only, on the same VM that is > the apache2 or nginx + php stack), allowing you to scale up to external > tools that do read only queries of the IP database for other purposes. > > On Sun, Jun 10, 2018 at 1:48 PM, Mike Lyon wrote: > > > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > > > Thanks, > > Mike > > > > -- > > Mike Lyon > > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > > > From jaychristopher327 at gmail.com Thu Jun 14 00:29:46 2018 From: jaychristopher327 at gmail.com (Jay Christopher) Date: Wed, 13 Jun 2018 17:29:46 -0700 Subject: What are people using for IPAM these days? In-Reply-To: References: Message-ID: Not sure I've seen it mentioned, so will throw NetBox into the mix. https://github.com/digitalocean/netbox - jay On Wed, Jun 13, 2018 at 3:50 PM Eric Kuhnke wrote: > Either phpipam or nipap. > > Both use fairly standard database backends and db schema (usually something > as simple as mariadb listenong on localhost only, on the same VM that is > the apache2 or nginx + php stack), allowing you to scale up to external > tools that do read only queries of the IP database for other purposes. > > On Sun, Jun 10, 2018 at 1:48 PM, Mike Lyon wrote: > > > Title says it all... Currently using IPPlan, but it is kinda antiquated.. > > > > Thanks, > > Mike > > > > -- > > Mike Lyon > > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > > > -- - Jay C. From vicente.luca at gmail.com Thu Jun 14 19:16:51 2018 From: vicente.luca at gmail.com (Vicente Luca) Date: Thu, 14 Jun 2018 12:16:51 -0700 Subject: BGP in a containers In-Reply-To: <7abba5dc-dd92-baa3-a6f3-d08f42e19025@2mbit.com> References: <7abba5dc-dd92-baa3-a6f3-d08f42e19025@2mbit.com> Message-ID: <2E16D595-63C4-4210-9C8A-0CE52E9540B7@gmail.com> I run BGP (bird) on containers in a high available production environment for supporting multiple kubernetes clusters, among other very critical pieces of my infrastructure. As long as you know what you’re doing and have people that knows how to troubleshoot, it's very reliable. the fact that you’re using containers shouldn’t matter which BGP daemon you will decide using. if you’re comfortable with quagga, containerize quagga. if you like gobgp, use gobgp. they all can be containerized and will work fine if the all the underlying foundation is proper configured. —vicente > On Jun 14, 2018, at 12:00 PM, Brielle Bruns wrote: > > On 6/14/2018 12:56 PM, james jones wrote: >> I am working on an personal experiment and was wondering what is the best >> option for running BGP in a docker base container. I have seen a lot blogs >> and docs referencing Quagga. I just want to make sure I am not over looking >> any other options before I dive in. Any thoughts or suggestions? >> -James > > *twitches* > > Please don't let this be an actual thing with something as critical as BGP. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org From jsage at finchhaven.com Tue Jun 12 23:04:07 2018 From: jsage at finchhaven.com (John Sage) Date: Tue, 12 Jun 2018 16:04:07 -0700 Subject: FWIW... Re: TEST Help? TEST In-Reply-To: <20180612131051.D2564BE5@m0117567.ppops.net> References: <20180612131051.D2564BE5@m0117567.ppops.net> Message-ID: <5B205167.6060008@finchhaven.com> On 06/12/2018 01:10 PM, Scott Weeks wrote: > > > Apologies for the noise. Please hit delete... > > Once again I am not able to send email to the list and > have either been moderated off again (for some mistake > or some unknown reason why) or something else is going > on. Sent email to admins@, but no response, so this > is just a test to see if anything gets through. FWIW this is what I've seen, by date/time... - John From marcusleskex at gmail.com Thu Jun 14 14:18:16 2018 From: marcusleskex at gmail.com (Marcus Leske) Date: Thu, 14 Jun 2018 14:18:16 +0000 Subject: fd.io vs cumulus vs snabb vs OVS vs OpenNSL Message-ID: Hi Any thought leader on the list to shed some light to what is happening in the world of open networking ? OVS vs OpenNSL vs Cumulus vs fd.io vs Snabb vs a lot of stuff :) Where is this going ? What are the obvious pros and cons of each when it comes to scale and feature velocity ? https://www.reddit.com/r/networking/comments/8r0afq/is_their_any_truth_to_the_trend_of_putting/ Danke From travis at netviscom.com Tue Jun 12 23:48:05 2018 From: travis at netviscom.com (Travis Garrison) Date: Tue, 12 Jun 2018 23:48:05 +0000 Subject: What are people using for IPAM these days? In-Reply-To: References: <20180611134006.D25631A5@m0117567.ppops.net> <02DC6ADC-C73E-48E1-B2EE-93CE2DC85B45@gmail.com> <20180612185205.GB18754@cmadams.net> Message-ID: >On 6/12/18 1:52 PM, Chris Adams wrote: >> Once upon a time, Randy Bush said: >>>> If you start with Excel, down Will It Scale Road, you will be sorry, >>>> so very sorry. Especially when it comes to v6. >>> >>> emacs! >> >> vim! >> > >ed! Butterflies! From ryan at kearney.io Wed Jun 13 14:48:58 2018 From: ryan at kearney.io (Ryan Kearney) Date: Wed, 13 Jun 2018 10:48:58 -0400 Subject: FWIW... Re: TEST Help? TEST In-Reply-To: <20180613070110.GE34704@excession.tpb.net> References: <20180612171656.D25644D7@m0117567.ppops.net> <20180613070110.GE34704@excession.tpb.net> Message-ID: Also, please stop putting quotes in your email signature... it's 2018. ​​ ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On June 13, 2018 2:01 AM, wrote: > Then perhaps that thread was killed by the moderators. Please heed > > the list charter. > > Also, please get a mail client that generates proper In-Reply-To > > headers and knows how to quote... it's 2018. > > -- Niels. > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > "It's amazing what people will do to get their name on the internet, > > which is odd, because all you really need is a Blogspot account." > > -- roy edroso, alicublog.blogspot.com From ryangard at gmail.com Thu Jun 14 21:17:05 2018 From: ryangard at gmail.com (Ryan Gard) Date: Thu, 14 Jun 2018 17:17:05 -0400 Subject: Google Scholar Contact? Message-ID: Hey, Can someone reach out to me off list in regards to Google Scholar? Been dealing with an issue in which a recently acquired IP block appears to have been blacklisted in the past and is impacting end users. Thanks! -- Ryan Gard From nanog at jack.fr.eu.org Thu Jun 14 21:28:50 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Thu, 14 Jun 2018 23:28:50 +0200 Subject: fd.io vs cumulus vs snabb vs OVS vs OpenNSL In-Reply-To: References: Message-ID: <5B22DE12.5050800@jack.fr.eu.org> Bof I currently use cumulus's software, I will then report my experience: not production ready You have a lot of features, with a fast development, but .. I expect my network to be a rock solid part of my infrastructure, especially when I am using the classic part, not the fancy ones When I have huge stability issue with something like bgp, what can I say but "get away from those software, it is not production-ready yet" ? On 06/14/2018 04:18 PM, Marcus Leske wrote: > Hi > > Any thought leader on the list to shed some light to what is happening > in the world of open networking ? OVS vs OpenNSL vs Cumulus vs fd.io > vs Snabb vs a lot of stuff :) > > Where is this going ? What are the obvious pros and cons of each when > it comes to scale and feature velocity ? > > https://www.reddit.com/r/networking/comments/8r0afq/is_their_any_truth_to_the_trend_of_putting/ > > Danke > From hugo at slabnet.com Thu Jun 14 22:30:47 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 14 Jun 2018 15:30:47 -0700 Subject: fd.io vs cumulus vs snabb vs OVS vs OpenNSL In-Reply-To: <5B22DE12.5050800@jack.fr.eu.org> References: <5B22DE12.5050800@jack.fr.eu.org> Message-ID: <20180614223047.GC12279@bamboo.slabnet.com> On Thu 2018-Jun-14 23:28:50 +0200, nanog at jack.fr.eu.org wrote: >Bof > >I currently use cumulus's software, I will then report my experience: >not production ready > >You have a lot of features, with a fast development, but .. >I expect my network to be a rock solid part of my infrastructure, >especially when I am using the classic part, not the fancy ones > >When I have huge stability issue with something like bgp, what can I say >but "get away from those software, it is not production-ready yet" ? I'd be curious about specifics. We've got some Cumulus with BGP and it hasn't given us any issues. Granted, it's very vanilla with a couple of SVIs per switch and just basic IPv4 unicast and it's just a management network, but it hasn't caused us any issues that I'm aware of. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From richard.hicks at gmail.com Fri Jun 15 00:03:57 2018 From: richard.hicks at gmail.com (Richard Hicks) Date: Thu, 14 Jun 2018 17:03:57 -0700 Subject: BGP in a containers In-Reply-To: References: Message-ID: I'm happy with GoBGP in a docker container for my BGP Dashboard/LookingGlass project. https://github.com/rhicks/bgp-dashboard Its just piping RIB updates, as JSON, to script to feed into MongoDB container. At work we also looked at GoBGP as a route-server for a small IXP type of setup, but ran into few issues that we didn't have the time to fully debug. So we switched to BIRD for that project. We are happy with both. On Thu, Jun 14, 2018 at 11:56 AM, james jones wrote: > I am working on an personal experiment and was wondering what is the best > option for running BGP in a docker base container. I have seen a lot blogs > and docs referencing Quagga. I just want to make sure I am not over looking > any other options before I dive in. Any thoughts or suggestions? > > -James > From nanog at ics-il.net Fri Jun 15 01:45:49 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 14 Jun 2018 20:45:49 -0500 (CDT) Subject: BGP in a containers In-Reply-To: References: Message-ID: <354033155.2785.1529027144903.JavaMail.mhammett@ThunderFuck> I wonder which part of the proposal people find offensive. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "james jones" To: "NANOG" Sent: Thursday, June 14, 2018 1:56:09 PM Subject: BGP in a containers I am working on an personal experiment and was wondering what is the best option for running BGP in a docker base container. I have seen a lot blogs and docs referencing Quagga. I just want to make sure I am not over looking any other options before I dive in. Any thoughts or suggestions? -James From hf0002+nanog at uah.edu Fri Jun 15 02:14:57 2018 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Thu, 14 Jun 2018 21:14:57 -0500 Subject: BGP in a containers In-Reply-To: <354033155.2785.1529027144903.JavaMail.mhammett@ThunderFuck> References: <354033155.2785.1529027144903.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, Jun 14, 2018 at 8:46 PM Mike Hammett wrote: > I wonder which part of the proposal people find offensive. I have no idea. All - You know no one is trying to make *you* run BGP inside of a container, right? From eric-list at truenet.com Fri Jun 15 02:24:20 2018 From: eric-list at truenet.com (Eric Tykwinski) Date: Thu, 14 Jun 2018 22:24:20 -0400 Subject: BGP in a containers In-Reply-To: References: <354033155.2785.1529027144903.JavaMail.mhammett@ThunderFuck> Message-ID: <26161EE5-DEBB-418E-B963-BEA6F04C5F4C@truenet.com> The funny part is I don’t like containers but love VMs, so kvm, vmware, citrix, hvm, et al. Not much difference but I tend to like the separation of OS knowledge, with all the bugs lately though I wonder if it’s worth it. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 > On Jun 14, 2018, at 10:14 PM, Hunter Fuller wrote: > > On Thu, Jun 14, 2018 at 8:46 PM Mike Hammett wrote: > >> I wonder which part of the proposal people find offensive. > > > I have no idea. All - You know no one is trying to make *you* run BGP > inside of a container, right? From oliver.oboyle at gmail.com Fri Jun 15 02:40:01 2018 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 14 Jun 2018 22:40:01 -0400 Subject: BGP in a containers In-Reply-To: <26161EE5-DEBB-418E-B963-BEA6F04C5F4C@truenet.com> References: <354033155.2785.1529027144903.JavaMail.mhammett@ThunderFuck> <26161EE5-DEBB-418E-B963-BEA6F04C5F4C@truenet.com> Message-ID: There's no reason why it shouldn't work well. It's just a minor paradigm shift that requires some solid testing and knowhow on the ops team. On Thu, Jun 14, 2018, 22:26 Eric Tykwinski, wrote: > The funny part is I don’t like containers but love VMs, so kvm, vmware, > citrix, hvm, et al. > Not much difference but I tend to like the separation of OS knowledge, > with all the bugs lately though I wonder if it’s worth it. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > > > On Jun 14, 2018, at 10:14 PM, Hunter Fuller > wrote: > > > > On Thu, Jun 14, 2018 at 8:46 PM Mike Hammett wrote: > > > >> I wonder which part of the proposal people find offensive. > > > > > > I have no idea. All - You know no one is trying to make *you* run BGP > > inside of a container, right? > > From morrowc.lists at gmail.com Fri Jun 15 05:00:42 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 15 Jun 2018 01:00:42 -0400 Subject: BGP in a containers In-Reply-To: References: <354033155.2785.1529027144903.JavaMail.mhammett@ThunderFuck> <26161EE5-DEBB-418E-B963-BEA6F04C5F4C@truenet.com> Message-ID: On Thu, Jun 14, 2018 at 10:41 PM Oliver O'Boyle wrote: > There's no reason why it shouldn't work well. It's just a minor paradigm > shift that requires some solid testing and knowhow on the ops team. > > and... XR or Junos are ... doing this under the covers for you anyway, so.. get used to the new paradigem! From mike at mtcc.com Fri Jun 15 00:22:55 2018 From: mike at mtcc.com (Michael Thomas) Date: Thu, 14 Jun 2018 17:22:55 -0700 Subject: BGP in a containers In-Reply-To: References: Message-ID: <226c82eb-41cb-7a6a-fcb9-02bf84453549@mtcc.com> So I have to ask, why is it advantageous to put this in a container rather than just run it directly on the container's host? Mike On 06/14/2018 05:03 PM, Richard Hicks wrote: > I'm happy with GoBGP in a docker container for my BGP > Dashboard/LookingGlass project. > https://github.com/rhicks/bgp-dashboard > > Its just piping RIB updates, as JSON, to script to feed into MongoDB > container. > > At work we also looked at GoBGP as a route-server for a small IXP type of > setup, but ran into few issues that we didn't have the time to fully > debug. So we switched to BIRD for that project. > We are happy with both. > > On Thu, Jun 14, 2018 at 11:56 AM, james jones wrote: > >> I am working on an personal experiment and was wondering what is the best >> option for running BGP in a docker base container. I have seen a lot blogs >> and docs referencing Quagga. I just want to make sure I am not over looking >> any other options before I dive in. Any thoughts or suggestions? >> >> -James >> From ray at oneunified.net Fri Jun 15 08:18:05 2018 From: ray at oneunified.net (Raymond Burkholder) Date: Fri, 15 Jun 2018 05:18:05 -0300 Subject: BGP in a containers In-Reply-To: <226c82eb-41cb-7a6a-fcb9-02bf84453549@mtcc.com> References: <226c82eb-41cb-7a6a-fcb9-02bf84453549@mtcc.com> Message-ID: <6eeec3a6-3c96-5c83-4786-e3a2d6e40694@oneunified.net> On 06/14/2018 09:22 PM, Michael Thomas wrote: > So I have to ask, why is it advantageous to put this in a container > rather than just run it directly > on the container's host? Most any host now-a-days has quite a bit of horse power to run services. All those services could be run natively all in one namespace on the same host, or ... I tend to gravitate towards running services individually in LXC containers. This creates a bit more overhead than running chroot style environments, but less than running full fledged kvm style virtualization for each service. I typically automate the provisioning and the spool up of the container and its service. This makes it easy to up-keep/rebuild/update/upgrade/load-balance services individually and enmasse across hosts. By running BGP within each container, as someone else mentioned, BGP can be used to advertise the loopback address of the service. I go one step further: for certain services I will anycast some addresses into bgp. This provides an easy way to load balance and provide resiliency of like service instances across hosts, Therefore, by running BGP within the container, and on the host, routes can be distributed across a network with all the policies available within the bgp protocol. I use Free Range Routing, which is a fork of Quagga, to do this. I use the eBGP variant for the hosts and containers, which allows for the elimination of OSPF or similar internal gateway protocol. Stepping away a bit, this means that BGP is used in tiered scenario. There is the regular eBGP with the public ASN for handling DFZ style public traffic. For internal traffic, private eBGP ASNs are used for routing traffic between and within hosts and containers. With recent improvements to Free Range Routing and the Linux Kernel, various combinations of MPLS, VxLAN, EVPN, and VRF configurations can be used to further segment and compartmentalize traffic within a host, and between containers. It is now very easy to run vlan-less between hosts through various easy to configure encapsulation mechanisms. To be explicit, this relies on a resilient layer 3 network between hosts, and eliminates the bothersome layer 2 redundancy headaches. That was a very long winded way to say: keep a very basic host configuration running a minimal set of functional services, and re-factor the functionality and split it across multiple containers to provide easy access to and maintenance of individual services like dns, smtp, database, dashboards, public routing, private routing, firewalling, monitoring, management, ... There is a higher up-front configuration cost, but over the longer term, if configured via automation tools like Salt or similar, maintenance and security is improved. It does require a different level of sophistication with operational staff. > > Mike > > On 06/14/2018 05:03 PM, Richard Hicks wrote: >> I'm happy with GoBGP in a docker container for my BGP >> Dashboard/LookingGlass project. >> https://github.com/rhicks/bgp-dashboard >> >> Its just piping RIB updates, as JSON, to script to feed into MongoDB >> container. >> >> At work we also looked at GoBGP as a route-server for a small IXP type of >> setup, but ran into few issues that we didn't have the time to fully >> debug.  So we switched to BIRD for that project. >> We are happy with both. >> >> On Thu, Jun 14, 2018 at 11:56 AM, james jones >> wrote: >> >>> I am working on an personal experiment and was wondering what is the >>> best >>> option for running BGP in a docker base container. I have seen a lot >>> blogs >>> and docs referencing Quagga. I just want to make sure I am not over >>> looking >>> any other options before I dive in. Any thoughts or suggestions? >>> >>> -James >>> > > -- Raymond Burkholder ray at oneunified.net https://blog.raymond.burkholder.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From hugo at slabnet.com Fri Jun 15 15:20:44 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 15 Jun 2018 08:20:44 -0700 Subject: BGP in a containers In-Reply-To: <6eeec3a6-3c96-5c83-4786-e3a2d6e40694@oneunified.net> References: <226c82eb-41cb-7a6a-fcb9-02bf84453549@mtcc.com> <6eeec3a6-3c96-5c83-4786-e3a2d6e40694@oneunified.net> Message-ID: <20180615152044.GD12279@bamboo.slabnet.com> On Fri 2018-Jun-15 05:18:05 -0300, Raymond Burkholder wrote: >On 06/14/2018 09:22 PM, Michael Thomas wrote: >>So I have to ask, why is it advantageous to put this in a container >>rather than just run it directly >>on the container's host? Some bits similar to Raymond's comments, but in our case this was specifically for a Kubernetes deployment. Our k8s deployment is mostly "self-hosted", i.e. the k8s control plane runs within k8s, with the workers being disposable. Dropping the routing into a container that runs in the host's/worker's network namespace means it is just another container (daemonset) that Kubernetes will schedule to the worker as part of initial bootstrapping. So, we don't run BGP within the application containers themselves but rather on the container hosts. Advertising service IPs is handled by IPVS pods that anycast the service IPs and do DSR + tunnel mode to the k8s pods backing a given L4 service, with an HTTP reverse proxy layer (Kubernetes ingress controllers) in the middle for HTTP/s services. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From cscora at apnic.net Fri Jun 15 18:03:08 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Jun 2018 04:03:08 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180615180308.C7526C450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 Jun, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 703538 Prefixes after maximum aggregation (per Origin AS): 270561 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 337701 Total ASes present in the Internet Routing Table: 60978 Prefixes per ASN: 11.54 Origin-only ASes present in the Internet Routing Table: 52643 Origin ASes announcing only one prefix: 23010 Transit ASes present in the Internet Routing Table: 8335 Transit-only ASes present in the Internet Routing Table: 278 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 30 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 48 Number of instances of unregistered ASNs: 48 Number of 32-bit ASNs allocated by the RIRs: 22964 Number of 32-bit ASNs visible in the Routing Table: 18494 Prefixes from 32-bit ASNs in the Routing Table: 77091 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 252 Number of addresses announced to Internet: 2857557955 Equivalent to 170 /8s, 82 /16s and 223 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 234947 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 191998 Total APNIC prefixes after maximum aggregation: 54599 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 190735 Unique aggregates announced from the APNIC address blocks: 77742 APNIC Region origin ASes present in the Internet Routing Table: 8866 APNIC Prefixes per ASN: 21.51 APNIC Region origin ASes announcing only one prefix: 2496 APNIC Region transit ASes present in the Internet Routing Table: 1332 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3837 Number of APNIC addresses announced to Internet: 767206658 Equivalent to 45 /8s, 186 /16s and 165 /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: 209304 Total ARIN prefixes after maximum aggregation: 99533 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209820 Unique aggregates announced from the ARIN address blocks: 99158 ARIN Region origin ASes present in the Internet Routing Table: 18200 ARIN Prefixes per ASN: 11.53 ARIN Region origin ASes announcing only one prefix: 6736 ARIN Region transit ASes present in the Internet Routing Table: 1806 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 19 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2363 Number of ARIN addresses announced to Internet: 1102973344 Equivalent to 65 /8s, 190 /16s and 9 /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: 192618 Total RIPE prefixes after maximum aggregation: 92399 RIPE Deaggregation factor: 2.08 Prefixes being announced from the RIPE address blocks: 188762 Unique aggregates announced from the RIPE address blocks: 112082 RIPE Region origin ASes present in the Internet Routing Table: 25230 RIPE Prefixes per ASN: 7.48 RIPE Region origin ASes announcing only one prefix: 11392 RIPE Region transit ASes present in the Internet Routing Table: 3516 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7093 Number of RIPE addresses announced to Internet: 716117120 Equivalent to 42 /8s, 175 /16s and 20 /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: 90608 Total LACNIC prefixes after maximum aggregation: 19978 LACNIC Deaggregation factor: 4.54 Prefixes being announced from the LACNIC address blocks: 92034 Unique aggregates announced from the LACNIC address blocks: 40788 LACNIC Region origin ASes present in the Internet Routing Table: 7220 LACNIC Prefixes per ASN: 12.75 LACNIC Region origin ASes announcing only one prefix: 2006 LACNIC Region transit ASes present in the Internet Routing Table: 1351 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4769 Number of LACNIC addresses announced to Internet: 172405152 Equivalent to 10 /8s, 70 /16s and 177 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 18961 Total AfriNIC prefixes after maximum aggregation: 4010 AfriNIC Deaggregation factor: 4.73 Prefixes being announced from the AfriNIC address blocks: 21935 Unique aggregates announced from the AfriNIC address blocks: 7706 AfriNIC Region origin ASes present in the Internet Routing Table: 1156 AfriNIC Prefixes per ASN: 18.97 AfriNIC Region origin ASes announcing only one prefix: 380 AfriNIC Region transit ASes present in the Internet Routing Table: 226 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 432 Number of AfriNIC addresses announced to Internet: 98414592 Equivalent to 5 /8s, 221 /16s and 176 /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 5425 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4290 420 439 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2922 1154 77 VIETEL-AS-AP Viettel Group, VN 4766 2849 11134 761 KIXS-AS-KR Korea Telecom, KR 9829 2803 1497 543 BSNL-NIB National Internet Backbone, IN 45899 2555 1598 162 VNPT-AS-VN VNPT Corp, VN 9394 2540 4907 31 CTTNET China TieTong Telecommunications 17974 2220 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2200 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2105 417 206 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3433 1324 85 SHAW - Shaw Communications Inc., CA 22773 3283 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2324 243 463 CABLEONE - CABLE ONE, INC., US 18566 2170 405 109 MEGAPATH5-US - MegaPath Corporation, US 16509 2148 4709 683 AMAZON-02 - Amazon.com, Inc., US 20115 2107 2562 469 CHARTER-NET-HKY-NC - Charter Communicat 209 2009 5070 609 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1991 342 167 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 1903 946 1357 AKAMAI-AS - Akamai Technologies, Inc., 7018 1739 20202 1272 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4284 1517 565 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2749 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2573 648 1891 AKAMAI-ASN1, US 34984 2022 335 499 TELLCOM-AS, TR 12389 2013 1877 707 ROSTELECOM-AS, RU 9121 1889 1692 19 TTNET, TR 13188 1610 100 43 TRIOLAN, UA 8402 1261 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 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 8151 4684 3306 586 Uninet S.A. de C.V., MX 10620 3563 541 254 Telmex Colombia S.A., CO 11830 2653 369 78 Instituto Costarricense de Electricidad 6503 1639 443 60 Axtel, S.A.B. de C.V., MX 7303 1507 1026 188 Telecom Argentina S.A., AR 28573 1032 2242 177 CLARO S.A., BR 3816 1010 505 130 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 926 126 85 Alestra, S. de R.L. de C.V., MX 6147 921 377 31 Telefonica del Peru S.A.A., PE 18881 911 1078 30 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1173 396 48 LINKdotNET-AS, EG 37611 858 107 9 Afrihost, ZA 36903 750 377 143 MT-MPLS, MA 36992 724 1413 40 ETISALAT-MISR, EG 8452 641 1730 18 TE-AS TE-AS, EG 24835 610 818 18 RAYA-AS, EG 37492 467 470 57 ORANGE-, TN 29571 454 68 11 ORANGE-COTE-IVOIRE, CI 37342 379 32 1 MOVITEL, MZ 15399 371 35 7 WANANCHI-, KE 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 5425 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4684 3306 586 Uninet S.A. de C.V., MX 7545 4290 420 439 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 4284 1517 565 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3563 541 254 Telmex Colombia S.A., CO 6327 3433 1324 85 SHAW - Shaw Communications Inc., CA 22773 3283 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2922 1154 77 VIETEL-AS-AP Viettel Group, VN 4766 2849 11134 761 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 8151 4684 4098 Uninet S.A. de C.V., MX 7545 4290 3851 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 12479 4284 3719 UNI2-AS, ES 6327 3433 3348 SHAW - Shaw Communications Inc., CA 10620 3563 3309 Telmex Colombia S.A., CO 22773 3283 3136 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2922 2845 VIETEL-AS-AP Viettel Group, VN 8551 2749 2706 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2653 2575 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 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 268309 UNALLOCATED 45.238.48.0/22 52655 Ti5 Tecnologia e Inovacao, BR 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65544 DOCUMENT 103.197.121.0/24 65542 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN 45.64.64.0/24 19551 INCAPSULA - Incapsula Inc, US 45.64.65.0/24 19551 INCAPSULA - Incapsula Inc, US 45.64.66.0/24 19551 INCAPSULA - Incapsula Inc, US 45.64.67.0/24 19551 INCAPSULA - Incapsula Inc, 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:14 /9:11 /10:37 /11:99 /12:290 /13:567 /14:1098 /15:1902 /16:13363 /17:7925 /18:13754 /19:25263 /20:39375 /21:45351 /22:87397 /23:70873 /24:394001 /25:828 /26:626 /27:636 /28:35 /29:20 /30:16 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3220 3433 SHAW - Shaw Communications Inc., CA 12479 3072 4284 UNI2-AS, ES 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2547 3283 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2211 2749 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2063 2170 MEGAPATH5-US - MegaPath Corporation, US 11830 2001 2653 Instituto Costarricense de Electricidad y Telec 11492 1921 2324 CABLEONE - CABLE ONE, INC., US 30036 1743 1991 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1612 3563 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1632 2:857 4:19 5:2828 6:40 7:1 8:1115 12:1873 13:195 14:1760 15:29 16:3 17:211 18:55 20:50 21:8 23:2668 24:2223 25:2 27:2426 31:2019 32:92 35:27 36:509 37:2749 38:1478 39:241 40:121 41:3160 42:681 43:1927 44:121 45:4712 46:3044 47:201 49:1324 50:1057 51:314 52:1053 54:367 55:2 56:12 57:39 58:1627 59:1000 60:390 61:2094 62:1852 63:1799 64:5030 65:2218 66:4665 67:2439 68:1168 69:3220 70:1152 71:564 72:2115 74:2736 75:422 76:454 77:1566 78:1714 79:1764 80:1504 81:1385 82:1084 83:768 84:1071 85:2016 86:587 87:1319 88:923 89:2341 90:212 91:6392 92:1203 93:2371 94:2395 95:2850 96:734 97:356 98:946 99:133 100:83 101:1265 102:78 103:17918 104:3609 105:246 106:651 107:1874 108:694 109:3459 110:1635 111:1774 112:1272 113:1275 114:1130 115:1649 116:1645 117:1756 118:2161 119:1668 120:986 121:1053 122:2456 123:1774 124:1439 125:1901 128:1036 129:655 130:452 131:1592 132:691 133:196 134:1026 135:222 136:507 137:561 138:1961 139:615 140:410 141:716 142:830 143:978 144:802 145:480 146:1202 147:727 148:1631 149:749 150:736 151:1062 152:787 153:312 154:1116 155:763 156:1066 157:799 158:652 159:1737 160:1122 161:783 162:2588 163:595 164:1062 165:1480 166:470 167:1287 168:3061 169:830 170:3733 171:454 172:1092 173:2014 174:905 175:781 176:1995 177:4068 178:2512 179:1217 180:2199 181:2230 182:2378 183:1179 184:1022 185:13627 186:3612 187:2348 188:2832 189:2065 190:8084 191:1421 192:9821 193:5976 194:4859 195:3985 196:2594 197:1573 198:5529 199:5909 200:7368 201:4898 202:10472 203:10200 204:4577 205:2909 206:3111 207:3177 208:4022 209:3958 210:4052 211:2108 212:3051 213:2746 214:976 215:57 216:5962 217:2123 218:903 219:628 220:1771 221:978 222:1022 223:1296 End of report From john at op-sec.us Fri Jun 15 20:17:32 2018 From: john at op-sec.us (John Fraizer) Date: Fri, 15 Jun 2018 16:17:32 -0400 Subject: fd.io vs cumulus vs snabb vs OVS vs OpenNSL In-Reply-To: <5B22DE12.5050800@jack.fr.eu.org> References: <5B22DE12.5050800@jack.fr.eu.org> Message-ID: I would also be very interested in what specific issues you are having... - What specific issues are you having with BGP running under Cumulus Linux. - What hardware are you running Cumulus Linux on? - What version of Cumulus Linux? -- John Fraizer LinkedIn profile: http://www.linkedin.com/in/johnfraizer/ On Thu, Jun 14, 2018 at 5:28 PM, wrote: > Bof > > I currently use cumulus's software, I will then report my experience: > not production ready > > You have a lot of features, with a fast development, but .. > I expect my network to be a rock solid part of my infrastructure, > especially when I am using the classic part, not the fancy ones > > When I have huge stability issue with something like bgp, what can I say > but "get away from those software, it is not production-ready yet" ? > > > > From nanog at jack.fr.eu.org Fri Jun 15 21:47:49 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Fri, 15 Jun 2018 23:47:49 +0200 Subject: fd.io vs cumulus vs snabb vs OVS vs OpenNSL In-Reply-To: References: <5B22DE12.5050800@jack.fr.eu.org> Message-ID: <5B243405.4020103@jack.fr.eu.org> On 06/15/2018 10:17 PM, John Fraizer wrote: > - What specific issues are you having with BGP running under Cumulus > Linux. - bgpd crashes - bgpd loading as hell after some time (can be fixed by restarting the process ..) - cumulus by itself (switchd & portwd) loads as hell as well, all the time, the hardware is under pressure all the time (which is an issue for CPU-based stuff : monitoring, sflow etc) > - What hardware are you running Cumulus Linux on? 5712-54X-O-AC-F from edgecore (https://www.edge-core.com/productsInfo.php?cls=&cls2=&cls3=44&id=15), which has specific issues by itself as well :/ > - What version of Cumulus Linux? The last one, 3.5.2 > > > -- > John Fraizer > LinkedIn profile: http://www.linkedin.com/in/johnfraizer/ > > > > On Thu, Jun 14, 2018 at 5:28 PM, wrote: > >> Bof >> >> I currently use cumulus's software, I will then report my experience: >> not production ready >> >> You have a lot of features, with a fast development, but .. >> I expect my network to be a rock solid part of my infrastructure, >> especially when I am using the classic part, not the fancy ones >> >> When I have huge stability issue with something like bgp, what can I say >> but "get away from those software, it is not production-ready yet" ? >> >> >> >> > From zmania101 at gmail.com Thu Jun 14 22:02:29 2018 From: zmania101 at gmail.com (Zach Puls) Date: Thu, 14 Jun 2018 18:02:29 -0400 Subject: Google Peering/Edge Network Contact? Message-ID: Does anyone have a contact for Google Peering / PNI? We have a caching appliance whose BGP session has been flapping nonstop for the past month or so. We've had a ticket open with Google since it started, but they haven't really made any headway, or provided much of a response. Thanks, -- Zachary Puls zach at zachpuls.com http://zachpuls.com/contact Network Engineer Kansas Fiber Network, LLC zpuls at ksfiber.net Any opinions expressed herein are solely of Zachary Puls, and do not necessarily reflect that of my employer. From michel.py at tsisemi.com Fri Jun 15 01:58:22 2018 From: michel.py at tsisemi.com (Michel Py) Date: Fri, 15 Jun 2018 01:58:22 +0000 Subject: BGP in a containers In-Reply-To: <354033155.2785.1529027144903.JavaMail.mhammett@ThunderFuck> References: <354033155.2785.1529027144903.JavaMail.mhammett@ThunderFuck> Message-ID: <7774b5e3954e409ca97fac73ba0ad0b4@CRA110.am.necel.com> > Mike Hammett wrote : > I wonder which part of the proposal people find offensive. The intent of the original post was vague. Like a lot of people, I would not run a full BGP router in a container. Now, if the purpose is to inject or learn a handful of routes in order to do limited host routing, I can see the need. A route-server or a looking glass in a container would be fine, or something to perform analysis on the routing table, but not anything that has to route actual traffic. I use ExaBGP to inject routes, perfect tool for that. If routes have to be received (not my use case) it makes more sense, as stated by previous posts, to use Quagga or BIRD. Which one is better : easy : if you like Cisco better, use Quagga. If you like Juniper better, use BIRD :P BIRD looking glass looks very good ;-) Hope this makes sense. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From alumbis at gmail.com Fri Jun 15 05:02:23 2018 From: alumbis at gmail.com (Pete Lumbis) Date: Fri, 15 Jun 2018 01:02:23 -0400 Subject: BGP in a containers In-Reply-To: References: <354033155.2785.1529027144903.JavaMail.mhammett@ThunderFuck> <26161EE5-DEBB-418E-B963-BEA6F04C5F4C@truenet.com> Message-ID: FRR, the modern fork of quagga, has a pre built docker container. https://hub.docker.com/r/cumulusnetworks/frrouting/ On Thu, Jun 14, 2018, 10:41 PM Oliver O'Boyle wrote: > There's no reason why it shouldn't work well. It's just a minor paradigm > shift that requires some solid testing and knowhow on the ops team. > > > > On Thu, Jun 14, 2018, 22:26 Eric Tykwinski, wrote: > > > The funny part is I don’t like containers but love VMs, so kvm, vmware, > > citrix, hvm, et al. > > Not much difference but I tend to like the separation of OS knowledge, > > with all the bugs lately though I wonder if it’s worth it. > > > > Sincerely, > > > > Eric Tykwinski > > TrueNet, Inc. > > P: 610-429-8300 > > > > > On Jun 14, 2018, at 10:14 PM, Hunter Fuller > > wrote: > > > > > > On Thu, Jun 14, 2018 at 8:46 PM Mike Hammett wrote: > > > > > >> I wonder which part of the proposal people find offensive. > > > > > > > > > I have no idea. All - You know no one is trying to make *you* run BGP > > > inside of a container, right? > > > > > From ongbh at ispworkshop.com Fri Jun 15 10:23:48 2018 From: ongbh at ispworkshop.com (Ong Beng Hui) Date: Fri, 15 Jun 2018 18:23:48 +0800 Subject: WC 2018 impact on network yet Message-ID: <014db520-c948-20f0-84b5-a90c39a17a64@ispworkshop.com> Hi, With every operators looking at high quality HD video stream, anyone feeling the impact for WC 2018 yet ? From andrewd at sterling.net Fri Jun 15 15:23:10 2018 From: andrewd at sterling.net (Andrew Denton) Date: Fri, 15 Jun 2018 15:23:10 +0000 Subject: BGP in a containers In-Reply-To: References: <81534112-AD52-403E-94C9-73C35ED5B847@benappy.com> Message-ID: On Thu, 2018-06-14 at 15:07 -0400, james jones wrote: > Yes, that's it. > > On Thu, Jun 14, 2018 at 3:05 PM Michel 'ic' Luczak > > wrote: > > I guess / hope what you’re trying to achieve is to announce services > from > the containers using BGP. If this is the case, what you’re looking > for is > called exabgp. > > ic Have a look at Project Calico, https://www.projectcalico.org/. They have the route-everything container networking pretty much figured out. - Andrew From tal at whatexit.org Fri Jun 15 15:44:24 2018 From: tal at whatexit.org (Tom Limoncelli) Date: Fri, 15 Jun 2018 11:44:24 -0400 Subject: BGP in a containers In-Reply-To: References: Message-ID: Using BGP (Quagga) in containers is a great way to build a simulation of your actual network. You can then test configuration changes in the simulation before you make them in production. You can even build this up into an automated test pipeline where new configurations are tested in simulation before put into production. There was a talk about an experimental system like this at the February 2017 meetup: https://developers.google.com/events/sre/nyc Title: "DevOps to NetworkOps" Speaker: Xavier Nicollet, Stack Overflow Tom On Thu, Jun 14, 2018 at 2:56 PM, james jones wrote: > I am working on an personal experiment and was wondering what is the best > option for running BGP in a docker base container. I have seen a lot blogs > and docs referencing Quagga. I just want to make sure I am not over looking > any other options before I dive in. Any thoughts or suggestions? > > -James > -- Email: tal at whatexit.org Work: tlimoncelli at StackOverflow.com Blog: http://EverythingSysadmin.com/ From mkonstan at cisco.com Fri Jun 15 15:48:38 2018 From: mkonstan at cisco.com (Maciek Konstantynowicz (mkonstan)) Date: Fri, 15 Jun 2018 15:48:38 +0000 Subject: fd.io vs cumulus vs snabb vs OVS vs OpenNSL Message-ID: <13AF7649-3ADA-4AA6-9723-CE8ADF2368F9@cisco.com> Hi, Gleaned this thread on nanog mailer archive [1] mentioning fd.io :) Not a "thought leader", but I thought I respond with some fd.io data points, hopefully relevant to the thread’s subject. Note that most of them focus on data plane functionality, performance and technology level comparison: - IPv4 routing (large FIB) at Terabit speed, a video clip (low-budget) showing what difference modern Xeon processors (Skylake) can make to SW data plane if coupled with something super-fast, produced by LF FD.io project for Xeon Skylake launch on 11th July 2017 (a year ago). [2] - SW data plane benchmarking, technical paper [3][4]. - Test and performance report for last fd.io release [5]. - Continuous trending of fd.io vpp master branch [6]. And although network control plane is not covered (e.g. BGP), many data plane hooks required are there incl. large FIBs, VRFs, hierarchical FIB for IP fast convergence, multicast, etc. HTH -Maciek [1] https://mailman.nanog.org/pipermail/nanog/2018-June/095897.html [2] "FD.io: A Universal Terabit Network Dataplane", https://www.youtube.com/watch?v=aLJ0XLeV3V4. [3] https://fd.io/wp-content/uploads/sites/34/2018/01/performance_analysis_sw_data_planes_dec21_2017.pdf [4] https://wiki.fd.io/images/3/31/Benchmarking-sw-data-planes-Dec5_2017.pdf [5] FD.io CSIT-CPL rls1804, https://docs.fd.io/csit/rls1804/report/. [6] FD.io CSIT-CPL continuous VPP performance trending: IPv4, https://docs.fd.io/csit/master/trending/new/trending/ip4.html as of next week above link will be migrated to: https://docs.fd.io/csit/master/trending/trending/ip4.html IPv6, https://docs.fd.io/csit/master/trending/new/trending/ip6.html as of next week above link will be migrated to: https://docs.fd.io/csit/master/trending/trending/ip6.html > From: Marcus Leske > Date: June 14, 2018 at 07:18:16 PDT > To: nanog at nanog.org > Subject: fd.io vs cumulus vs snabb vs OVS vs OpenNSL > > Hi > > Any thought leader on the list to shed some light to what is happening > in the world of open networking ? OVS vs OpenNSL vs Cumulus vs fd.io > vs Snabb vs a lot of stuff :) > > Where is this going ? What are the obvious pros and cons of each when > it comes to scale and feature velocity ? > > https://www.reddit.com/r/networking/comments/8r0afq/is_their_any_truth_to_the_trend_of_putting/ > > Danke From nanog at hkkl.fi Fri Jun 15 22:57:33 2018 From: nanog at hkkl.fi (Henri =?ISO-8859-1?Q?Gr=F6nroos?=) Date: Sat, 16 Jun 2018 01:57:33 +0300 Subject: fd.io vs cumulus vs snabb vs OVS vs OpenNSL In-Reply-To: <5B243405.4020103@jack.fr.eu.org> References: <5B22DE12.5050800@jack.fr.eu.org> <5B243405.4020103@jack.fr.eu.org> Message-ID: <1529103453.30016.10.camel@hkkl.fi> Hi, Well, 3.5.2 isn't exactly latest, there is 3.5.3, 3.6.0 and 3.6.1 also. But I guess switchd running cpu somewhat hot is normal (40% load in empty switch or so) as it is polling all the stuff from asic etc. I do agree that cpus on many edgecores & dells and similar are somewhat under powered, but haven't encountered similar problems with that (yet) myself. Would be also very interested to hear more specifics. , Henri On Fri, 2018-06-15 at 23:47 +0200, nanog at jack.fr.eu.org wrote: > On 06/15/2018 10:17 PM, John Fraizer wrote: > > - What specific issues are you having with BGP running under Cumulus > > Linux. > > - bgpd crashes > - bgpd loading as hell after some time (can be fixed by restarting the > process ..) > - cumulus by itself (switchd & portwd) loads as hell as well, all the > time, the hardware is under pressure all the time (which is an issue for > CPU-based stuff : monitoring, sflow etc) > > > - What hardware are you running Cumulus Linux on? > > 5712-54X-O-AC-F from edgecore > (https://www.edge-core.com/productsInfo.php?cls=&cls2=&cls3=44&id=15), > which has specific issues by itself as well :/ > > > - What version of Cumulus Linux? > > The last one, 3.5.2 > > > > > > > > -- > > John Fraizer > > LinkedIn profile: http://www.linkedin.com/in/johnfraizer/ > > > > > > > > On Thu, Jun 14, 2018 at 5:28 PM, wrote: > > > > > Bof > > > > > > I currently use cumulus's software, I will then report my experience: > > > not production ready > > > > > > You have a lot of features, with a fast development, but .. > > > I expect my network to be a rock solid part of my infrastructure, > > > especially when I am using the classic part, not the fancy ones > > > > > > When I have huge stability issue with something like bgp, what can I say > > > but "get away from those software, it is not production-ready yet" ? > > > > > > > > > > > > > > From alumbis at gmail.com Sat Jun 16 03:01:32 2018 From: alumbis at gmail.com (Pete Lumbis) Date: Fri, 15 Jun 2018 23:01:32 -0400 Subject: fd.io vs cumulus vs snabb vs OVS vs OpenNSL In-Reply-To: <5B243405.4020103@jack.fr.eu.org> References: <5B22DE12.5050800@jack.fr.eu.org> <5B243405.4020103@jack.fr.eu.org> Message-ID: I'm sorry you've had a negative experience and we should do better. Let's start by fixing your issues. If you are interested in chasing this down to resolution I'm 100% dedicated to getting this solved for you off list. If you're willing I'll even report back with what we found and how we fixed it. - Pete, Cumulus TME On Fri, Jun 15, 2018, 5:49 PM wrote: > On 06/15/2018 10:17 PM, John Fraizer wrote: > > - What specific issues are you having with BGP running under Cumulus > > Linux. > - bgpd crashes > - bgpd loading as hell after some time (can be fixed by restarting the > process ..) > - cumulus by itself (switchd & portwd) loads as hell as well, all the > time, the hardware is under pressure all the time (which is an issue for > CPU-based stuff : monitoring, sflow etc) > > > - What hardware are you running Cumulus Linux on? > 5712-54X-O-AC-F from edgecore > (https://www.edge-core.com/productsInfo.php?cls=&cls2=&cls3=44&id=15), > which has specific issues by itself as well :/ > > > - What version of Cumulus Linux? > The last one, 3.5.2 > > > > > > > > -- > > John Fraizer > > LinkedIn profile: http://www.linkedin.com/in/johnfraizer/ > > > > > > > > On Thu, Jun 14, 2018 at 5:28 PM, wrote: > > > >> Bof > >> > >> I currently use cumulus's software, I will then report my experience: > >> not production ready > >> > >> You have a lot of features, with a fast development, but .. > >> I expect my network to be a rock solid part of my infrastructure, > >> especially when I am using the classic part, not the fancy ones > >> > >> When I have huge stability issue with something like bgp, what can I say > >> but "get away from those software, it is not production-ready yet" ? > >> > >> > >> > >> > > > > From mysidia at gmail.com Sat Jun 16 05:51:15 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 16 Jun 2018 00:51:15 -0500 Subject: BGP in a containers In-Reply-To: <226c82eb-41cb-7a6a-fcb9-02bf84453549@mtcc.com> References: <226c82eb-41cb-7a6a-fcb9-02bf84453549@mtcc.com> Message-ID: On Thu, Jun 14, 2018 at 7:22 PM, Michael Thomas wrote: > So I have to ask, why is it advantageous to put this in a container rather > than just run it directly > on the container's host? There is no real reason not to run it in a container, and all the advantages of running ALL applications in standardized containers (whether the choice be the likes of vSphere,XEN,KVM,Virtuozzo, LXC, or Docker). Assuming the host runs containers: running one app. outside the container (BGP) would put the other applications at risk, since there could be a security vulnerability in the BGP implementation allowing runaway resource usage or remote code exploitation, or in theory, the install process for that app could "spoil" the host or introduce incompatibilities or divergence from expected host configuration. One of the major purposes of containers is to mitigate such problems. For example the BGP application could be exploited but the container boundary prevents access to sensitive data of other apps. sharing the hardware; the application installer running in a container cannot introduce conflicts or impact operating settings of the host platform. Also, the common model of virtualizing the compute resource calls for treating hosts as a shared compute farm --- no one host is special: any container can run equally on other hosts in the same pod, and you hardly ever even check which host a particular container has been scheduled to run on. Users of the resource are presented an interface for running their application: containers. No other option is offered... there is no such thing as "run my program (or run this container) directly on host X" option. ---- no host runs directly any programs or services which have configurations different from any other host, and also every host config is about identical other than hostname & ip address; Simply put: being able to run a program outside a container would violate the service model for datacenter compute services that is most commonly used these days. Running the BGP application in a container on a shared storage system managed by a host cluster would also make it easier to start the service up on a different host when the first host fails or requires maintenance. On the other hand, running directly on a host, suggests that individual hosts need to be backed up again, and some sort of manual restore of local files from the lost host will be required to copy the non-containerized application to a new host. > Mike -- -JH From nanog at radu-adrian.feurdean.net Sat Jun 16 12:59:49 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sat, 16 Jun 2018 14:59:49 +0200 Subject: WC 2018 impact on network yet In-Reply-To: <014db520-c948-20f0-84b5-a90c39a17a64@ispworkshop.com> References: <014db520-c948-20f0-84b5-a90c39a17a64@ispworkshop.com> Message-ID: <1529153989.1204945.1410099200.7442835E@webmail.messagingengine.com> On Fri, Jun 15, 2018, at 12:23, Ong Beng Hui wrote: > Hi, > > With every operators looking at high quality HD video stream, anyone > feeling the impact for WC 2018 yet ? It's too early. For now only minor changes (e.g. 2 hours ago, when local team had their first match we saw levels of traffic slightly higher then usual for that time of the day, but lower than usual prime-time). We expect things to change later in the competition. From kmedcalf at dessus.com Sat Jun 16 20:07:13 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 16 Jun 2018 14:07:13 -0600 Subject: WC 2018 impact on network yet In-Reply-To: <1529153989.1204945.1410099200.7442835E@webmail.messagingengine.com> Message-ID: People stream HD Video in the Water Closet? I don't think my 80" HDTV would fit in there! --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com at nanog.org] On >Behalf Of Radu-Adrian Feurdean >Sent: Saturday, 16 June, 2018 07:00 >To: nanog at nanog.org >Subject: Re: WC 2018 impact on network yet > >On Fri, Jun 15, 2018, at 12:23, Ong Beng Hui wrote: >> Hi, >> >> With every operators looking at high quality HD video stream, >anyone >> feeling the impact for WC 2018 yet ? > >It's too early. For now only minor changes (e.g. 2 hours ago, when >local team had their first match we saw levels of traffic slightly >higher then usual for that time of the day, but lower than usual >prime-time). We expect things to change later in the competition. From nanog at ics-il.net Sat Jun 16 20:13:53 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 16 Jun 2018 15:13:53 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <837f56b5-65f1-12e5-7b89-c1a387dbef9a@retevia.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <837f56b5-65f1-12e5-7b89-c1a387dbef9a@retevia.net> Message-ID: <327156475.3871.1529180031823.JavaMail.mhammett@ThunderFuck> But privacy! *sigh* People may just have to know how to turn the proxy on and off. It's a requirement we wouldn't dare consider in the US, but if you're in the middle of nowhere and you can get megabit or higher speeds (instead of dialup) if you learn how to turn a proxy on and off... you'll learn quickly. Sadly, it's just falling on deaf ears. Silicon Valley will continue to think they know better than everyone else and people outside of that bubble will continue to be disadvantaged. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Lee Howard" To: nanog at nanog.org Sent: Tuesday, May 29, 2018 9:55:18 AM Subject: Re: Impacts of Encryption Everywhere (any solution?) On 05/28/2018 10:23 AM, Mike Hammett wrote: > Has anyone outside of tech media, Silicon Valley or academia (all places wildly out of touch with the real world) put much thought into the impacts of encryption everywhere? See "Effects of Pervasive Encryption on Operators." https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/?include_text=1 TLS1.3 uses ephemeral keys, so even if you own both endpoints and everything in the middle, you can't decrypt a flow without some yet-to-be-developed technology. QUIC encrypts everything, and of course, HTTPS. > So often we hear about how we need the best modern encryption on all forms of communication because of whatever scary thing is trendy this week (Russia, NSA, Google, whatever). HTTPS your marketing information and generic education pieces because of the boogeyman! > > However, I recently came across a thread where someone was exploring getting a one megabit connection into their village and sharing it among many. The crowd I referenced earlier also believes you can't Internet under 100 megabit/s per home. Yeah. Too many people forget that most of the Internet is mobile, and mobile != LTE. People also assume packet loss < 0.1%, latency <100ms, and power reliability >99%. > However, this could be wildly improved with caching ala squid or something similar. The problem is that encrypted content is difficult to impossible for your average Joe to cache. The rewards for implementing caching are greatly mitigated and people like this must suffer a worse Internet experience because of some ideological high horse in a far-off land. > > Some things certainly do need to be encrypted, but encrypting everything means people with limited Internet access get worse performance OR mechanisms have to be out in place to break ALL encryption, this compromising security and privacy when it's really needed. > > To circle back to being somewhat on-topic, what mechanisms are available to maximize the amount of traffic someone in this situation could cache? The performance of third-world Internet depends on you. > A proxy is all I've thought of. But it means everything is dependent on the proxy, and it's even in-path for things that really should be encrypted, like email and messaging. I can't imagine why the weather should be encrypted, when everyone in a location wants to know the forecast. Lee From nanog at jack.fr.eu.org Sat Jun 16 21:45:06 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Sat, 16 Jun 2018 23:45:06 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <327156475.3871.1529180031823.JavaMail.mhammett@ThunderFuck> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <837f56b5-65f1-12e5-7b89-c1a387dbef9a@retevia.net> <327156475.3871.1529180031823.JavaMail.mhammett@ThunderFuck> Message-ID: <5B2584E2.3090803@jack.fr.eu.org> On 06/16/2018 10:13 PM, Mike Hammett wrote: > Sadly, it's just falling on deaf ears. Silicon Valley will continue to think they know better than everyone else and people outside of that bubble will continue to be disadvantaged. What, again ? Encryption is what is best for the most people. The few that will not use it can disable it. No issue then. From nanog at jack.fr.eu.org Sun Jun 17 10:40:01 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Sun, 17 Jun 2018 12:40:01 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <837f56b5-65f1-12e5-7b89-c1a387dbef9a@retevia.net> <327156475.3871.1529180031823.JavaMail.mhammett@ThunderFuck> <5B2584E2.3090803@jack.fr.eu.org> Message-ID: <5B263A81.30000@jack.fr.eu.org> Well, yes, there is, you simply have to break the end to end encryption On 06/17/2018 03:09 AM, Matthew Petach wrote: > Except that if websites are set to HTTPS only, there's no option for > disabling encryption on the client side. > > Matt > > > On Sat, Jun 16, 2018, 14:47 wrote: > >> On 06/16/2018 10:13 PM, Mike Hammett wrote: >>> Sadly, it's just falling on deaf ears. Silicon Valley will continue to >> think they know better than everyone else and people outside of that bubble >> will continue to be disadvantaged. >> >> What, again ? >> Encryption is what is best for the most people. >> The few that will not use it can disable it. >> >> No issue then. >> >> > From mh at xalto.net Sun Jun 17 17:14:15 2018 From: mh at xalto.net (Michael Hallgren) Date: Sun, 17 Jun 2018 19:14:15 +0200 Subject: Impacts of Encryption Everywhere (any =?UTF-8?Q?solution=3F?= =?UTF-8?Q?=29?= In-Reply-To: <5B263A81.30000@jack.fr.eu.org> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <837f56b5-65f1-12e5-7b89-c1a387dbef9a@retevia.net> <327156475.3871.1529180031823.JavaMail.mhammett@ThunderFuck> <5B2584E2.3090803@jack.fr.eu.org> <5B263A81.30000@jack.fr.eu.org> Message-ID: <7a347f5e3fe349651ccc5ec226f38c99@webmail.xalto.net> Le 2018-06-17 12:40, nanog at jack.fr.eu.org a écrit : > Well, yes, there is, you simply have to break the end to end encryption Yes, (or) deny service by Policy (remains to evaluate who's happy with that). Cheers, mh > > On 06/17/2018 03:09 AM, Matthew Petach wrote: >> Except that if websites are set to HTTPS only, there's no option for >> disabling encryption on the client side. >> >> Matt >> >> >> On Sat, Jun 16, 2018, 14:47 wrote: >> >>> On 06/16/2018 10:13 PM, Mike Hammett wrote: >>>> Sadly, it's just falling on deaf ears. Silicon Valley will continue >>>> to >>> think they know better than everyone else and people outside of that >>> bubble >>> will continue to be disadvantaged. >>> >>> What, again ? >>> Encryption is what is best for the most people. >>> The few that will not use it can disable it. >>> >>> No issue then. >>> >>> >> From brad at persius.net Sun Jun 17 18:53:52 2018 From: brad at persius.net (Brad) Date: Sun, 17 Jun 2018 12:53:52 -0600 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <7a347f5e3fe349651ccc5ec226f38c99@webmail.xalto.net> Message-ID: <20180617185400.2834180181@mail.alphavpn.com> While I agree there are unintended consequences every time advancements are made in relation to the security and stability of the Internet- I disagree we should be rejecting their implementations. Instead, we should innovate further. Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity. -Brad -------- Original message --------From: Michael Hallgren Date: 6/17/18 11:14 (GMT-07:00) To: nanog at jack.fr.eu.org Cc: Matthew Petach , nanog at nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) Le 2018-06-17 12:40, nanog at jack.fr.eu.org a écrit : > Well, yes, there is, you simply have to break the end to end encryption Yes, (or) deny service by Policy (remains to evaluate who's happy with that). Cheers, mh > > On 06/17/2018 03:09 AM, Matthew Petach wrote: >> Except that if websites are set to HTTPS only, there's no option for >> disabling encryption on the client side. >> >> Matt >> >> >> On Sat, Jun 16, 2018, 14:47 wrote: >> >>> On 06/16/2018 10:13 PM, Mike Hammett wrote: >>>> Sadly, it's just falling on deaf ears. Silicon Valley will continue >>>> to >>> think they know better than everyone else and people outside of that >>> bubble >>> will continue to be disadvantaged. >>> >>> What, again ? >>> Encryption is what is best for the most people. >>> The few that will not use it can disable it. >>> >>> No issue then. >>> >>> >> From nanog at ics-il.net Sun Jun 17 19:47:45 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 17 Jun 2018 14:47:45 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <20180617185400.2834180181@mail.alphavpn.com> References: <20180617185400.2834180181@mail.alphavpn.com> Message-ID: <1662848239.4320.1529264861407.JavaMail.mhammett@ThunderFuck> If additional capacity were something feasible, it would be done. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brad" To: nanog at nanog.org Sent: Sunday, June 17, 2018 1:53:52 PM Subject: Re: Impacts of Encryption Everywhere (any solution?) While I agree there are unintended consequences every time advancements are made in relation to the security and stability of the Internet- I disagree we should be rejecting their implementations. Instead, we should innovate further. Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity. -Brad -------- Original message --------From: Michael Hallgren Date: 6/17/18 11:14 (GMT-07:00) To: nanog at jack.fr.eu.org Cc: Matthew Petach , nanog at nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) Le 2018-06-17 12:40, nanog at jack.fr.eu.org a écrit : > Well, yes, there is, you simply have to break the end to end encryption Yes, (or) deny service by Policy (remains to evaluate who's happy with that). Cheers, mh > > On 06/17/2018 03:09 AM, Matthew Petach wrote: >> Except that if websites are set to HTTPS only, there's no option for >> disabling encryption on the client side. >> >> Matt >> >> >> On Sat, Jun 16, 2018, 14:47 wrote: >> >>> On 06/16/2018 10:13 PM, Mike Hammett wrote: >>>> Sadly, it's just falling on deaf ears. Silicon Valley will continue >>>> to >>> think they know better than everyone else and people outside of that >>> bubble >>> will continue to be disadvantaged. >>> >>> What, again ? >>> Encryption is what is best for the most people. >>> The few that will not use it can disable it. >>> >>> No issue then. >>> >>> >> From bill at herrin.us Sun Jun 17 20:03:24 2018 From: bill at herrin.us (William Herrin) Date: Sun, 17 Jun 2018 16:03:24 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <327156475.3871.1529180031823.JavaMail.mhammett@ThunderFuck> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <837f56b5-65f1-12e5-7b89-c1a387dbef9a@retevia.net> <327156475.3871.1529180031823.JavaMail.mhammett@ThunderFuck> Message-ID: On Sat, Jun 16, 2018 at 4:13 PM, Mike Hammett wrote: > Sadly, it's just falling on deaf ears. Silicon Valley will continue to think they know better than everyone else and people outside of that bubble will continue to be disadvantaged. Hi Mike, When the U.S. Government wants to encrypt classified information for transmission over an unclassified channel (such as the Internet) one of the interesting things the encryptor does is send data at a constant rate. If there isn't enough data to fill the channel, the encryptor pads its transmission with random bytes. If there's more data than the constant rate, it's queued and sent at a constant rate, even if the channel could handle more. Even over the internet where variable rate transmissions are the norm. This increases the _depth of defense_ against an adversary. Not only does the adversary have to figure out what you're saying, he has to figure out when and whether you're speaking at all. Depth of Defense. Remember that phrase; you'll hear it over and over again when security experts speak. Encrypting everything (not just information you consider private) also increases the depth of your defense against an adversary attempting to capture your secrets. An adversary must not only break or subvert your encryption, he must also figure out which if any of your communications are sensitive and which are banal. Depth of Defense. One of the linchpin concepts in effective security. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mark.tinka at seacom.mu Mon Jun 18 12:21:14 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 18 Jun 2018 14:21:14 +0200 Subject: Google Peering/Edge Network Contact? In-Reply-To: References: Message-ID: <5869e5e6-ac4d-028b-160d-73ce7bec6305@seacom.mu> On 15/Jun/18 00:02, Zach Puls wrote: > Does anyone have a contact for Google Peering / PNI? > > We have a caching appliance whose BGP session has been flapping nonstop for > the past month or so. We've had a ticket open with Google since it started, > but they haven't really made any headway, or provided much of a response. IIRC, if you're talking about their GGC (or the evolution of it), flapping BGP sessions is normal. BGP, in this case, is used for mapping and not routing. Google only say to complain if the session is down for more than an hour. Of course, it's possible you have a totally different issue. Mark. From hugo at slabnet.com Mon Jun 18 15:45:04 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 18 Jun 2018 08:45:04 -0700 Subject: BGP in a containers In-Reply-To: References: <226c82eb-41cb-7a6a-fcb9-02bf84453549@mtcc.com> Message-ID: <20180618154504.GA883@bamboo.slabnet.com> On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess wrote: > >Running the BGP application in a container on a shared storage system managed by >a host cluster would also make it easier to start the service up on a >different host when >the first host fails or requires maintenance. > >On the other hand, running directly on a host, suggests that >individual hosts need >to be backed up again, and some sort of manual restore of local >files from the lost host >will be required to copy the non-containerized application to a new host. Even if the BGP speaker is running right on the host, the shared storage or backups thing doesn't click for me. What about your BGP speaker will need persistent storage? At least in our environment, everything unique about the BGP speaker is config injected at startup or can be derived at startup. This might be based on differences in how we're using them (BGP daemon per container host in our case, rather than "I need X number of BGP speakers; schedule them somewhere"), I guess. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From luke at snabb.co Sat Jun 16 18:28:47 2018 From: luke at snabb.co (Luke Gorrie) Date: Sat, 16 Jun 2018 20:28:47 +0200 Subject: fd.io vs cumulus vs snabb vs OVS vs OpenNSL In-Reply-To: References: Message-ID: On Thu, 14 Jun 2018 at 22:17, Marcus Leske wrote: > Any thought leader on the list to shed some light to what is happening > in the world of open networking ? OVS vs OpenNSL vs Cumulus vs fd.io > vs Snabb vs a lot of stuff :) > > Where is this going ? I work on Snabb and to me our most interesting application area is "the long tail." You have a problem that you can describe on a whiteboard, but you can't get an off-the-shelf solution for, and you want to solve it by sitting down and writing an ordinary program in an ordinary high level programming language. So that is what you do. It's not necessarily *easy* but it is straight forwardly similar to the way people write other programs in languages like perl/python/ruby/javascript/etc. From jwalter at weebly.com Mon Jun 18 18:13:29 2018 From: jwalter at weebly.com (Jeff Walter) Date: Mon, 18 Jun 2018 11:13:29 -0700 Subject: BGP in a containers In-Reply-To: <20180618154504.GA883@bamboo.slabnet.com> References: <226c82eb-41cb-7a6a-fcb9-02bf84453549@mtcc.com> <20180618154504.GA883@bamboo.slabnet.com> Message-ID: Years back I ran ExaBGP inside a Docker container (when it wasn't "production ready") to anycast a contained service both within a datacenter and across them. To make routing work correctly I had to also run another BGP daemon on the Docker host machine; I can't remember if I used bird for this, but it seems like what I'd use since I didn't need programmatic control of prefixes. Would I do it that way today? Not a chance. How would I do it? That would really depend on two things: what I'm trying to accomplish with BGP and what the service is. If you just want portability of a service (not redundancy/balancing via anycast) is BGP really the best option? I'd make a strong case for OSPF due to it needing far less config. The same need for a routing instance on the Docker host would apply, but you wouldn't need to manage configuration for neighbors as containers come up and go down (since the IP will likely change). Sure, you could just add neighbor config for every IP Docker might use, however-- ouch. Jeff Walter On Mon, Jun 18, 2018 at 8:45 AM, Hugo Slabbert wrote: > > On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess wrote: > > >> Running the BGP application in a container on a shared storage system >> managed by >> a host cluster would also make it easier to start the service up on a >> different host when >> the first host fails or requires maintenance. >> >> On the other hand, running directly on a host, suggests that >> individual hosts need >> to be backed up again, and some sort of manual restore of local >> files from the lost host >> will be required to copy the non-containerized application to a new host. >> > > Even if the BGP speaker is running right on the host, the shared storage > or backups thing doesn't click for me. What about your BGP speaker will > need persistent storage? At least in our environment, everything unique > about the BGP speaker is config injected at startup or can be derived at > startup. This might be based on differences in how we're using them (BGP > daemon per container host in our case, rather than "I need X number of BGP > speakers; schedule them somewhere"), I guess. > > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > From dclements at gmail.com Mon Jun 18 18:29:41 2018 From: dclements at gmail.com (Doug Clements) Date: Mon, 18 Jun 2018 14:29:41 -0400 Subject: BGP in a containers In-Reply-To: References: <226c82eb-41cb-7a6a-fcb9-02bf84453549@mtcc.com> <20180618154504.GA883@bamboo.slabnet.com> Message-ID: These days I think the idea is to use unnumbered or dynamic neighbors so most of the configuration complexity goes away: https://docs.cumulusnetworks.com/display/DOCS/Border+Gateway+Protocol+-+BGP#BorderGatewayProtocol-BGP-ConfiguringBGPUnnumberedInterfaces In this case, your container would peer directly with the switch. --Doug On Mon, Jun 18, 2018 at 2:13 PM, Jeff Walter wrote: > Years back I ran ExaBGP inside a Docker container (when it wasn't > "production ready") to anycast a contained service both within a datacenter > and across them. To make routing work correctly I had to also run another > BGP daemon on the Docker host machine; I can't remember if I used bird for > this, but it seems like what I'd use since I didn't need programmatic > control of prefixes. > > Would I do it that way today? Not a chance. How would I do it? That would > really depend on two things: what I'm trying to accomplish with BGP and > what the service is. If you just want portability of a service (not > redundancy/balancing via anycast) is BGP really the best option? I'd make a > strong case for OSPF due to it needing far less config. The same need for a > routing instance on the Docker host would apply, but you wouldn't need to > manage configuration for neighbors as containers come up and go down (since > the IP will likely change). Sure, you could just add neighbor config for > every IP Docker might use, however-- ouch. > > Jeff Walter > > On Mon, Jun 18, 2018 at 8:45 AM, Hugo Slabbert wrote: > > > > > On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess wrote: > > > > > >> Running the BGP application in a container on a shared storage system > >> managed by > >> a host cluster would also make it easier to start the service up on a > >> different host when > >> the first host fails or requires maintenance. > >> > >> On the other hand, running directly on a host, suggests that > >> individual hosts need > >> to be backed up again, and some sort of manual restore of local > >> files from the lost host > >> will be required to copy the non-containerized application to a new > host. > >> > > > > Even if the BGP speaker is running right on the host, the shared storage > > or backups thing doesn't click for me. What about your BGP speaker will > > need persistent storage? At least in our environment, everything unique > > about the BGP speaker is config injected at startup or can be derived at > > startup. This might be based on differences in how we're using them (BGP > > daemon per container host in our case, rather than "I need X number of > BGP > > speakers; schedule them somewhere"), I guess. > > > > > > -- > > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > > pgp key: B178313E | also on Signal > > > From job at ntt.net Mon Jun 18 21:08:05 2018 From: job at ntt.net (Job Snijders) Date: Mon, 18 Jun 2018 23:08:05 +0200 Subject: Time to add 2002::/16 to bogon filters? Message-ID: Dear all, TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? It is kind of strange that in the default-free zone (where we don’t announce defaults to each other) - we will propagate what is effectively an IPv4 default-route, in the IPv6 DFZ. IETF has politely abandoned the prefix: https://tools.ietf.org/html/rfc7526 Wes George highlighted operational problems from accepting 2002::/16 on the data-plane slide 6: http://iepg.org/2018-03-18-ietf101/wes.pdf Is there still really any legit reason left to accept, or propagate, 2002::/16 on EBGP sessions in the DFZ? Kind regards, Job From jtk at depaul.edu Mon Jun 18 21:48:06 2018 From: jtk at depaul.edu (John Kristoff) Date: Mon, 18 Jun 2018 16:48:06 -0500 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: Message-ID: <20180618164806.03c9ff42@p50.localdomain> On Mon, 18 Jun 2018 21:08:05 +0000 Job Snijders wrote: > TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? Hi Job, I've been asking people about this recently. I don't particularly like having misdirected traffic or badly configured hosts sending junk to those who happen to be announcing addresses from this prefix. I'm planning on adding this to a bogon filter here. John From C-Mack.McBride at charter.com Mon Jun 18 22:56:58 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Mon, 18 Jun 2018 22:56:58 +0000 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <20180618164806.03c9ff42@p50.localdomain> References: <20180618164806.03c9ff42@p50.localdomain> Message-ID: This should have been filtered before. Lots of people improperly implemented this so it caused issues. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Kristoff Sent: Monday, June 18, 2018 3:48 PM To: Job Snijders Cc: NANOG [nanog at nanog.org] Subject: Re: Time to add 2002::/16 to bogon filters? On Mon, 18 Jun 2018 21:08:05 +0000 Job Snijders wrote: > TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? Hi Job, I've been asking people about this recently. I don't particularly like having misdirected traffic or badly configured hosts sending junk to those who happen to be announcing addresses from this prefix. I'm planning on adding this to a bogon filter here. John E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From jared at puck.nether.net Mon Jun 18 23:00:13 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 18 Jun 2018 19:00:13 -0400 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: Message-ID: > On Jun 18, 2018, at 5:08 PM, Job Snijders wrote: > > Dear all, > > TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > It is kind of strange that in the default-free zone (where we don’t > announce defaults to each other) - we will propagate what is effectively an > IPv4 default-route, in the IPv6 DFZ. > > IETF has politely abandoned the prefix: > https://tools.ietf.org/html/rfc7526 I don’t believe there is a reason that folks should accept this prefix from a transit/peer. If they have need for 6to4 within their network, they should operate their own local 6to4 relays. It seems native IPv6 is fairly widely available: https://www.google.com/intl/en/ipv6/statistics.html And there is almost zero 6to4 activity in those stats as well. Since it’s a known path for abuse as well, I would expect networks to not carry these IPv6 routes and filter them. - Jared From marka at isc.org Mon Jun 18 23:34:58 2018 From: marka at isc.org (Mark Andrews) Date: Tue, 19 Jun 2018 09:34:58 +1000 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: <20180618164806.03c9ff42@p50.localdomain> Message-ID: <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It they don’t want it all they have to do is withdraw the prefix. It is not up to the rest of us to second guess their decision to keep providing support. If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY. None of the problems required removing it from BGP. There were end sites that had firewalls that blocked 6to4 responses and the odd site that ran a gateway and failed to properly manage it. The rest could have been dealt with by configuring more gateways. If every dual stacked ASN had run their own gateways there wouldn’t have been a scaling issue. i.e. take the 2002::/16 traffic and dump it onto IPv4 as soon as possible and take the encapsulated traffic for the rest of IPv6 and de-encapsulate it as soon as possible. Mark > On 19 Jun 2018, at 8:56 am, McBride, Mack wrote: > > This should have been filtered before. > Lots of people improperly implemented this so it caused issues. > > Mack > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Kristoff > Sent: Monday, June 18, 2018 3:48 PM > To: Job Snijders > Cc: NANOG [nanog at nanog.org] > Subject: Re: Time to add 2002::/16 to bogon filters? > > On Mon, 18 Jun 2018 21:08:05 +0000 > Job Snijders wrote: > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > Hi Job, > > I've been asking people about this recently. I don't particularly like having misdirected traffic or badly configured hosts sending junk to those who happen to be announcing addresses from this prefix. I'm planning on adding this to a bogon filter here. > > John > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Tue Jun 19 00:23:46 2018 From: cb.list6 at gmail.com (Ca By) Date: Mon, 18 Jun 2018 17:23:46 -0700 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> Message-ID: On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews wrote: > If a ASN is announcing 2002::/16 then they are are happy to get the > traffic. It > they don’t want it all they have to do is withdraw the prefix. It is not > up to > the rest of us to second guess their decision to keep providing support. > That sounds like an interesting attack scenario where a malicious actor can insert themselves in a path, via bgp, announcing 6to4 space > If you filter 2002::/16 then you are performing a denial-of-service attack > on > the few sites that are still using it DELIBERATELY. > > None of the problems required removing it from BGP. There were end sites > that > had firewalls that blocked 6to4 responses and the odd site that ran a > gateway > and failed to properly manage it. The rest could have been dealt with by > configuring more gateways. If every dual stacked ASN had run their own > gateways > there wouldn’t have been a scaling issue. i.e. take the 2002::/16 traffic > and > dump it onto IPv4 as soon as possible and take the encapsulated traffic > for the > rest of IPv6 and de-encapsulate it as soon as possible. > > Mark > > On 19 Jun 2018, at 8:56 am, McBride, Mack > wrote: > > > > This should have been filtered before. > > Lots of people improperly implemented this so it caused issues. > > > > Mack > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Kristoff > > Sent: Monday, June 18, 2018 3:48 PM > > To: Job Snijders > > Cc: NANOG [nanog at nanog.org] > > Subject: Re: Time to add 2002::/16 to bogon filters? > > > > On Mon, 18 Jun 2018 21:08:05 +0000 > > Job Snijders wrote: > > > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > > > Hi Job, > > > > I've been asking people about this recently. I don't particularly like > having misdirected traffic or badly configured hosts sending junk to those > who happen to be announcing addresses from this prefix. I'm planning on > adding this to a bogon filter here. > > > > John > > E-MAIL CONFIDENTIALITY NOTICE: > > The contents of this e-mail message and any attachments are intended > solely for the addressee(s) and may contain confidential and/or legally > privileged information. If you are not the intended recipient of this > message or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message > and any attachments. If you are not the intended recipient, you are > notified that any use, dissemination, distribution, copying, or storage of > this message or any attachment is strictly prohibited. > > > > -- > 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 Tue Jun 19 00:31:43 2018 From: marka at isc.org (Mark Andrews) Date: Tue, 19 Jun 2018 10:31:43 +1000 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> Message-ID: <112D8652-88A8-468C-B360-E8FB10D69B70@isc.org> If you are using 2002::/16 you know are relying on third parties. Not that it is much different to any other address where you are relying on third parties. If one is going to filter 2002::/16 from BGP then install your own gateway to preserve the functionality. > On 19 Jun 2018, at 10:23 am, Ca By wrote: > > > > On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews wrote: > If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It > they don’t want it all they have to do is withdraw the prefix. It is not up to > the rest of us to second guess their decision to keep providing support. > > That sounds like an interesting attack scenario where a malicious actor can insert themselves in a path, via bgp, announcing 6to4 space > > > If you filter 2002::/16 then you are performing a denial-of-service attack on > the few sites that are still using it DELIBERATELY. > > None of the problems required removing it from BGP. There were end sites that > had firewalls that blocked 6to4 responses and the odd site that ran a gateway > and failed to properly manage it. The rest could have been dealt with by > configuring more gateways. If every dual stacked ASN had run their own gateways > there wouldn’t have been a scaling issue. i.e. take the 2002::/16 traffic and > dump it onto IPv4 as soon as possible and take the encapsulated traffic for the > rest of IPv6 and de-encapsulate it as soon as possible. > > Mark > > On 19 Jun 2018, at 8:56 am, McBride, Mack wrote: > > > > This should have been filtered before. > > Lots of people improperly implemented this so it caused issues. > > > > Mack > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Kristoff > > Sent: Monday, June 18, 2018 3:48 PM > > To: Job Snijders > > Cc: NANOG [nanog at nanog.org] > > Subject: Re: Time to add 2002::/16 to bogon filters? > > > > On Mon, 18 Jun 2018 21:08:05 +0000 > > Job Snijders wrote: > > > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > > > Hi Job, > > > > I've been asking people about this recently. I don't particularly like having misdirected traffic or badly configured hosts sending junk to those who happen to be announcing addresses from this prefix. I'm planning on adding this to a bogon filter here. > > > > John > > E-MAIL CONFIDENTIALITY NOTICE: > > The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. > > > > -- > 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 cb.list6 at gmail.com Tue Jun 19 00:37:40 2018 From: cb.list6 at gmail.com (Ca By) Date: Mon, 18 Jun 2018 17:37:40 -0700 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <112D8652-88A8-468C-B360-E8FB10D69B70@isc.org> References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> <112D8652-88A8-468C-B360-E8FB10D69B70@isc.org> Message-ID: On Mon, Jun 18, 2018 at 5:31 PM Mark Andrews wrote: > If you are using 2002::/16 you know are relying on third parties. I highlly doubt most people using 6to4 know they are using it, let alone the arbitrary nature of its routing. Not that it is much > different to any other address where you are relying on third parties. > > If one is going to filter 2002::/16 from BGP then install your own gateway > to preserve > the functionality. > > > On 19 Jun 2018, at 10:23 am, Ca By wrote: > > > > > > > > On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews wrote: > > If a ASN is announcing 2002::/16 then they are are happy to get the > traffic. It > > they don’t want it all they have to do is withdraw the prefix. It is > not up to > > the rest of us to second guess their decision to keep providing support. > > > > That sounds like an interesting attack scenario where a malicious actor > can insert themselves in a path, via bgp, announcing 6to4 space > > > > > > If you filter 2002::/16 then you are performing a denial-of-service > attack on > > the few sites that are still using it DELIBERATELY. > > > > None of the problems required removing it from BGP. There were end > sites that > > had firewalls that blocked 6to4 responses and the odd site that ran a > gateway > > and failed to properly manage it. The rest could have been dealt with by > > configuring more gateways. If every dual stacked ASN had run their own > gateways > > there wouldn’t have been a scaling issue. i.e. take the 2002::/16 > traffic and > > dump it onto IPv4 as soon as possible and take the encapsulated traffic > for the > > rest of IPv6 and de-encapsulate it as soon as possible. > > > > Mark > > > On 19 Jun 2018, at 8:56 am, McBride, Mack > wrote: > > > > > > This should have been filtered before. > > > Lots of people improperly implemented this so it caused issues. > > > > > > Mack > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John > Kristoff > > > Sent: Monday, June 18, 2018 3:48 PM > > > To: Job Snijders > > > Cc: NANOG [nanog at nanog.org] > > > Subject: Re: Time to add 2002::/16 to bogon filters? > > > > > > On Mon, 18 Jun 2018 21:08:05 +0000 > > > Job Snijders wrote: > > > > > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > > > > > Hi Job, > > > > > > I've been asking people about this recently. I don't particularly > like having misdirected traffic or badly configured hosts sending junk to > those who happen to be announcing addresses from this prefix. I'm planning > on adding this to a bogon filter here. > > > > > > John > > > E-MAIL CONFIDENTIALITY NOTICE: > > > The contents of this e-mail message and any attachments are intended > solely for the addressee(s) and may contain confidential and/or legally > privileged information. If you are not the intended recipient of this > message or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message > and any attachments. If you are not the intended recipient, you are notified > that any use, dissemination, distribution, cop > ying, > or storage of this message or any attachment is strictly prohibited. > > > > > > > -- > > 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 jared at puck.nether.net Tue Jun 19 01:18:23 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 18 Jun 2018 21:18:23 -0400 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <112D8652-88A8-468C-B360-E8FB10D69B70@isc.org> References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> <112D8652-88A8-468C-B360-E8FB10D69B70@isc.org> Message-ID: <38CC5D4D-80AE-43AB-890E-CB44D2174199@puck.nether.net> > On Jun 18, 2018, at 8:31 PM, Mark Andrews wrote: > > If you are using 2002::/16 you know are relying on third parties. Not that it is much > different to any other address where you are relying on third parties. > > If one is going to filter 2002::/16 from BGP then install your own gateway to preserve > the functionality. It does not appear the functionality is working at present, which I think is the more critical point. Taking a quick sampling of where I see the packets going from two different networks, it doesn’t seem to be going where it’s expected, nor is it working as expected. These appear to be at best routing leaks similar to leaking rfc6761 space that should be under your local control. They could also be seen as a privacy issue by taking packets destined to 2002::/16 somewhere unexpected and off-continent. I would expect even in the cases where it does work, it would be subject to the same challenges faced by people using VPN services (being blocked from your kids favorite streaming services) and much poorer performance than native IPv4. There is also the problem noted by Wes George with 6to4 being used in DNS amplification, which may be interesting.. http://iepg.org/2018-03-18-ietf101/wes.pdf I don’t believe most providers are intending to offer 6to4 as a global service. Even the large providers (eg: Comcast) seem to have disabled it ~4+ years ago. While I know there’s people on the internet that like to hang on to legacy things, this is one that should end. The networks and devices today no longer require this sort of transition technology, and the networks where it’s left won’t want it as it will be used for various bad things(tm). - Jared From jsklein at gmail.com Tue Jun 19 01:32:51 2018 From: jsklein at gmail.com (j k) Date: Mon, 18 Jun 2018 21:32:51 -0400 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <38CC5D4D-80AE-43AB-890E-CB44D2174199@puck.nether.net> References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> <112D8652-88A8-468C-B360-E8FB10D69B70@isc.org> <38CC5D4D-80AE-43AB-890E-CB44D2174199@puck.nether.net> Message-ID: This week I began mapping IPv6 SPAM headers "Received:" and "X-Received:" and have discovered over 50% are from: 10.0.0.0 – 10.255.255.255 2002:0a00:: - 2002:aff:ffff:ffff:ffff:ffff:ffff:ffff 172.16.0.0 – 172.31.255.255 2002:ac10:: - 2002:ac10:ffff:ffff:ffff:ffff:ffff:ffff 192.168.0.0 – 192.168.255.255 2002:c0A8:: - 2002:c0A8:ffff:ffff:ffff:ffff:ffff:ffff Can anyone else confirm my findings? Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Mon, Jun 18, 2018 at 9:18 PM, Jared Mauch wrote: > > > > On Jun 18, 2018, at 8:31 PM, Mark Andrews wrote: > > > > If you are using 2002::/16 you know are relying on third parties. Not > that it is much > > different to any other address where you are relying on third parties. > > > > If one is going to filter 2002::/16 from BGP then install your own > gateway to preserve > > the functionality. > > It does not appear the functionality is working at present, which I think > is the more critical point. Taking a quick sampling of where I see the > packets going from two different networks, it doesn’t seem to be going > where it’s expected, nor is it working as expected. These appear to be at > best routing leaks similar to leaking rfc6761 space that should be under > your local control. They could also be seen as a privacy issue by taking > packets destined to 2002::/16 somewhere unexpected and off-continent. > > I would expect even in the cases where it does work, it would be subject > to the same challenges faced by people using VPN services (being blocked > from your kids favorite streaming services) and much poorer performance > than native IPv4. > > There is also the problem noted by Wes George with 6to4 being used in DNS > amplification, which may be interesting.. > > http://iepg.org/2018-03-18-ietf101/wes.pdf > > I don’t believe most providers are intending to offer 6to4 as a global > service. Even the large providers (eg: Comcast) seem to have disabled it > ~4+ years ago. While I know there’s people on the internet that like to > hang on to legacy things, this is one that should end. The networks and > devices today no longer require this sort of transition technology, and the > networks where it’s left won’t want it as it will be used for various bad > things(tm). > > - Jared From chk at pobox.com Tue Jun 19 01:39:58 2018 From: chk at pobox.com (Harald Koch) Date: Mon, 18 Jun 2018 21:39:58 -0400 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> <112D8652-88A8-468C-B360-E8FB10D69B70@isc.org> Message-ID: 20 years from now when the IETF decides to reclaim / repurpose that prefix, y'all are going to have to run around removing it from your filters again... -- Harald From joelja at bogus.com Tue Jun 19 05:58:47 2018 From: joelja at bogus.com (joel jaeggli) Date: Mon, 18 Jun 2018 22:58:47 -0700 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: Message-ID: <804df776-c879-13c9-df64-46fdf250ea52@bogus.com> I personally would love to see social pressure applied removing this from the internet. certain prominent google search results. e.g. https://getipv6.info/display/IPv6/Linux+or+BSD+6to4+Relays probably also could use some curation given the appropriateness of reling on a anycast translator for your transition at this point. On 6/18/18 2:08 PM, Job Snijders wrote: > Dear all, > > TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > It is kind of strange that in the default-free zone (where we don’t > announce defaults to each other) - we will propagate what is effectively an > IPv4 default-route, in the IPv6 DFZ. > > IETF has politely abandoned the prefix: > https://tools.ietf.org/html/rfc7526 > > Wes George highlighted operational problems from accepting 2002::/16 on the > data-plane slide 6: > http://iepg.org/2018-03-18-ietf101/wes.pdf > > Is there still really any legit reason left to accept, or propagate, > 2002::/16 on EBGP sessions in the DFZ? > > Kind regards, > > Job > From joelja at bogus.com Tue Jun 19 06:04:29 2018 From: joelja at bogus.com (joel jaeggli) Date: Mon, 18 Jun 2018 23:04:29 -0700 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <38CC5D4D-80AE-43AB-890E-CB44D2174199@puck.nether.net> References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> <112D8652-88A8-468C-B360-E8FB10D69B70@isc.org> <38CC5D4D-80AE-43AB-890E-CB44D2174199@puck.nether.net> Message-ID: On 6/18/18 6:18 PM, Jared Mauch wrote: > I don’t believe most providers are intending to offer 6to4 as a global service. Even the large providers (eg: Comcast) seem to have disabled it ~4+ years ago. While I know there’s people on the internet that like to hang on to legacy things, this is one that should end. The networks and devices today no longer require this sort of transition technology, and the networks where it’s left won’t want it as it will be used for various bad things(tm). At some point it transitions from being a legacy transition tool which you really shouldn't be using to being an attractive nuisance, or worse genuinely dangerous either for the sender or the receiver. personally I think we've crossed that point and we have a responsibility to insure proper burial. > - Jared > From niels=nanog at bakker.net Tue Jun 19 09:15:09 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 19 Jun 2018 11:15:09 +0200 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> Message-ID: <20180619091509.GA3074@excession.tpb.net> * marka at isc.org (Mark Andrews) [Tue 19 Jun 2018, 01:35 CEST]: >If you filter 2002::/16 then you are performing a denial-of-service >attack on the few sites that are still using it DELIBERATELY. Find me one site with a competent admin that deliberately publishes 2002::/16 in DNS. >None of the problems required removing it from BGP. There were end >sites that had firewalls that blocked 6to4 responses and the odd >site that ran a gateway and failed to properly manage it. The rest >could have been dealt with by configuring more gateways. Could. But hasn't. Right now it's merely a security risk. People who used to run a gateway and competently managed it took them down years ago when they, being competent admins, realised the utility had run out. -- Niels. From dot at dotat.at Tue Jun 19 09:47:39 2018 From: dot at dotat.at (Tony Finch) Date: Tue, 19 Jun 2018 10:47:39 +0100 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <38CC5D4D-80AE-43AB-890E-CB44D2174199@puck.nether.net> References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> <112D8652-88A8-468C-B360-E8FB10D69B70@isc.org> <38CC5D4D-80AE-43AB-890E-CB44D2174199@puck.nether.net> Message-ID: Jared Mauch wrote: > > There is also the problem noted by Wes George with 6to4 being used in > DNS amplification, which may be interesting.. > > http://iepg.org/2018-03-18-ietf101/wes.pdf I configure my DNS servers with a long-ish list of bogon addresses. For v6, the list includes Teredo and 6to4 and various other horrors: # RFC 5156 and IANA IPv6 address space registry server 0000::/3 { bogus yes; }; server 2001:0000::/32 { bogus yes; }; server 2001:0002::/48 { bogus yes; }; server 2001:0010::/28 { bogus yes; }; server 2001:0db8::/32 { bogus yes; }; server 2002::/16 { bogus yes; }; server 3000::/4 { bogus yes; }; server 4000::/2 { bogus yes; }; server 8000::/1 { bogus yes; }; Tony. -- f.anthony.n.finch http://dotat.at/ Southeast Iceland: Cyclonic, mainly westerly, 6 to gale 8, decreasing 5 later. Rough or very rough, becoming moderate or rough later. Showers. Moderate or good. From nanog at radu-adrian.feurdean.net Tue Jun 19 11:52:17 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Tue, 19 Jun 2018 13:52:17 +0200 Subject: WC 2018 impact on network yet In-Reply-To: References: Message-ID: <1529409137.1607014.1413003552.3B63BDC6@webmail.messagingengine.com> On Sat, Jun 16, 2018, at 22:07, Keith Medcalf wrote: > > People stream HD Video in the Water Closet? I don't think my 80" HDTV > would fit in there! I don't think they do that, but they are more and more to receive regular TV via OTT STBs. And sport events, which attract viewers, are better candidates for higher definition (those days 4K) than regular tv programs (some of them still SD, some "regular HD"). So when everybody will watch the local favourite's match (important ones), we do expect traffic levels to be higher than usual. From lee.howard at retevia.net Tue Jun 19 14:53:49 2018 From: lee.howard at retevia.net (Lee Howard) Date: Tue, 19 Jun 2018 10:53:49 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <20180617185400.2834180181@mail.alphavpn.com> References: <20180617185400.2834180181@mail.alphavpn.com> Message-ID: <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> On 06/17/2018 02:53 PM, Brad wrote: > While I agree there are unintended consequences every time advancements are made in relation to the security and stability of the Internet- I disagree we should be rejecting their implementations. Instead, we should innovate further. I look forward to your innovations. > Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity. I encourage you to invest billions of dollars in rural broadband capacity worldwide. The rest of us will thank you for your sacrifice. Lee > -Brad > > -------- Original message --------From: Michael Hallgren Date: 6/17/18 11:14 (GMT-07:00) To: nanog at jack.fr.eu.org Cc: Matthew Petach , nanog at nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) > Le 2018-06-17 12:40, nanog at jack.fr.eu.org a écrit : >> Well, yes, there is, you simply have to break the end to end encryption > Yes, (or) deny service by Policy (remains to evaluate who's happy with > that). > > Cheers, > mh > >> On 06/17/2018 03:09 AM, Matthew Petach wrote: >>> Except that if websites are set to HTTPS only, there's no option for >>> disabling encryption on the client side. >>> >>> Matt >>> >>> >>> On Sat, Jun 16, 2018, 14:47 wrote: >>> >>>> On 06/16/2018 10:13 PM, Mike Hammett wrote: >>>>> Sadly, it's just falling on deaf ears. Silicon Valley will continue >>>>> to >>>> think they know better than everyone else and people outside of that >>>> bubble >>>> will continue to be disadvantaged. >>>> >>>> What, again ? >>>> Encryption is what is best for the most people. >>>> The few that will not use it can disable it. >>>> >>>> No issue then. >>>> >>>> From george.herbert at gmail.com Tue Jun 19 15:29:15 2018 From: george.herbert at gmail.com (George Herbert) Date: Tue, 19 Jun 2018 08:29:15 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> References: <20180617185400.2834180181@mail.alphavpn.com> <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> Message-ID: I’m confused. People are using last hop (wireless) arguments against HTTPS Everywhere; that’s the part that requires full bandwidth either way (as your non-HTTPS cache is upstream somewhere). The fiber links that are physically fixed and can handle in many cases better lasers, are the ongoing upgradable part. If you’re complaining your fiber backhaul is too big a deal, you’re playing the wrong game to start with. George William Herbert Sent from my iPhone > On Jun 19, 2018, at 7:53 AM, Lee Howard wrote: > > > >> On 06/17/2018 02:53 PM, Brad wrote: >> While I agree there are unintended consequences every time advancements are made in relation to the security and stability of the Internet- I disagree we should be rejecting their implementations. Instead, we should innovate further. > > I look forward to your innovations. >> Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity. > > I encourage you to invest billions of dollars in rural broadband capacity worldwide. The rest of us will thank you for your sacrifice. > > Lee > >> -Brad >> >> -------- Original message --------From: Michael Hallgren Date: 6/17/18 11:14 (GMT-07:00) To: nanog at jack.fr.eu.org Cc: Matthew Petach , nanog at nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) >> Le 2018-06-17 12:40, nanog at jack.fr.eu.org a écrit : >>> Well, yes, there is, you simply have to break the end to end encryption >> Yes, (or) deny service by Policy (remains to evaluate who's happy with >> that). >> >> Cheers, >> mh >> >>>> On 06/17/2018 03:09 AM, Matthew Petach wrote: >>>> Except that if websites are set to HTTPS only, there's no option for >>>> disabling encryption on the client side. >>>> >>>> Matt >>>> >>>> >>>>> On Sat, Jun 16, 2018, 14:47 wrote: >>>>> >>>>>> On 06/16/2018 10:13 PM, Mike Hammett wrote: >>>>>> Sadly, it's just falling on deaf ears. Silicon Valley will continue >>>>>> to >>>>> think they know better than everyone else and people outside of that >>>>> bubble >>>>> will continue to be disadvantaged. >>>>> >>>>> What, again ? >>>>> Encryption is what is best for the most people. >>>>> The few that will not use it can disable it. >>>>> >>>>> No issue then. >>>>> >>>>> > From bill at herrin.us Tue Jun 19 15:33:50 2018 From: bill at herrin.us (William Herrin) Date: Tue, 19 Jun 2018 11:33:50 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> References: <20180617185400.2834180181@mail.alphavpn.com> <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> Message-ID: On Tue, Jun 19, 2018 at 10:53 AM, Lee Howard wrote: > On 06/17/2018 02:53 PM, Brad wrote: >> While I agree there are unintended consequences every time advancements >> are made in relation to the security and stability of the Internet- I >> disagree we should be rejecting their implementations. Instead, we should >> innovate further. > > > I look forward to your innovations. The innovation I'd like to see is a multi-level streaming cache. Here's the basic idea: Define a network protocol such as "mlcache" mlcache://data.netflix.com/starwars/chunk12345 is a chunk of some video that netflix has. It's encrypted. The client got the decryption key for that chunk and instructions on how to load the chunks in what order in an authenticated http connection. The client does not connect to data.netflix.com. Instead, it probes an anycast IP address to find the nearest cache. If there is no cache, then it falls back on contacting data.netflix.com directly. If the cache probe returned a unicast IP address for a nearby cache then the client asks the cache to retrieve that chunk instead. If lots of folks using the cache are watching that particular video, the cache can supply the chunk without asking netflix for it again. If the cache doesn't have the chunk, it contacts the next cache upstream. If there is no next cache upstream, it contacts data.netflix.com directly. The cache is not application-specific. Anything willing to talk the cache protocol can use it to fetch chunks of data from any server. In principle this should work for live streams too. The head end server either replies "not yet" or holds the request open until the next chunk of data is available. The cache requests the chunk once and supplies it to all clients once retrieved. Keep the chunks small enough that the caching process delays the live stream by a second or two, no different than the television broadcasts do. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From C-Mack.McBride at charter.com Tue Jun 19 15:50:05 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Tue, 19 Jun 2018 15:50:05 +0000 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180617185400.2834180181@mail.alphavpn.com> <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> Message-ID: <3e07ac6e71034c77ad71f6e365dadab2@SC58MEXGP032.CORP.CHARTERCOM.com> Netflix is not supposed to be cacheable by third parties for legal reasons that have absolutely nothing to do with routing. Similar with most streaming services including stupid geolocation usage. If you have sufficient eyeballs, Netflix will work with you to get a local cache set up using their devices. If it is just you and a half dozen neighbors they won't. A far larger problem than the encryption is website design that doesn't cater to low bandwidth links. HTML5 is cool but marking a 10mbyte animation as non-cachable and putting it on the front page of a major bank website is a misuse of resources. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin Sent: Tuesday, June 19, 2018 9:34 AM To: Lee Howard Cc: nanog at nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) On Tue, Jun 19, 2018 at 10:53 AM, Lee Howard wrote: > On 06/17/2018 02:53 PM, Brad wrote: >> While I agree there are unintended consequences every time >> advancements are made in relation to the security and stability of >> the Internet- I disagree we should be rejecting their >> implementations. Instead, we should innovate further. > > > I look forward to your innovations. The innovation I'd like to see is a multi-level streaming cache. Here's the basic idea: Define a network protocol such as "mlcache" mlcache://data.netflix.com/starwars/chunk12345 is a chunk of some video that netflix has. It's encrypted. The client got the decryption key for that chunk and instructions on how to load the chunks in what order in an authenticated http connection. The client does not connect to data.netflix.com. Instead, it probes an anycast IP address to find the nearest cache. If there is no cache, then it falls back on contacting data.netflix.com directly. If the cache probe returned a unicast IP address for a nearby cache then the client asks the cache to retrieve that chunk instead. If lots of folks using the cache are watching that particular video, the cache can supply the chunk without asking netflix for it again. If the cache doesn't have the chunk, it contacts the next cache upstream. If there is no next cache upstream, it contacts data.netflix.com directly. The cache is not application-specific. Anything willing to talk the cache protocol can use it to fetch chunks of data from any server. In principle this should work for live streams too. The head end server either replies "not yet" or holds the request open until the next chunk of data is available. The cache requests the chunk once and supplies it to all clients once retrieved. Keep the chunks small enough that the caching process delays the live stream by a second or two, no different than the television broadcasts do. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From valdis.kletnieks at vt.edu Tue Jun 19 16:09:40 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 19 Jun 2018 12:09:40 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180617185400.2834180181@mail.alphavpn.com> <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> Message-ID: <110366.1529424580@turing-police.cc.vt.edu> On Tue, 19 Jun 2018 11:33:50 -0400, William Herrin said: > The innovation I'd like to see is a multi-level streaming cache. > Here's the basic idea: > > Define a network protocol such as "mlcache" > > mlcache://data.netflix.com/starwars/chunk12345 is a chunk of some > video that netflix has. It's encrypted. The client got the decryption > key for that chunk and instructions on how to load the chunks in what > order in an authenticated http connection. > > The client does not connect to data.netflix.com. Instead, it probes an > anycast IP address to find the nearest cache. If there is no cache, > then it falls back on contacting data.netflix.com directly. > > If the cache probe returned a unicast IP address for a nearby cache > then the client asks the cache to retrieve that chunk instead. If lots > of folks using the cache are watching that particular video, the cache > can supply the chunk without asking netflix for it again. > > If the cache doesn't have the chunk, it contacts the next cache > upstream. If there is no next cache upstream, it contacts > data.netflix.com directly. Congrats, you just re-invented BitTorrent. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From ml-nanog at techcompute.net Tue Jun 19 16:27:13 2018 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Tue, 19 Jun 2018 09:27:13 -0700 (PDT) Subject: Tunable QSFP Optics Message-ID: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> Does anyone know if any Single Mode QSFPs exist on the market that use wavelengths other than 1310nm (either self tunable or factory tuned)? I am looking to put more than one 40gb link on a fiber pair similar to using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't use 1310nm. Thanks. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From jackson.tim at gmail.com Tue Jun 19 16:31:09 2018 From: jackson.tim at gmail.com (Tim Jackson) Date: Tue, 19 Jun 2018 11:31:09 -0500 Subject: Tunable QSFP Optics In-Reply-To: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> Message-ID: You're gonna need to do something like: https://www.packetlight.com/innovations/40g-connectivity On Tue, Jun 19, 2018 at 11:27 AM, Lewis,Mitchell T. < ml-nanog at techcompute.net> wrote: > Does anyone know if any Single Mode QSFPs exist on the market that use > wavelengths other than 1310nm (either self tunable or factory tuned)? I am > looking to put more than one 40gb link on a fiber pair similar to using > DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't > use 1310nm. > > Thanks. > > > Regards, > > Mitchell T. Lewis > > [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] > > > [ http://linkedin.com/in/mlewiscc ] |203-816-0371 > > PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ > https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public > PGP Key ] > > From dcorbe at hammerfiber.com Tue Jun 19 16:33:58 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 19 Jun 2018 12:33:58 -0400 Subject: Tunable QSFP Optics In-Reply-To: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> Message-ID: QSFPs generally output 4 lanes of traffic. Either 4 channels at 10G or 4 channels at 25G. So unless you find an optic that can do single-channel OTN at 100G, you’re probably going to have a hard time plugging them into a DWDM shelf. at 12:27 PM, Lewis,Mitchell T. wrote: > Does anyone know if any Single Mode QSFPs exist on the market that use > wavelengths other than 1310nm (either self tunable or factory tuned)? I > am looking to put more than one 40gb link on a fiber pair similar to > using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that > don't use 1310nm. > > Thanks. > > > Regards, > > Mitchell T. Lewis > > [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] > > > [ http://linkedin.com/in/mlewiscc ] |203-816-0371 > > PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ > https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public > PGP Key ] From phil.lavin at cloudcall.com Tue Jun 19 16:35:24 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Tue, 19 Jun 2018 16:35:24 +0000 Subject: Tunable QSFP Optics In-Reply-To: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> Message-ID: > Does anyone know if any Single Mode QSFPs exist on the market that use wavelengths other than 1310nm (either self tunable or factory tuned)? > I am looking to put more than one 40gb link on a fiber pair similar to using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't use 1310nm. I've probed our optics vendor about this in the past when trying to achieve something similar. Although they state 1310nm, they actually run at 4 different 10G wavelengths (one of which is 1310) and as such are not suitable for Mux/Demuxing. From lguillory at reservetele.com Tue Jun 19 16:39:00 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 19 Jun 2018 16:39:00 +0000 Subject: Tunable QSFP Optics In-Reply-To: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF73C@RTC-EXCH01.RESERVE.LDS> I believe the 40g and 100g optics are already muxing 4 channels within the transceiver before outputting it to 1310. https://community.fs.com/blog/40gbase-lr4-qsfp-transceiver-links-cwdm-and-psm.html Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lewis,Mitchell T. Sent: Tuesday, June 19, 2018 11:27 AM To: NANOG Subject: Tunable QSFP Optics Does anyone know if any Single Mode QSFPs exist on the market that use wavelengths other than 1310nm (either self tunable or factory tuned)? I am looking to put more than one 40gb link on a fiber pair similar to using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't use 1310nm. Thanks. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From ml-nanog at techcompute.net Tue Jun 19 16:41:44 2018 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Tue, 19 Jun 2018 09:41:44 -0700 (PDT) Subject: Tunable QSFP Optics In-Reply-To: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> Message-ID: <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> Let me clarify a bit-I understand that 40GBase-LR4 uses 4 10g wavelengths(lanes) which typically are: 1264.5- 1277.5 nm 1284.5–1297.5 nm 1304.5–1317.5 nm 1324.5–1337.5 nm My question is are there any vendors that make optics which 4 wavelengths(lanes) are something other than those typically used by 40GBase-LR4? Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From: "Lewis,Mitchell T." To: "NANOG" Sent: Tuesday, 19 June, 2018 12:27:13 Subject: Tunable QSFP Optics Does anyone know if any Single Mode QSFPs exist on the market that use wavelengths other than 1310nm (either self tunable or factory tuned)? I am looking to put more than one 40gb link on a fiber pair similar to using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't use 1310nm. Thanks. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From nick at foobar.org Tue Jun 19 16:44:25 2018 From: nick at foobar.org (Nick Hilliard) Date: Tue, 19 Jun 2018 17:44:25 +0100 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: Message-ID: <1cda1e69-7bd0-25cd-d6d1-5725ccf8f89b@foobar.org> Job Snijders wrote on 18/06/2018 22:08: > Is there still really any legit reason left to accept, or propagate, > 2002::/16 on EBGP sessions in the DFZ? Out of curiosity, I ran a some atlas probe ping tests earlier today to both a 6to4 test host and a separate control host with good quality v6 connectivity: - 11000 6to4 probe requests - 10000 native ipv6 probe requests - 10 pings each - 3308 unique probes replied - 2907 attempted to ping both 6to4 and control hosts - 2569 could ping the control host - 2271 could ping the 6to4 host I.e. ~12% of probes were able to ping the control host, but not the 6to4 host. If anyone wants the measurement IDs, please let me know. Contrary to what Mark implied earlier in this thread about 6to4 connectivity failure being an end-site phenomenon, this figure is caused solely by intermediate path problems. If, as he suggested, end-site problems also contribute to poor quality 6to4 connectivity, then that would compound the failure result. From an operational point of view, what's relevant is whether dropping 2002::/16 would materially affect reliability for 6to4 users. Most serious studies into 6to4 connectivity have shown that it causes high failure rates, so arguably it could be seen as an improvement if you had consistent 100% failure instead of double-digit percentage failure rates to arbitrary 6to4 hosts. Consistency is intrinsically valuable. Despite this, the case for organised action is unclear. If individual operators want to drop the prefix, then that's their concern. If they choose to do so, I suspect that the reaction of most of the ipv6 world will be indifference. Nick From lguillory at reservetele.com Tue Jun 19 16:53:07 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 19 Jun 2018 16:53:07 +0000 Subject: Tunable QSFP Optics In-Reply-To: <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> They still leave the transceiver as a single 1310, the lanes color isn't ever expose since the mux takes place within the transceiver. When I looked into this for 40g and 100g I found no way to passively do it. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lewis,Mitchell T. Sent: Tuesday, June 19, 2018 11:42 AM To: NANOG Subject: Re: Tunable QSFP Optics Let me clarify a bit-I understand that 40GBase-LR4 uses 4 10g wavelengths(lanes) which typically are: 1264.5- 1277.5 nm 1284.5–1297.5 nm 1304.5–1317.5 nm 1324.5–1337.5 nm My question is are there any vendors that make optics which 4 wavelengths(lanes) are something other than those typically used by 40GBase-LR4? Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From: "Lewis,Mitchell T." To: "NANOG" Sent: Tuesday, 19 June, 2018 12:27:13 Subject: Tunable QSFP Optics Does anyone know if any Single Mode QSFPs exist on the market that use wavelengths other than 1310nm (either self tunable or factory tuned)? I am looking to put more than one 40gb link on a fiber pair similar to using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't use 1310nm. Thanks. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From ml-nanog at techcompute.net Tue Jun 19 16:55:42 2018 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Tue, 19 Jun 2018 09:55:42 -0700 (PDT) Subject: Tunable QSFP Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> Message-ID: <669716178.561448.1529427342495.JavaMail.zimbra@techcompute.net> So you weren't able to find anyone that uses different lane colors?(As an example 1550). I am not looking to mux alongside 10g waves, I am just looking to put 3 or 4 on a single fiber pair. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From: "Luke Guillory" To: "Lewis,Mitchell T." , "NANOG" Sent: Tuesday, 19 June, 2018 12:53:07 Subject: RE: Tunable QSFP Optics They still leave the transceiver as a single 1310, the lanes color isn't ever expose since the mux takes place within the transceiver. When I looked into this for 40g and 100g I found no way to passively do it. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lewis,Mitchell T. Sent: Tuesday, June 19, 2018 11:42 AM To: NANOG Subject: Re: Tunable QSFP Optics Let me clarify a bit-I understand that 40GBase-LR4 uses 4 10g wavelengths(lanes) which typically are: 1264.5- 1277.5 nm 1284.5–1297.5 nm 1304.5–1317.5 nm 1324.5–1337.5 nm My question is are there any vendors that make optics which 4 wavelengths(lanes) are something other than those typically used by 40GBase-LR4? Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From: "Lewis,Mitchell T." To: "NANOG" Sent: Tuesday, 19 June, 2018 12:27:13 Subject: Tunable QSFP Optics Does anyone know if any Single Mode QSFPs exist on the market that use wavelengths other than 1310nm (either self tunable or factory tuned)? I am looking to put more than one 40gb link on a fiber pair similar to using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't use 1310nm. Thanks. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From lguillory at reservetele.com Tue Jun 19 17:09:08 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 19 Jun 2018 17:09:08 +0000 Subject: Tunable QSFP Optics In-Reply-To: <669716178.561448.1529427342495.JavaMail.zimbra@techcompute.net> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> <669716178.561448.1529427342495.JavaMail.zimbra@techcompute.net> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FFB25@RTC-EXCH01.RESERVE.LDS> No, though the lane colors are irrelevant since we only care about the final output color. Why the lanes can’t be muxed into another output color I’m not sure, I can only find specs listed for the lanes but nothing for the final mux leaving the transceiver. Luke Guillory Vice President – Technology and Innovation [cid:image379199.JPG at ed701a6b.43904ddf] 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: Lewis,Mitchell T. [mailto:ml-nanog at techcompute.net] Sent: Tuesday, June 19, 2018 11:56 AM To: Luke Guillory Cc: NANOG Subject: Re: Tunable QSFP Optics So you weren't able to find anyone that uses different lane colors?(As an example 1550). I am not looking to mux alongside 10g waves, I am just looking to put 3 or 4 on a single fiber pair. [https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif] Regards, Mitchell T. Lewis MLewis at TechCompute.Net [https://static.licdn.com/scds/common/u/img/webpromo/btn_profile_greytxt_80x15.png]|203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E Public PGP Key ________________________________ From: "Luke Guillory" > To: "Lewis,Mitchell T." >, "NANOG" > Sent: Tuesday, 19 June, 2018 12:53:07 Subject: RE: Tunable QSFP Optics They still leave the transceiver as a single 1310, the lanes color isn't ever expose since the mux takes place within the transceiver. When I looked into this for 40g and 100g I found no way to passively do it. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lewis,Mitchell T. Sent: Tuesday, June 19, 2018 11:42 AM To: NANOG Subject: Re: Tunable QSFP Optics Let me clarify a bit-I understand that 40GBase-LR4 uses 4 10g wavelengths(lanes) which typically are: 1264.5- 1277.5 nm 1284.5–1297.5 nm 1304.5–1317.5 nm 1324.5–1337.5 nm My question is are there any vendors that make optics which 4 wavelengths(lanes) are something other than those typically used by 40GBase-LR4? Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From: "Lewis,Mitchell T." > To: "NANOG" > Sent: Tuesday, 19 June, 2018 12:27:13 Subject: Tunable QSFP Optics Does anyone know if any Single Mode QSFPs exist on the market that use wavelengths other than 1310nm (either self tunable or factory tuned)? I am looking to put more than one 40gb link on a fiber pair similar to using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't use 1310nm. Thanks. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From ml-nanog at techcompute.net Tue Jun 19 17:13:28 2018 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Tue, 19 Jun 2018 10:13:28 -0700 (PDT) Subject: Tunable QSFP Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FFB25@RTC-EXCH01.RESERVE.LDS> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> <669716178.561448.1529427342495.JavaMail.zimbra@techcompute.net> <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FFB25@RTC-EXCH01.RESERVE.LDS> Message-ID: <1862659259.564189.1529428408714.JavaMail.zimbra@techcompute.net> It is a bummer, if 40/100g optics existed that used 1550 or some other color than those could be muxed onto same fiber pair as 1310 optic (The method for passively doing that extraneous to this conversation. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From: "Luke Guillory" To: "Lewis,Mitchell T." Cc: "NANOG" Sent: Tuesday, 19 June, 2018 13:09:08 Subject: RE: Tunable QSFP Optics No, though the lane colors are irrelevant since we only care about the final output color. Why the lanes can’t be muxed into another output color I’m not sure, I can only find specs listed for the lanes but nothing for the final mux leaving the transceiver. Luke Guillory Vice President – Technology and Innovation [ http://www.rtconline.com/ ] 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: Lewis,Mitchell T. [mailto:ml-nanog at techcompute.net] Sent: Tuesday, June 19, 2018 11:56 AM To: Luke Guillory Cc: NANOG Subject: Re: Tunable QSFP Optics So you weren't able to find anyone that uses different lane colors?(As an example 1550). I am not looking to mux alongside 10g waves, I am just looking to put 3 or 4 on a single fiber pair. Regards, Mitchell T. Lewis [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] [ http://linkedin.com/in/mlewiscc ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] From: "Luke Guillory" < [ mailto:lguillory at reservetele.com | lguillory at reservetele.com ] > To: "Lewis,Mitchell T." < [ mailto:ml-nanog at techcompute.net | ml-nanog at techcompute.net ] >, "NANOG" < [ mailto:nanog at nanog.org | nanog at nanog.org ] > Sent: Tuesday, 19 June, 2018 12:53:07 Subject: RE: Tunable QSFP Optics They still leave the transceiver as a single 1310, the lanes color isn't ever expose since the mux takes place within the transceiver. When I looked into this for 40g and 100g I found no way to passively do it. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: [ mailto:lguillory at reservetele.com | 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 | mailto:nanog-bounces at nanog.org ] ] On Behalf Of Lewis,Mitchell T. Sent: Tuesday, June 19, 2018 11:42 AM To: NANOG Subject: Re: Tunable QSFP Optics Let me clarify a bit-I understand that 40GBase-LR4 uses 4 10g wavelengths(lanes) which typically are: 1264.5- 1277.5 nm 1284.5–1297.5 nm 1304.5–1317.5 nm 1324.5–1337.5 nm My question is are there any vendors that make optics which 4 wavelengths(lanes) are something other than those typically used by 40GBase-LR4? Regards, Mitchell T. Lewis [ [ mailto:MLewis at TechCompute.Net | mailto:MLewis at TechCompute.Net ] | [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] ] [ [ http://linkedin.com/in/mlewiscc | http://linkedin.com/in/mlewiscc ] ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E ] | Public PGP Key ] From: "Lewis,Mitchell T." < [ mailto:ml-nanog at techcompute.net | ml-nanog at techcompute.net ] > To: "NANOG" < [ mailto:nanog at nanog.org | nanog at nanog.org ] > Sent: Tuesday, 19 June, 2018 12:27:13 Subject: Tunable QSFP Optics Does anyone know if any Single Mode QSFPs exist on the market that use wavelengths other than 1310nm (either self tunable or factory tuned)? I am looking to put more than one 40gb link on a fiber pair similar to using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't use 1310nm. Thanks. Regards, Mitchell T. Lewis [ [ mailto:MLewis at TechCompute.Net | mailto:MLewis at TechCompute.Net ] | [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] ] [ [ http://linkedin.com/in/mlewiscc | http://linkedin.com/in/mlewiscc ] ] |203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E ] | Public PGP Key ] From lists.nanog at monmotha.net Tue Jun 19 17:47:54 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 19 Jun 2018 13:47:54 -0400 Subject: Tunable QSFP Optics In-Reply-To: <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> Message-ID: <16b98fa9-8da5-a175-6ff8-613d1f63b8f7@monmotha.net> On 06/19/2018 12:41 PM, Lewis,Mitchell T. wrote: > Let me clarify a bit-I understand that 40GBase-LR4 uses 4 10g wavelengths(lanes) which typically are: > 1264.5- 1277.5 nm > 1284.5–1297.5 nm > 1304.5–1317.5 nm > 1324.5–1337.5 nm > My question is are there any vendors that make optics which 4 wavelengths(lanes) are something other than those typically used by 40GBase-LR4? Did 40GBASE-FR ever catch on? It was supposed to be single-lane serial 40Gbps on 1310nm with the receiver also accepting 1550nm. For that matter, what are all the optical transport folks using for ~40Gbps OTU3? Or did they all just skip that and go straight to ~100Gbps OTU4 on coherent optics (which are fairly readily available albeit in CFP, not QSFP). -- Brandon Martin From wesgeorge at puck.nether.net Tue Jun 19 18:16:15 2018 From: wesgeorge at puck.nether.net (Wes George) Date: Tue, 19 Jun 2018 14:16:15 -0400 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> Message-ID: <5f1181cd-d338-92d5-a2e2-56ad5c34d4cc@puck.nether.net> On 6/18/18 7:34 PM, Mark Andrews wrote: > If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It > they don’t want it all they have to do is withdraw the prefix. It is not up to > the rest of us to second guess their decision to keep providing support. WG] I don't think that this is intentional in most cases anymore. It's most likely legacy cruft/zombie services. Because it mostly operates unattended and the few that are still using it probably don't notice when it breaks nor can they figure out to whom they should complain because anycast makes that nearly impossible, it continues operating quietly in the dusty and disused corners of the net below a sign saying "beware of the leopard" until the equipment gets retired or dies of old age. Also this argument would carry more weight if it hadn't already been had and concluded with RFC7526, and if it wasn't completely disabled on MS products now: https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features#features-were-no-longer-developing > > If you filter 2002::/16 then you are performing a denial-of-service attack on > the few sites that are still using it DELIBERATELY. WG] As opposed to the unintentional denial-of-service attacks that happen all the time because of the inherent flaws in the implementation and the low importance people place on first-class deployments of this service? Sites that are still using it deliberately should have found a more reliable solution years ago, even if it's a statically-provisioned GRE or 6in4 tunnel. Plenty of tunnel brokers out there to facilitate this if native IPv6 still isn't available. Keeping this around past its sell-by date is simply enabling bad behavior and a bad user experience for IPv6. Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From hf0002+nanog at uah.edu Tue Jun 19 19:28:25 2018 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Tue, 19 Jun 2018 14:28:25 -0500 Subject: Tunable QSFP Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> Message-ID: On Tue, Jun 19, 2018 at 11:53 AM Luke Guillory wrote: > They still leave the transceiver as a single 1310, the lanes color isn't > ever expose since the mux takes place within the transceiver. When I looked > into this for 40g and 100g I found no way to passively do it. > Luke, Can you link a document that corroborates this? I can only find ones that show it as 4 separate lanes and 4 separate colors, visible on the actual output. Example: https://www.nanog.org/meetings/nanog44/presentations/Monday/Hankins_100gbe_update_N44.pdf slide 11 This is also what I've observed anecdotally, but there could be other explanations, I am admittedly not an expert. -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 <(256)%20824-5331> Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From lguillory at reservetele.com Tue Jun 19 20:16:19 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 19 Jun 2018 20:16:19 +0000 Subject: Tunable QSFP Optics In-Reply-To: References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FA0030D@RTC-EXCH01.RESERVE.LDS> Seeing that it seems I’m misunderstanding things, so I went grab a meter and checked what was leaving. Both of the 100g SFPs were only outputting on 1310, while the 40g showed each of the 4 lanes. 100GBASE-LR4 QSFP28 Transceiver Module (SMF, 1310nm, 10km, LC, DOM) Optical Components DML 1310nm Juniper 100GBASE-ER4, Showing 1310 as the only color leaving. Parameter 100GBASE-ER4 Optical interface Single-mode Standard IEEE 802.3ba-2010 Maximum distance SMF cable, 40 km (24.9 miles) Transmitter wavelength per lane 1294.53 through 1296.59 nm 1299.02 through 1301.09 nm 1303.54 through 1305.63 nm 1308.09 through 1310.19 nm 40GBASE-LR4 Compatible 40GBASE-LR4 QSFP+ Transceiver Module (SMF, 1310nm, 10km, LC, DOM) Optical Components DFB CWDM [cid:image001.jpg at 01D407E0.78FB4970] From: Hunter Fuller [mailto:hf0002+nanog at uah.edu] Sent: Tuesday, June 19, 2018 2:28 PM To: Luke Guillory Cc: NANOG Subject: Re: Tunable QSFP Optics On Tue, Jun 19, 2018 at 11:53 AM Luke Guillory > wrote: They still leave the transceiver as a single 1310, the lanes color isn't ever expose since the mux takes place within the transceiver. When I looked into this for 40g and 100g I found no way to passively do it. Luke, Can you link a document that corroborates this? I can only find ones that show it as 4 separate lanes and 4 separate colors, visible on the actual output. Example: https://www.nanog.org/meetings/nanog44/presentations/Monday/Hankins_100gbe_update_N44.pdf slide 11 This is also what I've observed anecdotally, but there could be other explanations, I am admittedly not an expert. -- -- 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 Luke Guillory Vice President – Technology and Innovation [cid:imagee0a454.JPG at 9ab64be1.4fabdd45] 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 lists.nanog at monmotha.net Tue Jun 19 20:43:21 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 19 Jun 2018 16:43:21 -0400 Subject: Tunable QSFP Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FA0030D@RTC-EXCH01.RESERVE.LDS> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FA0030D@RTC-EXCH01.RESERVE.LDS> Message-ID: <109e766f-e257-beaa-94bf-4417196f7cb7@monmotha.net> On 06/19/2018 04:16 PM, Luke Guillory wrote: > Seeing that it seems I’m misunderstanding things, so I went grab a meter and checked what was leaving. Both of the 100g SFPs were only outputting on 1310, while the 40g showed each of the 4 lanes. IIRC, the lambda spacing for 100GBASE-LR4 is tighter than 40GBASE-LR4. 40G is spaced on the normal 20nm CWDM grid. 100G is spaced tighter at just under 5nm so that the entire thing mostly fits within the 20nm-wide "1310nm" CWDM grid. If you're using a CWDM meter, it'll probably bin it exactly that way. There's a separate non-IEEE "100GBASE-CWDM4" that has the 20nm lambda spacing like 40G does. -- Brandon Martin From hf0002+nanog at uah.edu Tue Jun 19 20:47:43 2018 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Tue, 19 Jun 2018 15:47:43 -0500 Subject: Tunable QSFP Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FA0030D@RTC-EXCH01.RESERVE.LDS> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FA0030D@RTC-EXCH01.RESERVE.LDS> Message-ID: On Tue, Jun 19, 2018 at 3:16 PM Luke Guillory wrote: > Seeing that it seems I’m misunderstanding things, so I went grab a meter > and checked what was leaving. Both of the 100g SFPs were only outputting on > 1310, while the 40g showed each of the 4 lanes. > > Thanks much for checking - I didn't have a meter handy. I certainly learned something about the tighter spacing of 100G colors. > > -- -- 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 Bryan at bryanfields.net Tue Jun 19 20:59:47 2018 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 19 Jun 2018 16:59:47 -0400 Subject: WC 2018 impact on network yet In-Reply-To: <014db520-c948-20f0-84b5-a90c39a17a64@ispworkshop.com> References: <014db520-c948-20f0-84b5-a90c39a17a64@ispworkshop.com> Message-ID: <977ba374-ff28-c8d1-ca77-cc65cbc9b058@bryanfields.net> On 6/15/18 6:23 AM, Ong Beng Hui wrote: > With every operators looking at high quality HD video stream, anyone > feeling the impact for WC 2018 yet ? I took and uber today, the driver was streaming a match on his phone in the suction cup mount. Hands free, so it's technically legal... -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From bill at herrin.us Tue Jun 19 21:04:45 2018 From: bill at herrin.us (William Herrin) Date: Tue, 19 Jun 2018 17:04:45 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <110366.1529424580@turing-police.cc.vt.edu> References: <20180617185400.2834180181@mail.alphavpn.com> <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> <110366.1529424580@turing-police.cc.vt.edu> Message-ID: On Tue, Jun 19, 2018 at 12:09 PM, wrote: > On Tue, 19 Jun 2018 11:33:50 -0400, William Herrin said: > >> The innovation I'd like to see is a multi-level streaming cache. >> Here's the basic idea: >> >> Define a network protocol such as "mlcache" >> >> mlcache://data.netflix.com/starwars/chunk12345 is a chunk of some >> video that netflix has. It's encrypted. The client got the decryption >> key for that chunk and instructions on how to load the chunks in what >> order in an authenticated http connection. >> >> The client does not connect to data.netflix.com. Instead, it probes an >> anycast IP address to find the nearest cache. If there is no cache, >> then it falls back on contacting data.netflix.com directly. >> >> If the cache probe returned a unicast IP address for a nearby cache >> then the client asks the cache to retrieve that chunk instead. If lots >> of folks using the cache are watching that particular video, the cache >> can supply the chunk without asking netflix for it again. >> >> If the cache doesn't have the chunk, it contacts the next cache >> upstream. If there is no next cache upstream, it contacts >> data.netflix.com directly. > > Congrats, you just re-invented BitTorrent. :) Except for the peer to peer part and every other aspect of bit torrent save the chunked transfer. Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From marka at isc.org Tue Jun 19 22:40:41 2018 From: marka at isc.org (Mark Andrews) Date: Wed, 20 Jun 2018 08:40:41 +1000 Subject: WC 2018 impact on network yet In-Reply-To: <977ba374-ff28-c8d1-ca77-cc65cbc9b058@bryanfields.net> References: <014db520-c948-20f0-84b5-a90c39a17a64@ispworkshop.com> <977ba374-ff28-c8d1-ca77-cc65cbc9b058@bryanfields.net> Message-ID: > On 20 Jun 2018, at 6:59 am, Bryan Fields wrote: > > On 6/15/18 6:23 AM, Ong Beng Hui wrote: >> With every operators looking at high quality HD video stream, anyone >> feeling the impact for WC 2018 yet ? > > I took and uber today, the driver was streaming a match on his phone in the > suction cup mount. > > Hands free, so it's technically legal… It wouldn’t be here. Videos other than reversing cameras are illegal to watch while driving. I suspect that there is a similar rule where you are. If there isn’t there is always the distracted driving coverall laws as well. > -- > 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 marka at isc.org Wed Jun 20 00:03:25 2018 From: marka at isc.org (Mark Andrews) Date: Wed, 20 Jun 2018 10:03:25 +1000 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: <5f1181cd-d338-92d5-a2e2-56ad5c34d4cc@puck.nether.net> References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> <5f1181cd-d338-92d5-a2e2-56ad5c34d4cc@puck.nether.net> Message-ID: > On 20 Jun 2018, at 4:16 am, Wes George wrote: > > On 6/18/18 7:34 PM, Mark Andrews wrote: > >> If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It >> they don’t want it all they have to do is withdraw the prefix. It is not up to >> the rest of us to second guess their decision to keep providing support. > WG] I don't think that this is intentional in most cases anymore. It's > most likely legacy cruft/zombie services. Because it mostly operates > unattended and the few that are still using it probably don't notice > when it breaks nor can they figure out to whom they should complain > because anycast makes that nearly impossible, it continues operating > quietly in the dusty and disused corners of the net below a sign saying > "beware of the leopard" until the equipment gets retired or dies of old > age. Also this argument would carry more weight if it hadn't already > been had and concluded with RFC7526, and if it wasn't completely > disabled on MS products now: > https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features#features-were-no-longer-developing >> >> If you filter 2002::/16 then you are performing a denial-of-service attack on >> the few sites that are still using it DELIBERATELY. > WG] As opposed to the unintentional denial-of-service attacks that > happen all the time because of the inherent flaws in the implementation > and the low importance people place on first-class deployments of this > service? Sites that are still using it deliberately should have found a > more reliable solution years ago, even if it's a statically-provisioned > GRE or 6in4 tunnel. Plenty of tunnel brokers out there to facilitate > this if native IPv6 still isn't available. Keeping this around past its > sell-by date is simply enabling bad behavior and a bad user experience > for IPv6. Actually there aren’t plenty of tunnel brokers anymore. Lots have shut up shop in the last couple of years. HE is still there but the others are gone or are not accepting new tunnels. At the moment I’m waiting for sane routing between HE and Optus to move my tunnel end point closer. Crossing the Pacific twice to get to HE’s pop in Sydney is insane. If I used it for IPv6 traffic there would be 6 crossing of the Pacific for most IPv6 traffic to get a IPv6 reply. That’s 4 more than there should be. I don’t expect Optus to offer IPv6 any time soon. Mark > Wes George > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at ics-il.net Wed Jun 20 00:25:40 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 19 Jun 2018 19:25:40 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180617185400.2834180181@mail.alphavpn.com> <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> Message-ID: <502177595.5716.1529454338914.JavaMail.mhammett@ThunderFuck> I encourage you to look at operating a network outside of a datacenter or corporate campus. The wireless last hop is *NOT* the problem. A modern deployment in a small village could put dozens of megabit/s to every house for $10k. The transit or transport connections *ARE* the fiscal problem. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "George Herbert" To: "Lee Howard" Cc: nanog at nanog.org Sent: Tuesday, June 19, 2018 10:29:15 AM Subject: Re: Impacts of Encryption Everywhere (any solution?) I’m confused. People are using last hop (wireless) arguments against HTTPS Everywhere; that’s the part that requires full bandwidth either way (as your non-HTTPS cache is upstream somewhere). The fiber links that are physically fixed and can handle in many cases better lasers, are the ongoing upgradable part. If you’re complaining your fiber backhaul is too big a deal, you’re playing the wrong game to start with. George William Herbert Sent from my iPhone > On Jun 19, 2018, at 7:53 AM, Lee Howard wrote: > > > >> On 06/17/2018 02:53 PM, Brad wrote: >> While I agree there are unintended consequences every time advancements are made in relation to the security and stability of the Internet- I disagree we should be rejecting their implementations. Instead, we should innovate further. > > I look forward to your innovations. >> Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity. > > I encourage you to invest billions of dollars in rural broadband capacity worldwide. The rest of us will thank you for your sacrifice. > > Lee > >> -Brad >> >> -------- Original message --------From: Michael Hallgren Date: 6/17/18 11:14 (GMT-07:00) To: nanog at jack.fr.eu.org Cc: Matthew Petach , nanog at nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) >> Le 2018-06-17 12:40, nanog at jack.fr.eu.org a écrit : >>> Well, yes, there is, you simply have to break the end to end encryption >> Yes, (or) deny service by Policy (remains to evaluate who's happy with >> that). >> >> Cheers, >> mh >> >>>> On 06/17/2018 03:09 AM, Matthew Petach wrote: >>>> Except that if websites are set to HTTPS only, there's no option for >>>> disabling encryption on the client side. >>>> >>>> Matt >>>> >>>> >>>>> On Sat, Jun 16, 2018, 14:47 wrote: >>>>> >>>>>> On 06/16/2018 10:13 PM, Mike Hammett wrote: >>>>>> Sadly, it's just falling on deaf ears. Silicon Valley will continue >>>>>> to >>>>> think they know better than everyone else and people outside of that >>>>> bubble >>>>> will continue to be disadvantaged. >>>>> >>>>> What, again ? >>>>> Encryption is what is best for the most people. >>>>> The few that will not use it can disable it. >>>>> >>>>> No issue then. >>>>> >>>>> > From nanog at ics-il.net Wed Jun 20 00:26:30 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 19 Jun 2018 19:26:30 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180617185400.2834180181@mail.alphavpn.com> <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> Message-ID: <489360258.5719.1529454386674.JavaMail.mhammett@ThunderFuck> There are solutions like that out there, but some people refuse to play in that sandbox. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "William Herrin" To: "Lee Howard" Cc: nanog at nanog.org Sent: Tuesday, June 19, 2018 10:33:50 AM Subject: Re: Impacts of Encryption Everywhere (any solution?) On Tue, Jun 19, 2018 at 10:53 AM, Lee Howard wrote: > On 06/17/2018 02:53 PM, Brad wrote: >> While I agree there are unintended consequences every time advancements >> are made in relation to the security and stability of the Internet- I >> disagree we should be rejecting their implementations. Instead, we should >> innovate further. > > > I look forward to your innovations. The innovation I'd like to see is a multi-level streaming cache. Here's the basic idea: Define a network protocol such as "mlcache" mlcache://data.netflix.com/starwars/chunk12345 is a chunk of some video that netflix has. It's encrypted. The client got the decryption key for that chunk and instructions on how to load the chunks in what order in an authenticated http connection. The client does not connect to data.netflix.com. Instead, it probes an anycast IP address to find the nearest cache. If there is no cache, then it falls back on contacting data.netflix.com directly. If the cache probe returned a unicast IP address for a nearby cache then the client asks the cache to retrieve that chunk instead. If lots of folks using the cache are watching that particular video, the cache can supply the chunk without asking netflix for it again. If the cache doesn't have the chunk, it contacts the next cache upstream. If there is no next cache upstream, it contacts data.netflix.com directly. The cache is not application-specific. Anything willing to talk the cache protocol can use it to fetch chunks of data from any server. In principle this should work for live streams too. The head end server either replies "not yet" or holds the request open until the next chunk of data is available. The cache requests the chunk once and supplies it to all clients once retrieved. Keep the chunks small enough that the caching process delays the live stream by a second or two, no different than the television broadcasts do. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From lobna_gouda at hotmail.com Wed Jun 20 00:32:35 2018 From: lobna_gouda at hotmail.com (lobna gouda) Date: Wed, 20 Jun 2018 00:32:35 +0000 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <9e2c59eb-2b9a-b68e-76c5-e60531c9a499@retevia.net> References: <20180611141656.D25636BB@m0117567.ppops.net>, <9e2c59eb-2b9a-b68e-76c5-e60531c9a499@retevia.net> Message-ID: Although the FB link is vague but argument itself is true. We just became more intelligent in deploying IPV6. The same measurement if was done in less than a decade for example would show that ipv4 is faster. The dual stack implementation and the slowness introduced by Teredo Tunneling were the main reasons and now we are getting smarter having it deprecating https://labs.ripe.net/Members/gih/examining-ipv6-performance https://tools.ietf.org/html/rfc6555 https://tools.ietf.org/html/rfc7526 Things change, Ipv6 response is showing better has IPV4 is having more TCP re-transmission which the culprit is still not known ( need more analysis) but fingers are pointing to the exhaustion of the ipv4 address so basically CGN , load-balancers and address sharing. Although we can not eliminate peering links and Firewalls. Yet if we have exactly the same topology and traffic crossing the links et Firewalls locations/policies. Analysis didnot confirm why it would have rather more harm on ipv4 than 6 Brgds, LG ________________________________ From: NANOG on behalf of Lee Howard Sent: Wednesday, June 13, 2018 7:46 AM To: nanog at nanog.org Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On 06/11/2018 05:16 PM, Scott Weeks wrote: > > --- cb.list6 at gmail.com wrote: > From: Ca By > >> Meanwhile, FB reports that 75% of mobiles in the USA >> reach them via ipv6 >> >> And Akaimai reports 80% of mobiles > And they both report ipv6 is faster / better. > ---------------------------------------- Let me grab a few more for you: https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html Preparing for IPv6-only mobile networks: Why and How - The ... blogs.akamai.com Apple's upcoming App Store submission requirement around supporting IPv6-only environments (announced last year at WWDC and being enforced starting June 1) has been getting plenty of recent coverage. iOS application developers already need to make sure their applications work in... https://blogs.akamai.com/2016/10/ipv6-at-akamai-edge-2016.html https://www.theregister.co.uk/2016/07/28/ipv6_now_faster_a_fifth_of_the_time which cites an academic paper http://dl.acm.org/citation.cfm?doid=2959424.2959429 by Vaibhav Bajpai and Jürgen Schönwälder https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-kahn/ https://community.infoblox.com/t5/IPv6-CoE-Blog/Can-IPv6-Rally-Be-Faster-than-IPv4-Part-1/ba-p/6419 https://www.nanog.org/meetings/abstract?id=2281 > I'd sure like to see how they came up with these > numbers in a technically oriented paper. Most of the above links explain how they got the numbers. Facebook, in particular, did A/B testing using Mobile Proxygen, which is to say that they configured their mobile app to report performance over both IPv4 and IPv6 from the same handset at the same time. Others, including APNIC's https://stats.labs.apnic.net/v6perf have a browser fetch two objects with unique URLs, one from an IPv4-only server and one from an IPv6-only server, and compare them. > There > should be no difference, except for no CGN or Happy > Eyeballs working better or something similar. Am I > missing something? Same routers; same links; same > RTTs; same interrupt times on servers; same etc, etc > for both protocols. From time to time somebody says, "Okay, maybe it works in practice, but does it work in *theory*?" Busy engineers hardly ever investigate things going inexplicably right. My hypothesis is that the observed difference in performance relates to how mobile networks deploy their transition mechanisms. Those with a dual-stack APN take a native path for IPv6, while using a CGN path for IPv4, which, combined with the Happy Eyeballs head start, might add 501microseconds, which is a ms, which is 15% of 7ms. Those with an IPv6-only APN use a native path for IPv6, while using either a NAT64 for IPv4 (identical performance to CGN) or 464xlat, which requires translation both in the handset and the NAT64; handsets may not be optimized for header translation. However, I have a dozen other hypotheses, and the few experiments I've been able to run have not confirmed any hypothesis. For instance, when one protocol is faster than another on a landline network, hop count is not a correlation (therefore, shorter paths, traffic engineering, etc., are not involved). Lee > > Hmm... Faster and better? > > The links seem to be an IPv6 cheerleader write up. > I looked at the URLs and the URLs one pointed to and > pulled out everything related to IPv6 being > faster/better. > > > Akamai URL: > > "For dual-stacked hostnames we typically see higher > average estimated throughput over IPv6 than over IPv4. > Some of this may be due to IPv6-connected users being > correlated with better connectivity, but over half of > dual-stacked hostnames (weighted by daily bytes > delivered) have IPv6 estimated throughput at least 50% > faster than IPv4, and 90% of these hostnames have the > IPv6 estimated throughput at least 10% faster than > IPv4." > > > > FB URL: > > "People using Facebook services typically see better > performance over IPv6..." > > and it points to > https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board > which says: > > "We’ve long been anticipating the exhaustion of IPv > in favor of the speed and performance benefits of > IPv6." > > "We’ve observed that accessing Facebook can be 10-15 > percent faster over IPv6." > > > I'd sure like to see how they came up with these > numbers in a technically oriented paper. There > should be no difference, except for no CGN or Happy > Eyeballs working better or something similar. Am I > missing something? Same routers; same links; same > RTTs; same interrupt times on servers; same etc, etc > for both protocols. > > scott From michael at wi-fiber.io Wed Jun 20 01:10:59 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 19 Jun 2018 19:10:59 -0600 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <502177595.5716.1529454338914.JavaMail.mhammett@ThunderFuck> References: <20180617185400.2834180181@mail.alphavpn.com> <59404220-8871-0f8c-5496-e99e2a696929@retevia.net> <502177595.5716.1529454338914.JavaMail.mhammett@ThunderFuck> Message-ID: I've always said that the fiber middle mile price themselves out of more money. I want a fiber connection that will service a subdivision(20-50 households) with speeds up to 1gbps, oh that's $2k/mo. The problem is that we want a fiber connection for 10 or 20 subdivisions, oh, that's 2k per, but you get 10% discount because of the amount.. Alternatively, we could get a single 10g connection from an IX/first mile for $2500, and use 10-20 $3k radios to get a gig into every sub division, We've tried to get fiber providers to allow us to purchase bandwidth based upon 3 criteria: 1) the cost for them to buildout, they are a business and need to get their money back. 2) total burstable capacity, 10g circuits cost more than 1g, but 200m circuits shouldn't cost less than 1g. 3) by the number of subscribers on each link. We have offered to 1) pay for their fiber install costs, 2) pay a base tariff and 3) pay up 25% of base revenue per user. In this case, fiber company gets paid to put the fiber in, and ~$500/mo for each connection they're giving to us, in this scenario they will make $10k/mo profit, plus expand their network. In the other scenario they make only $2500/mo and come in uncompetetively for businesses in our market(because they have a new buildout to bake into their price) Just doesn't make sense to us to pay individually for fiber connections when we know it's packet switched anyway, and the load on their network is the same On 19 June 2018 at 18:25, Mike Hammett wrote: > I encourage you to look at operating a network outside of a datacenter or > corporate campus. > > > The wireless last hop is *NOT* the problem. A modern deployment in a small > village could put dozens of megabit/s to every house for $10k. The transit > or transport connections *ARE* the fiscal problem. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "George Herbert" > To: "Lee Howard" > Cc: nanog at nanog.org > Sent: Tuesday, June 19, 2018 10:29:15 AM > Subject: Re: Impacts of Encryption Everywhere (any solution?) > > I’m confused. > > People are using last hop (wireless) arguments against HTTPS Everywhere; > that’s the part that requires full bandwidth either way (as your non-HTTPS > cache is upstream somewhere). The fiber links that are physically fixed and > can handle in many cases better lasers, are the ongoing upgradable part. > > If you’re complaining your fiber backhaul is too big a deal, you’re > playing the wrong game to start with. > > > George William Herbert > Sent from my iPhone > > > On Jun 19, 2018, at 7:53 AM, Lee Howard wrote: > > > > > > > >> On 06/17/2018 02:53 PM, Brad wrote: > >> While I agree there are unintended consequences every time advancements > are made in relation to the security and stability of the Internet- I > disagree we should be rejecting their implementations. Instead, we should > innovate further. > > > > I look forward to your innovations. > >> Just because end to end encryption causes bandwidth issues for a very > small number users - then perhaps they could benefit the most by these > changes with additional capacity. > > > > I encourage you to invest billions of dollars in rural broadband > capacity worldwide. The rest of us will thank you for your sacrifice. > > > > Lee > > > >> -Brad > >> > >> -------- Original message --------From: Michael Hallgren > Date: 6/17/18 11:14 (GMT-07:00) To: nanog at jack.fr.eu.org Cc: Matthew > Petach , nanog at nanog.org Subject: Re: Impacts of > Encryption Everywhere (any solution?) > >> Le 2018-06-17 12:40, nanog at jack.fr.eu.org a écrit : > >>> Well, yes, there is, you simply have to break the end to end > encryption > >> Yes, (or) deny service by Policy (remains to evaluate who's happy with > >> that). > >> > >> Cheers, > >> mh > >> > >>>> On 06/17/2018 03:09 AM, Matthew Petach wrote: > >>>> Except that if websites are set to HTTPS only, there's no option for > >>>> disabling encryption on the client side. > >>>> > >>>> Matt > >>>> > >>>> > >>>>> On Sat, Jun 16, 2018, 14:47 wrote: > >>>>> > >>>>>> On 06/16/2018 10:13 PM, Mike Hammett wrote: > >>>>>> Sadly, it's just falling on deaf ears. Silicon Valley will continue > >>>>>> to > >>>>> think they know better than everyone else and people outside of that > >>>>> bubble > >>>>> will continue to be disadvantaged. > >>>>> > >>>>> What, again ? > >>>>> Encryption is what is best for the most people. > >>>>> The few that will not use it can disable it. > >>>>> > >>>>> No issue then. > >>>>> > >>>>> > > > > From jared at puck.nether.net Wed Jun 20 03:34:22 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Jun 2018 23:34:22 -0400 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: <20180618164806.03c9ff42@p50.localdomain> <55679919-8ED0-486A-BD9B-7DA8B3FB3A4A@isc.org> <5f1181cd-d338-92d5-a2e2-56ad5c34d4cc@puck.nether.net> Message-ID: <03DE4482-4448-4851-9785-34444251DD21@puck.nether.net> > On Jun 19, 2018, at 8:03 PM, Mark Andrews wrote: > >> >> On 20 Jun 2018, at 4:16 am, Wes George wrote: >> >> On 6/18/18 7:34 PM, Mark Andrews wrote: >> >>> If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It >>> they don’t want it all they have to do is withdraw the prefix. It is not up to >>> the rest of us to second guess their decision to keep providing support. >> WG] I don't think that this is intentional in most cases anymore. It's >> most likely legacy cruft/zombie services. Because it mostly operates >> unattended and the few that are still using it probably don't notice >> when it breaks nor can they figure out to whom they should complain >> because anycast makes that nearly impossible, it continues operating >> quietly in the dusty and disused corners of the net below a sign saying >> "beware of the leopard" until the equipment gets retired or dies of old >> age. Also this argument would carry more weight if it hadn't already >> been had and concluded with RFC7526, and if it wasn't completely >> disabled on MS products now: >> https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features#features-were-no-longer-developing >>> >>> If you filter 2002::/16 then you are performing a denial-of-service attack on >>> the few sites that are still using it DELIBERATELY. >> WG] As opposed to the unintentional denial-of-service attacks that >> happen all the time because of the inherent flaws in the implementation >> and the low importance people place on first-class deployments of this >> service? Sites that are still using it deliberately should have found a >> more reliable solution years ago, even if it's a statically-provisioned >> GRE or 6in4 tunnel. Plenty of tunnel brokers out there to facilitate >> this if native IPv6 still isn't available. Keeping this around past its >> sell-by date is simply enabling bad behavior and a bad user experience >> for IPv6. > > Actually there aren’t plenty of tunnel brokers anymore. Lots have shut > up shop in the last couple of years. HE is still there but the others > are gone or are not accepting new tunnels. > > At the moment I’m waiting for sane routing between HE and Optus to move > my tunnel end point closer. Crossing the Pacific twice to get to HE’s pop > in Sydney is insane. If I used it for IPv6 traffic there would be 6 crossing > of the Pacific for most IPv6 traffic to get a IPv6 reply. That’s 4 more than > there should be. > > I don’t expect Optus to offer IPv6 any time soon. Vote with your wallet? Does Optus offer a good 6to4 gateway? Right now the 6to4 gateway I’m routed to is too far away to even make sense. Going from a US national eyeball provider to Prague isn’t the right solution either. At a previous job we tried to figure out if there was value in offering commercial IPv6 tunnels that would workaround some of the problems you speak of. The problem is the market wasn’t large enough to really justify it. I know a few folks working on offering some commercial IPv6 transition solutions, perhaps they would be willing to sell it to you or offer it for a freemium so you can provide feedback? I’d love to solve the physics problem for you as well, but that’s perhaps a bit harder. - Jared From jared at puck.nether.net Wed Jun 20 03:48:52 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Jun 2018 23:48:52 -0400 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <20180612000734.GL50997@vurt.meerval.net> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> Message-ID: <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> > On Jun 11, 2018, at 8:07 PM, Job Snijders wrote: > > On Mon, Jun 11, 2018 at 05:01:24PM -0700, Ca By wrote: >>> I posit that the more miles a packet has to travel, the more likely >>> it is to be an IPv4 packet. >> >> Related. The more miles the traffic travels the more likely it is the >> long tail ipv4 15% of internet that is not the wales : google, fb, >> netflix, apple, akamai ... and i will even throw in cloudflare. >> >> I hear transit is dead > > Well, be that as it may, I'm still going to go to work tomorrow ;-) I see in the SMB space, including the small time FTTH and WISP communities they are mostly focused on IPv4 with little IPv6 going on. While they could access most content on IPv6 their common platforms still are not IPv6 friendly. UBNT is rolling out IPv6 finally to some of their UniFi lines as well as their airOS 8.x by making it default enabled. There is still some way to go but folks are making progress. MikroTik is getting there but most people are just not enabling it either. The WISP folks gripe about geolocation issues for the IPv4 blocks they are leasing as well, and some end-user content still isn’t IPv6 ready (such as Hulu). What I can see is that the folks that made the jump are less likely to be required to hold NAT state so have fewer problems. It’s not quite as simple as 96-more-bits because you learn there is no ARP (it’s NDP) and you can DHCPv6 + SLAAC or a combination thereof, but they just don’t have the operational experience. There’s also the perfectly valid comments from others that they can’t get IPv6 on their FIOS, Business class DOCSIS services, etc.. It’s also often easier to get a static IPv4 and dynamic IPv6 but getting static IPv6 is harder. Thankfully progress is being made here, but often much slower than the early adopters here would want. Then again, I hear everything is in the cloud anyways so as long as I can reach the NetBookAzureTube perhaps all is well? - Jared From sethm at rollernet.us Wed Jun 20 03:55:11 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 19 Jun 2018 20:55:11 -0700 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> Message-ID: <1566e3a5-3fd9-2cfd-2eff-4f92f33fd995@rollernet.us> On 6/19/18 8:48 PM, Jared Mauch wrote: > MikroTik is getting there but most people are just not enabling it either. RouterOS still has "will not fix" IPv6 bugs, so that doesn't help shops dependent on Mikrotik want to move forward with deploying it. From jhaustin at gmail.com Wed Jun 20 03:59:13 2018 From: jhaustin at gmail.com (Jeremy Austin) Date: Tue, 19 Jun 2018 19:59:13 -0800 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <1566e3a5-3fd9-2cfd-2eff-4f92f33fd995@rollernet.us> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <1566e3a5-3fd9-2cfd-2eff-4f92f33fd995@rollernet.us> Message-ID: On Tue, Jun 19, 2018 at 7:56 PM Seth Mattinen wrote: > > On 6/19/18 8:48 PM, Jared Mauch wrote: > > MikroTik is getting there but most people are just not enabling it either. > > > RouterOS still has "will not fix" IPv6 bugs, so that doesn't help shops > dependent on Mikrotik want to move forward with deploying it. Quick, somebody port FRR to Tile… -- Jeremy Austin jhaustin at gmail.com (907) 895-2311 office (907) 803-5422 cell Heritage NetWorks - Whitestone Power & Communications - Vertical Broadband, LLC From jared at puck.nether.net Wed Jun 20 04:06:24 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 20 Jun 2018 00:06:24 -0400 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <1566e3a5-3fd9-2cfd-2eff-4f92f33fd995@rollernet.us> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <1566e3a5-3fd9-2cfd-2eff-4f92f33fd995@rollernet.us> Message-ID: <4D132A6C-1552-4593-BC96-6DFDBAB64BB5@puck.nether.net> > On Jun 19, 2018, at 11:55 PM, Seth Mattinen wrote: > > On 6/19/18 8:48 PM, Jared Mauch wrote: >> MikroTik is getting there but most people are just not enabling it either. > > > RouterOS still has "will not fix" IPv6 bugs, so that doesn't help shops dependent on Mikrotik want to move forward with deploying it. I know. They’re very popular in the WISP and FTTH communities that are doing sub-10G as their aggregate bits. I understand the price appeal but not a fan personally. - Jared From ekgermann at semperen.com Wed Jun 20 03:07:08 2018 From: ekgermann at semperen.com (Eric Germann) Date: Tue, 19 Jun 2018 23:07:08 -0400 Subject: Gmail security contact off list Message-ID: Can someone from Gmail security contact me off list. Pardon the interruption EKG From elmi at 4ever.de Wed Jun 20 08:37:10 2018 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 20 Jun 2018 10:37:10 +0200 Subject: Sourcing Dell servers in Buenos Aires (AR) Message-ID: <20180620083710.GA705@anx-nb3810.anexia.local> Hi helpful people around the world, we are currently at a loss of sourcing Dell servers (R630 etc.) for our Buenos Aires datacenter... can anybody here jump in and provide us with hardware there short-term, or recommend a local dealer? We need to upgrade quickly, and estimates for import run in weeks to months :-( Yours, Elmar. From mark.tinka at seacom.mu Wed Jun 20 15:33:50 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 20 Jun 2018 17:33:50 +0200 Subject: SAFNOG-4 + EANOG, tzNOG & TISPA Meeting Announcement Message-ID: <17e1a4b8-f9ef-fc56-63bc-5473d745e952@seacom.mu> Hello all. It gives me great pleasure to announce that SAFNOG-4, in collaboration with EANOG (East Africa Network Operators Group) and tzNOG (Tanzania Network Operators Group), and hosted by TISPA (Tanzania Internet Service Providers Association) will be held between the 24th - 29th September, 2018, in the warm and sunny city of Dar Es Salaam, Tanzania. What is exciting about this year's SAFNOG meeting is that it will be partnering with EANOG and tzNOG, to include both plenary and workshop sessions during the week, as part of the agenda. The main plenary meeting will be held at the Hyatt Regency Dar Es Salaam hotel between 24th - 26th September, while the the workshop will be held at the Bank of Tanzania building between 26th - 29th September, 2018. Details about the event registration and agenda will be made available at these locations:     - www.safnog.org     - www.tznog.or.tz     - www.eanog.org Please mark your calendars. SAFNOG, EANOG, tzNOG and TISPA look forward to seeing you in Dar Es Salaam. Cheers, Mark Tinka On Behalf of the SAFNOG/EANOG/tzNOG Organizing Committee From dovid at telecurve.com Wed Jun 20 17:13:45 2018 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 20 Jun 2018 13:13:45 -0400 Subject: Documenting hardware Message-ID: I am sure this has been covered in the past but I can't seem to find it. We need a simple solution to document connections in the date center. We don't need anything fancy (e.g. something that will probe our hardware). We need something where we can enter what switch ports are connected to what servers the vlans for each port etc. TIA. From chaim.rieger at gmail.com Wed Jun 20 17:16:22 2018 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 20 Jun 2018 10:16:22 -0700 Subject: Documenting hardware In-Reply-To: References: Message-ID: Netdisco On Wed, Jun 20, 2018 at 10:15 AM Dovid Bender wrote: > I am sure this has been covered in the past but I can't seem to find it. We > need a simple solution to document connections in the date center. We don't > need anything fancy (e.g. something that will probe our hardware). We need > something where we can enter what switch ports are connected to what > servers the vlans for each port etc. > > TIA. > From lathama at gmail.com Wed Jun 20 17:20:02 2018 From: lathama at gmail.com (Andrew Latham) Date: Wed, 20 Jun 2018 12:20:02 -0500 Subject: Documenting hardware In-Reply-To: References: Message-ID: As mentioned in the IPAM thread there are many solutions out there that cover the whole DCIM stack. A device documentation could be captured via https://netbox.readthedocs.io/en/latest/data-model/dcim/#devices or even https://www.mediawiki.org On Wed, Jun 20, 2018 at 12:15 PM Dovid Bender wrote: > I am sure this has been covered in the past but I can't seem to find it. We > need a simple solution to document connections in the date center. We don't > need anything fancy (e.g. something that will probe our hardware). We need > something where we can enter what switch ports are connected to what > servers the vlans for each port etc. > > TIA. > -- - Andrew "lathama" Latham - From sam.oduor at gmail.com Wed Jun 20 20:14:58 2018 From: sam.oduor at gmail.com (Sam Oduor) Date: Wed, 20 Jun 2018 23:14:58 +0300 Subject: SAFNOG-4 + EANOG, tzNOG & TISPA Meeting Announcement In-Reply-To: <17e1a4b8-f9ef-fc56-63bc-5473d745e952@seacom.mu> References: <17e1a4b8-f9ef-fc56-63bc-5473d745e952@seacom.mu> Message-ID: Good stuff and great to learn about the existence of this network operator groups ! On Wed, Jun 20, 2018 at 6:33 PM, Mark Tinka wrote: > Hello all. > > It gives me great pleasure to announce that SAFNOG-4, in collaboration > with EANOG (East Africa Network Operators Group) and tzNOG (Tanzania > Network Operators Group), and hosted by TISPA (Tanzania Internet Service > Providers Association) will be held between the 24th - 29th September, > 2018, in the warm and sunny city of Dar Es Salaam, Tanzania. > > What is exciting about this year's SAFNOG meeting is that it will be > partnering with EANOG and tzNOG, to include both plenary and workshop > sessions during the week, as part of the agenda. > > The main plenary meeting will be held at the Hyatt Regency Dar Es Salaam > hotel between 24th - 26th September, while the the workshop will be held > at the Bank of Tanzania building between 26th - 29th September, 2018. > > Details about the event registration and agenda will be made available > at these locations: > > - www.safnog.org > - www.tznog.or.tz > - www.eanog.org > > Please mark your calendars. > > SAFNOG, EANOG, tzNOG and TISPA look forward to seeing you in Dar Es Salaam. > > Cheers, > > Mark Tinka > On Behalf of the SAFNOG/EANOG/tzNOG Organizing Committee > -- Samson Oduor From wmf at felter.org Wed Jun 20 21:22:21 2018 From: wmf at felter.org (Wes Felter) Date: Wed, 20 Jun 2018 16:22:21 -0500 Subject: Tunable QSFP Optics In-Reply-To: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> Message-ID: On 6/19/18 11:27 AM, Lewis,Mitchell T. wrote: > Does anyone know if any Single Mode QSFPs exist on the market that use wavelengths other than 1310nm (either self tunable or factory tuned)? I am looking to put more than one 40gb link on a fiber pair similar to using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't use 1310nm. Inphi ColorZ? They aren't tunable but you can order a variety of different wavelengths in the 15xx nm range. Wes Felter now hiring cloud DCI DWDM operators in Austin/NYC/Boston From gourmetcisco at hotmail.com Wed Jun 20 23:58:25 2018 From: gourmetcisco at hotmail.com (Hank Disuko) Date: Wed, 20 Jun 2018 23:58:25 +0000 Subject: Any Fastly CDN engineers here? Message-ID: Bit of a longshot, but I'm having some very interesting issues with the Fastly nodes in Miami. Thanks, Hank. From justin at cloudflare.com Thu Jun 21 00:04:06 2018 From: justin at cloudflare.com (Justin Paine) Date: Wed, 20 Jun 2018 17:04:06 -0700 Subject: Any Fastly CDN engineers here? In-Reply-To: References: Message-ID: Replying offlist. ____________ Justin Paine Head of Trust & Safety Cloudflare Inc. PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D On Wed, Jun 20, 2018 at 4:59 PM Hank Disuko wrote: > > Bit of a longshot, but I'm having some very interesting issues with the Fastly nodes in Miami. > > > Thanks, > > Hank. From ryan.landry at gmail.com Thu Jun 21 00:25:07 2018 From: ryan.landry at gmail.com (Ryan Landry) Date: Wed, 20 Jun 2018 17:25:07 -0700 Subject: Any Fastly CDN engineers here? In-Reply-To: References: Message-ID: Happy to help. We’ve engaged off list. On Wed, Jun 20, 2018 at 17:00 Hank Disuko wrote: > Bit of a longshot, but I'm having some very interesting issues with the > Fastly nodes in Miami. > > > Thanks, > > Hank. > From job at ntt.net Thu Jun 21 02:15:52 2018 From: job at ntt.net (Job Snijders) Date: Wed, 20 Jun 2018 21:15:52 -0500 Subject: Fwd: New on RIPE Labs: BGP Large Communities - Uptake by the Community at Large? In-Reply-To: References: Message-ID: Large BGP Communities are on the rise! :-) ---------- Forwarded message --------- From: Mirjam Kuehne Date: Wed, 20 Jun 2018 at 07:51 Subject: [routing-wg] New on RIPE Labs: BGP Large Communities - Uptake by the Community at Large? To: Dear colleagues, In this new article on RIPE Labs we look at the uptake of BGP Large Communities using the RIPE Routing Information Service (RIS): https://labs.ripe.net/Members/emileaben/bgp-large-communities-uptake-by-the-community-at-large Kind regards, Mirjam Kühne RIPE NCC From ben at 6by7.net Thu Jun 21 03:32:44 2018 From: ben at 6by7.net (Ben Cannon) Date: Wed, 20 Jun 2018 20:32:44 -0700 Subject: Tunable QSFP Optics In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> <1418258857.558652.1529426504702.JavaMail.zimbra@techcompute.net> <8D89F96B7AB1B84F9E049CC7BB91BF5C027F9FF904@RTC-EXCH01.RESERVE.LDS> Message-ID: This little bad-boy has the wavelengths (I believe all exactly 1310.00nm) broken out onto individual fibers (MTP/MPO) https://www.fs.com/products/37016.html Combine with: https://www.fs.com/products/30515.html and 4 DWDM SFP+ modules, plus 4 standard 10G LR SFP+. Receiver sensitivity kind of sucks, but regen/amps should make interesting deployments possible with standard gear. -Ben. > On Jun 19, 2018, at 9:53 AM, Luke Guillory wrote: > > They still leave the transceiver as a single 1310, the lanes color isn't ever expose since the mux takes place within the transceiver. When I looked into this for 40g and 100g I found no way to passively do it. > > > > > > > Luke Guillory > Vice President – Technology and Innovation > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > _________________________________________________________________________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lewis,Mitchell T. > Sent: Tuesday, June 19, 2018 11:42 AM > To: NANOG > Subject: Re: Tunable QSFP Optics > > Let me clarify a bit-I understand that 40GBase-LR4 uses 4 10g wavelengths(lanes) which typically are: > 1264.5- 1277.5 nm > 1284.5–1297.5 nm > 1304.5–1317.5 nm > 1324.5–1337.5 nm > My question is are there any vendors that make optics which 4 wavelengths(lanes) are something other than those typically used by 40GBase-LR4? > > > Regards, > > Mitchell T. Lewis > > [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] > > > [ http://linkedin.com/in/mlewiscc ] |203-816-0371 > > PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] > > > > From: "Lewis,Mitchell T." > To: "NANOG" > Sent: Tuesday, 19 June, 2018 12:27:13 > Subject: Tunable QSFP Optics > > Does anyone know if any Single Mode QSFPs exist on the market that use wavelengths other than 1310nm (either self tunable or factory tuned)? I am looking to put more than one 40gb link on a fiber pair similar to using DWDM OADMs for 1g & 10g but can't seem to find any qsfp optics that don't use 1310nm. > > Thanks. > > > Regards, > > Mitchell T. Lewis > > [ mailto:MLewis at TechCompute.Net | MLewis at TechCompute.Net ] > > > [ http://linkedin.com/in/mlewiscc ] |203-816-0371 > > PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ https://pgp.mit.edu/pks/lookup?op=get&search=0x2AFA805732A1394E | Public PGP Key ] > > > From randy at psg.com Thu Jun 21 15:35:35 2018 From: randy at psg.com (Randy Bush) Date: Thu, 21 Jun 2018 08:35:35 -0700 Subject: at&t business ipv6 Message-ID: dear lazynet: sorry to ask an end customer question here, but we're at a bit of a useless point, with actual clue being blocked by an account rep. i have at&t gig fiber at home and it seems to be a pd /64. works fine. at the office, we have at&t business 1g fiber going into an arris. behind it we have a cisco asa with five lan segments. only ipv4 is enabled. i want to enable v6 in the office, but can not find out what at&t is providing. i would hope something such as a pd /56 with a static allocation. after all, we pay through the nose for five static v4 prefixes. anyone been to this movie and care to divulge the plot? thanks randy From nick at foobar.org Thu Jun 21 16:07:48 2018 From: nick at foobar.org (Nick Hilliard) Date: Thu, 21 Jun 2018 17:07:48 +0100 Subject: at&t business ipv6 In-Reply-To: References: Message-ID: Randy Bush wrote on 21/06/2018 16:35: > anyone been to this movie and care to divulge the plot? Yes, one particular plotline which can explain why docsis systems do this is that standard residential customers are provisioned using giant broadcast domains directly on the cable, with DHCP config. Obviously it's more complicated because it's docsis, but lemme handwave and say that this is the gist of it. Because you're dealing with giant broadcast domains, you assign IP address blocks to individual CMTSs and your customers are assigned out of those ranges. Assigning ipv6 in this context is really simple: it's part of the baseline DOCSIS3.0 standard and is supported incredibly well by all parts of the network. Static addresses don't fit into this paradigm because you if you configure your static customers from a single broadcast domain, then they are glued to a particular CMTS and can't be moved from that CMTS unless you renumber them. This doesn't work in practice because if you want to grow your network, you probably want to be able to move around chunks of your cable network from one CMTS to another in order to balance out your traffic. Or you might want to split a bunch of cable nodes from one CMTS to multiple, according as your traffic outgrew the capabilities of a single CMTS (a node in this context is a small chunk of a cable network). One way of getting around this mess is to backhaul all your static customer interfaces using mpls l2vpn PWHE up to a L3 box which just handles static IP addresses. You configure the customer's static default gateway IP address on an interface on this head-end router, and the customer's cable modem will have a virtual connection directly to that interface. The thing is, this virtual interface termination system might or might not be tied into the entire ipv6 provisioning system. If it isn't, you're SoL. So even if dirt-cheap residential customers can get ipv6 very easily, it's different by virtue of the fact that you're using static IP addresses, because they're a headache for cable operators. Nick From randy at psg.com Thu Jun 21 16:19:43 2018 From: randy at psg.com (Randy Bush) Date: Thu, 21 Jun 2018 09:19:43 -0700 Subject: at&t business ipv6 In-Reply-To: References: Message-ID: > Yes, one particular plotline which can explain why docsis systems do > this is that standard residential customers are provisioned using > giant broadcast domains directly on the cable, with DHCP config. > Obviously it's more complicated because it's docsis, but lemme > handwave and say that this is the gist of it. Because you're dealing > with giant broadcast domains, you assign IP address blocks to > individual CMTSs and your customers are assigned out of those ranges. > > Assigning ipv6 in this context is really simple: it's part of the > baseline DOCSIS3.0 standard and is supported incredibly well by all > parts of the network. > > Static addresses don't fit into this paradigm because you if you > configure your static customers from a single broadcast domain, then > they are glued to a particular CMTS and can't be moved from that CMTS > unless you renumber them. > > This doesn't work in practice because if you want to grow your > network, you probably want to be able to move around chunks of your > cable network from one CMTS to another in order to balance out your > traffic. Or you might want to split a bunch of cable nodes from one > CMTS to multiple, according as your traffic outgrew the capabilities > of a single CMTS (a node in this context is a small chunk of a cable > network). > > One way of getting around this mess is to backhaul all your static > customer interfaces using mpls l2vpn PWHE up to a L3 box which just > handles static IP addresses. You configure the customer's static > default gateway IP address on an interface on this head-end router, > and the customer's cable modem will have a virtual connection directly > to that interface. The thing is, this virtual interface termination > system might or might not be tied into the entire ipv6 provisioning > system. If it isn't, you're SoL. So even if dirt-cheap residential > customers can get ipv6 very easily, it's different by virtue of the > fact that you're using static IP addresses, because they're a headache > for cable operators. aha! makes sense. i'll settle for dynamic. if i need static internally, i can always do nat66 :)/2 i do not want to play how hard can we make ipv6 deployment; just want to enable it on a five-segment office lan. but i am beginning to see that there may be a reason i am having problems getting past an account rep. randy From C-Mack.McBride at charter.com Thu Jun 21 16:59:19 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Thu, 21 Jun 2018 16:59:19 +0000 Subject: at&t business ipv6 In-Reply-To: References: Message-ID: <83e884d33441444c9df1ec34ae50c3a0@SC58MEXGP032.CORP.CHARTERCOM.com> I will speak more generally as I don't have insight into that provider. Last mile providers are working on ipv6 everywhere because ipv4 is expensive and so is CGN and MAP-T. IPv6 can reduce the need for ipv4 addresses and translation technology. In all likelihood the device your office is connected to is not yet ipv6 enabled but there is a date somewhere on a calendar belonging to an engineering group or two. The sales rep probably doesn't have a clue what that date is which is why he isn't giving you information. He simply doesn't have it. Nor is an engineering group likely to give it to sales until it is a planned maintenance. Engineers don't like promising things they can't deliver. Sales likes promising the moon if they know there is cheese available at some point in the future. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush Sent: Thursday, June 21, 2018 10:20 AM To: Nick Hilliard Cc: North American Network Operators' Group Subject: Re: at&t business ipv6 > Yes, one particular plotline which can explain why docsis systems do > this is that standard residential customers are provisioned using > giant broadcast domains directly on the cable, with DHCP config. > Obviously it's more complicated because it's docsis, but lemme > handwave and say that this is the gist of it. Because you're dealing > with giant broadcast domains, you assign IP address blocks to > individual CMTSs and your customers are assigned out of those ranges. > > Assigning ipv6 in this context is really simple: it's part of the > baseline DOCSIS3.0 standard and is supported incredibly well by all > parts of the network. > > Static addresses don't fit into this paradigm because you if you > configure your static customers from a single broadcast domain, then > they are glued to a particular CMTS and can't be moved from that CMTS > unless you renumber them. > > This doesn't work in practice because if you want to grow your > network, you probably want to be able to move around chunks of your > cable network from one CMTS to another in order to balance out your > traffic. Or you might want to split a bunch of cable nodes from one > CMTS to multiple, according as your traffic outgrew the capabilities > of a single CMTS (a node in this context is a small chunk of a cable > network). > > One way of getting around this mess is to backhaul all your static > customer interfaces using mpls l2vpn PWHE up to a L3 box which just > handles static IP addresses. You configure the customer's static > default gateway IP address on an interface on this head-end router, > and the customer's cable modem will have a virtual connection directly > to that interface. The thing is, this virtual interface termination > system might or might not be tied into the entire ipv6 provisioning > system. If it isn't, you're SoL. So even if dirt-cheap residential > customers can get ipv6 very easily, it's different by virtue of the > fact that you're using static IP addresses, because they're a headache > for cable operators. aha! makes sense. i'll settle for dynamic. if i need static internally, i can always do nat66 :)/2 i do not want to play how hard can we make ipv6 deployment; just want to enable it on a five-segment office lan. but i am beginning to see that there may be a reason i am having problems getting past an account rep. randy E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From sethm at rollernet.us Thu Jun 21 17:39:10 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 21 Jun 2018 10:39:10 -0700 Subject: at&t business ipv6 In-Reply-To: <83e884d33441444c9df1ec34ae50c3a0@SC58MEXGP032.CORP.CHARTERCOM.com> References: <83e884d33441444c9df1ec34ae50c3a0@SC58MEXGP032.CORP.CHARTERCOM.com> Message-ID: <6a9207ab-46a9-aedf-aff9-9c17d559ff0d@rollernet.us> On 6/21/18 09:59, McBride, Mack wrote: > I will speak more generally as I don't have insight into that provider. > Last mile providers are working on ipv6 everywhere because ipv4 is expensive and so is CGN and MAP-T. > IPv6 can reduce the need for ipv4 addresses and translation technology. > In all likelihood the device your office is connected to is not yet ipv6 enabled but there is a date somewhere on a calendar belonging to an engineering group or two. > The sales rep probably doesn't have a clue what that date is which is why he isn't giving you information. > He simply doesn't have it. Nor is an engineering group likely to give it to sales until it is a planned maintenance. > Engineers don't like promising things they can't deliver. > Sales likes promising the moon if they know there is cheese available at some point in the future. The only thing that's worked for me is refusing to sign agreements or following through on cancellations unless it's delivered, not promised. ~Seth From richard at pedantictheory.com Fri Jun 22 00:25:47 2018 From: richard at pedantictheory.com (Richard Porter) Date: Thu, 21 Jun 2018 17:25:47 -0700 Subject: Sorta [OT] Contact Request Message-ID: <3CA23D78-C1DD-4BCE-91D1-69DB4502792C@pedantictheory.com> Short story, Wife is moving us to a remote location. Anyone from Windstream ISP in greater Dallas TX area on the list that can contact me? Thanks!, ~Richard From mark.tinka at seacom.mu Fri Jun 22 07:04:02 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 22 Jun 2018 09:04:02 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> Message-ID: <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> On 20/Jun/18 05:48, Jared Mauch wrote: > MikroTik is getting there but most people are just not enabling it either. I have a MikroTik hAP Lite router for my FTTH service at my house. It has excellent support for IPv6, including a ton of translation mechanisms. My problem is my home provider doesn't do IPv6, so I run a 6-in-4 tunnel back to my own backbone for the service (no latency impact as my home provider is my IP Transit customer :-) ). This is a little unstable because my home provider doesn't know how to give me a stable IPv4 address for my FTTH service. But I do have to say that I am massively impressed by what that little MikroTik box can do. IPv6 on my home LAN works as expected, as it does across the 6-in-4 tunnel. Mark. From mark.tinka at seacom.mu Fri Jun 22 07:10:17 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 22 Jun 2018 09:10:17 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <4D132A6C-1552-4593-BC96-6DFDBAB64BB5@puck.nether.net> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <1566e3a5-3fd9-2cfd-2eff-4f92f33fd995@rollernet.us> <4D132A6C-1552-4593-BC96-6DFDBAB64BB5@puck.nether.net> Message-ID: On 20/Jun/18 06:06, Jared Mauch wrote: > I know. They’re very popular in the WISP and FTTH communities that are doing sub-10G as their aggregate bits. I understand the price appeal but not a fan personally. Not a fan either for the backbone, even though a lot of ISP's in South Africa use them for this... admittedly, small networks that simply don't have the cash to dish out to the big vendors. I know we've had some issues setting up BGP sessions with MikroTik-based customers/peers, mainly around how RouterOS interprets various BGP-related RFC's. But for the home, I can't fault them. They do fix plenty of bugs (almost as much as they push out new features). I have seen some IPv6 bug fixes in recent updates they've published, but nothing that really makes a difference to my home world, as far as I can remember. Mark. From jordi.palet at consulintel.es Fri Jun 22 08:00:16 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 22 Jun 2018 10:00:16 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> Message-ID: <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> I've many customers using MikroTik. The problem with its IPv6 support is that is only supporting 6in4, which by the way, they call it 6to4, so it is very weird and confusing customers ... So for native IPv6 or a 6in4 tunnel, is fine, but any other transition mechanism is NOT supported, so we end up reflashing then with OpenWRT. Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Mark Tinka Fecha: viernes, 22 de junio de 2018, 9:07 Para: Jared Mauch , Job Snijders CC: North American Network Operators' Group Asunto: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On 20/Jun/18 05:48, Jared Mauch wrote: > MikroTik is getting there but most people are just not enabling it either. I have a MikroTik hAP Lite router for my FTTH service at my house. It has excellent support for IPv6, including a ton of translation mechanisms. My problem is my home provider doesn't do IPv6, so I run a 6-in-4 tunnel back to my own backbone for the service (no latency impact as my home provider is my IP Transit customer :-) ). This is a little unstable because my home provider doesn't know how to give me a stable IPv4 address for my FTTH service. But I do have to say that I am massively impressed by what that little MikroTik box can do. IPv6 on my home LAN works as expected, as it does across the 6-in-4 tunnel. Mark. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mark.tinka at seacom.mu Fri Jun 22 10:09:28 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 22 Jun 2018 12:09:28 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> Message-ID: <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> On 22/Jun/18 10:00, JORDI PALET MARTINEZ via NANOG wrote: > > The problem with its IPv6 support is that is only supporting 6in4, which by the way, they call it 6to4, so it is very weird and confusing customers ... That "6-to-4 actually means 6-in-4" was quite confusing to me as well. I just enabled it to prove that they had a language moment there. Good thing it didn't backfire on me :-). > So for native IPv6 or a 6in4 tunnel, is fine, but any other transition mechanism is NOT supported, so we end up reflashing then with OpenWRT. Not sure I'd blame them either - they develop a lot of features for pretty much next-to-nothing; and are being enabled by customers that are willing to take the risk for relief on budget. They could be more inclined to fix bugs and develop corner-case features sooner if they were in the premium market. But, as my (well-known on this list) American friend would say, "I conjecturbate" :-). Mark. From jordi.palet at consulintel.es Fri Jun 22 10:47:29 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 22 Jun 2018 12:47:29 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> Message-ID: <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> The problem with its IPv6 support is that is only supporting 6in4, which by the way, they call it 6to4, so it is very weird and confusing customers ... That "6-to-4 actually means 6-in-4" was quite confusing to me as well. I just enabled it to prove that they had a language moment there. Good thing it didn't backfire on me :-). Yeah I can confirm, as I tested it several times, 6to4 for them is proto41, but it is very confusing and against standards nomenclature … This don’t say anything good from a vendor, in my opinion! So for native IPv6 or a 6in4 tunnel, is fine, but any other transition mechanism is NOT supported, so we end up reflashing then with OpenWRT. Not sure I'd blame them either - they develop a lot of features for pretty much next-to-nothing; and are being enabled by customers that are willing to take the risk for relief on budget. I’ve got very good customers from Mikrotik asking them in private and in public and they even didn’t reply. No other transition mechanism is available, no roadmap. So, you can’t use them for example for an IPv6-only access network which clearly is what is needed now. They could be more inclined to fix bugs and develop corner-case features sooner if they were in the premium market. But, as my (well-known on this list) American friend would say, "I conjecturbate" :-). They basically run a Linux … and you have OpenWRT sources with all what they need to implement 4in6 transition mechanisms, so no excuses! I must say also that no excuses for other CPE vendors, of course, but others at least have DS-Lite or even lw4o6. Very few offer 464XLAT (CLAT part is what the CPE needs) or MAP-T/E. Hopefully this will change soon. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mark.tinka at seacom.mu Fri Jun 22 11:23:21 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 22 Jun 2018 13:23:21 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> Message-ID: On 22/Jun/18 12:47, JORDI PALET MARTINEZ wrote: > > Yeah I can confirm, as I tested it several times, 6to4 for them is > proto41, but it is very confusing and against standards nomenclature … > This don’t say anything good from a vendor, in my opinion! > Even those networks I know running MikroTik for revenue generation don't run around saying they think they are working with the best vendor :-). But the truth is in the numbers - I'm to find another vendor in my parts that sells more gear without presence in any country on the continent. >   > > They basically run a Linux … and you have OpenWRT sources with all > what they need to implement 4in6 transition mechanisms, so no excuses! > I must say also that no excuses for other CPE vendors, of course, but > others at least have DS-Lite or even lw4o6. Very few offer 464XLAT > (CLAT part is what the CPE needs) or MAP-T/E. Hopefully this will > change soon. > On the plus side, MikroTik regularly push out updates for their devices, unlike traditional home CPE whose updates tend to disappear one year after you buy and install them, leaving the only option to update software being a hardware swap-out. Can MikroTik do more, certainly. But this is clearly a case of "you get what you pay for". On the other hand, Cisco have (yet again) delayed ORR until 2019/2020, if at all. Juniper have screwed up their EX switch CLI with this ELS monstrosity, a problem they hope to correct in 2019/2020, if at all. And I'm paying through eyes for those puppies... Mark. From jordi.palet at consulintel.es Fri Jun 22 13:05:43 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 22 Jun 2018 15:05:43 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> Message-ID: I’m not really sure “you get what you pay for” … compare with OpenWRT … you have frequent updates, even in days when some important security flaw is discovered, as it happened a few months ago with WiFi. You can even develop yourself what you want or pay folks to do it for you. And of course, you don’t depend on a specific hardware vendor. You can have a single model or several ones depending on customer’s needs, but all share the same firmware. You can buy very good quality products from China with 1-5 FastEthernet or Gigabit ports, 1 or dual radio WiFi, 1 or several USB (2.0 or 3.0), with or without Bluetooth, SD card support, even SATA support, and even LTE support. You have so many vendors that you can even decide what CPU you prefer to have and even what Wireless chips … A basic one will be around 15 USD, the most powerful one will be around 30 USD (without the LTE interface, but space for it). Regards, Jordi De: Mark Tinka Fecha: viernes, 22 de junio de 2018, 13:23 Para: JORDI PALET MARTINEZ CC: "nanog at nanog.org" Asunto: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On 22/Jun/18 12:47, JORDI PALET MARTINEZ wrote: Yeah I can confirm, as I tested it several times, 6to4 for them is proto41, but it is very confusing and against standards nomenclature … This don’t say anything good from a vendor, in my opinion! Even those networks I know running MikroTik for revenue generation don't run around saying they think they are working with the best vendor :-). But the truth is in the numbers - I'm to find another vendor in my parts that sells more gear without presence in any country on the continent. They basically run a Linux … and you have OpenWRT sources with all what they need to implement 4in6 transition mechanisms, so no excuses! I must say also that no excuses for other CPE vendors, of course, but others at least have DS-Lite or even lw4o6. Very few offer 464XLAT (CLAT part is what the CPE needs) or MAP-T/E. Hopefully this will change soon. On the plus side, MikroTik regularly push out updates for their devices, unlike traditional home CPE whose updates tend to disappear one year after you buy and install them, leaving the only option to update software being a hardware swap-out. Can MikroTik do more, certainly. But this is clearly a case of "you get what you pay for". On the other hand, Cisco have (yet again) delayed ORR until 2019/2020, if at all. Juniper have screwed up their EX switch CLI with this ELS monstrosity, a problem they hope to correct in 2019/2020, if at all. And I'm paying through eyes for those puppies... Mark. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mark.tinka at seacom.mu Fri Jun 22 13:31:29 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 22 Jun 2018 15:31:29 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> Message-ID: On 22/Jun/18 15:05, JORDI PALET MARTINEZ via NANOG wrote: > I’m not really sure “you get what you pay for” … compare with OpenWRT … you have frequent updates, even in days when some important security flaw is discovered, as it happened a few months ago with WiFi. You can even develop yourself what you want or pay folks to do it for you. No one disputes that, but there is a reason why operators are paying for MikroTik instead of taking a white box and flashing it with free code from any number of sources. They could either spend time developing free code on white boxes to a level where it does everything they want, or they could decide for what MikroTik offers for an integrated solution (hardware + software), the time and effort are outweighed by the cost, as a function of traditional alternatives such as Cisco, Juniper, Nokia, Brocade, e.t.c. Joe Average has neither the experience nor the inclination to flash whatever box he has with OpenWRT. You and I do (well, I've grown lazy, so...). Copy & paste for FTTH service providers dealing with thousands or millions of customers who want to pay nothing for 1Gbps to their house, and you quickly see why this is not an easy problem to solve. Pity that vCPE's don't seem to be picking up as they were once touted to... that would have been an easy truck-roll for IPv6 to everyone that guaranteed it would work, always! Mark. From cscora at apnic.net Fri Jun 22 18:03:03 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Jun 2018 04:03:03 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180622180303.562DDC450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Jun, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 703303 Prefixes after maximum aggregation (per Origin AS): 270193 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 338217 Total ASes present in the Internet Routing Table: 61035 Prefixes per ASN: 11.52 Origin-only ASes present in the Internet Routing Table: 52713 Origin ASes announcing only one prefix: 23017 Transit ASes present in the Internet Routing Table: 8322 Transit-only ASes present in the Internet Routing Table: 278 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 35 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 57 Number of instances of unregistered ASNs: 58 Number of 32-bit ASNs allocated by the RIRs: 23039 Number of 32-bit ASNs visible in the Routing Table: 18570 Prefixes from 32-bit ASNs in the Routing Table: 77573 Number of bogon 32-bit ASNs visible in the Routing Table: 19 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 251 Number of addresses announced to Internet: 2857601731 Equivalent to 170 /8s, 83 /16s and 138 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 234814 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 191808 Total APNIC prefixes after maximum aggregation: 54535 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 190565 Unique aggregates announced from the APNIC address blocks: 77963 APNIC Region origin ASes present in the Internet Routing Table: 8891 APNIC Prefixes per ASN: 21.43 APNIC Region origin ASes announcing only one prefix: 2504 APNIC Region transit ASes present in the Internet Routing Table: 1333 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 35 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3865 Number of APNIC addresses announced to Internet: 767315458 Equivalent to 45 /8s, 188 /16s and 78 /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: 209266 Total ARIN prefixes after maximum aggregation: 99538 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209732 Unique aggregates announced from the ARIN address blocks: 99325 ARIN Region origin ASes present in the Internet Routing Table: 18203 ARIN Prefixes per ASN: 11.52 ARIN Region origin ASes announcing only one prefix: 6745 ARIN Region transit ASes present in the Internet Routing Table: 1809 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2367 Number of ARIN addresses announced to Internet: 1103139744 Equivalent to 65 /8s, 192 /16s and 147 /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: 192413 Total RIPE prefixes after maximum aggregation: 91986 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 188546 Unique aggregates announced from the RIPE address blocks: 112093 RIPE Region origin ASes present in the Internet Routing Table: 25224 RIPE Prefixes per ASN: 7.47 RIPE Region origin ASes announcing only one prefix: 11371 RIPE Region transit ASes present in the Internet Routing Table: 3507 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7109 Number of RIPE addresses announced to Internet: 715741568 Equivalent to 42 /8s, 169 /16s and 89 /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: 91026 Total LACNIC prefixes after maximum aggregation: 20078 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 92442 Unique aggregates announced from the LACNIC address blocks: 40924 LACNIC Region origin ASes present in the Internet Routing Table: 7248 LACNIC Prefixes per ASN: 12.75 LACNIC Region origin ASes announcing only one prefix: 2013 LACNIC Region transit ASes present in the Internet Routing Table: 1348 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4792 Number of LACNIC addresses announced to Internet: 172466080 Equivalent to 10 /8s, 71 /16s and 159 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 18732 Total AfriNIC prefixes after maximum aggregation: 4007 AfriNIC Deaggregation factor: 4.67 Prefixes being announced from the AfriNIC address blocks: 21767 Unique aggregates announced from the AfriNIC address blocks: 7688 AfriNIC Region origin ASes present in the Internet Routing Table: 1162 AfriNIC Prefixes per ASN: 18.73 AfriNIC Region origin ASes announcing only one prefix: 384 AfriNIC Region transit ASes present in the Internet Routing Table: 225 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 437 Number of AfriNIC addresses announced to Internet: 98499072 Equivalent to 5 /8s, 222 /16s and 250 /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 5427 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4294 422 437 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2918 1153 79 VIETEL-AS-AP Viettel Group, VN 4766 2847 11134 760 KIXS-AS-KR Korea Telecom, KR 9829 2812 1497 543 BSNL-NIB National Internet Backbone, IN 9394 2540 4907 31 CTTNET China TieTong Telecommunications 45899 2511 1602 158 VNPT-AS-VN VNPT Corp, VN 9808 2245 8699 26 CMNET-GD Guangdong Mobile Communication 17974 2220 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2107 417 205 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3429 1324 84 SHAW - Shaw Communications Inc., CA 22773 3285 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2359 242 474 CABLEONE - CABLE ONE, INC., US 16509 2171 4711 687 AMAZON-02 - Amazon.com, Inc., US 18566 2170 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2108 2570 470 CHARTER-NET-HKY-NC - Charter Communicat 209 2018 5070 610 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1996 342 162 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 1938 968 1384 AKAMAI-AS - Akamai Technologies, Inc., 7018 1739 20202 1271 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4392 1604 117 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2724 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2548 632 1879 AKAMAI-ASN1, US 12389 2013 1877 708 ROSTELECOM-AS, RU 34984 2013 334 495 TELLCOM-AS, TR 9121 1898 1692 19 TTNET, TR 13188 1609 100 43 TRIOLAN, UA 8402 1267 544 14 CORBINA-AS OJSC "Vimpelcom", RU 9198 1067 363 28 KAZTELECOM-AS, KZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 4988 3308 584 Uninet S.A. de C.V., MX 10620 3561 541 258 Telmex Colombia S.A., CO 11830 2654 369 78 Instituto Costarricense de Electricidad 6503 1640 443 60 Axtel, S.A.B. de C.V., MX 7303 1507 1026 188 Telecom Argentina S.A., AR 3816 1422 555 217 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1036 2245 180 CLARO S.A., BR 11172 927 127 86 Alestra, S. de R.L. de C.V., MX 6147 920 377 31 Telefonica del Peru S.A.A., PE 18881 913 1078 30 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 1067 396 48 LINKdotNET-AS, EG 37611 871 107 9 Afrihost, ZA 36903 753 378 140 MT-MPLS, MA 36992 738 1411 39 ETISALAT-MISR, EG 8452 622 1730 18 TE-AS TE-AS, EG 24835 580 802 18 RAYA-AS, EG 37492 472 470 57 ORANGE-, TN 29571 454 68 11 ORANGE-COTE-IVOIRE, CI 37342 379 32 1 MOVITEL, MZ 15399 373 39 8 WANANCHI-, KE 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 5427 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4988 3308 584 Uninet S.A. de C.V., MX 12479 4392 1604 117 UNI2-AS, ES 7545 4294 422 437 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3561 541 258 Telmex Colombia S.A., CO 6327 3429 1324 84 SHAW - Shaw Communications Inc., CA 22773 3285 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2918 1153 79 VIETEL-AS-AP Viettel Group, VN 4766 2847 11134 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 8151 4988 4404 Uninet S.A. de C.V., MX 12479 4392 4275 UNI2-AS, ES 7545 4294 3857 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3429 3345 SHAW - Shaw Communications Inc., CA 10620 3561 3303 Telmex Colombia S.A., CO 22773 3285 3138 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2918 2839 VIETEL-AS-AP Viettel Group, VN 8551 2724 2681 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2654 2576 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 64514 PRIVATE 5.42.231.0/24 35753 ITC ITC AS number, SA 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65544 DOCUMENT 103.197.121.0/24 65542 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.143.192.0/24 22119 -Reserved AS-, ZZ 23.164.128.0/24 20473 AS-CHOOPA - Choopa, LLC, US 27.100.7.0/24 56096 UNKNOWN 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 43.251.84.0/23 133676 PNPL-AS Precious netcom pvt ltd, IN 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 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:14 /9:11 /10:37 /11:99 /12:290 /13:567 /14:1097 /15:1903 /16:13360 /17:7929 /18:13781 /19:25231 /20:39221 /21:45434 /22:87306 /23:70744 /24:394098 /25:820 /26:613 /27:620 /28:35 /29:20 /30:17 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3216 3429 SHAW - Shaw Communications Inc., CA 12479 3136 4392 UNI2-AS, ES 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2547 3285 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2186 2724 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2063 2170 MEGAPATH5-US - MegaPath Corporation, US 11830 2002 2654 Instituto Costarricense de Electricidad y Telec 11492 1916 2359 CABLEONE - CABLE ONE, INC., US 30036 1748 1996 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1612 3561 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1604 2:851 4:20 5:2828 6:40 7:1 8:1122 12:1874 13:195 14:1750 15:30 16:3 17:214 18:55 20:49 23:2628 24:2222 25:2 27:2416 31:2018 32:92 35:27 36:498 37:2753 38:1450 39:229 40:123 41:3099 42:674 43:1922 44:122 45:4765 46:3035 47:201 49:1326 50:1051 51:315 52:1058 54:372 55:4 56:12 57:39 58:1624 59:1001 60:388 61:2094 62:1848 63:1788 64:5029 65:2215 66:4666 67:2446 68:1168 69:3225 70:1152 71:556 72:2120 74:2725 75:422 76:454 77:1545 78:1716 79:1732 80:1510 81:1391 82:1075 83:784 84:1074 85:2040 86:567 87:1300 88:927 89:2343 90:212 91:6388 92:1199 93:2367 94:2389 95:2871 96:737 97:357 98:945 99:133 100:83 101:1231 102:102 103:17968 104:3565 105:211 106:650 107:1783 108:694 109:3445 110:1640 111:1776 112:1276 113:1270 114:1125 115:1659 116:1644 117:1754 118:2151 119:1670 120:990 121:1053 122:2471 123:1779 124:1439 125:1905 128:1082 129:668 130:454 131:1603 132:695 133:193 134:1019 135:225 136:499 137:564 138:1971 139:646 140:430 141:722 142:802 143:975 144:801 145:481 146:1189 147:725 148:1637 149:760 150:733 151:1059 152:788 153:314 154:1148 155:769 156:1074 157:797 158:649 159:1739 160:1155 161:788 162:2581 163:593 164:1063 165:1486 166:451 167:1299 168:3075 169:818 170:3779 171:457 172:1078 173:2011 174:907 175:779 176:1995 177:4109 178:2510 179:1218 180:2197 181:2286 182:2379 183:1191 184:1028 185:13667 186:3596 187:2341 188:2857 189:2070 190:8122 191:1428 192:9833 193:5977 194:4857 195:3971 196:2600 197:1571 198:5544 199:5894 200:7338 201:5004 202:10457 203:10190 204:4565 205:2894 206:3109 207:3172 208:3999 209:3967 210:4035 211:2099 212:3025 213:2774 214:981 215:57 216:6000 217:2122 218:897 219:633 220:1766 221:977 222:1023 223:1296 End of report From jared at puck.nether.net Sat Jun 23 11:17:15 2018 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 23 Jun 2018 07:17:15 -0400 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> Message-ID: <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> > On Jun 22, 2018, at 9:31 AM, Mark Tinka wrote: > > > > On 22/Jun/18 15:05, JORDI PALET MARTINEZ via NANOG wrote: > >> I’m not really sure “you get what you pay for” … compare with OpenWRT … you have frequent updates, even in days when some important security flaw is discovered, as it happened a few months ago with WiFi. You can even develop yourself what you want or pay folks to do it for you. > > No one disputes that, but there is a reason why operators are paying for > MikroTik instead of taking a white box and flashing it with free code > from any number of sources. > > They could either spend time developing free code on white boxes to a > level where it does everything they want, or they could decide for what > MikroTik offers for an integrated solution (hardware + software), the > time and effort are outweighed by the cost, as a function of traditional > alternatives such as Cisco, Juniper, Nokia, Brocade, e.t.c. > > Joe Average has neither the experience nor the inclination to flash > whatever box he has with OpenWRT. You and I do (well, I've grown lazy, > so...). Copy & paste for FTTH service providers dealing with thousands > or millions of customers who want to pay nothing for 1Gbps to their > house, and you quickly see why this is not an easy problem to solve. I’ve found most folks doing Tik need the GUI, etc to interact with the devices. I can’t say I blame them in some ways either. Have you tried to upgrade an IOS-XR device before? One-click updates in Tik are much easier. Even UBNT it’s fairly straightforward. Personally I use Tik for layer-2 stuff, be it media converters or switches where there’s not some other alternative that makes more sense. I’m comfortable with a CLI, but most people I’ve tried to say “hey, use this it’s better” say “I can’t http/https to it, the learning curve is too steep”. - Jared From jean at ddostest.me Sat Jun 23 16:27:35 2018 From: jean at ddostest.me (Jean | ddostest.me) Date: Sat, 23 Jun 2018 12:27:35 -0400 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> <9e2c59eb-2b9a-b68e-76c5-e60531c9a499@retevia.net> Message-ID: <322c14af-82db-c8dd-6bd8-6b3b3d8196d1@ddostest.me> From an Apple device point of view, ipv6 should be faster than ipv4 where both are available. Because, Apple adds a 25 ms artifical penalty to ipv4 dns resolution. https://ma.ttias.be/apple-favours-ipv6-gives-ipv4-a-25ms-penalty/ So if you test facebook from a Mac/iPhone/iPad, it will definitely loads faster over ipv6 On 06/19/2018 08:32 PM, lobna gouda wrote: > Although the FB link is vague but argument itself is true. We just became more intelligent in deploying IPV6. The same measurement if was done in less than a decade for example would show that ipv4 is faster. The dual stack implementation and the slowness introduced by Teredo Tunneling were the main reasons and now we are getting smarter having it deprecating > > https://labs.ripe.net/Members/gih/examining-ipv6-performance > > https://tools.ietf.org/html/rfc6555 > > https://tools.ietf.org/html/rfc7526 > Things change, Ipv6 response is showing better has IPV4 is having more TCP re-transmission which the culprit is still not known ( need more analysis) but fingers are pointing to the exhaustion of the ipv4 address so basically CGN , load-balancers and address sharing. Although we can not eliminate peering links and Firewalls. Yet if we have exactly the same topology and traffic crossing the links et Firewalls locations/policies. Analysis didnot confirm why it would have rather more harm on ipv4 than 6 > > Brgds, > > LG > > > ________________________________ > From: NANOG on behalf of Lee Howard > Sent: Wednesday, June 13, 2018 7:46 AM > To: nanog at nanog.org > Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap > > > > On 06/11/2018 05:16 PM, Scott Weeks wrote: >> --- cb.list6 at gmail.com wrote: >> From: Ca By >> >>> Meanwhile, FB reports that 75% of mobiles in the USA >>> reach them via ipv6 >>> >>> And Akaimai reports 80% of mobiles >> And they both report ipv6 is faster / better. >> ---------------------------------------- > Let me grab a few more for you: > > https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html > Preparing for IPv6-only mobile networks: Why and How - The ... > blogs.akamai.com > Apple's upcoming App Store submission requirement around supporting IPv6-only environments (announced last year at WWDC and being enforced starting June 1) has been getting plenty of recent coverage. iOS application developers already need to make sure their applications work in... > > > > > > https://blogs.akamai.com/2016/10/ipv6-at-akamai-edge-2016.html > > https://www.theregister.co.uk/2016/07/28/ipv6_now_faster_a_fifth_of_the_time > which cites an academic paper > http://dl.acm.org/citation.cfm?doid=2959424.2959429 by Vaibhav Bajpai > and Jürgen Schönwälder > > https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-kahn/ > > https://community.infoblox.com/t5/IPv6-CoE-Blog/Can-IPv6-Rally-Be-Faster-than-IPv4-Part-1/ba-p/6419 > > > https://www.nanog.org/meetings/abstract?id=2281 > >> I'd sure like to see how they came up with these >> numbers in a technically oriented paper. > Most of the above links explain how they got the numbers. > Facebook, in particular, did A/B testing using Mobile Proxygen, which is > to say that they configured their mobile app to report performance over > both IPv4 and IPv6 from the same handset at the same time. > Others, including APNIC's https://stats.labs.apnic.net/v6perf have a > browser fetch two objects with unique URLs, one from an IPv4-only server > and one from an IPv6-only server, and compare them. > > > >> There >> should be no difference, except for no CGN or Happy >> Eyeballs working better or something similar. Am I >> missing something? Same routers; same links; same >> RTTs; same interrupt times on servers; same etc, etc >> for both protocols. > From time to time somebody says, "Okay, maybe it works in practice, but > does it work in *theory*?" > > Busy engineers hardly ever investigate things going inexplicably right. > > My hypothesis is that the observed difference in performance relates to > how mobile networks deploy their transition mechanisms. Those with a > dual-stack APN take a native path for IPv6, while using a CGN path for > IPv4, which, combined with the Happy Eyeballs head start, might add > 501microseconds, which is a ms, which is 15% of 7ms. Those with an > IPv6-only APN use a native path for IPv6, while using either a NAT64 for > IPv4 (identical performance to CGN) or 464xlat, which requires > translation both in the handset and the NAT64; handsets may not be > optimized for header translation. > > However, I have a dozen other hypotheses, and the few experiments I've > been able to run have not confirmed any hypothesis. For instance, when > one protocol is faster than another on a landline network, hop count is > not a correlation (therefore, shorter paths, traffic engineering, etc., > are not involved). > > Lee > >> Hmm... Faster and better? >> >> The links seem to be an IPv6 cheerleader write up. >> I looked at the URLs and the URLs one pointed to and >> pulled out everything related to IPv6 being >> faster/better. >> >> >> Akamai URL: >> >> "For dual-stacked hostnames we typically see higher >> average estimated throughput over IPv6 than over IPv4. >> Some of this may be due to IPv6-connected users being >> correlated with better connectivity, but over half of >> dual-stacked hostnames (weighted by daily bytes >> delivered) have IPv6 estimated throughput at least 50% >> faster than IPv4, and 90% of these hostnames have the >> IPv6 estimated throughput at least 10% faster than >> IPv4." >> >> >> >> FB URL: >> >> "People using Facebook services typically see better >> performance over IPv6..." >> >> and it points to >> https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board >> which says: >> >> "We’ve long been anticipating the exhaustion of IPv >> in favor of the speed and performance benefits of >> IPv6." >> >> "We’ve observed that accessing Facebook can be 10-15 >> percent faster over IPv6." >> >> >> I'd sure like to see how they came up with these >> numbers in a technically oriented paper. There >> should be no difference, except for no CGN or Happy >> Eyeballs working better or something similar. Am I >> missing something? Same routers; same links; same >> RTTs; same interrupt times on servers; same etc, etc >> for both protocols. >> >> scott From randy at psg.com Sat Jun 23 18:14:45 2018 From: randy at psg.com (Randy Bush) Date: Sat, 23 Jun 2018 11:14:45 -0700 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> Message-ID: in small corners, e.g. home, i use ubiquiti erx. i use the cli for config, and the gooey for watching traffic levels in pretty colors. they play well with both concast and at&t u-verse ipv4 and ipv6. in san jose $dayjob, i am stuck with a cisco asa for cpe, a 1990s retro antique providing job security for a thousand engineers who maximize complexity. randy From valdis.kletnieks at vt.edu Sat Jun 23 21:16:59 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 23 Jun 2018 17:16:59 -0400 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <322c14af-82db-c8dd-6bd8-6b3b3d8196d1@ddostest.me> References: <20180611141656.D25636BB@m0117567.ppops.net> <9e2c59eb-2b9a-b68e-76c5-e60531c9a499@retevia.net> <322c14af-82db-c8dd-6bd8-6b3b3d8196d1@ddostest.me> Message-ID: <181889.1529788619@turing-police.cc.vt.edu> On Sat, 23 Jun 2018 12:27:35 -0400, "Jean | ddostest.me via NANOG" said: > Because, Apple adds a 25 ms artifical penalty to ipv4 dns resolution. > > https://ma.ttias.be/apple-favours-ipv6-gives-ipv4-a-25ms-penalty/ Umm.. It's 3 year old news that Apple implemented Happy Eyeballs. And if you read, it continues on saying that both Firefox and Chrome use a 300ms timer rather than 25ms. The solution is, of course, to not build websites that need to hit 20 or 30 IPv4-only tracking and affiliate and ad sites. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nanog at ics-il.net Sat Jun 23 21:17:32 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 23 Jun 2018 16:17:32 -0500 (CDT) Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <4D132A6C-1552-4593-BC96-6DFDBAB64BB5@puck.nether.net> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <1566e3a5-3fd9-2cfd-2eff-4f92f33fd995@rollernet.us> <4D132A6C-1552-4593-BC96-6DFDBAB64BB5@puck.nether.net> Message-ID: <868977006.8011.1529788647193.JavaMail.mhammett@ThunderFuck> Not much limiting them to the sub-10G world, though. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Seth Mattinen" Cc: nanog at nanog.org Sent: Tuesday, June 19, 2018 11:06:24 PM Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap > On Jun 19, 2018, at 11:55 PM, Seth Mattinen wrote: > > On 6/19/18 8:48 PM, Jared Mauch wrote: >> MikroTik is getting there but most people are just not enabling it either. > > > RouterOS still has "will not fix" IPv6 bugs, so that doesn't help shops dependent on Mikrotik want to move forward with deploying it. I know. They’re very popular in the WISP and FTTH communities that are doing sub-10G as their aggregate bits. I understand the price appeal but not a fan personally. - Jared From nanog at ics-il.net Sat Jun 23 21:19:37 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 23 Jun 2018 16:19:37 -0500 (CDT) Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> Message-ID: <1371338668.8015.1529788773057.JavaMail.mhammett@ThunderFuck> Your last paragraph hits it on the head. I hear people bash Mikrotik, but then I've heard many times people with $$$$ vendor's gear complaining just as much (just about different things) and they're paying significantly more for that privilege. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" To: "JORDI PALET MARTINEZ" Cc: nanog at nanog.org Sent: Friday, June 22, 2018 6:23:21 AM Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On 22/Jun/18 12:47, JORDI PALET MARTINEZ wrote: > > Yeah I can confirm, as I tested it several times, 6to4 for them is > proto41, but it is very confusing and against standards nomenclature … > This don’t say anything good from a vendor, in my opinion! > Even those networks I know running MikroTik for revenue generation don't run around saying they think they are working with the best vendor :-). But the truth is in the numbers - I'm to find another vendor in my parts that sells more gear without presence in any country on the continent. > > > They basically run a Linux … and you have OpenWRT sources with all > what they need to implement 4in6 transition mechanisms, so no excuses! > I must say also that no excuses for other CPE vendors, of course, but > others at least have DS-Lite or even lw4o6. Very few offer 464XLAT > (CLAT part is what the CPE needs) or MAP-T/E. Hopefully this will > change soon. > On the plus side, MikroTik regularly push out updates for their devices, unlike traditional home CPE whose updates tend to disappear one year after you buy and install them, leaving the only option to update software being a hardware swap-out. Can MikroTik do more, certainly. But this is clearly a case of "you get what you pay for". On the other hand, Cisco have (yet again) delayed ORR until 2019/2020, if at all. Juniper have screwed up their EX switch CLI with this ELS monstrosity, a problem they hope to correct in 2019/2020, if at all. And I'm paying through eyes for those puppies... Mark. From nanog at ics-il.net Sat Jun 23 21:23:52 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 23 Jun 2018 16:23:52 -0500 (CDT) Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> References: <20180611141656.D25636BB@m0117567.ppops.net> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> Message-ID: <930894544.8023.1529789031517.JavaMail.mhammett@ThunderFuck> A couple of the big draws to Mikrotik (aside from the performance and features you get for the price) are Winbox, Torch, and real-time stats. Great features that don't really have an equal elsewhere. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Mark Tinka" Cc: nanog at nanog.org Sent: Saturday, June 23, 2018 6:17:15 AM Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap > On Jun 22, 2018, at 9:31 AM, Mark Tinka wrote: > > > > On 22/Jun/18 15:05, JORDI PALET MARTINEZ via NANOG wrote: > >> I’m not really sure “you get what you pay for” … compare with OpenWRT … you have frequent updates, even in days when some important security flaw is discovered, as it happened a few months ago with WiFi. You can even develop yourself what you want or pay folks to do it for you. > > No one disputes that, but there is a reason why operators are paying for > MikroTik instead of taking a white box and flashing it with free code > from any number of sources. > > They could either spend time developing free code on white boxes to a > level where it does everything they want, or they could decide for what > MikroTik offers for an integrated solution (hardware + software), the > time and effort are outweighed by the cost, as a function of traditional > alternatives such as Cisco, Juniper, Nokia, Brocade, e.t.c. > > Joe Average has neither the experience nor the inclination to flash > whatever box he has with OpenWRT. You and I do (well, I've grown lazy, > so...). Copy & paste for FTTH service providers dealing with thousands > or millions of customers who want to pay nothing for 1Gbps to their > house, and you quickly see why this is not an easy problem to solve. I’ve found most folks doing Tik need the GUI, etc to interact with the devices. I can’t say I blame them in some ways either. Have you tried to upgrade an IOS-XR device before? One-click updates in Tik are much easier. Even UBNT it’s fairly straightforward. Personally I use Tik for layer-2 stuff, be it media converters or switches where there’s not some other alternative that makes more sense. I’m comfortable with a CLI, but most people I’ve tried to say “hey, use this it’s better” say “I can’t http/https to it, the learning curve is too steep”. - Jared From lee.howard at retevia.net Sun Jun 24 14:52:24 2018 From: lee.howard at retevia.net (Lee Howard) Date: Sun, 24 Jun 2018 10:52:24 -0400 Subject: at&t business ipv6 In-Reply-To: References: Message-ID: On 06/21/2018 12:07 PM, Nick Hilliard wrote: > Randy Bush wrote on 21/06/2018 16:35: > > > Static addresses don't fit into this paradigm because you if you > configure your static customers from a single broadcast domain, then > they are glued to a particular CMTS and can't be moved from that CMTS > unless you renumber them. Completely agree with all you've said here about how DOCSIS works. Several cable operators (at least) are working to make it so that DHCPv6 assigns business customers  the same IPv6 prefix every time. Yes, it's DHCPv6 instead of static configuration, but I think it works. Additional question, though: Randy said "at&t business 1g fiber going into an Arris" As fiber, it'll be PON. If it were a traditional cable company, I'd guess DPOE (DOCSIS Provisioning Over Ethernet). Except it's AT&T, and I don't know if they're provisioning DOCSIS over their fiber; I would think it's GPON, using the same infrastructure as their U-Verse product (fiber to the curb, DSL to the home). That used to be PPPoE and not DHCP, but my information may be out of date. Lee From list at satchell.net Sun Jun 24 16:31:00 2018 From: list at satchell.net (Stephen Satchell) Date: Sun, 24 Jun 2018 09:31:00 -0700 Subject: at&t business ipv6 In-Reply-To: References: Message-ID: <7d5dfee2-91c9-e696-e9eb-55e91efb6028@satchell.net> On 06/24/2018 07:52 AM, Lee Howard wrote: > Randy said "at&t business 1g fiber going into an Arris" > As fiber, it'll be PON. If it were a traditional cable company, I'd > guess DPOE (DOCSIS Provisioning Over Ethernet). AT&T fiber goes into a PON, and then into an Arris BGW210. (Yes, I have business fiber here at satchell.net) From zhuifeng0426 at gmail.com Sun Jun 24 23:51:45 2018 From: zhuifeng0426 at gmail.com (Yifeng Zhou) Date: Sun, 24 Jun 2018 16:51:45 -0700 Subject: TCP TIMELY implementation guide Message-ID: Hi There, May I know if there's any TCP TIMELY implementation guide? Want to play with it.. Thanks! From mark.tinka at seacom.mu Mon Jun 25 08:25:49 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 25 Jun 2018 10:25:49 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> Message-ID: On 23/Jun/18 13:17, Jared Mauch wrote: > I’ve found most folks doing Tik need the GUI, etc to interact with the devices. I can’t say I blame them in some ways either. Have you tried to upgrade an IOS-XR device before? If I'm honest, one of the reasons I continue to go with the MX480 in the edge, as opposed to an ASR9000. > One-click updates in Tik are much easier. Even UBNT it’s fairly straightforward. Personally I use Tik for layer-2 stuff, be it media converters or switches where there’s not some other alternative that makes more sense. I’m comfortable with a CLI, but most people I’ve tried to say “hey, use this it’s better” say “I can’t http/https to it, the learning curve is too steep”. I use the GUI myself. I've fiddled around with the RouterOS CLI, and while it's not difficult to learn, I'm old and lazy now. The GUI is very well laid out, does everything it says it's supposed to do, which is fine by me. Mark. From mark.tinka at seacom.mu Mon Jun 25 08:27:58 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 25 Jun 2018 10:27:58 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> Message-ID: On 23/Jun/18 20:14, Randy Bush wrote: > in small corners, e.g. home, i use ubiquiti erx. i use the cli for > config, and the gooey for watching traffic levels in pretty colors. > they play well with both concast and at&t u-verse ipv4 and ipv6. That was a good tip, as I hadn't seen these before this thread. One thing I like about the MikroTik is that it goes forever without needing a reboot. My previous Claix GPON ONU + IP Router combo box needed a reboot a couple of times a year as it was running out of memory to hold NAT44 state. Same thing as my previous Netgear and Linksys routers. The MikroTik; well, had for almost 2 years and only reboot it to do software updates. Mark. From randy at psg.com Mon Jun 25 13:50:07 2018 From: randy at psg.com (Randy Bush) Date: Mon, 25 Jun 2018 06:50:07 -0700 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> Message-ID: > That was a good tip, as I hadn't seen these before this thread. they also make a good small-isp or large office router for USD 300 https://www.ubnt.com/edgemax/edgerouter-pro/ > One thing I like about the MikroTik is that it goes forever without > needing a reboot. while i have not run a ubiquiti forever, i have run them for a very long time. > My previous Claix GPON ONU + IP Router combo box needed a reboot a > couple of times a year as it was running out of memory to hold NAT44 > state. quaint i think microtik and ubiquiti are the two serious home geek cpe players of note. i was mostly happy with a netgear into which i blew openwrt, but the netgear was mediocre hardware. randy From ben at 6by7.net Mon Jun 25 13:57:00 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 25 Jun 2018 06:57:00 -0700 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> Message-ID: <87E8381E-1764-4537-AF9C-0FC48072A70C@6by7.net> I’ll cop to ubiquiti at home and at work too (mainly for Wi-Fi and some ptp backhaul in which they are very strong). Any kind of HA in their routers keeps them out my enterprise clients of mine, let alone my network core. -Ben On Jun 25, 2018, at 6:50 AM, Randy Bush wrote: >> That was a good tip, as I hadn't seen these before this thread. > > they also make a good small-isp or large office router for USD 300 > https://www.ubnt.com/edgemax/edgerouter-pro/ > >> One thing I like about the MikroTik is that it goes forever without >> needing a reboot. > > while i have not run a ubiquiti forever, i have run them for a very long > time. > >> My previous Claix GPON ONU + IP Router combo box needed a reboot a >> couple of times a year as it was running out of memory to hold NAT44 >> state. > > quaint > > i think microtik and ubiquiti are the two serious home geek cpe players > of note. i was mostly happy with a netgear into which i blew openwrt, > but the netgear was mediocre hardware. > > randy From mark.tinka at seacom.mu Mon Jun 25 14:02:48 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 25 Jun 2018 16:02:48 +0200 Subject: IPv6 faster/better proof? was Re: Need /24 (arin) asap In-Reply-To: <87E8381E-1764-4537-AF9C-0FC48072A70C@6by7.net> References: <20180611141656.D25636BB@m0117567.ppops.net> <20180612000734.GL50997@vurt.meerval.net> <9F728937-20F8-43AD-8CC3-226CA1F0B51F@puck.nether.net> <85dee917-c08f-9a50-1319-0bd8e0adff4d@seacom.mu> <9F432988-9E02-4627-8982-51E3E386EE44@consulintel.es> <04179199-f7da-1e90-1c1d-75ec3e53e045@seacom.mu> <9FC492DB-F772-4C01-B581-53C441BFE282@consulintel.es> <2A9C7915-5A16-45F5-AC62-3D0DBB57DA2A@puck.nether.net> <87E8381E-1764-4537-AF9C-0FC48072A70C@6by7.net> Message-ID: On 25/Jun/18 15:57, Ben Cannon wrote: > I’ll cop to ubiquiti at home and at work too (mainly for Wi-Fi and some ptp backhaul in which they are very strong). Any kind of HA in their routers keeps them out my enterprise clients of mine, let alone my network core. With pressure on pricing in some of our markets in Africa, we are seeing Enterprise customers asking for el-cheapo router options, and MikroTik has been right up there with plenty for sub-1Gbps deliveries. I'm thinking the Ubiquiti ERX could be a viable option, as it pays to have more than one from the pot. Mark. From benno at NLnetLabs.nl Mon Jun 25 14:20:22 2018 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Mon, 25 Jun 2018 16:20:22 +0200 Subject: Call for presentations RIPE 77 Message-ID: <2b183bb0-c389-b6c0-7d29-c9207a5601b4@NLnetLabs.nl> Dear colleagues, Please find the CFP for RIPE 77 below or at: https://ripe77.ripe.net/submit-topic/cfp/. The deadline for submissions is *26 August 2018*. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings, see the "Speakers" paragraph in CFP for more information. Kind regards, Benno Overeinder RIPE PC Chair https://ripe77.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. *RIPE 77 will take place from 15-19 October in Amsterdam, The Netherlands* The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 77. See the full descriptions of the different presentation formats: https://ripe77.ripe.net/submit-topic/presentation-formats/ Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *26 August 2018*. Proposals submitted after this date will be considered depending on the slots still available in the programme. The PC is looking for presentations covering the topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) ---- Speakers ---- Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc at ripe.net. Also note that, on an individual basis, participants can apply for a RIPE Fellowship or RACI to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship https://www.ripe.net/participate/ripe/raci ---- Submissions ---- Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe77.ripe.net/plenary-or-wg/ RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and should not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour (during evening sessions) - Lightning talks: 10 minutes in total for both the presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe77.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe77.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. ---- Diversity and Inclusion - On-Site Childcare and the RIPE Meeting Code of Conduct ---- Did you know that RIPE Meetings now have on-site childcare? You can reserve a spot for your child (age 6 months – 10 years) during the registration process for the meeting. Registrations for RIPE 77 will open mid-July. Childcare places are limited, so please be quick to reserve a spot for your child! Read about the experiences of our next generation of engineers at: https://labs.ripe.net/Members/agowland/ripe-meeting-diversity-efforts-on-site-childcare-at-ripe-76 Ensuring that RIPE Meeting values are upheld and that attendees experience a professional, respectful and safe meeting is a priority. Please do read the RIPE Meeting Code of Conduct: https://www.ripe.net/participate/meetings/ripe-meetings/ripe-meeting-code-of-conduct --- If you have any questions or requests concerning content submissions, please email pc at ripe.net. From rfg at tristatelogic.com Tue Jun 26 04:49:15 2018 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 25 Jun 2018 21:49:15 -0700 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 Message-ID: <65543.1529988555@segfault.tristatelogic.com> Sometimes I see stuff that just makes me shake my head in disbelief. Here is a good example: https://bgp.he.net/AS3266#_prefixes I mean seriously, WTF? As should be blatantly self-evident to pretty much everyone who has ever looked at any of the Internet's innumeriable prior incidents of very deliberately engineered IP space hijackings, all of the routes currently being announced by AS3266 (Bitcanal, Portugal) except for the ones in 213/8 are bloody obvious hijacks. (And to their credit, even Spamhaus has a couple of the U.S. legacy /16 blocks explicitly listed as such.) That's 39 deliberately hijacked routes, at least going by the data visible on bgp.he.net. But even that data from bgp.he.net dramatically understates the case, I'm sorry to say. According to the more complete and up-to-the-minute data that I just now fetched from RIPEstat, the real number of hijacked routes is more on the order of 130 separate hijacked routes for a total of 224,512 IPv4 addresses: https://pastebin.com/raw/Jw1my9Bb In simpler terms, Bitcanal has made off with the rough equivalent of an entire /14 block of IPv4 addresses that never belonged to them. (And of course, they haven't paid a dime to anyone for any of that space.) Of couse we could all be shocked (Shocked!) at this turn of events if it were not for the fact that Bitcanal already has a rich, longstanding, and sordid history of involvement with IP space hijacks. All one has to do is google for "Bitcanal" and "hijack" to find that out. This isn't exactly a state secret. In fact if you lookup "IP space hijacking" in any modern Internet dictionary you'll find Mr. Joao Silveira's picture next to the definition: https://twitter.com/bitcanal :-) This guy Silveira has obviously decided that he is a law unto himself, and can grab whatever IP space happens to be lying around for his own purposes... and no need to fill out any tedious forms -or- pay any fees for using any of this space to any of those annoying Regional Internet Registries. As usual, and as I have said here previously, I generally don't mind too much when these kinds of greedy idiots decide to color outside the lines. As long as they just confine themselves to hijacking abandoned IP blocks belonging to banks and/or government agencies, well then it's no skin off my nose. But when they start reselling their stolen IP space to spammers, as Mr. Silveira is apparently in the habit of doing, then I get ticked off. And actually, Mr. Silveira must be *exceptionally* greedy in that he is apparently not satisfied to just sub-lease his own legitimate IP space to snowshoe spammers, as he is clearly doing: https://pastebin.com/raw/5P5rnQ2y Obviously, merely hosting snowshoe spammers in his own IP space isn't enough to keep Mr. Silveira in the style to which he has become accustomned, so he has to go out and rip off other people's IP space and then resell that to spammers also. The fact that there exists a jerk like this on the Internet isn't really all that surprising. What I personally -do- find rather surprising is that three companies that each outght to know better, namely Cogent, GTT, and Level3 are collectively supplying more than 3/4ths of this guy's IPv4 connectivity, at least according to the graph displayed here: https://bgp.he.net/AS197426 Without the generous support of Cogent, GTT, and Level3 this dumbass lowlife IP address space thief would be largely if not entirely toast. So what are they waiting for? Why don't their turf this jackass? Are they waiting for an engraved invitation or what? As I always ask, retorically, in cases like this: Where are the grownups? I would like everyone reading this who is a customer of Cogent, GTT, or Level3 to try to contact these companies and ask them why they are providing connectivity/peering to a hijacking jerk like this Silveira character. Ask them why -you- have to endure more spam in your inbox just so that -they- can make another one tenth of one percent profit by peering with this hijacking, spammer-loving miscreant. I would ask them myself, but I personally am not a direct customer of any of them, so they would all, most probably, just tell me to go pound sand. If you do manage to make contact, please be sure to mention all three of Mr. Silveira's ASNs, i.e. AS42229, AS197426, and AS3266. And don't let whoever you talk to try to weasel out of responsibility for this travesty, e.g. by claiming that they don't know anything about what's been going on with all those hijacks announced by AS3266, and/or that they only provide peering for AS197426. The hijacks may all be originating from Mr. Silveira's AS3266, but bgp.he.net makes clear that AS3266 has one, and only one peer, i.e. Mr. Silveira's AS197426: https://bgp.he.net/AS3266 So basically, Cogent, GTT, and Level3 are the prime enablers of this massive theft of IP space. (They might try to claim that BitCanal's historical propensity to engage in hijacks is sonmething "brand new" or at least that -they- may not have been aware of it until now, in which case you should ask them if they have anybody on staff who is paying attention. As noted above, it isn't as if Bitcanal just started pulling this crap yesterday. Far from it.) Oh! And you might also mention the fact that Spamhaus, and, I would guess, at least a few of the oether public blacklists already have most or all of Mr. Silveira's IP space... hijacked or otherwise... blacklisted, presumably for good and ample cause. As long as Cogent, GTT, and Level3 are willing to go along with this nonsense, i.e. by selling peering to this Silveira thief, crime on the Internet -does- pay, and the theft of other people's IP space will continue to be rewarded rather than punished, as it should be. If that becomes the new normal for Internet behavior, then god help us all. Regards, rfg From job at instituut.net Tue Jun 26 05:01:52 2018 From: job at instituut.net (Job Snijders) Date: Mon, 25 Jun 2018 23:01:52 -0600 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: <65543.1529988555@segfault.tristatelogic.com> References: <65543.1529988555@segfault.tristatelogic.com> Message-ID: On Mon, 25 Jun 2018 at 22:49, Ronald F. Guilmette wrote: > Without the generous support of Cogent, GTT, and Level3 this dumbass > lowlife IP address space thief would be largely if not entirely toast. > So what are they waiting for? Why don't their turf this jackass? Are > they waiting for an engraved invitation or what? > > As I always ask, retorically, in cases like this: Where are the grownups? You could ask the same about the IXPs that facilitate the reach and impact of Bitcanal’s BGP hijacks by allowing that network on their platform: https://bgp.he.net/AS197426#_ix Kind regards, Job From ops.lists at gmail.com Tue Jun 26 05:12:41 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 26 Jun 2018 10:42:41 +0530 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> Message-ID: <5F392CD8-4517-4A71-ABAC-6AB17C6EA300@gmail.com> "we are not the internet police" right? ( On 26/06/18, 10:33 AM, "NANOG on behalf of Job Snijders" wrote: On Mon, 25 Jun 2018 at 22:49, Ronald F. Guilmette wrote: > Without the generous support of Cogent, GTT, and Level3 this dumbass > lowlife IP address space thief would be largely if not entirely toast. > So what are they waiting for? Why don't their turf this jackass? Are > they waiting for an engraved invitation or what? > > As I always ask, retorically, in cases like this: Where are the grownups? You could ask the same about the IXPs that facilitate the reach and impact of Bitcanal’s BGP hijacks by allowing that network on their platform: https://bgp.he.net/AS197426#_ix Kind regards, Job From rfg at tristatelogic.com Tue Jun 26 05:24:47 2018 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 25 Jun 2018 22:24:47 -0700 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: Message-ID: <65682.1529990687@segfault.tristatelogic.com> In message , Job Snijders wrote: >On Mon, 25 Jun 2018 at 22:49, Ronald F. Guilmette >wrote: >> As I always ask, retorically, in cases like this: Where are the grownups? > >You could ask the same about the IXPs that facilitate the reach and impact >of Bitcanal's BGP hijacks by allowing that network on their platform: >https://bgp.he.net/AS197426#_ix I can and I do ask that question. Indeed it would appear that at least one such IX was persuaded, via a Spamhaus escalation last year, to appropriately kick Mr. Silveira's ass to the curb: April, 2017: https://www.isptoday.nl/nieuws/de-cix-door-spamhaus-op-de-bon-geslingerd/ DE-CIX: "We are in direct contact with Spamhouse regarding this, in order to avoid such incidents in the future, and are counting on an open and direct dialog with our Spamhouse colleagues." But first things first. As I have stated, bgp.he.net shows that more than three fourths of Mr. Silveira's connectivity is coming to him via just the three companies I named, Cogent, GTT, and Level3. Without them, both the financial and political burden of supporting this crook would fall onto a motley collection of smaller and more easily influenced players... ones who might be more easily persuaded to cease and desist from their ongoing support of IP address space theft. But the first step is to make it clear to the various law abiding customers of Cogent, GTT, and Level3 that these three companies are acting irresponsibly in their continued peering with Mr. Silveira's various ASNs, and that this -does- negatively affect everyone, or at least everyone who has an email inbox, and/or anyone and everyone who still believes that the formal system of IP address allocation, as administered by the five RiRs, prevents chaos from breaking out across the entire Internet. Regards, rfg From hank at efes.iucc.ac.il Tue Jun 26 07:35:19 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 26 Jun 2018 10:35:19 +0300 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: <65543.1529988555@segfault.tristatelogic.com> References: <65543.1529988555@segfault.tristatelogic.com> Message-ID: <5fe7d0a7-8441-01af-46e4-dba2a2f2d689@efes.iucc.ac.il> On 26/06/2018 07:49, Ronald F. Guilmette wrote: You are mistaken.  Cogent and Level3 are signatories to MANRS: https://www.manrs.org/participants/ so this clearly can't happen and you are making this up. :-) -Hank > > > The fact that there exists a jerk like this on the Internet isn't really > all that surprising. What I personally -do- find rather surprising is that > three companies that each outght to know better, namely Cogent, GTT, and > Level3 are collectively supplying more than 3/4ths of this guy's IPv4 > connectivity, at least according to the graph displayed here: > > https://bgp.he.net/AS197426 > > Without the generous support of Cogent, GTT, and Level3 this dumbass > lowlife IP address space thief would be largely if not entirely toast. > So what are they waiting for? Why don't their turf this jackass? Are > they waiting for an engraved invitation or what? > > As I always ask, retorically, in cases like this: Where are the grownups? > > I would like everyone reading this who is a customer of Cogent, GTT, or > Level3 to try to contact these companies and ask them why they are providing > connectivity/peering to a hijacking jerk like this Silveira character. > Ask them why -you- have to endure more spam in your inbox just so that > -they- can make another one tenth of one percent profit by peering with > this hijacking, spammer-loving miscreant. I would ask them myself, but > I personally am not a direct customer of any of them, so they would all, > most probably, just tell me to go pound sand. > > If you do manage to make contact, please be sure to mention all three of > Mr. Silveira's ASNs, i.e. AS42229, AS197426, and AS3266. And don't let > whoever you talk to try to weasel out of responsibility for this travesty, > e.g. by claiming that they don't know anything about what's been going on > with all those hijacks announced by AS3266, and/or that they only provide > peering for AS197426. The hijacks may all be originating from Mr. Silveira's > AS3266, but bgp.he.net makes clear that AS3266 has one, and only one peer, > i.e. Mr. Silveira's AS197426: > > https://bgp.he.net/AS3266 > > So basically, Cogent, GTT, and Level3 are the prime enablers of this > massive theft of IP space. (They might try to claim that BitCanal's > historical propensity to engage in hijacks is sonmething "brand new" > or at least that -they- may not have been aware of it until now, in which > case you should ask them if they have anybody on staff who is paying > attention. As noted above, it isn't as if Bitcanal just started pulling > this crap yesterday. Far from it.) > > Oh! And you might also mention the fact that Spamhaus, and, I would guess, > at least a few of the oether public blacklists already have most or all of > Mr. Silveira's IP space... hijacked or otherwise... blacklisted, presumably > for good and ample cause. > > As long as Cogent, GTT, and Level3 are willing to go along with this > nonsense, i.e. by selling peering to this Silveira thief, crime on > the Internet -does- pay, and the theft of other people's IP space > will continue to be rewarded rather than punished, as it should be. > > If that becomes the new normal for Internet behavior, then god help us > all. > > > Regards, > rfg > From jerome at ceriz.fr Tue Jun 26 09:21:09 2018 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Tue, 26 Jun 2018 11:21:09 +0200 Subject: Circulator and LR4/ER4 (was Re: Tunable QSFP Optics) In-Reply-To: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> References: <1550970777.555038.1529425633632.JavaMail.zimbra@techcompute.net> Message-ID: <79ee2608-4c84-0901-896d-2b3f09279490@ceriz.fr> Hi Mitchell, Le 19/06/2018 à 18:27, Lewis,Mitchell T. a écrit : > Does anyone know if any Single Mode QSFPs exist on the market that > use wavelengths other than 1310nm (either self tunable or factory > tuned)? I found none. > I am looking to put more than one 40gb link on a fiber pair > similar to using DWDM OADMs for 1g & 10g but can't seem to find any > qsfp optics that don't use 1310nm. I' considering the use of a circulator to do 40/100G over a single strand. Do you think that would work ? Would it solve four problem ? https://www.fs.com/products/33364.html Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From ixp.user.one at gmail.com Tue Jun 26 07:41:00 2018 From: ixp.user.one at gmail.com (IXP User One) Date: Tue, 26 Jun 2018 09:41:00 +0200 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: <5fe7d0a7-8441-01af-46e4-dba2a2f2d689@efes.iucc.ac.il> References: <65543.1529988555@segfault.tristatelogic.com> <5fe7d0a7-8441-01af-46e4-dba2a2f2d689@efes.iucc.ac.il> Message-ID: Hi all, I have heard that DE-CIX expelled BitCanal from their IXPs. One of their guys also gave a presentation about how DE-CIX handles abuse cases: https://ripe75.ripe.net/archives/video/103/ I don't know how other IXPs are handling such cases. Would be interesting to know. Best regards, IUO On Tue, Jun 26, 2018 at 9:35 AM, Hank Nussbacher wrote: > On 26/06/2018 07:49, Ronald F. Guilmette wrote: > > You are mistaken. Cogent and Level3 are signatories to MANRS: > https://www.manrs.org/participants/ > so this clearly can't happen and you are making this up. > > :-) > > -Hank > > > > > > > The fact that there exists a jerk like this on the Internet isn't really > > all that surprising. What I personally -do- find rather surprising is > that > > three companies that each outght to know better, namely Cogent, GTT, and > > Level3 are collectively supplying more than 3/4ths of this guy's IPv4 > > connectivity, at least according to the graph displayed here: > > > > https://bgp.he.net/AS197426 > > > > Without the generous support of Cogent, GTT, and Level3 this dumbass > > lowlife IP address space thief would be largely if not entirely toast. > > So what are they waiting for? Why don't their turf this jackass? Are > > they waiting for an engraved invitation or what? > > > > As I always ask, retorically, in cases like this: Where are the > grownups? > > > > I would like everyone reading this who is a customer of Cogent, GTT, or > > Level3 to try to contact these companies and ask them why they are > providing > > connectivity/peering to a hijacking jerk like this Silveira character. > > Ask them why -you- have to endure more spam in your inbox just so that > > -they- can make another one tenth of one percent profit by peering with > > this hijacking, spammer-loving miscreant. I would ask them myself, but > > I personally am not a direct customer of any of them, so they would all, > > most probably, just tell me to go pound sand. > > > > If you do manage to make contact, please be sure to mention all three of > > Mr. Silveira's ASNs, i.e. AS42229, AS197426, and AS3266. And don't let > > whoever you talk to try to weasel out of responsibility for this > travesty, > > e.g. by claiming that they don't know anything about what's been going on > > with all those hijacks announced by AS3266, and/or that they only provide > > peering for AS197426. The hijacks may all be originating from Mr. > Silveira's > > AS3266, but bgp.he.net makes clear that AS3266 has one, and only one > peer, > > i.e. Mr. Silveira's AS197426: > > > > https://bgp.he.net/AS3266 > > > > So basically, Cogent, GTT, and Level3 are the prime enablers of this > > massive theft of IP space. (They might try to claim that BitCanal's > > historical propensity to engage in hijacks is sonmething "brand new" > > or at least that -they- may not have been aware of it until now, in which > > case you should ask them if they have anybody on staff who is paying > > attention. As noted above, it isn't as if Bitcanal just started pulling > > this crap yesterday. Far from it.) > > > > Oh! And you might also mention the fact that Spamhaus, and, I would > guess, > > at least a few of the oether public blacklists already have most or all > of > > Mr. Silveira's IP space... hijacked or otherwise... blacklisted, > presumably > > for good and ample cause. > > > > As long as Cogent, GTT, and Level3 are willing to go along with this > > nonsense, i.e. by selling peering to this Silveira thief, crime on > > the Internet -does- pay, and the theft of other people's IP space > > will continue to be rewarded rather than punished, as it should be. > > > > If that becomes the new normal for Internet behavior, then god help us > > all. > > > > > > Regards, > > rfg > > > > From thomas.king at de-cix.net Tue Jun 26 14:08:58 2018 From: thomas.king at de-cix.net (Thomas King) Date: Tue, 26 Jun 2018 14:08:58 +0000 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> <5fe7d0a7-8441-01af-46e4-dba2a2f2d689@efes.iucc.ac.il> Message-ID: <7792FB2F-3411-4D45-9089-7E34F85747D2@de-cix.net> I am the guy who gave the presentation. We ask our customers to report misbehavior of peers at DE-CIX IXPs (e.g. IP hijack, ASN hijacks) to abuse at de-cix.net. We will look into reported cases and collect evidence so that we can act accordingly. So far, this process helped us to identify and fix configuration errors from peers on a few occasions. Also, as a last resort we expelled a small number of permanent and notorious rule breakers. Best regards, Thomas On 26.06.18, 15:16, "IXP User One" wrote: Hi all, I have heard that DE-CIX expelled BitCanal from their IXPs. One of their guys also gave a presentation about how DE-CIX handles abuse cases: https://ripe75.ripe.net/archives/video/103/ I don't know how other IXPs are handling such cases. Would be interesting to know. Best regards, IUO On Tue, Jun 26, 2018 at 9:35 AM, Hank Nussbacher wrote: > On 26/06/2018 07:49, Ronald F. Guilmette wrote: > > You are mistaken. Cogent and Level3 are signatories to MANRS: > https://www.manrs.org/participants/ > so this clearly can't happen and you are making this up. > > :-) > > -Hank > > > > > > > The fact that there exists a jerk like this on the Internet isn't really > > all that surprising. What I personally -do- find rather surprising is > that > > three companies that each outght to know better, namely Cogent, GTT, and > > Level3 are collectively supplying more than 3/4ths of this guy's IPv4 > > connectivity, at least according to the graph displayed here: > > > > https://bgp.he.net/AS197426 > > > > Without the generous support of Cogent, GTT, and Level3 this dumbass > > lowlife IP address space thief would be largely if not entirely toast. > > So what are they waiting for? Why don't their turf this jackass? Are > > they waiting for an engraved invitation or what? > > > > As I always ask, retorically, in cases like this: Where are the > grownups? > > > > I would like everyone reading this who is a customer of Cogent, GTT, or > > Level3 to try to contact these companies and ask them why they are > providing > > connectivity/peering to a hijacking jerk like this Silveira character. > > Ask them why -you- have to endure more spam in your inbox just so that > > -they- can make another one tenth of one percent profit by peering with > > this hijacking, spammer-loving miscreant. I would ask them myself, but > > I personally am not a direct customer of any of them, so they would all, > > most probably, just tell me to go pound sand. > > > > If you do manage to make contact, please be sure to mention all three of > > Mr. Silveira's ASNs, i.e. AS42229, AS197426, and AS3266. And don't let > > whoever you talk to try to weasel out of responsibility for this > travesty, > > e.g. by claiming that they don't know anything about what's been going on > > with all those hijacks announced by AS3266, and/or that they only provide > > peering for AS197426. The hijacks may all be originating from Mr. > Silveira's > > AS3266, but bgp.he.net makes clear that AS3266 has one, and only one > peer, > > i.e. Mr. Silveira's AS197426: > > > > https://bgp.he.net/AS3266 > > > > So basically, Cogent, GTT, and Level3 are the prime enablers of this > > massive theft of IP space. (They might try to claim that BitCanal's > > historical propensity to engage in hijacks is sonmething "brand new" > > or at least that -they- may not have been aware of it until now, in which > > case you should ask them if they have anybody on staff who is paying > > attention. As noted above, it isn't as if Bitcanal just started pulling > > this crap yesterday. Far from it.) > > > > Oh! And you might also mention the fact that Spamhaus, and, I would > guess, > > at least a few of the oether public blacklists already have most or all > of > > Mr. Silveira's IP space... hijacked or otherwise... blacklisted, > presumably > > for good and ample cause. > > > > As long as Cogent, GTT, and Level3 are willing to go along with this > > nonsense, i.e. by selling peering to this Silveira thief, crime on > > the Internet -does- pay, and the theft of other people's IP space > > will continue to be rewarded rather than punished, as it should be. > > > > If that becomes the new normal for Internet behavior, then god help us > > all. > > > > > > Regards, > > rfg > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5353 bytes Desc: not available URL: From hank at efes.iucc.ac.il Tue Jun 26 15:14:02 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 26 Jun 2018 18:14:02 +0300 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: <7792FB2F-3411-4D45-9089-7E34F85747D2@de-cix.net> References: <65543.1529988555@segfault.tristatelogic.com> <5fe7d0a7-8441-01af-46e4-dba2a2f2d689@efes.iucc.ac.il> <7792FB2F-3411-4D45-9089-7E34F85747D2@de-cix.net> Message-ID: On 26/06/2018 17:08, Thomas King wrote: Kudos to DE-CIX for getting it right. -Hank > I am the guy who gave the presentation. We ask our customers to report misbehavior of peers at DE-CIX IXPs (e.g. IP hijack, ASN hijacks) to abuse at de-cix.net. We will look into reported cases and collect evidence so that we can act accordingly. So far, this process helped us to identify and fix configuration errors from peers on a few occasions. Also, as a last resort we expelled a small number of permanent and notorious rule breakers. > > Best regards, > Thomas > > > On 26.06.18, 15:16, "IXP User One" wrote: > > Hi all, > > I have heard that DE-CIX expelled BitCanal from their IXPs. One of their > guys also gave a presentation about how DE-CIX handles abuse cases: > https://ripe75.ripe.net/archives/video/103/ > > I don't know how other IXPs are handling such cases. Would be interesting > to know. > > Best regards, > IUO > > > On Tue, Jun 26, 2018 at 9:35 AM, Hank Nussbacher > wrote: > > > On 26/06/2018 07:49, Ronald F. Guilmette wrote: > > > > You are mistaken. Cogent and Level3 are signatories to MANRS: > > https://www.manrs.org/participants/ > > so this clearly can't happen and you are making this up. > > > > :-) > > > > -Hank > > > > > > > > > > > The fact that there exists a jerk like this on the Internet isn't really > > > all that surprising. What I personally -do- find rather surprising is > > that > > > three companies that each outght to know better, namely Cogent, GTT, and > > > Level3 are collectively supplying more than 3/4ths of this guy's IPv4 > > > connectivity, at least according to the graph displayed here: > > > > > > https://bgp.he.net/AS197426 > > > > > > Without the generous support of Cogent, GTT, and Level3 this dumbass > > > lowlife IP address space thief would be largely if not entirely toast. > > > So what are they waiting for? Why don't their turf this jackass? Are > > > they waiting for an engraved invitation or what? > > > > > > As I always ask, retorically, in cases like this: Where are the > > grownups? > > > > > > I would like everyone reading this who is a customer of Cogent, GTT, or > > > Level3 to try to contact these companies and ask them why they are > > providing > > > connectivity/peering to a hijacking jerk like this Silveira character. > > > Ask them why -you- have to endure more spam in your inbox just so that > > > -they- can make another one tenth of one percent profit by peering with > > > this hijacking, spammer-loving miscreant. I would ask them myself, but > > > I personally am not a direct customer of any of them, so they would all, > > > most probably, just tell me to go pound sand. > > > > > > If you do manage to make contact, please be sure to mention all three of > > > Mr. Silveira's ASNs, i.e. AS42229, AS197426, and AS3266. And don't let > > > whoever you talk to try to weasel out of responsibility for this > > travesty, > > > e.g. by claiming that they don't know anything about what's been going on > > > with all those hijacks announced by AS3266, and/or that they only provide > > > peering for AS197426. The hijacks may all be originating from Mr. > > Silveira's > > > AS3266, but bgp.he.net makes clear that AS3266 has one, and only one > > peer, > > > i.e. Mr. Silveira's AS197426: > > > > > > https://bgp.he.net/AS3266 > > > > > > So basically, Cogent, GTT, and Level3 are the prime enablers of this > > > massive theft of IP space. (They might try to claim that BitCanal's > > > historical propensity to engage in hijacks is sonmething "brand new" > > > or at least that -they- may not have been aware of it until now, in which > > > case you should ask them if they have anybody on staff who is paying > > > attention. As noted above, it isn't as if Bitcanal just started pulling > > > this crap yesterday. Far from it.) > > > > > > Oh! And you might also mention the fact that Spamhaus, and, I would > > guess, > > > at least a few of the oether public blacklists already have most or all > > of > > > Mr. Silveira's IP space... hijacked or otherwise... blacklisted, > > presumably > > > for good and ample cause. > > > > > > As long as Cogent, GTT, and Level3 are willing to go along with this > > > nonsense, i.e. by selling peering to this Silveira thief, crime on > > > the Internet -does- pay, and the theft of other people's IP space > > > will continue to be rewarded rather than punished, as it should be. > > > > > > If that becomes the new normal for Internet behavior, then god help us > > > all. > > > > > > > > > Regards, > > > rfg > > > > > > > > From Jacques.Latour at cira.ca Tue Jun 26 15:40:49 2018 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Tue, 26 Jun 2018 15:40:49 +0000 Subject: Call For Presentations - Joint CENTR-Tech / DNS-OARC Workshop, Amsterdam, NL, 13th/14th October 2018 Message-ID: Hi All! The 29th DNS-OARC Workshop will be a joint workshop combined with CENTR-Tech and will take place at the Hotel Okura, Amsterdam, Netherlands, on October 13th and 14th 2018. The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. A timeslot will also be available for lightning talks (5-10 minutes) on day two of the workshop for which submissions will be accepted on the first day of the workshop, until 4pm. The second afternoon of the workshop will start with a Members-only session which will include reports on DNS-OARC's activities. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. The Members-only session will be followed by the AGM. Workshop Milestones: * 15 Jun 2018 - Submissions and Registrations open via Indico * 13 Jul 2018 - Deadline for submission * 17 Aug 2018 - Contribution list published * 14 Sep 2018 - Full agenda published * 06 Oct 2018 - Deadline for slideset submission * 13 Oct 2018 - Workshop Details for presentation submission are published here: https://indico.dns-oarc.net/event/29/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissions at dns-oarc.net Jacques, for the joint Programme Committee From sf at lists.esoteric.ca Tue Jun 26 16:18:19 2018 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Tue, 26 Jun 2018 12:18:19 -0400 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> Message-ID: Job, Unless of course they are not actually on an IXP listed. Bitcanal is not a member of TorIX and as far as I recall, never has been. The IP they list in PeeringDB was never assigned to them at any point and in fact was used by an AS112 instance which was run by TorIX directly on the fabric for a time. I sent in a note to PeeringDB several years ago about Bitcanal claiming to be a peer when they were not and never heard back.. I'll resend. -- Stephen (ops, TorIX) On 2018-06-26 1:01 AM, Job Snijders wrote: > On Mon, 25 Jun 2018 at 22:49, Ronald F. Guilmette > wrote: > >> Without the generous support of Cogent, GTT, and Level3 this dumbass >> lowlife IP address space thief would be largely if not entirely toast. >> So what are they waiting for? Why don't their turf this jackass? Are >> they waiting for an engraved invitation or what? >> >> As I always ask, retorically, in cases like this: Where are the grownups? > > > > You could ask the same about the IXPs that facilitate the reach and impact > of Bitcanal’s BGP hijacks by allowing that network on their platform: > https://bgp.he.net/AS197426#_ix > > Kind regards, > > Job > From nanog at ics-il.net Tue Jun 26 16:23:47 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 26 Jun 2018 11:23:47 -0500 (CDT) Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> Message-ID: <2136730419.2563.1530030224687.JavaMail.mhammett@ThunderFuck> IXP Manager now has IXF exports that PeeringDB can use to cleanup stale members. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Stephen Fulton" To: nanog at nanog.org Sent: Tuesday, June 26, 2018 11:18:19 AM Subject: Re: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 Job, Unless of course they are not actually on an IXP listed. Bitcanal is not a member of TorIX and as far as I recall, never has been. The IP they list in PeeringDB was never assigned to them at any point and in fact was used by an AS112 instance which was run by TorIX directly on the fabric for a time. I sent in a note to PeeringDB several years ago about Bitcanal claiming to be a peer when they were not and never heard back.. I'll resend. -- Stephen (ops, TorIX) On 2018-06-26 1:01 AM, Job Snijders wrote: > On Mon, 25 Jun 2018 at 22:49, Ronald F. Guilmette > wrote: > >> Without the generous support of Cogent, GTT, and Level3 this dumbass >> lowlife IP address space thief would be largely if not entirely toast. >> So what are they waiting for? Why don't their turf this jackass? Are >> they waiting for an engraved invitation or what? >> >> As I always ask, retorically, in cases like this: Where are the grownups? > > > > You could ask the same about the IXPs that facilitate the reach and impact > of Bitcanal’s BGP hijacks by allowing that network on their platform: > https://bgp.he.net/AS197426#_ix > > Kind regards, > > Job > From nanog at ics-il.net Tue Jun 26 16:17:31 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 26 Jun 2018 11:17:31 -0500 (CDT) Subject: Verizon\MCI Real Estate Department In-Reply-To: <30813469.2524.1530029402056.JavaMail.mhammett@ThunderFuck> Message-ID: <1776295001.2550.1530029848329.JavaMail.mhammett@ThunderFuck> Does anyone have a contact at Verizon\MCI's Real Estate department? Their web site is rather consumer-focused and has no mention of anything related to that. Nagging them on Twitter has been a dud as well. They have a fiber route through my family's property (from a Williams pipeline) and I'm trying to verify the easement information on record is what they have as well. Multiple Williams pipes from the same original builder now in different hands makes things a bit more tricky. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From zhuifeng0426 at gmail.com Tue Jun 26 17:15:10 2018 From: zhuifeng0426 at gmail.com (Yifeng Zhou) Date: Tue, 26 Jun 2018 10:15:10 -0700 Subject: TCP TIMELY implementation guide In-Reply-To: References: Message-ID: 2nd try... 2018-06-24 16:51 GMT-07:00 Yifeng Zhou : > Hi There, > > May I know if there's any TCP TIMELY implementation guide? Want to play > with it.. > > Thanks! > From job at instituut.net Tue Jun 26 17:22:18 2018 From: job at instituut.net (Job Snijders) Date: Tue, 26 Jun 2018 17:22:18 +0000 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> Message-ID: <20180626172218.GK5413@vurt.meerval.net> (I've updated the email subject to make it more accurate) On Tue, Jun 26, 2018 at 12:18:19PM -0400, Stephen Fulton wrote: > Unless of course they are not actually on an IXP listed. Of course. > Bitcanal is not a member of TorIX and as far as I recall, never has > been. The IP they list in PeeringDB was never assigned to them at any > point and in fact was used by an AS112 instance which was run by TorIX > directly on the fabric for a time. I sent in a note to PeeringDB > several years ago about Bitcanal claiming to be a peer when they were > not and never heard back.. I'll resend. Thank you for this clarification. Indeed a note to the PeeringDB Admin committee should help clean this up. Please note that this organisation also goes under the name of "Ebony Horizon". I've manually confirmed bitcanal/AS 197426 is connected to AMS-IX, ECIX Frankfurt, ESPANIX, FranceIX Paris, GigaPIX, and LINX LON1. At most of these IXPs, bitcanal seems to be connected the the IXP's route servers. In my mind, if we want to consider responsibility, these IXPs are as much at fault as any upstream provider. Connectivity is connectivity. Kind regards, Job From bruns at 2mbit.com Tue Jun 26 17:44:24 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 26 Jun 2018 11:44:24 -0600 Subject: TCP TIMELY implementation guide In-Reply-To: References: Message-ID: On 6/26/2018 11:15 AM, Yifeng Zhou wrote: > 2nd try... > > 2018-06-24 16:51 GMT-07:00 Yifeng Zhou : > >> Hi There, >> >> May I know if there's any TCP TIMELY implementation guide? Want to play >> with it.. >> >> Thanks! >> We got your message first time around. Likely, if you didn't get any responses, its because noone had anything to say about it. Have you googled around and/or looked at any kind of RFCs or examples? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From job at instituut.net Tue Jun 26 18:23:55 2018 From: job at instituut.net (Job Snijders) Date: Tue, 26 Jun 2018 18:23:55 +0000 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> Message-ID: <20180626182355.GO5413@vurt.meerval.net> Dear Simon, On Tue, Jun 26, 2018 at 12:13:26PM -0600, Simon Muyal wrote: > On the France-IX route servers, we are applying filters based on IRR > DBs. I double checked the list https://pastebin.com/raw/Jw1my9Bb and > these prefixes should be filtered if bitcanal starts announcing them. > Currently, bitcanal/AS197426 is not announcing any prefix on our route > servers: > > https://lg.franceix.net/irr_found_for/RS1+RS2/ipv4?q=197426 > https://lg.franceix.net/irr_notfound_for/RS1+RS2/ipv4?q=197426 I'm very happy FranceIX apply filters - however Bitcanal is known to submit fabricated/falsified IRR information to databases like RADB and RIPE. I've reported this multiple times over the years to IRR database operators. In conclusion in the case of Bitcanal, most of your filtering is useless (and so is mine). Participants like Bitcanal dillute the value of your route servers and the IXP as a whole. Kind regards, Job From nanog at ics-il.net Tue Jun 26 18:27:49 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 26 Jun 2018 13:27:49 -0500 (CDT) Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <20180626182355.GO5413@vurt.meerval.net> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> <20180626182355.GO5413@vurt.meerval.net> Message-ID: <1494516972.2816.1530037668680.JavaMail.mhammett@ThunderFuck> Any solution to that? Yell at the IRRs more? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Job Snijders" To: "Simon Muyal" Cc: nanog at nanog.org Sent: Tuesday, June 26, 2018 1:23:55 PM Subject: Re: AS3266: BitCanal hijack factory, courtesy of many connectivity providers Dear Simon, On Tue, Jun 26, 2018 at 12:13:26PM -0600, Simon Muyal wrote: > On the France-IX route servers, we are applying filters based on IRR > DBs. I double checked the list https://pastebin.com/raw/Jw1my9Bb and > these prefixes should be filtered if bitcanal starts announcing them. > Currently, bitcanal/AS197426 is not announcing any prefix on our route > servers: > > https://lg.franceix.net/irr_found_for/RS1+RS2/ipv4?q=197426 > https://lg.franceix.net/irr_notfound_for/RS1+RS2/ipv4?q=197426 I'm very happy FranceIX apply filters - however Bitcanal is known to submit fabricated/falsified IRR information to databases like RADB and RIPE. I've reported this multiple times over the years to IRR database operators. In conclusion in the case of Bitcanal, most of your filtering is useless (and so is mine). Participants like Bitcanal dillute the value of your route servers and the IXP as a whole. Kind regards, Job From job at instituut.net Tue Jun 26 18:30:05 2018 From: job at instituut.net (Job Snijders) Date: Tue, 26 Jun 2018 12:30:05 -0600 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <1494516972.2816.1530037668680.JavaMail.mhammett@ThunderFuck> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> <20180626182355.GO5413@vurt.meerval.net> <1494516972.2816.1530037668680.JavaMail.mhammett@ThunderFuck> Message-ID: On Tue, 26 Jun 2018 at 12:28, Mike Hammett wrote: > Any solution to that? Yell at the IRRs more? Or more generally, everyone involved should consider to stop selling services to well-known BGP hijackers. Kind regards, Job From nanog at ics-il.net Tue Jun 26 18:31:45 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 26 Jun 2018 13:31:45 -0500 (CDT) Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> <20180626182355.GO5413@vurt.meerval.net> <1494516972.2816.1530037668680.JavaMail.mhammett@ThunderFuck> Message-ID: <247157176.2825.1530037904234.JavaMail.mhammett@ThunderFuck> Authoritative list of shame with supporting evidence? (Yes, I assume there isn't one and that one would have to be created.) Many network operators aren't going to know who's supposed to be on that list and who isn't. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Job Snijders" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Tuesday, June 26, 2018 1:30:05 PM Subject: Re: AS3266: BitCanal hijack factory, courtesy of many connectivity providers On Tue, 26 Jun 2018 at 12:28, Mike Hammett < nanog at ics-il.net > wrote: Any solution to that? Yell at the IRRs more? Or more generally, everyone involved should consider to stop selling services to well-known BGP hijackers. Kind regards, Job From maxtul at netassist.ua Tue Jun 26 18:50:33 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 26 Jun 2018 21:50:33 +0300 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <1494516972.2816.1530037668680.JavaMail.mhammett@ThunderFuck> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> <20180626182355.GO5413@vurt.meerval.net> <1494516972.2816.1530037668680.JavaMail.mhammett@ThunderFuck> Message-ID: RPKI? BGPsec? 26.06.18 21:27, Mike Hammett пише: > Any solution to that? Yell at the IRRs more? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Job Snijders" > To: "Simon Muyal" > Cc: nanog at nanog.org > Sent: Tuesday, June 26, 2018 1:23:55 PM > Subject: Re: AS3266: BitCanal hijack factory, courtesy of many connectivity providers > > Dear Simon, > > On Tue, Jun 26, 2018 at 12:13:26PM -0600, Simon Muyal wrote: >> On the France-IX route servers, we are applying filters based on IRR >> DBs. I double checked the list https://pastebin.com/raw/Jw1my9Bb and >> these prefixes should be filtered if bitcanal starts announcing them. >> Currently, bitcanal/AS197426 is not announcing any prefix on our route >> servers: >> >> https://lg.franceix.net/irr_found_for/RS1+RS2/ipv4?q=197426 >> https://lg.franceix.net/irr_notfound_for/RS1+RS2/ipv4?q=197426 > > I'm very happy FranceIX apply filters - however Bitcanal is known to > submit fabricated/falsified IRR information to databases like RADB and > RIPE. I've reported this multiple times over the years to IRR database > operators. > > In conclusion in the case of Bitcanal, most of your filtering is useless > (and so is mine). Participants like Bitcanal dillute the value of your > route servers and the IXP as a whole. > > Kind regards, > > Job > > From nanog at radu-adrian.feurdean.net Tue Jun 26 19:57:14 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Tue, 26 Jun 2018 21:57:14 +0200 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <20180626182355.GO5413@vurt.meerval.net> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> <20180626182355.GO5413@vurt.meerval.net> Message-ID: <1530043034.3453896.1421327768.7C5D35A7@webmail.messagingengine.com> On Tue, Jun 26, 2018, at 20:23, Job Snijders wrote: > I'm very happy FranceIX apply filters - however Bitcanal is known to > submit fabricated/falsified IRR information to databases like RADB and > RIPE. I've reported this multiple times over the years to IRR database > operators. > > In conclusion in the case of Bitcanal, most of your filtering is useless > (and so is mine). Participants like Bitcanal dillute the value of your > route servers and the IXP as a whole. I can confirm that this mornig (~09h30 CEST, when I read the first message in the thread) there were no BitCanal announces received from FranceIX Paris RS. Not even the ones with an IRR record (the ones in 213/8). All of them were from transit. From job at instituut.net Tue Jun 26 21:52:57 2018 From: job at instituut.net (Job Snijders) Date: Tue, 26 Jun 2018 21:52:57 +0000 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <1530043034.3453896.1421327768.7C5D35A7@webmail.messagingengine.com> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> <20180626182355.GO5413@vurt.meerval.net> <1530043034.3453896.1421327768.7C5D35A7@webmail.messagingengine.com> Message-ID: <20180626215257.GQ5413@vurt.meerval.net> On Tue, Jun 26, 2018 at 09:57:14PM +0200, Radu-Adrian Feurdean wrote: > On Tue, Jun 26, 2018, at 20:23, Job Snijders wrote: > > I'm very happy FranceIX apply filters - however Bitcanal is known to > > submit fabricated/falsified IRR information to databases like RADB > > and RIPE. I've reported this multiple times over the years to IRR > > database operators. > > > > In conclusion in the case of Bitcanal, most of your filtering is > > useless (and so is mine). Participants like Bitcanal dillute the > > value of your route servers and the IXP as a whole. > > I can confirm that this mornig (~09h30 CEST, when I read the first > message in the thread) there were no BitCanal announces received from > FranceIX Paris RS. What about now? Still squeaky clean? What about now? What about tomorrow? You only need to announce hijacked routes for the duration of the spamming campaign (usually just a few hours). The presence of this type of actor poses a risk to all connnected to the IX fabric. Kind regards, Job From mehmet at akcin.net Tue Jun 26 23:56:00 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 26 Jun 2018 17:56:00 -0600 Subject: Submarine Cable Status Map Experiment Message-ID: Hello NANOGers, Today i presented a lighting talk to ask for feedback on the submarine cable status project. I am still trying to work details on how the governance and sustainability of this project should be structured. I know there are more people in the list than those who attend in person to NANOG in Denver hence I want to share my slides here https://pc.nanog.org/static/published/meetings/NANOG73/1749/20180626_Akcin_Lightning_Talk_Submarine_v1.pdf There seems to be tremendous amount of interest and support on this experiment. We are working on getting data (Kmz/Kml) from the operators of submarine cable systems so we can build our map and display cable status current demo page is available at https://map.kapany.net If you have ideas you want to share and help this map experiment become a reality, please don't hesitate to contact me directly or join our mailing list. at https://groups.google.com/a/kapany.net/forum/#!forum/subsea I would like to thank Aaron Hughes, Ognian Mitev, NANOG PC, Telegeography , Angola Cables, Alaska Communications and Seaborn Networks for their amazing support so far. ps: please feel free to pass this message to other groups / nogs to get the message to those who are interested. Thank you! Mehmet From surfer at mauigateway.com Tue Jun 26 20:31:46 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 26 Jun 2018 13:31:46 -0700 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 Message-ID: <20180626133146.3D77686C@m0117566.ppops.net> On Mon, 25 Jun 2018 at 22:49, Ronald F. Guilmette wrote: > Without the generous support of Cogent, GTT, and Level3 this dumbass > lowlife IP address space thief would be largely if not entirely toast. > So what are they waiting for? Why don't their turf this jackass? Are > they waiting for an engraved invitation or what? > > As I always ask, retorically, in cases like this: Where are the grownups? --- ops.lists at gmail.com wrote: From: Suresh Ramasubramanian "we are not the internet police" right? ( ----------------------------- So your answer is to let them hijack whatever/whenever they want? scott From ops.lists at gmail.com Wed Jun 27 02:18:58 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 27 Jun 2018 07:48:58 +0530 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: <20180626133146.3D77686C@m0117566.ppops.net> References: <20180626133146.3D77686C@m0117566.ppops.net> Message-ID: <021FD488-E611-4A50-8E2A-2377631370DF@gmail.com> Oh dear. The problem with sarcasm is that it falls flat if people don't realize you're being sarcastic. On 27/06/18, 6:53 AM, "NANOG on behalf of Scott Weeks" wrote: On Mon, 25 Jun 2018 at 22:49, Ronald F. Guilmette wrote: > Without the generous support of Cogent, GTT, and Level3 this dumbass > lowlife IP address space thief would be largely if not entirely toast. > So what are they waiting for? Why don't their turf this jackass? Are > they waiting for an engraved invitation or what? > > As I always ask, retorically, in cases like this: Where are the grownups? --- ops.lists at gmail.com wrote: From: Suresh Ramasubramanian "we are not the internet police" right? ( ----------------------------- So your answer is to let them hijack whatever/whenever they want? scott From mark.tinka at seacom.mu Wed Jun 27 07:24:10 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 27 Jun 2018 09:24:10 +0200 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <247157176.2825.1530037904234.JavaMail.mhammett@ThunderFuck> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> <20180626182355.GO5413@vurt.meerval.net> <1494516972.2816.1530037668680.JavaMail.mhammett@ThunderFuck> <247157176.2825.1530037904234.JavaMail.mhammett@ThunderFuck> Message-ID: <185aa08b-46c8-fa75-edd9-1ebc46538be4@seacom.mu> On 26/Jun/18 20:31, Mike Hammett wrote: > Authoritative list of shame with supporting evidence? (Yes, I assume there isn't one and that one would have to be created.) > > Many network operators aren't going to know who's supposed to be on that list and who isn't. I tend to agree - I probably wouldn't know this well-known list, unless it's shared somewhere. Perhaps something that MANRS members have access to, although it would be good that it is accessible to the entire power-networking community. I imagine a Sales person doing a deal with a well-known spammer, and the provisioning team (who have no time/energy to follow what's happening in the world) delivering the service. Might be difficult to get this turned off after the Sales team have shown a TCV for the quarter/year heavily bumped by said sale. A list of shame that we can share with the Sales and Delivery teams could help stem the problem at its root. Mark. From mark.tinka at seacom.mu Wed Jun 27 07:25:46 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 27 Jun 2018 09:25:46 +0200 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: <021FD488-E611-4A50-8E2A-2377631370DF@gmail.com> References: <20180626133146.3D77686C@m0117566.ppops.net> <021FD488-E611-4A50-8E2A-2377631370DF@gmail.com> Message-ID: <0c79163f-13e3-fd97-ecfe-52937ac97117@seacom.mu> On 27/Jun/18 04:18, Suresh Ramasubramanian wrote: > Oh dear. The problem with sarcasm is that it falls flat if people don't realize you're being sarcastic. Text-based messaging is terribly reliable at helping miss the point... It's a good things our kids of today call each other on the phone to avoid that :-)... Mark. From ak at list.ak.cx Wed Jun 27 10:58:12 2018 From: ak at list.ak.cx (=?UTF-8?Q?Andr=c3=a9_Keller?=) Date: Wed, 27 Jun 2018 12:58:12 +0200 Subject: AS2386 / INS-AS - AT&T Data Communications Services contact off list Message-ID: Hi, could somebody of AS2386 contact me off-list? It seems that you accept prefixes 12.139.62.0/24 / 12.139.63.0/24 with a wrong origin AS. Regards André From has at google.com Tue Jun 26 18:57:54 2018 From: has at google.com (Heather Schiller) Date: Tue, 26 Jun 2018 14:57:54 -0400 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <247157176.2825.1530037904234.JavaMail.mhammett@ThunderFuck> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> <20180626182355.GO5413@vurt.meerval.net> <1494516972.2816.1530037668680.JavaMail.mhammett@ThunderFuck> <247157176.2825.1530037904234.JavaMail.mhammett@ThunderFuck> Message-ID: https://datatracker.ietf.org/wg/sidr/about/ Being presented at nanog nowish: Architecting Robust BGP Routing Policies Lightning Talk: BGP Transport Security - Do You Care? Lightning Talk: Legal Barriers to Securing the Routing Architecture On Tue, Jun 26, 2018 at 2:31 PM, Mike Hammett wrote: > Authoritative list of shame with supporting evidence? (Yes, I assume there > isn't one and that one would have to be created.) > > Many network operators aren't going to know who's supposed to be on that > list and who isn't. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Job Snijders" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Tuesday, June 26, 2018 1:30:05 PM > Subject: Re: AS3266: BitCanal hijack factory, courtesy of many > connectivity providers > > > On Tue, 26 Jun 2018 at 12:28, Mike Hammett < nanog at ics-il.net > wrote: > > > > > Any solution to that? Yell at the IRRs more? > > > > > Or more generally, everyone involved should consider to stop selling > services to well-known BGP hijackers. > > > Kind regards, > > > Job > From smuyal at franceix.net Tue Jun 26 18:13:26 2018 From: smuyal at franceix.net (Simon Muyal) Date: Tue, 26 Jun 2018 12:13:26 -0600 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <20180626172218.GK5413@vurt.meerval.net> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> Message-ID: Hi Job, all, On the France-IX route servers, we are applying filters based on IRR DBs. I double checked the list https://pastebin.com/raw/Jw1my9Bb and these prefixes should be filtered if bitcanal starts announcing them. Currently, bitcanal/AS197426 is not announcing any prefix on our route servers: https://lg.franceix.net/irr_found_for/RS1+RS2/ipv4?q=197426 https://lg.franceix.net/irr_notfound_for/RS1+RS2/ipv4?q=197426 regards, Simon -- Simon Muyal CTO FranceIX Tél: +33 (0)1 70 61 97 74 Mob: +33 (0)6 21 17 29 51 Le 26/06/2018 à 11:22, Job Snijders a écrit : > (I've updated the email subject to make it more accurate) > > On Tue, Jun 26, 2018 at 12:18:19PM -0400, Stephen Fulton wrote: >> Unless of course they are not actually on an IXP listed. > Of course. > >> Bitcanal is not a member of TorIX and as far as I recall, never has >> been. The IP they list in PeeringDB was never assigned to them at any >> point and in fact was used by an AS112 instance which was run by TorIX >> directly on the fabric for a time. I sent in a note to PeeringDB >> several years ago about Bitcanal claiming to be a peer when they were >> not and never heard back.. I'll resend. > Thank you for this clarification. Indeed a note to the PeeringDB Admin > committee should help clean this up. Please note that this organisation > also goes under the name of "Ebony Horizon". > > I've manually confirmed bitcanal/AS 197426 is connected to AMS-IX, ECIX > Frankfurt, ESPANIX, FranceIX Paris, GigaPIX, and LINX LON1. > > At most of these IXPs, bitcanal seems to be connected the the IXP's > route servers. In my mind, if we want to consider responsibility, these > IXPs are as much at fault as any upstream provider. Connectivity is > connectivity. > > Kind regards, > > Job From ak at list.ak.cx Wed Jun 27 14:40:59 2018 From: ak at list.ak.cx (=?UTF-8?Q?Andr=c3=a9_Keller?=) Date: Wed, 27 Jun 2018 16:40:59 +0200 Subject: AS2386 / INS-AS - AT&T Data Communications Services contact off list In-Reply-To: References: Message-ID: <51089a25-66ac-1afe-61b1-55e27c5a4167@list.ak.cx> Hi, On 27.06.2018 12:58, André Keller wrote: > could somebody of AS2386 contact me off-list? got a reply, thank you very much. Regards André From cvuljanic at gmail.com Wed Jun 27 15:58:22 2018 From: cvuljanic at gmail.com (Craig) Date: Wed, 27 Jun 2018 11:58:22 -0400 Subject: Microsoft Express Routes woes... Message-ID: This is classic....... We have a direct BGP peering session to Microsoft using Express Routes for the public peering session for services like Email, one drive, etc. this uses MS Public. We also have/use MS Azure Public as well as MS Azure Private in place for a few years now. We have had this happen a few times already where one team at MS makes a routing change, and the other team is either not aware of the change, or else doesn't communicate the change properly. So late last night, while a change was being made to a completely different area of our network, they asked that I back out my change due to our entire organization not being able to access share-point online, or MS One drive. I had zero evidence it was our change. further investigation on our border routers, revealed all four (4) of our ISP's were advertising the MS block as a /24 prefix: A:MY_NAME_CHANGED# show router 1053 bgp routes 13.107.136.0/24 ======================================================================== BGP Router ID:10.11.0.29 AS:122 Local AS:122 ======================================================================== Legend - Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid l - leaked, x - stale, > - best, b - backup, p - purge Origin codes : i - IGP, e - EGP, ? - incomplete ======================================================================== BGP IPv4 Routes ======================================================================== Flag Network LocalPref MED Nexthop (Router) Path-Id Label As-Path ------------------------------------------------------------------------------- u*>? 13.107.136.0/24 250 10450 4.49.118.153 None - 3356 8075 8068 ------------------------------------------------------------------------------- Routes : 1 HOWEVER MS Express Routes was advertising this: A:MY_NAME_CHANGED# show router 1053 bgp routes 13.107.136.0/22 ======================================================================== BGP Router ID:10.11.0.29 AS:122 Local AS:122 ======================================================================== Legend - Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid l - leaked, x - stale, > - best, b - backup, p - purge Origin codes : i - IGP, e - EGP, ? - incomplete ======================================================================== BGP IPv4 Routes ======================================================================== Flag Network LocalPref MED Nexthop (Router) Path-Id Label As-Path ------------------------------------------------------------------------------- i 13.107.136.0/22 300 0 157.229.11.66 None - 12076 So another call to MS support and escalations to get this more specific prefix fixed or if Express routes can advertise this more specific vs the /22 block. *Questions:* Has anyone else ran into this with MS if you have a direct peering session to them? Has anyone did an audit on the route table's received from MS over express routes, vs what they receive from their ISP's and noticed the differences? MS needs to seriously think about: Careful coordination of routing changes Policies to prevent specific routes being advertised while larger blocks are advertised over express routes. Anyway I am tired, as I have not had much sleep, any comments on this, would like to hear from you. -Craig From ingrid at aerkman.com Wed Jun 27 17:57:44 2018 From: ingrid at aerkman.com (Ingrid Erkman) Date: Wed, 27 Jun 2018 10:57:44 -0700 Subject: Microsoft Express Routes woes... In-Reply-To: References: Message-ID: Hi Craig, Microsoft apologizes for your routing issue. Our Wide Area Networking and Express Route teams were already aware of this issue from your ticket. I have communicated with their leadership, and they are working on a fix for you. Please feel free to contact me at ingrid.erkman at microsoft.com if you would like to follow up off list. Thanks, Ingrid Erkman Director of Interconnection Microsoft On Wed, Jun 27, 2018 at 8:58 AM, Craig wrote: > This is classic....... > > We have a direct BGP peering session to Microsoft using Express Routes for > the public peering session for services like Email, one drive, etc. this > uses MS Public. We also have/use MS Azure Public as well as MS Azure > Private in place for a few years now. We have had this happen a few times > already where one team at MS makes a routing change, and the other team is > either not aware of the change, or else doesn't communicate the change > properly. > > So late last night, while a change was being made to a completely different > area of our network, they asked that I back out my change due to our entire > organization not being able to access share-point online, or MS One drive. > > I had zero evidence it was our change. further investigation on our border > routers, revealed all four (4) of our ISP's were advertising the MS block > as a /24 prefix: > > A:MY_NAME_CHANGED# show router 1053 bgp routes 13.107.136.0/24 > ======================================================================== > BGP Router ID:10.11.0.29 AS:122 Local AS:122 > ======================================================================== > Legend - > Status codes : u - used, s - suppressed, h - history, d - decayed, * - > valid > l - leaked, x - stale, > - best, b - backup, p - purge > Origin codes : i - IGP, e - EGP, ? - incomplete > > ======================================================================== > BGP IPv4 Routes > ======================================================================== > Flag Network LocalPref MED > Nexthop (Router) Path-Id Label > As-Path > ------------------------------------------------------------ > ------------------- > u*>? 13.107.136.0/24 250 > 10450 > 4.49.118.153 None - > 3356 8075 8068 > ------------------------------------------------------------ > ------------------- > Routes : 1 > > HOWEVER MS Express Routes was advertising this: > > A:MY_NAME_CHANGED# show router 1053 bgp routes 13.107.136.0/22 > ======================================================================== > BGP Router ID:10.11.0.29 AS:122 Local AS:122 > ======================================================================== > Legend - > Status codes : u - used, s - suppressed, h - history, d - decayed, * - > valid > l - leaked, x - stale, > - best, b - backup, p - purge > Origin codes : i - IGP, e - EGP, ? - incomplete > > ======================================================================== > BGP IPv4 Routes > ======================================================================== > Flag Network LocalPref MED > Nexthop (Router) Path-Id Label > As-Path > ------------------------------------------------------------ > ------------------- > i 13.107.136.0/22 300 0 > 157.229.11.66 None - > 12076 > > So another call to MS support and escalations to get this more specific > prefix fixed or if Express routes can advertise this more specific vs the > /22 block. > > *Questions:* > Has anyone else ran into this with MS if you have a direct peering session > to them? > Has anyone did an audit on the route table's received from MS over express > routes, vs what they receive from their ISP's and noticed the differences? > > MS needs to seriously think about: > Careful coordination of routing changes > Policies to prevent specific routes being advertised while larger blocks > are advertised over express routes. > > Anyway I am tired, as I have not had much sleep, any comments on this, > would like to hear from you. > > > > -Craig > From adam at davenpro.com Wed Jun 27 19:12:07 2018 From: adam at davenpro.com (Adam Davenport) Date: Wed, 27 Jun 2018 12:12:07 -0700 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <65543.1529988555@segfault.tristatelogic.com> References: <65543.1529988555@segfault.tristatelogic.com> Message-ID: GTT takes all AUP violations extremely seriously.  Any offending parties mentioned in this thread have been dealt with accordingly, and GTT now considers the matter resolved from its side. On 6/25/2018 9:49 PM, Ronald F. Guilmette wrote: > Sometimes I see stuff that just makes me shake my head in disbelief. > Here is a good example: > > https://bgp.he.net/AS3266#_prefixes > > I mean seriously, WTF? > > As should be blatantly self-evident to pretty much everyone who has ever > looked at any of the Internet's innumeriable prior incidents of very > deliberately engineered IP space hijackings, all of the routes currently > being announced by AS3266 (Bitcanal, Portugal) except for the ones in > 213/8 are bloody obvious hijacks. (And to their credit, even Spamhaus > has a couple of the U.S. legacy /16 blocks explicitly listed as such.) > > That's 39 deliberately hijacked routes, at least going by the data > visible on bgp.he.net. But even that data from bgp.he.net dramatically > understates the case, I'm sorry to say. According to the more complete > and up-to-the-minute data that I just now fetched from RIPEstat, the real > number of hijacked routes is more on the order of 130 separate hijacked > routes for a total of 224,512 IPv4 addresses: > > https://pastebin.com/raw/Jw1my9Bb > > In simpler terms, Bitcanal has made off with the rough equivalent of an > entire /14 block of IPv4 addresses that never belonged to them. (And of > course, they haven't paid a dime to anyone for any of that space.) > > Of couse we could all be shocked (Shocked!) at this turn of events if > it were not for the fact that Bitcanal already has a rich, longstanding, > and sordid history of involvement with IP space hijacks. All one has to > do is google for "Bitcanal" and "hijack" to find that out. This isn't > exactly a state secret. In fact if you lookup "IP space hijacking" in > any modern Internet dictionary you'll find Mr. Joao Silveira's picture > next to the definition: https://twitter.com/bitcanal :-) > > This guy Silveira has obviously decided that he is a law unto himself, > and can grab whatever IP space happens to be lying around for his own > purposes... and no need to fill out any tedious forms -or- pay any fees > for using any of this space to any of those annoying Regional Internet > Registries. > > As usual, and as I have said here previously, I generally don't mind too > much when these kinds of greedy idiots decide to color outside the lines. > As long as they just confine themselves to hijacking abandoned IP blocks > belonging to banks and/or government agencies, well then it's no skin off > my nose. But when they start reselling their stolen IP space to spammers, > as Mr. Silveira is apparently in the habit of doing, then I get ticked off. > And actually, Mr. Silveira must be *exceptionally* greedy in that he is > apparently not satisfied to just sub-lease his own legitimate IP space to > snowshoe spammers, as he is clearly doing: > > https://pastebin.com/raw/5P5rnQ2y > > Obviously, merely hosting snowshoe spammers in his own IP space isn't enough > to keep Mr. Silveira in the style to which he has become accustomned, so he > has to go out and rip off other people's IP space and then resell that to > spammers also. > > The fact that there exists a jerk like this on the Internet isn't really > all that surprising. What I personally -do- find rather surprising is that > three companies that each outght to know better, namely Cogent, GTT, and > Level3 are collectively supplying more than 3/4ths of this guy's IPv4 > connectivity, at least according to the graph displayed here: > > https://bgp.he.net/AS197426 > > Without the generous support of Cogent, GTT, and Level3 this dumbass > lowlife IP address space thief would be largely if not entirely toast. > So what are they waiting for? Why don't their turf this jackass? Are > they waiting for an engraved invitation or what? > > As I always ask, retorically, in cases like this: Where are the grownups? > > I would like everyone reading this who is a customer of Cogent, GTT, or > Level3 to try to contact these companies and ask them why they are providing > connectivity/peering to a hijacking jerk like this Silveira character. > Ask them why -you- have to endure more spam in your inbox just so that > -they- can make another one tenth of one percent profit by peering with > this hijacking, spammer-loving miscreant. I would ask them myself, but > I personally am not a direct customer of any of them, so they would all, > most probably, just tell me to go pound sand. > > If you do manage to make contact, please be sure to mention all three of > Mr. Silveira's ASNs, i.e. AS42229, AS197426, and AS3266. And don't let > whoever you talk to try to weasel out of responsibility for this travesty, > e.g. by claiming that they don't know anything about what's been going on > with all those hijacks announced by AS3266, and/or that they only provide > peering for AS197426. The hijacks may all be originating from Mr. Silveira's > AS3266, but bgp.he.net makes clear that AS3266 has one, and only one peer, > i.e. Mr. Silveira's AS197426: > > https://bgp.he.net/AS3266 > > So basically, Cogent, GTT, and Level3 are the prime enablers of this > massive theft of IP space. (They might try to claim that BitCanal's > historical propensity to engage in hijacks is sonmething "brand new" > or at least that -they- may not have been aware of it until now, in which > case you should ask them if they have anybody on staff who is paying > attention. As noted above, it isn't as if Bitcanal just started pulling > this crap yesterday. Far from it.) > > Oh! And you might also mention the fact that Spamhaus, and, I would guess, > at least a few of the oether public blacklists already have most or all of > Mr. Silveira's IP space... hijacked or otherwise... blacklisted, presumably > for good and ample cause. > > As long as Cogent, GTT, and Level3 are willing to go along with this > nonsense, i.e. by selling peering to this Silveira thief, crime on > the Internet -does- pay, and the theft of other people's IP space > will continue to be rewarded rather than punished, as it should be. > > If that becomes the new normal for Internet behavior, then god help us > all. > > > Regards, > rfg > From ahebert at pubnix.net Wed Jun 27 20:49:39 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 27 Jun 2018 16:49:39 -0400 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: <0c79163f-13e3-fd97-ecfe-52937ac97117@seacom.mu> References: <20180626133146.3D77686C@m0117566.ppops.net> <021FD488-E611-4A50-8E2A-2377631370DF@gmail.com> <0c79163f-13e3-fd97-ecfe-52937ac97117@seacom.mu> Message-ID: <4b884716-65d6-8df4-f040-ae1cfd5fde9d@pubnix.net>     I ain't friday, but: There is no RFC for the Sarcastica font yet?     PS:  Our little adventure in BGP who-done-it (a few weeks back) burned about 25-30h man hours estimated.  Should have been sub 5 hours if 1 guy would have cooperated instead of ignoring the issue. ----- 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/27/18 03:25, Mark Tinka wrote: > > On 27/Jun/18 04:18, Suresh Ramasubramanian wrote: > >> Oh dear. The problem with sarcasm is that it falls flat if people don't realize you're being sarcastic. > Text-based messaging is terribly reliable at helping miss the point... > > It's a good things our kids of today call each other on the phone to > avoid that :-)... > > Mark. > From Ryan.Hamel at quadranet.com Wed Jun 27 20:53:45 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Wed, 27 Jun 2018 20:53:45 +0000 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: <4b884716-65d6-8df4-f040-ae1cfd5fde9d@pubnix.net> References: <20180626133146.3D77686C@m0117566.ppops.net> <021FD488-E611-4A50-8E2A-2377631370DF@gmail.com> <0c79163f-13e3-fd97-ecfe-52937ac97117@seacom.mu> <4b884716-65d6-8df4-f040-ae1cfd5fde9d@pubnix.net> Message-ID: Why would we need an RFC for Comic Sans? -----Original Message----- From: NANOG On Behalf Of Alain Hebert Sent: Wednesday, June 27, 2018 1:50 PM To: nanog at nanog.org Subject: Re: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3     I ain't friday, but: There is no RFC for the Sarcastica font yet?     PS:  Our little adventure in BGP who-done-it (a few weeks back) burned about 25-30h man hours estimated.  Should have been sub 5 hours if 1 guy would have cooperated instead of ignoring the issue. ----- 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/27/18 03:25, Mark Tinka wrote: > > On 27/Jun/18 04:18, Suresh Ramasubramanian wrote: > >> Oh dear. The problem with sarcasm is that it falls flat if people don't realize you're being sarcastic. > Text-based messaging is terribly reliable at helping miss the point... > > It's a good things our kids of today call each other on the phone to > avoid that :-)... > > Mark. > From kmedcalf at dessus.com Wed Jun 27 21:29:29 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 27 Jun 2018 15:29:29 -0600 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: Message-ID: My VT52 does not do fonts ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ryan Hamel >Sent: Wednesday, 27 June, 2018 14:54 >To: ahebert at pubnix.net; nanog at nanog.org >Subject: RE: AS3266: BitCanal hijack factory, courtesy of Cogent, >GTT, and Level3 > >Why would we need an RFC for Comic Sans? > >-----Original Message----- >From: NANOG On Behalf Of Alain Hebert >Sent: Wednesday, June 27, 2018 1:50 PM >To: nanog at nanog.org >Subject: Re: AS3266: BitCanal hijack factory, courtesy of Cogent, >GTT, and Level3 > >     I ain't friday, but: There is no RFC for the Sarcastica font >yet? > >     PS:  Our little adventure in BGP who-done-it (a few weeks back) >burned about 25-30h man hours estimated.  Should have been sub 5 >hours if 1 guy would have cooperated instead of ignoring the issue. > >----- >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/27/18 03:25, Mark Tinka wrote: >> >> On 27/Jun/18 04:18, Suresh Ramasubramanian wrote: >> >>> Oh dear. The problem with sarcasm is that it falls flat if people >don't realize you're being sarcastic. >> Text-based messaging is terribly reliable at helping miss the >point... >> >> It's a good things our kids of today call each other on the phone >to >> avoid that :-)... >> >> Mark. >> From goemon at sasami.anime.net Wed Jun 27 22:57:38 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Wed, 27 Jun 2018 15:57:38 -0700 (PDT) Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: <5F392CD8-4517-4A71-ABAC-6AB17C6EA300@gmail.com> References: <65543.1529988555@segfault.tristatelogic.com> <5F392CD8-4517-4A71-ABAC-6AB17C6EA300@gmail.com> Message-ID: On Tue, 26 Jun 2018, Suresh Ramasubramanian wrote: > "we are not the internet police" right? ( Indeed. Aid and abet would be a more accurate description. -Dan From surfer at mauigateway.com Thu Jun 28 00:01:25 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 27 Jun 2018 17:01:25 -0700 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 Message-ID: <20180627170125.3D77026E@m0117458.ppops.net> I suppose next you'll be telling me to get rid of my CRT when it works just fine? Black background, white text. :) scott From job at instituut.net Thu Jun 28 00:14:12 2018 From: job at instituut.net (Job Snijders) Date: Wed, 27 Jun 2018 18:14:12 -0600 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: <20180627170125.3D77026E@m0117458.ppops.net> References: <20180627170125.3D77026E@m0117458.ppops.net> Message-ID: People - please just stop the off topic chatter. It is ludicrous that a thread about bgp hijacks morphed into font discussions. Either contribute to the operational issue at hand by evaluating your terms & conditions (or abuse policies) and applying them to your operations, or remain silent. From surfer at mauigateway.com Thu Jun 28 01:03:41 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 27 Jun 2018 18:03:41 -0700 Subject: courtesy Message-ID: <20180627180341.3D770150@m0117458.ppops.net> --- job at instituut.net wrote: People - please just stop the off topic chatter. It is ludicrous that a thread about bgp hijacks morphed into font discussions. Either contribute to the operational issue at hand by evaluating your terms & conditions (or abuse policies) and applying them to your operations, or remain silent. ------------------------------------- While I have to agree with what you said in the first paragraph (there was too much of off topic chatter on this thread), I disagree with the second paragraph. You are not the King of NANOG where you can demand folks contribute in the manner you expect or "remain silent". The "Please" is acceptable and we'd likely all comply. The "remain silent" demand is not and it's likely to not gain compliance. scott From colebusby92 at gmail.com Thu Jun 28 01:42:39 2018 From: colebusby92 at gmail.com (Cole Busby) Date: Wed, 27 Jun 2018 18:42:39 -0700 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: References: <20180627170125.3D77026E@m0117458.ppops.net> Message-ID: hey all, while I'm in no place to make demands or requests of anyone, like many of you I have this thread on "loud". it may be beneficial to add a "-discussions" for when threads go off topic. outages implemented something similar and (for the most part) squelched the "me too" and off-topic threads from the main sub list with mods politely reminding off topic messages to use discussions for banter. I love read the conversation but as with most folks, maybe keeping it relevant to the subscription model. there's always discord, slack, mumble and IRC if you want to make a banter area too. sincerely, CB On Wed, Jun 27, 2018, 5:15 PM Job Snijders wrote: > People - please just stop the off topic chatter. It is ludicrous that a > thread about bgp hijacks morphed into font discussions. > > Either contribute to the operational issue at hand by evaluating your terms > & conditions (or abuse policies) and applying them to your operations, or > remain silent. > From randy at psg.com Thu Jun 28 01:43:26 2018 From: randy at psg.com (Randy Bush) Date: Wed, 27 Jun 2018 18:43:26 -0700 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: References: <20180627170125.3D77026E@m0117458.ppops.net> Message-ID: > People - please just stop the off topic chatter. It is ludicrous that a > thread about bgp hijacks morphed into font discussions. > > Either contribute to the operational issue at hand by evaluating your terms > & conditions (or abuse policies) and applying them to your operations, or > remain silent. ah! there are net police. come back with a warrant From toddunder at gmail.com Thu Jun 28 03:32:36 2018 From: toddunder at gmail.com (Todd Underwood) Date: Wed, 27 Jun 2018 23:32:36 -0400 Subject: courtesy In-Reply-To: <20180627180341.3D770150@m0117458.ppops.net> References: <20180627180341.3D770150@m0117458.ppops.net> Message-ID: the "please" distributes to both clauses and the difference is a matter of style rather than substance. job's point is sound and correct. please try to respect his firm suggestion. thanks, t On Wed, Jun 27, 2018 at 9:03 PM, Scott Weeks wrote: > > > --- job at instituut.net wrote: > People - please just stop the off topic chatter. It is > ludicrous that a thread about bgp hijacks morphed into > font discussions. > > Either contribute to the operational issue at hand by > evaluating your terms & conditions (or abuse policies) > and applying them to your operations, or remain silent. > ------------------------------------- > > > While I have to agree with what you said in the first > paragraph (there was too much of off topic chatter on > this thread), I disagree with the second paragraph. > You are not the King of NANOG where you can demand > folks contribute in the manner you expect or "remain > silent". The "Please" is acceptable and we'd likely > all comply. The "remain silent" demand is not and > it's likely to not gain compliance. > > scott > From hank at efes.iucc.ac.il Thu Jun 28 04:44:39 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 28 Jun 2018 07:44:39 +0300 Subject: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3 In-Reply-To: References: <20180627170125.3D77026E@m0117458.ppops.net> Message-ID: <0c68be1c-6161-8986-13bd-4e7823fd85eb@efes.iucc.ac.il> On 28/06/2018 04:43, Randy Bush wrote: >> People - please just stop the off topic chatter. It is ludicrous that a >> thread about bgp hijacks morphed into font discussions. >> >> Either contribute to the operational issue at hand by evaluating your terms >> & conditions (or abuse policies) and applying them to your operations, or >> remain silent. > ah! there are net police. > > come back with a warrant > Of course there are cuz I made them up 24 years ago: http://www.interall.co.il/netcops.html -Hank From mehmet at akcin.net Thu Jun 28 13:40:44 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 28 Jun 2018 07:40:44 -0600 Subject: Submarine Cable Status Map Experiment In-Reply-To: References: Message-ID: PS: We may need to rebuild (Validate) the map with KMZs. https://map.kapany.net If you are authorized and able to share KMZs of the cable systems you manage, please contact me offlist. Mehmet On Tue, Jun 26, 2018 at 5:56 PM Mehmet Akcin wrote: > Hello NANOGers, > > Today i presented a lighting talk to ask for feedback on the submarine > cable status project. I am still trying to work details on how the > governance and sustainability of this project should be structured. I know > there are more people in the list than those who attend in person to NANOG > in Denver hence I want to share my slides here > > > https://pc.nanog.org/static/published/meetings/NANOG73/1749/20180626_Akcin_Lightning_Talk_Submarine_v1.pdf > > There seems to be tremendous amount of interest and support on this > experiment. We are working on getting data (Kmz/Kml) from the operators of > submarine cable systems so we can build our map and display cable status > current demo page is available at https://map.kapany.net > > If you have ideas you want to share and help this map experiment become a > reality, please don't hesitate to contact me directly or join our mailing > list. at https://groups.google.com/a/kapany.net/forum/#!forum/subsea > > I would like to thank Aaron Hughes, Ognian Mitev, NANOG PC, Telegeography > , Angola Cables, Alaska Communications and Seaborn Networks for their > amazing support so far. > > ps: please feel free to pass this message to other groups / nogs to get > the message to those who are interested. > > Thank you! > > Mehmet > From C-Mack.McBride at charter.com Thu Jun 28 15:56:46 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Thu, 28 Jun 2018 15:56:46 +0000 Subject: AS3266: BitCanal hijack factory, courtesy of many connectivity providers In-Reply-To: <1530043034.3453896.1421327768.7C5D35A7@webmail.messagingengine.com> References: <65543.1529988555@segfault.tristatelogic.com> <20180626172218.GK5413@vurt.meerval.net> <20180626182355.GO5413@vurt.meerval.net> <1530043034.3453896.1421327768.7C5D35A7@webmail.messagingengine.com> Message-ID: https://bgp.he.net/AS205869#_peers This is another chronic hijacker that is spoofing downstream ASNs and Prefixes. They are currently hijacking 25 prefixes. Mostly /18s,/19s and /20s. Telcom Italia, Telia and Eurotrans Telecom are upstreams. Of course people making money off of it aren't going to do anything about it. Eurotrans Telecom has telia and tata as upstreams. They are also peered with HE but HE doesn't appear to be accepting the hijacked routes. Good for them. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Radu-Adrian Feurdean Sent: Tuesday, June 26, 2018 1:57 PM To: nanog at nanog.org Subject: Re: AS3266: BitCanal hijack factory, courtesy of many connectivity providers On Tue, Jun 26, 2018, at 20:23, Job Snijders wrote: > I'm very happy FranceIX apply filters - however Bitcanal is known to > submit fabricated/falsified IRR information to databases like RADB and > RIPE. I've reported this multiple times over the years to IRR database > operators. > > In conclusion in the case of Bitcanal, most of your filtering is > useless (and so is mine). Participants like Bitcanal dillute the value > of your route servers and the IXP as a whole. I can confirm that this mornig (~09h30 CEST, when I read the first message in the thread) there were no BitCanal announces received from FranceIX Paris RS. Not even the ones with an IRR record (the ones in 213/8). All of them were from transit. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From job at ntt.net Thu Jun 28 18:58:18 2018 From: job at ntt.net (Job Snijders) Date: Thu, 28 Jun 2018 12:58:18 -0600 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: Message-ID: Dear alll, Thank you all for your input. Just a heads-up - we deployed a few days ago. NTT / AS 2914 now considers “2002::/16 le 128” and “192.88.99.0/24 le 32” to be bogon prefixes, and no longer accepts announcements for these destinations from any EBGP neighbor. Kind regards, Job From bengelly at gmail.com Thu Jun 28 19:11:22 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Thu, 28 Jun 2018 21:11:22 +0200 Subject: Time to add 2002::/16 to bogon filters? In-Reply-To: References: Message-ID: Hello Job, Thank you for this feedback. I guess that NTT adopting this as a best practice will ring some bells around. Do you know if Team Cymru has updated their filters accordingly ? Best regards. > Le 28 juin 2018 à 20:58, Job Snijders a écrit : > > Dear alll, > > Thank you all for your input. Just a heads-up - we deployed a few days ago. > > NTT / AS 2914 now considers “2002::/16 le 128” and “192.88.99.0/24 le 32” > to be bogon prefixes, and no longer accepts announcements for these > destinations from any EBGP neighbor. > > Kind regards, > > Job From dcorbe at hammerfiber.com Fri Jun 29 17:53:28 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Fri, 29 Jun 2018 13:53:28 -0400 Subject: Comcast Message-ID: Can someone from Comcast contact me off list? Your customers can’t reach my network right now. From ssaner at hubris.net Fri Jun 29 17:57:39 2018 From: ssaner at hubris.net (Steve Saner) Date: Fri, 29 Jun 2018 12:57:39 -0500 Subject: Comcast In-Reply-To: References: Message-ID: On 06/29/2018 12:53 PM, Daniel Corbe wrote: > Can someone from Comcast contact me off list? > > Your customers can’t reach my network right now. > Seems to be a known issue: https://tech.slashdot.org/story/18/06/29/1730238/comcast-and-xfinity-facing-a-nationwide-outage-users-say Steve -- -------------------------------------------------------------------------- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net From eric-list at truenet.com Fri Jun 29 17:57:34 2018 From: eric-list at truenet.com (Eric Tykwinski) Date: Fri, 29 Jun 2018 13:57:34 -0400 Subject: Comcast In-Reply-To: References: Message-ID: <01b501d40fd2$a86fe040$f94fa0c0$@truenet.com> Nationwide outage for them right now: https://twitter.com/hashtag/comcast Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Corbe > Sent: Friday, June 29, 2018 1:53 PM > To: NANOG > Subject: Comcast > > Can someone from Comcast contact me off list? > > Your customers can’t reach my network right now. From cheetahmorph at gmail.com Fri Jun 29 17:57:51 2018 From: cheetahmorph at gmail.com (Ryan Gooler) Date: Fri, 29 Jun 2018 12:57:51 -0500 Subject: Comcast In-Reply-To: References: Message-ID: <8CF43960-5C88-48F0-86BC-134A1B998CDB@gmail.com> There’s a major Comcast outage going on. I’m pretty sure they’ve noticed. http://downdetector.com/status/comcast-xfinity > On Jun 29, 2018, at 12:53 PM, Daniel Corbe wrote: > > Can someone from Comcast contact me off list? > > Your customers can’t reach my network right now. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From steve at blighty.com Fri Jun 29 17:59:01 2018 From: steve at blighty.com (Steve Atkins) Date: Fri, 29 Jun 2018 10:59:01 -0700 Subject: Comcast In-Reply-To: References: Message-ID: <15EADE53-7935-4332-B47E-141FF6E09BAD@blighty.com> > On Jun 29, 2018, at 10:53 AM, Daniel Corbe wrote: > > Can someone from Comcast contact me off list? > > Your customers can’t reach my network right now. > It's much bigger than just your network, and probably bigger than just Comcast. They're aware of it, but probably kind of busy. Cheers, Steve From john-nanog at peachfamily.net Fri Jun 29 17:59:34 2018 From: john-nanog at peachfamily.net (John Peach) Date: Fri, 29 Jun 2018 13:59:34 -0400 Subject: Comcast In-Reply-To: References: Message-ID: <23514cc2-122f-4582-494a-7a526383f8bb@peachfamily.net> On 06/29/18 13:53, Daniel Corbe wrote: > Can someone from Comcast contact me off list? > > Your customers can’t reach my network right now. > They appear to have a nationwide outage: https://twitter.com/search?f=tweets&q=comcast%20xfinity%20outage&src=typd -- John PGP Public Key: 412934AC From rwebb at ropeguru.com Fri Jun 29 18:00:46 2018 From: rwebb at ropeguru.com (Robert Webb) Date: Fri, 29 Jun 2018 18:00:46 +0000 Subject: Comcast In-Reply-To: References: Message-ID: I have been noticing oddities too getting out to sites. Tracing route to www.dslreports.com [64.91.255.98] over a maximum of 30 hops: 1 4 ms 5 ms 3 ms 192.168.1.1 2 13 ms 15 ms 13 ms 96.120.80.37 3 13 ms 15 ms 15 ms 68.85.70.9 4 19 ms 23 ms 26 ms ae-45-ar02.charlvilleco.va.richmond.comcast.net [69.139.206.9] 5 28 ms 24 ms 26 ms be-21508-cr02.ashburn.va.ibone.comcast.net [68.86.91.53] 6 30 ms 22 ms 29 ms be-10130-pe04.ashburn.va.ibone.comcast.net [68.86.82.214] 7 27 ms 22 ms 24 ms 50.248.118.174 8 26 ms 26 ms 26 ms be3083.ccr41.dca01.atlas.cogentco.com [154.54.30.53] 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * ^C Tracing route to ubnt.lithium.com [208.74.207.27] over a maximum of 30 hops: 1 6 ms 3 ms 12 ms 192.168.1.1 2 15 ms 13 ms 18 ms 96.120.80.37 3 15 ms 10 ms 15 ms 68.85.70.9 4 23 ms 30 ms 21 ms ae-45-ar02.charlvilleco.va.richmond.comcast.net [69.139.206.9] 5 24 ms 24 ms 32 ms be-21508-cr02.ashburn.va.ibone.comcast.net [68.86.91.53] 6 28 ms 25 ms 24 ms be-10142-pe01.ashburn.va.ibone.comcast.net [68.86.86.34] 7 24 ms 30 ms 25 ms ash-b1-link.telia.net [62.115.149.64] 8 22 ms 28 ms 27 ms verisign-ic-325405-ash-b1.c.telia.net [62.115.155.209] 9 26 ms 22 ms 26 ms 64.6.73.231 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. -----Original Message----- From: NANOG On Behalf Of Daniel Corbe Sent: Friday, June 29, 2018 1:53 PM To: NANOG Subject: Comcast Can someone from Comcast contact me off list? Your customers can’t reach my network right now. From phil.lavin at cloudcall.com Fri Jun 29 18:01:30 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Fri, 29 Jun 2018 18:01:30 +0000 Subject: Comcast In-Reply-To: References: Message-ID: <4A64754E-FA61-4DF7-906C-B848951265EE@cloudcall.com> There’s a fairly wide reaching outage in the US. I imagine Comcast are already aware. > On 29 Jun 2018, at 18:56, Daniel Corbe wrote: > > Can someone from Comcast contact me off list? > > Your customers can’t reach my network right now. > From dcorbe at hammerfiber.com Fri Jun 29 18:02:25 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Fri, 29 Jun 2018 14:02:25 -0400 Subject: Comcast In-Reply-To: References: Message-ID: <81F56F98-8CC4-4BA2-8E54-33B383C388B1@hammerfiber.com> at 1:57 PM, Steve Saner wrote: > On 06/29/2018 12:53 PM, Daniel Corbe wrote: >> Can someone from Comcast contact me off list? >> Your customers can’t reach my network right now. > > Seems to be a known issue: > > https://tech.slashdot.org/story/18/06/29/1730238/comcast-and-xfinity-facing-a-nationwide-outage-users-say > > Steve > Thank you all! Sorry for the noise. -Daniel From cscora at apnic.net Fri Jun 29 18:03:11 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Jun 2018 04:03:11 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180629180311.EF485C450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 30 Jun, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 704428 Prefixes after maximum aggregation (per Origin AS): 270513 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 338397 Total ASes present in the Internet Routing Table: 61088 Prefixes per ASN: 11.53 Origin-only ASes present in the Internet Routing Table: 52749 Origin ASes announcing only one prefix: 23016 Transit ASes present in the Internet Routing Table: 8339 Transit-only ASes present in the Internet Routing Table: 279 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 35 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 59 Number of instances of unregistered ASNs: 60 Number of 32-bit ASNs allocated by the RIRs: 23121 Number of 32-bit ASNs visible in the Routing Table: 18629 Prefixes from 32-bit ASNs in the Routing Table: 77713 Number of bogon 32-bit ASNs visible in the Routing Table: 19 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 256 Number of addresses announced to Internet: 2858486211 Equivalent to 170 /8s, 97 /16s and 9 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 235143 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 192169 Total APNIC prefixes after maximum aggregation: 54695 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 190813 Unique aggregates announced from the APNIC address blocks: 78049 APNIC Region origin ASes present in the Internet Routing Table: 8917 APNIC Prefixes per ASN: 21.40 APNIC Region origin ASes announcing only one prefix: 2517 APNIC Region transit ASes present in the Internet Routing Table: 1335 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3884 Number of APNIC addresses announced to Internet: 767652354 Equivalent to 45 /8s, 193 /16s and 114 /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: 209432 Total ARIN prefixes after maximum aggregation: 99692 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209864 Unique aggregates announced from the ARIN address blocks: 99446 ARIN Region origin ASes present in the Internet Routing Table: 18191 ARIN Prefixes per ASN: 11.54 ARIN Region origin ASes announcing only one prefix: 6733 ARIN Region transit ASes present in the Internet Routing Table: 1817 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2370 Number of ARIN addresses announced to Internet: 1102961056 Equivalent to 65 /8s, 189 /16s and 217 /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: 192778 Total RIPE prefixes after maximum aggregation: 92071 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 188916 Unique aggregates announced from the RIPE address blocks: 112121 RIPE Region origin ASes present in the Internet Routing Table: 25232 RIPE Prefixes per ASN: 7.49 RIPE Region origin ASes announcing only one prefix: 11360 RIPE Region transit ASes present in the Internet Routing Table: 3507 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7118 Number of RIPE addresses announced to Internet: 715915648 Equivalent to 42 /8s, 172 /16s and 1 /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: 91081 Total LACNIC prefixes after maximum aggregation: 19997 LACNIC Deaggregation factor: 4.55 Prefixes being announced from the LACNIC address blocks: 92503 Unique aggregates announced from the LACNIC address blocks: 40846 LACNIC Region origin ASes present in the Internet Routing Table: 7275 LACNIC Prefixes per ASN: 12.72 LACNIC Region origin ASes announcing only one prefix: 2021 LACNIC Region transit ASes present in the Internet Routing Table: 1347 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4818 Number of LACNIC addresses announced to Internet: 172429728 Equivalent to 10 /8s, 71 /16s and 17 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 18908 Total AfriNIC prefixes after maximum aggregation: 4007 AfriNIC Deaggregation factor: 4.72 Prefixes being announced from the AfriNIC address blocks: 22076 Unique aggregates announced from the AfriNIC address blocks: 7713 AfriNIC Region origin ASes present in the Internet Routing Table: 1163 AfriNIC Prefixes per ASN: 18.98 AfriNIC Region origin ASes announcing only one prefix: 385 AfriNIC Region transit ASes present in the Internet Routing Table: 232 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 439 Number of AfriNIC addresses announced to Internet: 99088128 Equivalent to 5 /8s, 231 /16s and 247 /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 5424 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4313 424 442 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2880 1150 79 VIETEL-AS-AP Viettel Group, VN 4766 2849 11134 761 KIXS-AS-KR Korea Telecom, KR 9829 2812 1497 543 BSNL-NIB National Internet Backbone, IN 9394 2539 4907 31 CTTNET China TieTong Telecommunications 45899 2532 1603 158 VNPT-AS-VN VNPT Corp, VN 17974 2261 930 70 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2245 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2108 417 205 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3415 1324 84 SHAW - Shaw Communications Inc., CA 22773 3287 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2365 242 474 CABLEONE - CABLE ONE, INC., US 16509 2197 4716 708 AMAZON-02 - Amazon.com, Inc., US 18566 2170 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2107 2573 472 CHARTER-NET-HKY-NC - Charter Communicat 209 2034 5070 611 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 2000 343 161 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 1953 979 1388 AKAMAI-AS - Akamai Technologies, Inc., 7018 1744 20203 1273 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4417 1604 118 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2641 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2543 627 1874 AKAMAI-ASN1, US 34984 2017 335 496 TELLCOM-AS, TR 12389 2013 1877 708 ROSTELECOM-AS, RU 9121 1894 1692 19 TTNET, TR 13188 1601 100 43 TRIOLAN, UA 8402 1247 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 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 8151 4995 3299 584 Uninet S.A. de C.V., MX 10620 3565 542 251 Telmex Colombia S.A., CO 11830 2655 369 78 Instituto Costarricense de Electricidad 6503 1666 443 60 Axtel, S.A.B. de C.V., MX 7303 1507 1026 188 Telecom Argentina S.A., AR 28573 1035 2245 180 CLARO S.A., BR 3816 1008 505 129 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 931 377 31 Telefonica del Peru S.A.A., PE 11172 928 127 86 Alestra, S. de R.L. de C.V., MX 18881 913 1078 30 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 1153 396 48 LINKdotNET-AS, EG 37611 878 107 9 Afrihost, ZA 36903 766 385 138 MT-MPLS, MA 36992 752 1411 39 ETISALAT-MISR, EG 8452 633 1730 18 TE-AS TE-AS, EG 24835 611 818 18 RAYA-AS, EG 37492 472 470 57 ORANGE-, TN 29571 453 68 11 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 15399 374 39 8 WANANCHI-, KE 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 5424 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4995 3299 584 Uninet S.A. de C.V., MX 12479 4417 1604 118 UNI2-AS, ES 7545 4313 424 442 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3565 542 251 Telmex Colombia S.A., CO 6327 3415 1324 84 SHAW - Shaw Communications Inc., CA 22773 3287 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2880 1150 79 VIETEL-AS-AP Viettel Group, VN 4766 2849 11134 761 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 8151 4995 4411 Uninet S.A. de C.V., MX 12479 4417 4299 UNI2-AS, ES 7545 4313 3871 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3415 3331 SHAW - Shaw Communications Inc., CA 10620 3565 3314 Telmex Colombia S.A., CO 22773 3287 3140 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2880 2801 VIETEL-AS-AP Viettel Group, VN 8551 2641 2598 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2655 2577 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 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65544 DOCUMENT 103.197.121.0/24 65542 UNKNOWN 4259905537 PRIVATE 103.250.48.0/24 132917 YELLOWPAGESGROUP-AS-AP Yellow Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ 41.76.143.0/24 37500 -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:14 /9:11 /10:37 /11:99 /12:290 /13:568 /14:1097 /15:1898 /16:13360 /17:7933 /18:13761 /19:25252 /20:39302 /21:45486 /22:87624 /23:71032 /24:394474 /25:820 /26:613 /27:628 /28:35 /29:20 /30:18 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3202 3415 SHAW - Shaw Communications Inc., CA 12479 3160 4417 UNI2-AS, ES 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2549 3287 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2103 2641 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2063 2170 MEGAPATH5-US - MegaPath Corporation, US 11830 2003 2655 Instituto Costarricense de Electricidad y Telec 11492 1916 2365 CABLEONE - CABLE ONE, INC., US 30036 1752 2000 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1612 3565 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1578 2:849 4:18 5:2817 6:41 7:1 8:1124 12:1874 13:196 14:1748 15:30 16:3 17:213 18:54 20:49 23:2625 24:2224 25:2 27:2424 31:2022 32:92 35:27 36:494 37:2771 38:1460 39:229 40:122 41:3104 42:675 43:1932 44:118 45:4832 46:3040 47:201 49:1329 50:1056 51:316 52:1067 54:372 55:3 56:12 57:39 58:1622 59:1000 60:389 61:2102 62:1858 63:1803 64:5066 65:2208 66:4663 67:2438 68:1168 69:3239 70:1158 71:567 72:2112 74:2716 75:422 76:457 77:1553 78:1712 79:1693 80:1510 81:1381 82:1069 83:789 84:1065 85:2012 86:569 87:1307 88:928 89:2343 90:212 91:6387 92:1211 93:2375 94:2389 95:2880 96:731 97:357 98:947 99:133 100:83 101:1232 102:105 103:18036 104:3569 105:213 106:655 107:1780 108:695 109:3396 110:1606 111:1776 112:1283 113:1270 114:1124 115:1661 116:1640 117:1755 118:2160 119:1675 120:992 121:1054 122:2470 123:1778 124:1440 125:1922 128:1080 129:672 130:458 131:1610 132:690 133:195 134:1016 135:224 136:500 137:562 138:1984 139:649 140:453 141:724 142:801 143:980 144:800 145:481 146:1196 147:721 148:1629 149:760 150:735 151:1095 152:793 153:317 154:1213 155:765 156:1120 157:789 158:653 159:1739 160:1168 161:789 162:2589 163:595 164:1064 165:1492 166:449 167:1314 168:3058 169:815 170:3783 171:461 172:1077 173:2007 174:908 175:776 176:1982 177:4050 178:2534 179:1216 180:2191 181:2304 182:2370 183:1193 184:1029 185:13715 186:3599 187:2347 188:2852 189:2114 190:8122 191:1405 192:9829 193:5985 194:4858 195:3978 196:2602 197:1574 198:5545 199:5918 200:7332 201:5006 202:10459 203:10120 204:4581 205:2898 206:3108 207:3187 208:3982 209:3974 210:4047 211:2106 212:3000 213:2768 214:983 215:57 216:5984 217:2122 218:896 219:634 220:1773 221:983 222:1022 223:1297 End of report From tailsnpipes at gmail.com Thu Jun 28 16:29:28 2018 From: tailsnpipes at gmail.com (Tails Pipes) Date: Thu, 28 Jun 2018 09:29:28 -0700 Subject: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks) In-Reply-To: <004101d40e35$c2daed10$4890c730$@netconsultings.com> References: <004101d40e35$c2daed10$4890c730$@netconsultings.com> Message-ID: No, things changed there as well. Lookup merchant sillicon, and revise this post every 6 months. have you heard of Barefoot networks? The days of ASICs from Cisco are gone and we are glad, we tested the P4 DSL (cisco never got that right with mantel) on Nexus and its wonderful. The asics you speak of are no longer important or valuable because people realized that in many networking planets and galaxies, the asic is reflects the network design, they are related, and specifically for the data center, the clos fabric design won, and that does not require fancy asics. I guess your knowledge is out dated a bit. Cisco itself is using those merchant sillicon ASICs happily. (lookup Chuck's comments on nexus9000, best selling cisco switch ever)...guess it is a good switch, because bright box pushed cisco to do that, and if any one on this list can disagree with me here, i'm up to that challenge. What i have discovered recently is that things happen in following way. Your boss or his boss picks a work culture (no one gets fired for buying IBM/Cisco), that culture (buying the shiny suits) impacts how you do work, it makes you select vendors (the ones that sends me to vegas every year) and not the right network design, you select cisco and you are stuck there for life, because once they tell you how things should work (aka : certificates), things are worse, now every time you make a new network purchase (afraid of new CLI ), you will not be able to look the other way because you just dont know any thing else (and loosing your certificate value). I wish the culture would change to, no one got fired for buying closed but didnt get promoted either. change requires boldness. https://toolr.io/2018/06/18/stop-abusing-the-word-open/ On Wed, Jun 27, 2018 at 9:41 AM, wrote: > > Tails Pipes > > Sent: Friday, June 22, 2018 3:00 PM > > > > can you easily answer this question ? why packets are not pushed in > linux ? > > is it because of big switch, cumulus, pica8 ? > > > > can you push packets in linux without writing code to do that ? who is > writing > > that code ? > > > > this is supposedly a community effort, something that older generations > > dont understand. > > > If pure linux as NOS has some legs it'll fly regardless of cisco blessing, > don't worry no single company owns the whole industry. > Also we can argue that this is only about the OS but in reality it's also > the quality of apps running on top and the quality of the underlying HW > that plays a major role. > The quality of BGP app for instance, or the ability of the forwarding ASIC > to deliver the stated pps rate even if multiple features are enabled or > protect high priority traffic even if ASIC is overloaded. > > > Oh and with regards to: > < I am sick of having to learn all the cisco specific terms to all sorts > of different boxes and technologies > I'd recommend you read all the cisco books on networking to get yourself > educated on the topic and to get the difference between SW and HW > forwarding ( -on why packets are not routed in linux) > And while on that I suggest you read all Stanford university lectures on > how routers work too, it'll help you understand why Cisco and Juniper ASICs > are so much more expensive than white-box ASICs. > > adam > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: > > > From zbare at kinber.org Fri Jun 29 17:58:49 2018 From: zbare at kinber.org (Zach Bare) Date: Fri, 29 Jun 2018 13:58:49 -0400 Subject: Comcast In-Reply-To: References: Message-ID: Just an FYI Daniel, it looks like Comcast is experiencing a fairly large routing issue, at least through parts of the Eastern and Midwestern US. This is likely the cause. [image: photo] Zach Bare Network Engineer at KINBER Address 5775 Allentown Blvd., Suite 101, Harrisburg, PA 17112 Phone 717-963-7490 | PennREN NOC 833-736-6736 (833-PENNREN) <717-963-7490+%7C+PennREN+NOC+833-736-6736+(833-PENNREN)?utm_source=WiseStamp&utm_medium=email&utm_term=&utm_content=&utm_campaign=signature> Mobile 717-469-5461 <717-469-5461?utm_source=WiseStamp&utm_medium=email&utm_term=&utm_content=&utm_campaign=signature> Email zbare at kinber.org On Fri, Jun 29, 2018 at 1:53 PM, Daniel Corbe wrote: > Can someone from Comcast contact me off list? > > Your customers can’t reach my network right now. > > From denis.zhirovetskiy at adeptcore.com Fri Jun 29 17:59:04 2018 From: denis.zhirovetskiy at adeptcore.com (Denis Zhirovetskiy) Date: Fri, 29 Jun 2018 17:59:04 +0000 Subject: Comcast In-Reply-To: References: Message-ID: Comcast is having a global outage at this moment. IT Should Be Easy! Denis ZhirovetskiyFollow Us President Adeptcore, Inc. T: 847-595-0343 D 847-960-3420 E: denis.zhirovetskiy at adeptcore.com W: http://www.adeptcore.com 738 E Dundee Rd #143 PalatineIL60074 Cloud Managed Services Backup Office 365 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify support at adeptcore.com. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Corbe Sent: Friday, June 29, 2018 12:53 PM To: NANOG Subject: Comcast Can someone from Comcast contact me off list? Your customers can’t reach my network right now. From shibuya at nic.ad.jp Thu Jun 28 02:58:57 2018 From: shibuya at nic.ad.jp (Akira Shibuya) Date: Thu, 28 Jun 2018 11:58:57 +0900 Subject: General survey about situation of website blocking in your country/economy Message-ID: <3f90ccbc-e522-7fc0-0a37-477cbe1a277d@nic.ad.jp> Dear nanog members, JPNIC - Japan Network Information Center is now soliciting your input about the situation of website blocking all over the world, especially from the viewpoint of copyright infringement. In order to cope with vicious infringements, the Japanese government is considering countermeasures including the legislation of website blocking, alleging that blocking technologies are already being operated in many countries and regions of the world(*). JPNIC wants to grasp the real situation of the world. We would be grateful if you could answer the survey below by July 10th. https://docs.google.com/forms/d/e/1FAIpQLSfgxaDgDwHbWOv7RNbHYTRbNHQa_HFCPv01HwLWa4GCZRgkuQ/viewform?c=0& It would be highly appreciated if you could kindly provide us with your input. (*)Background: Japan calls for 'emergency measure’blocking access to websites that pirate manga and anime https://www.japantimes.co.jp/news/2018/04/13/national/japan-calls-emergency-measure-blocking-access-websites-pirate-manga-anime/#.WzMkJVX7TOV If you have any question about the survey, please feel free to email us at: web-blocking at nic.ad.jp All the Best, Akira Shibuya (on behalf of JPNIC secretariat)