From florin at andrei.myip.org Mon May 1 18:07:49 2017 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 01 May 2017 11:07:49 -0700 Subject: AWS us-west-2 routed through Europe from NY? In-Reply-To: References: <5790aefa181b0a4a85f2d0a525ecc322@andrei.myip.org> <20170428202820.GI86663@excession.tpb.net> <49ce5fcdbaaf94e981ce61fd72b63445@andrei.myip.org> Message-ID: Phil, The traceroute was done by a coworker in Quebec on April 26, from one of our corporate offices. His IP address was probably 104.163.180.188 at the time. He was tracing one of our endpoints in AWS us-west-2; I do not know which IPs our endpoint had at the time, but one of its current IPs is 52.89.73.31 This is the trace as he described it: Route - #1: 2.7 ms IP Address: 192.168.1.1 Hostname: local TTL: 64 - #2: 34.8 ms IP Address: 10.170.162.238 TTL: 50 - #3: 17.3 ms IP Address: 10.170.192.53 TTL: 250 - #4: 16.7 ms IP Address: 74.116.184.145 Hostname: 0.xe-11-1-0.er1.mtl7.ebox.ca TTL: 249 AS Number: AS1403 AS Name: EBOX Country Name: Canada Country Code: CA Time Zone: America/Toronto Region: Quebec City: Vieux-Saint-Laurent Latitude: 45.475 Longitude: -73.696 - #5: 15.6 ms IP Address: 213.248.76.201 Hostname: motl-b1-link.telia.net TTL: 248 AS Number: AS1299 AS Name: Telia Company AB Country Name: Europe Country Code: EU Time Zone: Europe/Vaduz - #6: 31.8 ms IP Address: 62.115.134.52 Hostname: nyk-bb4-link.telia.net TTL: 247 AS Number: AS1299 AS Name: Telia Company AB Country Name: Europe Country Code: EU Time Zone: Europe/Vaduz - #7: 47.7 ms IP Address: 213.155.136.19 Hostname: chi-b21-link.telia.net TTL: 246 AS Number: AS1299 AS Name: Telia Company AB Country Name: Europe Country Code: EU Time Zone: Europe/Vaduz - #8: 89.7 ms IP Address: 62.115.117.48 Hostname: sea-b1-link.telia.net TTL: 245 AS Number: AS1299 AS Name: Telia Company AB Country Name: Europe Country Code: EU Time Zone: Europe/Vaduz - #9: 90.7 ms IP Address: 62.115.34.102 Hostname: amazon-ic-302508-sea-b1.c.telia.net TTL: 244 AS Number: AS1299 AS Name: Telia Company AB Country Name: Europe Country Code: EU Time Zone: Europe/Vaduz - #10: 86.3 ms IP Address: 52.95.52.80 TTL: 239 Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: Washington City: Seattle Latitude: 47.634 Longitude: -122.342 - #11: 80.8 ms IP Address: 52.95.52.97 TTL: 241 Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: Washington City: Seattle Latitude: 47.634 Longitude: -122.342 - #12: 86.1 ms IP Address: 54.239.43.124 TTL: 240 Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: Washington City: Seattle Latitude: 47.610 Longitude: -122.334 - #13: 94.3 ms IP Address: 52.93.13.12 TTL: 235 Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: Oregon City: Boardman Latitude: 45.870 Longitude: -119.688 - #14: 86.5 ms IP Address: 52.93.12.249 TTL: 238 Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: Oregon City: Boardman Latitude: 45.870 Longitude: -119.688 - #15: 111.7 ms IP Address: 52.93.12.140 TTL: 234 Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: Oregon City: Boardman Latitude: 45.870 Longitude: -119.688 - #16: 92.6 ms IP Address: 52.93.12.173 TTL: 234 Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: Oregon City: Boardman Latitude: 45.870 Longitude: -119.688 - #17: 88.3 ms IP Address: 52.93.15.217 TTL: 236 Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: Oregon City: Boardman Latitude: 45.870 Longitude: -119.688 - #18: N/A TTL: 0 We expected that trace to go straight East Coast / West Coast, but instead it went through Europe. For comparison, this is a trace also by same coworker to api.postmates.com, which was correctly routed on the shortest geographical path (more or less): Route - #1: 3.0 ms IP Address: 192.168.1.1 Hostname: local TTL: 64 - #2: 29.0 ms IP Address: 10.170.162.238 TTL: 50 - #3: 17.9 ms IP Address: 10.170.192.53 TTL: 250 - #4: 19.7 ms IP Address: 74.116.184.145 Hostname: 0.xe-11-1-0.er1.mtl7.ebox.ca TTL: 249 AS Number: AS1403 AS Name: EBOX Country Name: Canada Country Code: CA Time Zone: America/Toronto Region: Quebec City: Vieux-Saint-Laurent Latitude: 45.475 Longitude: -73.696 - #5: 17.7 ms IP Address: 96.127.249.30 TTL: 248 AS Number: AS1403 AS Name: EBOX Country Name: Canada Country Code: CA Time Zone: America/Toronto Region: Quebec City: Longueuil Latitude: 45.518 Longitude: -73.502 - #6: 18.0 ms IP Address: 198.179.18.55 Hostname: cloudflare.peer.qix.ca TTL: 247 Country Name: Canada Country Code: CA Time Zone: America/Toronto Region: Quebec City: Montreal Latitude: 45.501 Longitude: -73.568 - #7: 17.6 ms IP Address: 104.16.42.25 Hostname: api.postmates.com TTL: 55 AS Number: AS13335 AS Name: CloudFlare Country Name: United States Country Code: US Time Zone: America/Los_Angeles Region: California City: San Francisco Latitude: 37.770 Longitude: -122.393 On 2017-04-28 17:05, Phillip McGuire wrote: > Hey Florin, > > Do you have a traceroute showing the issue? FYI, you can test against > any > of the IPs listed here under US-West-2, they all respond to ICMP > requests. > > http://ec2-reachability.amazonaws.com/ > > -Phil > > > > On Fri, Apr 28, 2017 at 1:33 PM, Florin Andrei > wrote: > >> On 2017-04-28 13:28, Niels Bakker wrote: >> >>> * florin at andrei.myip.org (Florin Andrei) [Fri 28 Apr 2017, 21:12 >>> CEST]: >>> >>>> I've seen a few strange instances where IP addresses in the AWS >>>> us-west-2 region (Oregon) are routed through Europe if you start the >>>> traceroute from some providers in the northern East Coast (Quebec, >>>> New >>>> York). Any idea what's going on? I assume it's temporary. >>>> >>> >>> Can you be a little bit more vague in your problem description? >>> While >>> ommitting the source networks from where you tried, you still >>> included >>> the destination. The list expects better. >>> >> >> Sorry. Here's one source: 104.163.180.188 >> >> >> -- >> Florin Andrei >> http://florin.myip.org/ >> -- Florin Andrei http://florin.myip.org/ From bob at FiberInternetCenter.com Mon May 1 18:12:03 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 1 May 2017 11:12:03 -0700 Subject: AWS us-west-2 routed through Europe from NY? In-Reply-To: References: <5790aefa181b0a4a85f2d0a525ecc322@andrei.myip.org> <20170428202820.GI86663@excession.tpb.net> <49ce5fcdbaaf94e981ce61fd72b63445@andrei.myip.org> Message-ID: <17aa99241bb8ac38122a0813d62d0c80.squirrel@66.201.44.180> Is this still happening? Thank You Bob Evans CTO > Phil, > > The traceroute was done by a coworker in Quebec on April 26, from one of > our corporate offices. His IP address was probably 104.163.180.188 at > the time. He was tracing one of our endpoints in AWS us-west-2; I do not > know which IPs our endpoint had at the time, but one of its current IPs > is 52.89.73.31 > > This is the trace as he described it: > > Route > - #1: 2.7 ms > IP Address: 192.168.1.1 > Hostname: local > TTL: 64 > - #2: 34.8 ms > IP Address: 10.170.162.238 > TTL: 50 > - #3: 17.3 ms > IP Address: 10.170.192.53 > TTL: 250 > - #4: 16.7 ms > IP Address: 74.116.184.145 > Hostname: 0.xe-11-1-0.er1.mtl7.ebox.ca > TTL: 249 > AS Number: AS1403 > AS Name: EBOX > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Vieux-Saint-Laurent > Latitude: 45.475 > Longitude: -73.696 > - #5: 15.6 ms > IP Address: 213.248.76.201 > Hostname: motl-b1-link.telia.net > TTL: 248 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #6: 31.8 ms > IP Address: 62.115.134.52 > Hostname: nyk-bb4-link.telia.net > TTL: 247 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #7: 47.7 ms > IP Address: 213.155.136.19 > Hostname: chi-b21-link.telia.net > TTL: 246 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #8: 89.7 ms > IP Address: 62.115.117.48 > Hostname: sea-b1-link.telia.net > TTL: 245 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #9: 90.7 ms > IP Address: 62.115.34.102 > Hostname: amazon-ic-302508-sea-b1.c.telia.net > TTL: 244 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #10: 86.3 ms > IP Address: 52.95.52.80 > TTL: 239 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Washington > City: Seattle > Latitude: 47.634 > Longitude: -122.342 > - #11: 80.8 ms > IP Address: 52.95.52.97 > TTL: 241 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Washington > City: Seattle > Latitude: 47.634 > Longitude: -122.342 > - #12: 86.1 ms > IP Address: 54.239.43.124 > TTL: 240 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Washington > City: Seattle > Latitude: 47.610 > Longitude: -122.334 > - #13: 94.3 ms > IP Address: 52.93.13.12 > TTL: 235 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #14: 86.5 ms > IP Address: 52.93.12.249 > TTL: 238 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #15: 111.7 ms > IP Address: 52.93.12.140 > TTL: 234 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #16: 92.6 ms > IP Address: 52.93.12.173 > TTL: 234 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #17: 88.3 ms > IP Address: 52.93.15.217 > TTL: 236 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #18: N/A > TTL: 0 > > > We expected that trace to go straight East Coast / West Coast, but > instead it went through Europe. > > For comparison, this is a trace also by same coworker to > api.postmates.com, which was correctly routed on the shortest > geographical path (more or less): > > Route > - #1: 3.0 ms > IP Address: 192.168.1.1 > Hostname: local > TTL: 64 > - #2: 29.0 ms > IP Address: 10.170.162.238 > TTL: 50 > - #3: 17.9 ms > IP Address: 10.170.192.53 > TTL: 250 > - #4: 19.7 ms > IP Address: 74.116.184.145 > Hostname: 0.xe-11-1-0.er1.mtl7.ebox.ca > TTL: 249 > AS Number: AS1403 > AS Name: EBOX > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Vieux-Saint-Laurent > Latitude: 45.475 > Longitude: -73.696 > - #5: 17.7 ms > IP Address: 96.127.249.30 > TTL: 248 > AS Number: AS1403 > AS Name: EBOX > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Longueuil > Latitude: 45.518 > Longitude: -73.502 > - #6: 18.0 ms > IP Address: 198.179.18.55 > Hostname: cloudflare.peer.qix.ca > TTL: 247 > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Montreal > Latitude: 45.501 > Longitude: -73.568 > - #7: 17.6 ms > IP Address: 104.16.42.25 > Hostname: api.postmates.com > TTL: 55 > AS Number: AS13335 > AS Name: CloudFlare > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: California > City: San Francisco > Latitude: 37.770 > Longitude: -122.393 > > > On 2017-04-28 17:05, Phillip McGuire wrote: >> Hey Florin, >> >> Do you have a traceroute showing the issue? FYI, you can test against >> any >> of the IPs listed here under US-West-2, they all respond to ICMP >> requests. >> >> http://ec2-reachability.amazonaws.com/ >> >> -Phil >> >> >> >> On Fri, Apr 28, 2017 at 1:33 PM, Florin Andrei >> wrote: >> >>> On 2017-04-28 13:28, Niels Bakker wrote: >>> >>>> * florin at andrei.myip.org (Florin Andrei) [Fri 28 Apr 2017, 21:12 >>>> CEST]: >>>> >>>>> I've seen a few strange instances where IP addresses in the AWS >>>>> us-west-2 region (Oregon) are routed through Europe if you start the >>>>> traceroute from some providers in the northern East Coast (Quebec, >>>>> New >>>>> York). Any idea what's going on? I assume it's temporary. >>>>> >>>> >>>> Can you be a little bit more vague in your problem description? >>>> While >>>> ommitting the source networks from where you tried, you still >>>> included >>>> the destination. The list expects better. >>>> >>> >>> Sorry. Here's one source: 104.163.180.188 >>> >>> >>> -- >>> Florin Andrei >>> http://florin.myip.org/ >>> > > -- > Florin Andrei > http://florin.myip.org/ > From nik at neko.id.au Mon May 1 18:34:28 2017 From: nik at neko.id.au (Nikolas Geyer) Date: Mon, 1 May 2017 18:34:28 +0000 Subject: AWS us-west-2 routed through Europe from NY? In-Reply-To: References: <5790aefa181b0a4a85f2d0a525ecc322@andrei.myip.org> <20170428202820.GI86663@excession.tpb.net> <49ce5fcdbaaf94e981ce61fd72b63445@andrei.myip.org> , Message-ID: <117D9E79-8887-4574-9030-4972F6691B46@neko.id.au> It hasn't gone through Europe, it's just most of Telia's IP space will return a geolocation of Europe. The trace provided goes to New York, Chicago then Seattle. Sent from my iPhone > On 1 May 2017, at 2:10 pm, Florin Andrei wrote: > > Phil, > > The traceroute was done by a coworker in Quebec on April 26, from one of our corporate offices. His IP address was probably 104.163.180.188 at the time. He was tracing one of our endpoints in AWS us-west-2; I do not know which IPs our endpoint had at the time, but one of its current IPs is 52.89.73.31 > > This is the trace as he described it: > > Route > - #1: 2.7 ms > IP Address: 192.168.1.1 > Hostname: local > TTL: 64 > - #2: 34.8 ms > IP Address: 10.170.162.238 > TTL: 50 > - #3: 17.3 ms > IP Address: 10.170.192.53 > TTL: 250 > - #4: 16.7 ms > IP Address: 74.116.184.145 > Hostname: 0.xe-11-1-0.er1.mtl7.ebox.ca > TTL: 249 > AS Number: AS1403 > AS Name: EBOX > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Vieux-Saint-Laurent > Latitude: 45.475 > Longitude: -73.696 > - #5: 15.6 ms > IP Address: 213.248.76.201 > Hostname: motl-b1-link.telia.net > TTL: 248 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #6: 31.8 ms > IP Address: 62.115.134.52 > Hostname: nyk-bb4-link.telia.net > TTL: 247 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #7: 47.7 ms > IP Address: 213.155.136.19 > Hostname: chi-b21-link.telia.net > TTL: 246 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #8: 89.7 ms > IP Address: 62.115.117.48 > Hostname: sea-b1-link.telia.net > TTL: 245 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #9: 90.7 ms > IP Address: 62.115.34.102 > Hostname: amazon-ic-302508-sea-b1.c.telia.net > TTL: 244 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #10: 86.3 ms > IP Address: 52.95.52.80 > TTL: 239 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Washington > City: Seattle > Latitude: 47.634 > Longitude: -122.342 > - #11: 80.8 ms > IP Address: 52.95.52.97 > TTL: 241 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Washington > City: Seattle > Latitude: 47.634 > Longitude: -122.342 > - #12: 86.1 ms > IP Address: 54.239.43.124 > TTL: 240 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Washington > City: Seattle > Latitude: 47.610 > Longitude: -122.334 > - #13: 94.3 ms > IP Address: 52.93.13.12 > TTL: 235 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #14: 86.5 ms > IP Address: 52.93.12.249 > TTL: 238 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #15: 111.7 ms > IP Address: 52.93.12.140 > TTL: 234 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #16: 92.6 ms > IP Address: 52.93.12.173 > TTL: 234 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #17: 88.3 ms > IP Address: 52.93.15.217 > TTL: 236 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #18: N/A > TTL: 0 > > > We expected that trace to go straight East Coast / West Coast, but instead it went through Europe. > > For comparison, this is a trace also by same coworker to api.postmates.com, which was correctly routed on the shortest geographical path (more or less): > > Route > - #1: 3.0 ms > IP Address: 192.168.1.1 > Hostname: local > TTL: 64 > - #2: 29.0 ms > IP Address: 10.170.162.238 > TTL: 50 > - #3: 17.9 ms > IP Address: 10.170.192.53 > TTL: 250 > - #4: 19.7 ms > IP Address: 74.116.184.145 > Hostname: 0.xe-11-1-0.er1.mtl7.ebox.ca > TTL: 249 > AS Number: AS1403 > AS Name: EBOX > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Vieux-Saint-Laurent > Latitude: 45.475 > Longitude: -73.696 > - #5: 17.7 ms > IP Address: 96.127.249.30 > TTL: 248 > AS Number: AS1403 > AS Name: EBOX > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Longueuil > Latitude: 45.518 > Longitude: -73.502 > - #6: 18.0 ms > IP Address: 198.179.18.55 > Hostname: cloudflare.peer.qix.ca > TTL: 247 > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Montreal > Latitude: 45.501 > Longitude: -73.568 > - #7: 17.6 ms > IP Address: 104.16.42.25 > Hostname: api.postmates.com > TTL: 55 > AS Number: AS13335 > AS Name: CloudFlare > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: California > City: San Francisco > Latitude: 37.770 > Longitude: -122.393 > > >> On 2017-04-28 17:05, Phillip McGuire wrote: >> Hey Florin, >> Do you have a traceroute showing the issue? FYI, you can test against any >> of the IPs listed here under US-West-2, they all respond to ICMP requests. >> http://ec2-reachability.amazonaws.com/ >> -Phil >> On Fri, Apr 28, 2017 at 1:33 PM, Florin Andrei >> wrote: >>> On 2017-04-28 13:28, Niels Bakker wrote: >>>> * florin at andrei.myip.org (Florin Andrei) [Fri 28 Apr 2017, 21:12 CEST]: >>>>> I've seen a few strange instances where IP addresses in the AWS >>>>> us-west-2 region (Oregon) are routed through Europe if you start the >>>>> traceroute from some providers in the northern East Coast (Quebec, New >>>>> York). Any idea what's going on? I assume it's temporary. >>>> Can you be a little bit more vague in your problem description? While >>>> ommitting the source networks from where you tried, you still included >>>> the destination. The list expects better. >>> Sorry. Here's one source: 104.163.180.188 >>> -- >>> Florin Andrei >>> http://florin.myip.org/ > > -- > Florin Andrei > http://florin.myip.org/ From eric.kuhnke at gmail.com Mon May 1 22:35:21 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 1 May 2017 15:35:21 -0700 Subject: AWS us-west-2 routed through Europe from NY? In-Reply-To: References: <5790aefa181b0a4a85f2d0a525ecc322@andrei.myip.org> <20170428202820.GI86663@excession.tpb.net> <49ce5fcdbaaf94e981ce61fd72b63445@andrei.myip.org> Message-ID: Just because a "fancy" traceroute tool does ARIN, RIPE or APNIC lookups, or uses a third party geolocation tool such as Maxmind to determine who owns a given netblock, does not mean that each hop of the traceroute is going through that country... It's just saying "this block of IPs is owned by Telia, which is based in Europe". If you look at the reverse DNS for the route they have used fairly common abbreviations to denote that this link goes city-to-city within North America. Also you would probably notice if your end to end latency from Quebec to Oregon was taking a round trip through Europe. I bet your RTT ping to the end point AWS IP in Oregon is low enough that the currently known laws of physics would prohibit it from taking a round trip through an atlantic cable and back again. https://www.google.com/search?q=nanog+traceroute+presentation&oq=nanog+traceroute+presentation&aqs=chrome..69i57.2365j0j7&sourceid=chrome&ie=UTF-8 On Mon, May 1, 2017 at 11:07 AM, Florin Andrei wrote: > Phil, > > The traceroute was done by a coworker in Quebec on April 26, from one of > our corporate offices. His IP address was probably 104.163.180.188 at the > time. He was tracing one of our endpoints in AWS us-west-2; I do not know > which IPs our endpoint had at the time, but one of its current IPs is > 52.89.73.31 > > This is the trace as he described it: > > Route > - #1: 2.7 ms > IP Address: 192.168.1.1 > Hostname: local > TTL: 64 > - #2: 34.8 ms > IP Address: 10.170.162.238 > TTL: 50 > - #3: 17.3 ms > IP Address: 10.170.192.53 > TTL: 250 > - #4: 16.7 ms > IP Address: 74.116.184.145 > Hostname: 0.xe-11-1-0.er1.mtl7.ebox.ca > TTL: 249 > AS Number: AS1403 > AS Name: EBOX > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Vieux-Saint-Laurent > Latitude: 45.475 > Longitude: -73.696 > - #5: 15.6 ms > IP Address: 213.248.76.201 > Hostname: motl-b1-link.telia.net > TTL: 248 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #6: 31.8 ms > IP Address: 62.115.134.52 > Hostname: nyk-bb4-link.telia.net > TTL: 247 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #7: 47.7 ms > IP Address: 213.155.136.19 > Hostname: chi-b21-link.telia.net > TTL: 246 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #8: 89.7 ms > IP Address: 62.115.117.48 > Hostname: sea-b1-link.telia.net > TTL: 245 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #9: 90.7 ms > IP Address: 62.115.34.102 > Hostname: amazon-ic-302508-sea-b1.c.telia.net > TTL: 244 > AS Number: AS1299 > AS Name: Telia Company AB > Country Name: Europe > Country Code: EU > Time Zone: Europe/Vaduz > - #10: 86.3 ms > IP Address: 52.95.52.80 > TTL: 239 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Washington > City: Seattle > Latitude: 47.634 > Longitude: -122.342 > - #11: 80.8 ms > IP Address: 52.95.52.97 > TTL: 241 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Washington > City: Seattle > Latitude: 47.634 > Longitude: -122.342 > - #12: 86.1 ms > IP Address: 54.239.43.124 > TTL: 240 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Washington > City: Seattle > Latitude: 47.610 > Longitude: -122.334 > - #13: 94.3 ms > IP Address: 52.93.13.12 > TTL: 235 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #14: 86.5 ms > IP Address: 52.93.12.249 > TTL: 238 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #15: 111.7 ms > IP Address: 52.93.12.140 > TTL: 234 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #16: 92.6 ms > IP Address: 52.93.12.173 > TTL: 234 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #17: 88.3 ms > IP Address: 52.93.15.217 > TTL: 236 > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: Oregon > City: Boardman > Latitude: 45.870 > Longitude: -119.688 > - #18: N/A > TTL: 0 > > > We expected that trace to go straight East Coast / West Coast, but instead > it went through Europe. > > For comparison, this is a trace also by same coworker to api.postmates.com, > which was correctly routed on the shortest geographical path (more or less): > > Route > - #1: 3.0 ms > IP Address: 192.168.1.1 > Hostname: local > TTL: 64 > - #2: 29.0 ms > IP Address: 10.170.162.238 > TTL: 50 > - #3: 17.9 ms > IP Address: 10.170.192.53 > TTL: 250 > - #4: 19.7 ms > IP Address: 74.116.184.145 > Hostname: 0.xe-11-1-0.er1.mtl7.ebox.ca > TTL: 249 > AS Number: AS1403 > AS Name: EBOX > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Vieux-Saint-Laurent > Latitude: 45.475 > Longitude: -73.696 > - #5: 17.7 ms > IP Address: 96.127.249.30 > TTL: 248 > AS Number: AS1403 > AS Name: EBOX > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Longueuil > Latitude: 45.518 > Longitude: -73.502 > - #6: 18.0 ms > IP Address: 198.179.18.55 > Hostname: cloudflare.peer.qix.ca > TTL: 247 > Country Name: Canada > Country Code: CA > Time Zone: America/Toronto > Region: Quebec > City: Montreal > Latitude: 45.501 > Longitude: -73.568 > - #7: 17.6 ms > IP Address: 104.16.42.25 > Hostname: api.postmates.com > TTL: 55 > AS Number: AS13335 > AS Name: CloudFlare > Country Name: United States > Country Code: US > Time Zone: America/Los_Angeles > Region: California > City: San Francisco > Latitude: 37.770 > Longitude: -122.393 > > > > On 2017-04-28 17:05, Phillip McGuire wrote: > >> Hey Florin, >> >> Do you have a traceroute showing the issue? FYI, you can test against any >> of the IPs listed here under US-West-2, they all respond to ICMP requests. >> >> http://ec2-reachability.amazonaws.com/ >> >> -Phil >> >> >> >> On Fri, Apr 28, 2017 at 1:33 PM, Florin Andrei >> wrote: >> >> On 2017-04-28 13:28, Niels Bakker wrote: >>> >>> * florin at andrei.myip.org (Florin Andrei) [Fri 28 Apr 2017, 21:12 CEST]: >>>> >>>> I've seen a few strange instances where IP addresses in the AWS >>>>> us-west-2 region (Oregon) are routed through Europe if you start the >>>>> traceroute from some providers in the northern East Coast (Quebec, New >>>>> York). Any idea what's going on? I assume it's temporary. >>>>> >>>>> >>>> Can you be a little bit more vague in your problem description? While >>>> ommitting the source networks from where you tried, you still included >>>> the destination. The list expects better. >>>> >>>> >>> Sorry. Here's one source: 104.163.180.188 >>> >>> >>> -- >>> Florin Andrei >>> http://florin.myip.org/ >>> >>> > -- > Florin Andrei > http://florin.myip.org/ > From florin at andrei.myip.org Mon May 1 23:25:01 2017 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 01 May 2017 16:25:01 -0700 Subject: AWS us-west-2 routed through Europe from NY? In-Reply-To: <117D9E79-8887-4574-9030-4972F6691B46@neko.id.au> References: <5790aefa181b0a4a85f2d0a525ecc322@andrei.myip.org> <20170428202820.GI86663@excession.tpb.net> <49ce5fcdbaaf94e981ce61fd72b63445@andrei.myip.org> , <117D9E79-8887-4574-9030-4972F6691B46@neko.id.au> Message-ID: <5a55e9754ed61a7f1cd83b1e6c0006b6@andrei.myip.org> That's embarrassing. Thanks for opening my eyes. Sorry for wasting everyone's time. On 2017-05-01 11:34, Nikolas Geyer wrote: > It hasn't gone through Europe, it's just most of Telia's IP space will > return a geolocation of Europe. The trace provided goes to New York, > Chicago then Seattle. > > Sent from my iPhone > >> On 1 May 2017, at 2:10 pm, Florin Andrei >> wrote: >> >> Phil, >> >> The traceroute was done by a coworker in Quebec on April 26, from one >> of our corporate offices. His IP address was probably 104.163.180.188 >> at the time. He was tracing one of our endpoints in AWS us-west-2; I >> do not know which IPs our endpoint had at the time, but one of its >> current IPs is 52.89.73.31 >> >> This is the trace as he described it: >> >> Route >> - #1: 2.7 ms >> IP Address: 192.168.1.1 >> Hostname: local >> TTL: 64 >> - #2: 34.8 ms >> IP Address: 10.170.162.238 >> TTL: 50 >> - #3: 17.3 ms >> IP Address: 10.170.192.53 >> TTL: 250 >> - #4: 16.7 ms >> IP Address: 74.116.184.145 >> Hostname: 0.xe-11-1-0.er1.mtl7.ebox.ca >> TTL: 249 >> AS Number: AS1403 >> AS Name: EBOX >> Country Name: Canada >> Country Code: CA >> Time Zone: America/Toronto >> Region: Quebec >> City: Vieux-Saint-Laurent >> Latitude: 45.475 >> Longitude: -73.696 >> - #5: 15.6 ms >> IP Address: 213.248.76.201 >> Hostname: motl-b1-link.telia.net >> TTL: 248 >> AS Number: AS1299 >> AS Name: Telia Company AB >> Country Name: Europe >> Country Code: EU >> Time Zone: Europe/Vaduz >> - #6: 31.8 ms >> IP Address: 62.115.134.52 >> Hostname: nyk-bb4-link.telia.net >> TTL: 247 >> AS Number: AS1299 >> AS Name: Telia Company AB >> Country Name: Europe >> Country Code: EU >> Time Zone: Europe/Vaduz >> - #7: 47.7 ms >> IP Address: 213.155.136.19 >> Hostname: chi-b21-link.telia.net >> TTL: 246 >> AS Number: AS1299 >> AS Name: Telia Company AB >> Country Name: Europe >> Country Code: EU >> Time Zone: Europe/Vaduz >> - #8: 89.7 ms >> IP Address: 62.115.117.48 >> Hostname: sea-b1-link.telia.net >> TTL: 245 >> AS Number: AS1299 >> AS Name: Telia Company AB >> Country Name: Europe >> Country Code: EU >> Time Zone: Europe/Vaduz >> - #9: 90.7 ms >> IP Address: 62.115.34.102 >> Hostname: amazon-ic-302508-sea-b1.c.telia.net >> TTL: 244 >> AS Number: AS1299 >> AS Name: Telia Company AB >> Country Name: Europe >> Country Code: EU >> Time Zone: Europe/Vaduz >> - #10: 86.3 ms >> IP Address: 52.95.52.80 >> TTL: 239 >> Country Name: United States >> Country Code: US >> Time Zone: America/Los_Angeles >> Region: Washington >> City: Seattle >> Latitude: 47.634 >> Longitude: -122.342 >> - #11: 80.8 ms >> IP Address: 52.95.52.97 >> TTL: 241 >> Country Name: United States >> Country Code: US >> Time Zone: America/Los_Angeles >> Region: Washington >> City: Seattle >> Latitude: 47.634 >> Longitude: -122.342 >> - #12: 86.1 ms >> IP Address: 54.239.43.124 >> TTL: 240 >> Country Name: United States >> Country Code: US >> Time Zone: America/Los_Angeles >> Region: Washington >> City: Seattle >> Latitude: 47.610 >> Longitude: -122.334 >> - #13: 94.3 ms >> IP Address: 52.93.13.12 >> TTL: 235 >> Country Name: United States >> Country Code: US >> Time Zone: America/Los_Angeles >> Region: Oregon >> City: Boardman >> Latitude: 45.870 >> Longitude: -119.688 >> - #14: 86.5 ms >> IP Address: 52.93.12.249 >> TTL: 238 >> Country Name: United States >> Country Code: US >> Time Zone: America/Los_Angeles >> Region: Oregon >> City: Boardman >> Latitude: 45.870 >> Longitude: -119.688 >> - #15: 111.7 ms >> IP Address: 52.93.12.140 >> TTL: 234 >> Country Name: United States >> Country Code: US >> Time Zone: America/Los_Angeles >> Region: Oregon >> City: Boardman >> Latitude: 45.870 >> Longitude: -119.688 >> - #16: 92.6 ms >> IP Address: 52.93.12.173 >> TTL: 234 >> Country Name: United States >> Country Code: US >> Time Zone: America/Los_Angeles >> Region: Oregon >> City: Boardman >> Latitude: 45.870 >> Longitude: -119.688 >> - #17: 88.3 ms >> IP Address: 52.93.15.217 >> TTL: 236 >> Country Name: United States >> Country Code: US >> Time Zone: America/Los_Angeles >> Region: Oregon >> City: Boardman >> Latitude: 45.870 >> Longitude: -119.688 >> - #18: N/A >> TTL: 0 >> >> >> We expected that trace to go straight East Coast / West Coast, but >> instead it went through Europe. >> >> For comparison, this is a trace also by same coworker to >> api.postmates.com, which was correctly routed on the shortest >> geographical path (more or less): >> >> Route >> - #1: 3.0 ms >> IP Address: 192.168.1.1 >> Hostname: local >> TTL: 64 >> - #2: 29.0 ms >> IP Address: 10.170.162.238 >> TTL: 50 >> - #3: 17.9 ms >> IP Address: 10.170.192.53 >> TTL: 250 >> - #4: 19.7 ms >> IP Address: 74.116.184.145 >> Hostname: 0.xe-11-1-0.er1.mtl7.ebox.ca >> TTL: 249 >> AS Number: AS1403 >> AS Name: EBOX >> Country Name: Canada >> Country Code: CA >> Time Zone: America/Toronto >> Region: Quebec >> City: Vieux-Saint-Laurent >> Latitude: 45.475 >> Longitude: -73.696 >> - #5: 17.7 ms >> IP Address: 96.127.249.30 >> TTL: 248 >> AS Number: AS1403 >> AS Name: EBOX >> Country Name: Canada >> Country Code: CA >> Time Zone: America/Toronto >> Region: Quebec >> City: Longueuil >> Latitude: 45.518 >> Longitude: -73.502 >> - #6: 18.0 ms >> IP Address: 198.179.18.55 >> Hostname: cloudflare.peer.qix.ca >> TTL: 247 >> Country Name: Canada >> Country Code: CA >> Time Zone: America/Toronto >> Region: Quebec >> City: Montreal >> Latitude: 45.501 >> Longitude: -73.568 >> - #7: 17.6 ms >> IP Address: 104.16.42.25 >> Hostname: api.postmates.com >> TTL: 55 >> AS Number: AS13335 >> AS Name: CloudFlare >> Country Name: United States >> Country Code: US >> Time Zone: America/Los_Angeles >> Region: California >> City: San Francisco >> Latitude: 37.770 >> Longitude: -122.393 >> >> >>> On 2017-04-28 17:05, Phillip McGuire wrote: >>> Hey Florin, >>> Do you have a traceroute showing the issue? FYI, you can test against >>> any >>> of the IPs listed here under US-West-2, they all respond to ICMP >>> requests. >>> http://ec2-reachability.amazonaws.com/ >>> -Phil >>> On Fri, Apr 28, 2017 at 1:33 PM, Florin Andrei >>> >>> wrote: >>>> On 2017-04-28 13:28, Niels Bakker wrote: >>>>> * florin at andrei.myip.org (Florin Andrei) [Fri 28 Apr 2017, 21:12 >>>>> CEST]: >>>>>> I've seen a few strange instances where IP addresses in the AWS >>>>>> us-west-2 region (Oregon) are routed through Europe if you start >>>>>> the >>>>>> traceroute from some providers in the northern East Coast (Quebec, >>>>>> New >>>>>> York). Any idea what's going on? I assume it's temporary. >>>>> Can you be a little bit more vague in your problem description? >>>>> While >>>>> ommitting the source networks from where you tried, you still >>>>> included >>>>> the destination. The list expects better. >>>> Sorry. Here's one source: 104.163.180.188 >>>> -- >>>> Florin Andrei >>>> http://florin.myip.org/ >> >> -- >> Florin Andrei >> http://florin.myip.org/ -- Florin Andrei http://florin.myip.org/ From math at sizone.org Tue May 2 05:47:34 2017 From: math at sizone.org (Ken Chase) Date: Tue, 2 May 2017 01:47:34 -0400 Subject: intel remote management exploit Message-ID: <20170502054734.GT10223@sizone.org> How we all feeling about this? Trying hard to get a bead on how freaked out we're all sposta be right this second. (Most of my gear is AMD, but as the article indicates, your toaster probably has Intel in it too.) https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr some analysis: http://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/ 01:41 < azend|vps> Better hope your pfsense firewall isn't Intel based see? and just before bed... (why do i check mail before bed...) /kc -- Ken Chase - math at sizone.org Guelph Canada From valdis.kletnieks at vt.edu Tue May 2 05:49:04 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 02 May 2017 01:49:04 -0400 Subject: Financial services BGP hijack last week? Message-ID: <42995.1493704144@turing-police.cc.vt.edu> I didn't see any mention of this here. Any comments? "On Wednesday, large chunks of network traffic belonging to MasterCard, Visa, and more than two dozen other financial services companies were briefly routed through a Russian government-controlled telecom under unexplained circumstances that renew lingering questions about the trust and reliability of some of the most sensitive Internet communications." https://arstechnica.com/security/2017/04/russian-controlled-telecom-hijacks-financial-services-internet-traffic/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From maxtul at netassist.ua Tue May 2 11:55:28 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 2 May 2017 14:55:28 +0300 Subject: Financial services BGP hijack last week? In-Reply-To: <42995.1493704144@turing-police.cc.vt.edu> References: <42995.1493704144@turing-police.cc.vt.edu> Message-ID: <590873B0.90302@netassist.ua> All know. Nobody care. On 02.05.17 08:49, valdis.kletnieks at vt.edu wrote: > I didn't see any mention of this here. Any comments? > > "On Wednesday, large chunks of network traffic belonging to MasterCard, Visa, > and more than two dozen other financial services companies were briefly routed > through a Russian government-controlled telecom under unexplained circumstances > that renew lingering questions about the trust and reliability of some of the > most sensitive Internet communications." > > https://arstechnica.com/security/2017/04/russian-controlled-telecom-hijacks-financial-services-internet-traffic/ > From nikosietf at gmail.com Tue May 2 07:29:32 2017 From: nikosietf at gmail.com (Nikos Leontsinis) Date: Tue, 2 May 2017 08:29:32 +0100 Subject: Financial services BGP hijack last week? In-Reply-To: <42995.1493704144@turing-police.cc.vt.edu> References: <42995.1493704144@turing-police.cc.vt.edu> Message-ID: it only proves the need for wider RPKI adoption.... On 2 May 2017 at 06:49, wrote: > I didn't see any mention of this here. Any comments? > > "On Wednesday, large chunks of network traffic belonging to MasterCard, Visa, > and more than two dozen other financial services companies were briefly routed > through a Russian government-controlled telecom under unexplained circumstances > that renew lingering questions about the trust and reliability of some of the > most sensitive Internet communications." > > https://arstechnica.com/security/2017/04/russian-controlled-telecom-hijacks-financial-services-internet-traffic/ From s at christoph3r.net Tue May 2 10:21:31 2017 From: s at christoph3r.net (Scott Christopher) Date: Tue, 02 May 2017 03:21:31 -0700 Subject: Financial services BGP hijack last week? In-Reply-To: <42995.1493704144@turing-police.cc.vt.edu> References: <42995.1493704144@turing-police.cc.vt.edu> Message-ID: <1493720491.2227285.962859176.488FE99F@webmail.messagingengine.com> On Mon, May 1, 2017, at 10:49 PM, valdis.kletnieks at vt.edu wrote: > I didn't see any mention of this here. Any comments? > > [...] > > https://arstechnica.com/security/2017/04/russian-controlled-telecom-hijacks-financial-services-internet-traffic/ Governments mopping up signals and data isn't a new concept, and certainly not unique to the Russian Federation. Personally I'm more concerned about important people giving up passwords so easily to spearfishers. . . -- Regards, S From williamsjj at digitar.com Mon May 1 20:20:44 2017 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Mon, 1 May 2017 20:20:44 +0000 Subject: Need help from walmart.com NOC Message-ID: <8fb0071cf95349d1986fe970a22b1968@digitar.com> Hi, We run an Internet filtering service for protecting kids and folks with addiction issues. As of a couple of days ago, walmart.com stopped responding to requests (connection is formed but no response) through our filtering servers. If anyone here from Walmart could contact me off list, that would be greatly appreciated. Thank you in advance. -J From bortzmeyer at nic.fr Tue May 2 12:19:25 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 2 May 2017 14:19:25 +0200 Subject: Financial services BGP hijack last week? In-Reply-To: <42995.1493704144@turing-police.cc.vt.edu> References: <42995.1493704144@turing-police.cc.vt.edu> Message-ID: <20170502121925.yhmrd5abkogpfzhz@nic.fr> On Tue, May 02, 2017 at 01:49:04AM -0400, valdis.kletnieks at vt.edu wrote a message of 29 lines which said: > I didn't see any mention of this here. You should susbcribe to @bgpstream on Twitter, and read BGPmon blog :-) https://twitter.com/bgpstream https://bgpmon.net/bgpstream-and-the-curious-case-of-as12389/ (five days ago) From job at ntt.net Tue May 2 12:27:29 2017 From: job at ntt.net (Job Snijders) Date: Tue, 2 May 2017 14:27:29 +0200 Subject: Financial services BGP hijack last week? In-Reply-To: References: <42995.1493704144@turing-police.cc.vt.edu> Message-ID: <20170502122729.ogun2nvu47i5sqvh@Vurt.local> On Tue, May 02, 2017 at 08:29:32AM +0100, Nikos Leontsinis wrote: > it only proves the need for wider RPKI adoption.... How can we actually encourage RPKI adoption? Kind regards, Job From jharr at unomaha.edu Tue May 2 13:38:26 2017 From: jharr at unomaha.edu (James Harr) Date: Tue, 2 May 2017 13:38:26 +0000 Subject: Akamai contact Message-ID: Hi, Can someone from Akamai contact me off-list? We're having a problems accessing a testing website served from the Akamai CDN during finals week. -- James Harr Lead Network Engineer University of Nebraska at Omaha 402-554-4925 M:402-660-5466 From jharr at unomaha.edu Tue May 2 14:27:35 2017 From: jharr at unomaha.edu (James Harr) Date: Tue, 2 May 2017 14:27:35 +0000 Subject: Akamai contact In-Reply-To: References: Message-ID: Akamai contacted me off-list. Thanks! -- James Harr Lead Network Engineer University of Nebraska at Omaha 402-554-4925 M:402-660-5466 ________________________________ From: NANOG on behalf of James Harr Sent: Tuesday, May 2, 2017 8:38:26 AM To: nanog at nanog.org Subject: Akamai contact Hi, Can someone from Akamai contact me off-list? We're having a problems accessing a testing website served from the Akamai CDN during finals week. -- James Harr Lead Network Engineer University of Nebraska at Omaha 402-554-4925 M:402-660-5466 From Rich.Compton at charter.com Tue May 2 15:21:11 2017 From: Rich.Compton at charter.com (Compton, Rich A) Date: Tue, 2 May 2017 15:21:11 +0000 Subject: Financial services BGP hijack last week? In-Reply-To: <20170502122729.ogun2nvu47i5sqvh@Vurt.local> References: <42995.1493704144@turing-police.cc.vt.edu> <20170502122729.ogun2nvu47i5sqvh@Vurt.local> Message-ID: That?s the million dollar question. I think that there will be more adoption from the Internet at large when some big players adopt it. Right now the use of rsync in RPKI is preventing a lot of large ISPs from implementing it (too difficult to provide redundancy with rsync). There is a protocol called RPKI Repository Delta Protocol (RRDP) https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08 which will alleviate these concerns but it is still in draft. I think once that becomes an RFC we will see more adoption of RPKI. Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr, Englewood, CO 80112 On 5/2/17, 6:27 AM, "NANOG on behalf of Job Snijders" wrote: >On Tue, May 02, 2017 at 08:29:32AM +0100, Nikos Leontsinis wrote: >> it only proves the need for wider RPKI adoption.... > >How can we actually encourage RPKI adoption? > >Kind regards, > >Job 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 Tue May 2 16:49:10 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 2 May 2017 11:49:10 -0500 (CDT) Subject: Financial services BGP hijack last week? In-Reply-To: <20170502122729.ogun2nvu47i5sqvh@Vurt.local> References: <42995.1493704144@turing-police.cc.vt.edu> <20170502122729.ogun2nvu47i5sqvh@Vurt.local> Message-ID: <1855197592.6512.1493743748722.JavaMail.mhammett@ThunderFuck> Lower cost router platforms don't have RPKI capability. Mikrotik claims that v7 will... whenever that comes out. AFAIK, Ubiquiti doesn't support it either. Both have submitted and acknowledged feature requests for it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Job Snijders" To: "Nikos Leontsinis" Cc: nanog at nanog.org Sent: Tuesday, May 2, 2017 7:27:29 AM Subject: Re: Financial services BGP hijack last week? On Tue, May 02, 2017 at 08:29:32AM +0100, Nikos Leontsinis wrote: > it only proves the need for wider RPKI adoption.... How can we actually encourage RPKI adoption? Kind regards, Job From rod.beck at unitedcablecompany.com Tue May 2 17:24:09 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 2 May 2017 17:24:09 +0000 Subject: Old Long Haul Versus New Long Haul Fiber In-Reply-To: <1855197592.6512.1493743748722.JavaMail.mhammett@ThunderFuck> References: <42995.1493704144@turing-police.cc.vt.edu> <20170502122729.ogun2nvu47i5sqvh@Vurt.local>, <1855197592.6512.1493743748722.JavaMail.mhammett@ThunderFuck> Message-ID: I am curious how much of a performance gap exists between new long haul fiber and fiber laid during the Great Boom from 1998-2001. We are very close to 20 years. I assume there are two dimensions, namely bit carrying capacity of an individual wave and total bandwidth capacity of a fiber pair. I have been told and readily believe that fiber improvements do make a difference. But I have no sense of magnitudes. My impression is that the 1998-2001 fiber probably cannot handle above 100 gig waves and about 14 terabits per fiber pair at least on Trans-Atlantic cables. - R. www.crosslakefibre.ca www.unitedcablecompany.com From doug at sdnessentials.com Tue May 2 17:44:53 2017 From: doug at sdnessentials.com (Doug Marschke) Date: Tue, 2 May 2017 10:44:53 -0700 Subject: SD-WAN for enlightened In-Reply-To: References: <001401d2b78f$a5b69b60$f123d220$@sdnessentials.com> Message-ID: <132301d2c36b$cec21ab0$6c465010$@sdnessentials.com> Too many to list. I don?t know who is ?winning? in market share right now, as I am sure each vendor tracks their wins differently. There are definitely a few making more noise than others. Doug Marschke CTO www.sdnessentials.com JNCIE-SP #41, JNCIE-ENT #3 415-902-5702 (cell) 415-340-3112 (office) From: Colton Conor [mailto:colton.conor at gmail.com] Sent: Thursday, April 27, 2017 6:26 PM To: Doug Marschke Cc: Kasper Adel ; NANOG list Subject: Re: SD-WAN for enlightened So who are the big SD-WAN players out there? On Mon, Apr 17, 2017 at 10:31 AM, Doug Marschke > wrote: Hello Kasper, I will do my best to answer your SD-WAN question, but as you mentioned it is a buzzword that has a bit of confusion in its definitions. I would say that a SD-WAN solution should have the following elements: 1.) Ability to manage multiple WAN connection and choose the path based on user and machine criteria (The Hybrid WAN) 2.) A controller to manage the polices and operations of the SD-WAN devices 3.) Analytics on the network and application level 4.) A software overlay that abstracts and secures the underlying networks Currently there are a lot of solutions out there by many vendors. Some do all of these and some a subset, so it make the landscape a bit confusing. Lots of times vendors use SD-WAN when they are really just talking about Hybrid WAN (multiple connections) or WAN optimization. Doug Marschke CTO www.sdnessentials.com JNCIE-SP #41, JNCIE-ENT #3 415-902-5702 (cell) 415-340-3112 (office) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org ] On Behalf Of Kasper Adel Sent: Sunday, April 16, 2017 1:14 PM To: NANOG list > Subject: SD-WAN for enlightened Hi, I'm not sure if the buzzword SD-WAN is used to compensate for another buzzword that got over-utilized (SDN) or it is a true 'new and improved' way of doing things that has some innovation into it. I heard different explanation from different vendors: 1) appliances (+ controller) placed in-line to put traffic in tunnels based on policy, with some DPI and traffic tagging...(to do performance/policy based routing) over an expensive link (MPLS) and a cheap one (broadband) with some 'firewall-like' filtering capabilities. 2) same as above, with a flavor of 'machine learning' to find a pattern for traffic to optimize utilization. 3) a controller that instantiates and tears down tunnels from 'classic routers' based on external policies and Network based features to do performance based routing over an expensive link (MPLS) and a cheap one (broadband) with encryption. Is the above a decent high-level summary? Has anyone tried any of these solutions, any general feedback ? Cheers, Kim From netfortius at gmail.com Tue May 2 18:19:03 2017 From: netfortius at gmail.com (Stefan) Date: Tue, 2 May 2017 13:19:03 -0500 Subject: SD-WAN for enlightened In-Reply-To: <132301d2c36b$cec21ab0$6c465010$@sdnessentials.com> References: <001401d2b78f$a5b69b60$f123d220$@sdnessentials.com> <132301d2c36b$cec21ab0$6c465010$@sdnessentials.com> Message-ID: As of this announcement: http://investor.cisco.com/investor-relations/news-and-events/news/news-details/2017/Cisco-Announces-Intent-to-Acquire-Viptela/default.aspx there will be one less than before :-) Seriously - when I first learned about them, upon service inclusion of the Viptela products into the VzB SD-WAN offering, they (Viptela - http://blog.ipspace.net/2014/11/viptela-sen-hybrid-wan-connectivity.html) looked very nice, already, as standalone products. And that was a few years back. ***Stefan On Tue, May 2, 2017 at 12:44 PM, Doug Marschke wrote: > Too many to list. I don?t know who is ?winning? in market share right > now, as I am sure each vendor tracks their wins differently. > > There are definitely a few making more noise than others. > > Doug Marschke > > CTO > > www.sdnessentials.com > > JNCIE-SP #41, JNCIE-ENT #3 > > 415-902-5702 (cell) > > 415-340-3112 (office) > > > > From: Colton Conor [mailto:colton.conor at gmail.com] > Sent: Thursday, April 27, 2017 6:26 PM > To: Doug Marschke > Cc: Kasper Adel ; NANOG list > Subject: Re: SD-WAN for enlightened > > > > So who are the big SD-WAN players out there? > > > > On Mon, Apr 17, 2017 at 10:31 AM, Doug Marschke > wrote: > > Hello Kasper, > > I will do my best to answer your SD-WAN question, but as you mentioned it > is a buzzword that has a bit of confusion in its definitions. I would say > that a SD-WAN solution should have the following elements: > > 1.) Ability to manage multiple WAN connection and choose the path based on > user and machine criteria (The Hybrid WAN) > 2.) A controller to manage the polices and operations of the SD-WAN devices > 3.) Analytics on the network and application level > 4.) A software overlay that abstracts and secures the underlying networks > > Currently there are a lot of solutions out there by many vendors. Some do > all of these and some a subset, so it make the landscape a bit confusing. > Lots of times vendors use SD-WAN when they are really just talking about > Hybrid WAN (multiple connections) or WAN optimization. > > > > > > Doug Marschke > CTO > www.sdnessentials.com > JNCIE-SP #41, JNCIE-ENT #3 > 415-902-5702 (cell) > 415-340-3112 (office) > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org org> ] On Behalf Of Kasper Adel > Sent: Sunday, April 16, 2017 1:14 PM > To: NANOG list > > Subject: SD-WAN for enlightened > > Hi, > > I'm not sure if the buzzword SD-WAN is used to compensate for another > buzzword that got over-utilized (SDN) or it is a true 'new and improved' > way of doing things that has some innovation into it. > > I heard different explanation from different vendors: > > 1) appliances (+ controller) placed in-line to put traffic in tunnels > based on policy, with some DPI and traffic tagging...(to do > performance/policy based routing) over an expensive link (MPLS) and a cheap > one (broadband) with some 'firewall-like' filtering capabilities. > 2) same as above, with a flavor of 'machine learning' to find a pattern > for traffic to optimize utilization. > 3) a controller that instantiates and tears down tunnels from 'classic > routers' based on external policies and Network based features to do > performance based routing over an expensive link (MPLS) and a cheap one > (broadband) with encryption. > > Is the above a decent high-level summary? > > Has anyone tried any of these solutions, any general feedback ? > > Cheers, > Kim > > > > From mattlists at rivervalleyinternet.net Tue May 2 21:14:09 2017 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 2 May 2017 17:14:09 -0400 Subject: Frontier Message-ID: I need a network administrator from Frontier to contact me ASAP regarding BGP advertisement of a block that needs to stop please. We are down. Have been told it will be several days until restoration. And frontier is advertising our ips so I can't even advertise them out a different route. The NOC had been completely unhelpful. 570-707-3000 mhoppes at rivervalleyinternet.net From randy at psg.com Tue May 2 23:43:52 2017 From: randy at psg.com (Randy Bush) Date: Wed, 03 May 2017 08:43:52 +0900 Subject: Financial services BGP hijack last week? In-Reply-To: <20170502122729.ogun2nvu47i5sqvh@Vurt.local> References: <42995.1493704144@turing-police.cc.vt.edu> <20170502122729.ogun2nvu47i5sqvh@Vurt.local> Message-ID: >> it only proves the need for wider RPKI adoption.... > How can we actually encourage RPKI adoption? http://certification-stats.ripe.net/ tim, oleg, alex, ..., the ripe/ncc team, and the ripe community have worked very hard to make it easy, and the numbers show their success. lacnic even more so when looked at as a percentage (not shown at the above url); i.e. they have approximately 25% coverage; also due to solid policy, community, and technical work. arin has made it very difficult for a large and important segment of their membeship, and the numbers show their negative success. the other regions are asleep. but the rpki is only part of the equation. to be pedantic, The RPKI is the X.509 based hierarchy [rfc 6481] with is congruent with the internet IP address allocation administration, the IANA, RIRS, ISPs, ... It is the substrate on which the next two are based. It is currently deployed in all five administrative regions. RPKI-based Origin Validation [rfc 6811] uses the RPKI data to allow a router to verify that the autonomous system announcing an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it should prevent the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakistani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from many vendors. Path validation, a downstream technology just finishing standardisation, uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to formally cryptographically validate that the originating autonomous system was truly authorized to announce the IP address prefix, and that the systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. one blocker for origin validation deployment today is lack of solid testing of vendors' implementations; and one is known to be sorely mis-implemented. there is work to be done. as stephane pointed out, if you want to be overwhelmed with tweets or email, subscribe to the feed of mis- originations at andree's http://bgpmon.net/. as the sea level rises, maybe we'll do more about this problem. randy From morrowc.lists at gmail.com Wed May 3 00:34:24 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 May 2017 20:34:24 -0400 Subject: Financial services BGP hijack last week? In-Reply-To: References: <42995.1493704144@turing-police.cc.vt.edu> <20170502122729.ogun2nvu47i5sqvh@Vurt.local> Message-ID: On Tue, May 2, 2017 at 11:21 AM, Compton, Rich A wrote: > That?s the million dollar question. I think that there will be more > adoption from the Internet at large when some big players adopt it. Right > now the use of rsync in RPKI is preventing a lot of large ISPs from > implementing it (too difficult to provide redundancy with rsync). There is > how is it hard to provide redundancy with rsync? From randy at psg.com Wed May 3 00:47:06 2017 From: randy at psg.com (Randy Bush) Date: Wed, 03 May 2017 09:47:06 +0900 Subject: Financial services BGP hijack last week? In-Reply-To: References: <42995.1493704144@turing-police.cc.vt.edu> <20170502122729.ogun2nvu47i5sqvh@Vurt.local> Message-ID: > the use of rsync in RPKI is preventing a lot of large ISPs from > implementing it (too difficult to provide redundancy with > rsync). uh, at least the DRL implementation supports caches feeding off of caches in (if you are silly enough) an arbitrarily complex graph. some years back, our research group actually used large clusters to emulate large deployments with multi-level caching and found it quite efficient. see Olaf Maennel, Iain Phillips, Debbie Perouli, Randy Bush, Rob Austein, and Askar Jaboldinov, "Towards a Framework for Evaluating BGP Security," CSET'12, 5th Workshop on Cyber Security Experimentation and Test. https://www.usenix.org/system/files/conference/cset12/cset12-final19.pdf randy From edugas at unknowndevice.ca Wed May 3 01:09:26 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 2 May 2017 21:09:26 -0400 Subject: Frontier In-Reply-To: References: Message-ID: I hope someone contacted you off-list because their NOC's answer was unacceptable. Pretty sure it's a human error and not malicious but network operators have to react quickly to this type of issue. Several days? Even several hours is a ridiculous response time. Contact their upstream providers and mention they (the upstream) are not doing their job by filtering their customer's BGP announcements. Contact IXes (if they're connected to any), peers, etc. Rinse and repeat. At last, threaten them with legal actions by sending angry emails or calls to senior ops/management/marketing/legal department. On May 2, 2017 17:14, "Matt Hoppes" wrote: I need a network administrator from Frontier to contact me ASAP regarding BGP advertisement of a block that needs to stop please. We are down. Have been told it will be several days until restoration. And frontier is advertising our ips so I can't even advertise them out a different route. The NOC had been completely unhelpful. 570-707-3000 mhoppes at rivervalleyinternet.net From mattlists at rivervalleyinternet.net Wed May 3 01:27:06 2017 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 2 May 2017 21:27:06 -0400 Subject: Frontier In-Reply-To: References: Message-ID: Someone did. Unfortunately response time through frontiers NOC seems to have gotten terrible since the acquisition of many Verizon properties. When ever we have issues it's the norm to wait two to four hours before we hear anything back and often the NOC scrambles the information. 50% of the time when we call in for ticket updates the ticket has been closed or can't be found. Hang up. Call back now it's found. And several times the ticket had been closed without confirming with the end user the issue has actually been fixed. It's terrible. > On May 2, 2017, at 9:09 PM, Eric Dugas wrote: > > I hope someone contacted you off-list because their NOC's answer was unacceptable. > > Pretty sure it's a human error and not malicious but network operators have to react quickly to this type of issue. > > Several days? Even several hours is a ridiculous response time. Contact their upstream providers and mention they (the upstream) are not doing their job by filtering their customer's BGP announcements. Contact IXes (if they're connected to any), peers, etc. Rinse and repeat. > > At last, threaten them with legal actions by sending angry emails or calls to senior ops/management/marketing/legal department. > > On May 2, 2017 17:14, "Matt Hoppes" wrote: > I need a network administrator from Frontier to contact me ASAP regarding BGP advertisement of a block that needs to stop please. > > We are down. Have been told it will be several days until restoration. And frontier is advertising our ips so I can't even advertise them out a different route. > > The NOC had been completely unhelpful. > > 570-707-3000 > mhoppes at rivervalleyinternet.net > From clane1875 at gmail.com Wed May 3 12:27:41 2017 From: clane1875 at gmail.com (Chris Lane) Date: Wed, 3 May 2017 08:27:41 -0400 Subject: GEO LOCATION Message-ID: All We have several direct allocations from ARIN which we then provide smaller prefixes to our customers across the country. Our HQ is on the East coast, but many of our customers are on the West Coast. Trying to understand and fix some of my west coast customers GEO LOCATION issues as they are reporting for instance when running "speed tests" to Internet sites the location pops up as an East Coast server instead of West and more local. Any help would be appreciated Thank you Chris From josh at imaginenetworksllc.com Wed May 3 12:31:37 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 3 May 2017 08:31:37 -0400 Subject: GEO LOCATION In-Reply-To: References: Message-ID: Speedtest.net uses Maxmind I believe. You can correct it on their website. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On May 3, 2017 8:29 AM, "Chris Lane" wrote: > All > > We have several direct allocations from ARIN which we then provide smaller > prefixes to our customers across the country. Our HQ is on the East coast, > but many of our customers are on the West Coast. Trying to understand and > fix some of my west coast customers GEO LOCATION issues as they are > reporting for instance when running "speed tests" to Internet sites the > location pops up as an East Coast server instead of West and more local. > > Any help would be appreciated > > Thank you > Chris > From jared at puck.nether.net Wed May 3 12:32:48 2017 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 3 May 2017 08:32:48 -0400 Subject: GEO LOCATION In-Reply-To: References: Message-ID: <7D1AAC17-0C4B-4BAF-80B5-E0C41691C979@puck.nether.net> > On May 3, 2017, at 8:27 AM, Chris Lane wrote: > > All > > We have several direct allocations from ARIN which we then provide smaller > prefixes to our customers across the country. Our HQ is on the East coast, > but many of our customers are on the West Coast. Trying to understand and > fix some of my west coast customers GEO LOCATION issues as they are > reporting for instance when running "speed tests" to Internet sites the > location pops up as an East Coast server instead of West and more local. A number of CDNs use tools like the DNS server/query source to identify where the clients are. If they are all using a centralized DNS server, some providers will classify you as in one area vs another. Consider using a different DNS query-source for east coast vs west coast users. Consider using tools like ECS (EDNS0-Client-Subnet) if possible to provide hints to the various CDNs/Geolocation folks. If you?re aware of a specific mis-charachtherisation, consider posting the relevant DNS server information or IP ranges involved. If you don?t know how to find your DNS server query-source, a tool like this: https://cmdns.dev.dns-oarc.net/ Will help you find the information easily. - Jared From Rich.Compton at charter.com Wed May 3 17:39:02 2017 From: Rich.Compton at charter.com (Compton, Rich A) Date: Wed, 3 May 2017 17:39:02 +0000 Subject: Financial services BGP hijack last week? In-Reply-To: References: <42995.1493704144@turing-police.cc.vt.edu> <20170502122729.ogun2nvu47i5sqvh@Vurt.local> Message-ID: The servers where the RPKI data is published (the Trust Anchor and the CAs) are referred to using a single URI, meaning that any sort of geographic redundancy or failover has to be handled via external means (anycast, load balancing, etc.) but rsync isn?t well-suited for this sort of implementation. [cid:DE8A0963-605D-4E57-8A58-E154EF0E790C] Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr, Englewood, CO 80112 From: > on behalf of Christopher Morrow > Date: Tuesday, May 2, 2017 at 6:34 PM To: Compton Rich A > Cc: Job Snijders >, Nikos Leontsinis >, NANOG list > Subject: Re: Financial services BGP hijack last week? On Tue, May 2, 2017 at 11:21 AM, Compton, Rich A > wrote: That?s the million dollar question. I think that there will be more adoption from the Internet at large when some big players adopt it. Right now the use of rsync in RPKI is preventing a lot of large ISPs from implementing it (too difficult to provide redundancy with rsync). There is how is it hard to provide redundancy with rsync? 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 morrowc.lists at gmail.com Wed May 3 17:46:25 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 3 May 2017 13:46:25 -0400 Subject: Financial services BGP hijack last week? In-Reply-To: References: <42995.1493704144@turing-police.cc.vt.edu> <20170502122729.ogun2nvu47i5sqvh@Vurt.local> Message-ID: On Wed, May 3, 2017 at 1:39 PM, Compton, Rich A wrote: > The servers where the RPKI data is published (the Trust Anchor and the > CAs) are referred to using a single URI, meaning that any > sure, but even with rrdp there's just one URI you'd follow, which translates to some hostname + path. > sort of geographic redundancy or failover has to be handled via external > means (anycast, load balancing, etc.) but rsync isn?t well-suited for this > sort of implementation. > why's that? it seems to work fine for many free software repositories, for instance. Yes, updates to that repository would have to be 'managed' but that's also the case for rrdp, or any other 'more than one copy' solutions of publicly available data, right? https://github.com/google/rpki-mgmt/ does some of the lifting to sort out the 'how to get my updates to all the copies of my repository'... it doesn't yet support RRDP, but it's not hard to see where to stick that in the config/setup. From hannigan at gmail.com Thu May 4 04:31:49 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 4 May 2017 00:31:49 -0400 Subject: Retarus (AS 48328) Message-ID: I hate to do this, but I have exhausted _all of my sources of data including the SOA (points at VRSN) and domain name contact addresses for: Registrant Name: Retarus GmbH Registrant Organization: Retarus GmbH Registrant Street: Aschauerstrasse 30 Registrant City: Muenchen Registrant State/Province: Bav Registrant Postal Code: 81549 Registrant Country: DE I worked backwards from a domain name of RMX.DE. I don't know what the distinction is other than this name perhaps being an operational domain for their mail security services. If someone has a pointer or can do an offline introduction to someone in tech-ops or networking there, I'd appreciate it. Best, -M< From Lars.Andersson at fiberdata.se Thu May 4 11:02:31 2017 From: Lars.Andersson at fiberdata.se (Lars Andersson) Date: Thu, 4 May 2017 11:02:31 +0000 Subject: Question regarding geolocation In-Reply-To: <984ce10253ac4812b2d21f03119e5126@elara.ad.fiberdata.se> References: <984ce10253ac4812b2d21f03119e5126@elara.ad.fiberdata.se> Message-ID: <0a24c7a6af674e81863a2fc23fca2f05@elara.ad.fiberdata.se> Hello, I am helping a small Service Provider in Sweden and we have some issues with IP addresses having the wrong country in geolocation. They show up as Norwegian even though they should be Swedish. The site we have most problems with and try to solve is HBO. Can anyone maybe give some input as to how HBO update their geolocation info? Maybe a certain geolocation provider? We have contacted RIPE and they have acknowledged our addresses in the RIPE database as correctly setup with country object as SE. Furthermore the geolocation providers/sites we checked which show the correct info are ip2location, amakai, maxmind, ipinfo.io and EurekAPI. If anyone from HBO see this mail I would appreciate an off list response. Best regards Lars Andersson, Fiberdata From matt.torres at state.or.us Thu May 4 12:46:42 2017 From: matt.torres at state.or.us (Torres, Matt) Date: Thu, 4 May 2017 12:46:42 +0000 Subject: Ingress filtering from an external cloud service to the internal network Message-ID: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3BEC0@ExchMBXProd02.win.lottery.state.or.us> NANOG, We have a hybrid cloud model that includes an external cloud service that needs to reach back into our internal network. The application documentation states that this connection cannot go through a proxy server. I am not in a position to redesign this solution or change the parameters. My question to NANOG is how to manage (filter/secure) the ingress traffic from the external cloud service. Past network guy managed inbound firewall rules based on the cloud-providers source IP address, but this wasn't sustainable and led to multiple outages as the external (source) IP has changed from time to time. I can define the destination ports well enough, but not the source IP addresses. Any ideas on how I can filter this type of inbound traffic from an internet-based service? Thanks Matt From nikosietf at gmail.com Thu May 4 11:06:53 2017 From: nikosietf at gmail.com (Nikos Leontsinis) Date: Thu, 4 May 2017 12:06:53 +0100 Subject: [NANOG] In-Reply-To: References: <42995.1493704144@turing-police.cc.vt.edu> <20170502122729.ogun2nvu47i5sqvh@Vurt.local> Message-ID: You can use rpki without even touching your network just by enabling the ROAs today in the RIPE database. This is a harmless piece of work that you can do today helping the wider community and raise awareness as a first step. /nikos On 2 May 2017 at 16:21, Compton, Rich A wrote: > That? the million dollar question. I think that there will be more > adoption from the Internet at large when some big players adopt it. Right > now the use of rsync in RPKI is preventing a lot of large ISPs from > implementing it (too difficult to provide redundancy with rsync). There is > a protocol called RPKI Repository Delta Protocol (RRDP) > https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08 which will > alleviate these concerns but it is still in draft. I think once that > becomes an RFC we will see more adoption of RPKI. > > > > Rich Compton | Principal Eng | 314.596.2828 > 14810 Grasslands Dr, Englewood, CO 80112 > > > > > > > On 5/2/17, 6:27 AM, "NANOG on behalf of Job Snijders" > wrote: > >>On Tue, May 02, 2017 at 08:29:32AM +0100, Nikos Leontsinis wrote: >>> it only proves the need for wider RPKI adoption.... >> >>How can we actually encourage RPKI adoption? >> >>Kind regards, >> >>Job > > 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 James at arenalgroup.co Thu May 4 15:26:49 2017 From: James at arenalgroup.co (James Breeden) Date: Thu, 4 May 2017 15:26:49 +0000 Subject: Ingress filtering from an external cloud service to the internal network In-Reply-To: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3BEC0@ExchMBXProd02.win.lottery.state.or.us> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3BEC0@ExchMBXProd02.win.lottery.state.or.us> Message-ID: Is it possible for you to get a private/direct connect service from your network perimeter to the cloud provider and eliminate using the public connectivity? Or because its Internet-based you have to use public connectivity? James W. Breeden Managing Partner Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | www.arenalgroup.co -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Torres, Matt Sent: Thursday, May 4, 2017 7:47 AM To: nanog at nanog.org Subject: Ingress filtering from an external cloud service to the internal network NANOG, We have a hybrid cloud model that includes an external cloud service that needs to reach back into our internal network. The application documentation states that this connection cannot go through a proxy server. I am not in a position to redesign this solution or change the parameters. My question to NANOG is how to manage (filter/secure) the ingress traffic from the external cloud service. Past network guy managed inbound firewall rules based on the cloud-providers source IP address, but this wasn't sustainable and led to multiple outages as the external (source) IP has changed from time to time. I can define the destination ports well enough, but not the source IP addresses. Any ideas on how I can filter this type of inbound traffic from an internet-based service? Thanks Matt From jneiberger at gmail.com Thu May 4 17:25:21 2017 From: jneiberger at gmail.com (John Neiberger) Date: Thu, 4 May 2017 11:25:21 -0600 Subject: Need someone from CenturyLink to fix urgent routing issue Message-ID: Could someone from CenturyLink reach out to me off-list, please? You are currently hijacking some of our space and it is causing an active outage for many customers. We have someone calling in to CL support, as well, but we typically get a basic help desk that is slow to respond and this is a bit more urgent. Thanks! John From eric.kuhnke at gmail.com Thu May 4 18:33:01 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 4 May 2017 11:33:01 -0700 Subject: Geolocation of o3b satellite end user terminals Message-ID: Since today seems like the day for IP geolocation related topics... Does anyone have direct experience with third-party IP geolocation services and o3b served enterprise/ISP-type high capacity customers? For those who are not familiar with them, o3b satellite terminals can be located literally anywhere in the world below 45 degrees north or south latitude, served from a fleet of MEO satellites. Each terminal is a twin pair of motorized/tracking antennas and associated modems, etc with an IP/Ethernet hand off to the customer. Their gateways to the Internet are located in about a dozen places around the globe and ordinarily go out to the Internet through o3b's own IP network. From bz_siege_01 at hotmail.com Thu May 4 20:39:16 2017 From: bz_siege_01 at hotmail.com (c b) Date: Thu, 4 May 2017 20:39:16 +0000 Subject: Need recommendation on an affordable internet edge router Message-ID: We have a number of internet edge routers across several data centers approaching EOL/EOS, and are budgeting for replacements. Like most enterprises, we have been Cisco-centric in our routing/switching platforms. The ASR1Ks are too small for our needs and the ASR9Ks are prohibitively expensive and probably overkill. That being said, our IT staff is willing to look at other vendors if they are the right fit. Requirements: * Can handle full internet tables, both v4 and v6 with room for reasonable growth over the next 5 years. * VRF capability. * About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if they are 1Gb/10Gb select-rate ports.) * Full-Feature BGP (address-families, communities, peer-groups, etc...) * Used by carriers or large enterprises in a production role for at least a year (and not causing ulcers) * Affordable. I know that's subjective, but we need a solution that is as close as possible to commodity-pricing if this modernization effort balloons to include all of our data centers. We are open to named vendors and even so-called brite-box solutions. A little nervous about fringe solutions like pure whitebox with Quagga, but if the savings are there and people can vouch for it, we will consider it. In other words, if you've used it and stand by it, we value that input and will put it on the initial list. Also, if you chose solution-X after comparing it to solution-Y it would be very helpful to detail what you tested and why you chose. Thanks in advance. From job at instituut.net Thu May 4 20:47:34 2017 From: job at instituut.net (Job Snijders) Date: Thu, 04 May 2017 20:47:34 +0000 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: Message-ID: What have you compared so far yourself? Job On Thu, 4 May 2017 at 22:40, c b wrote: > We have a number of internet edge routers across several data centers > approaching EOL/EOS, and are budgeting for replacements. Like most > enterprises, we have been Cisco-centric in our routing/switching platforms. > The ASR1Ks are too small for our needs and the ASR9Ks are prohibitively > expensive and probably overkill. That being said, our IT staff is willing > to look at other vendors if they are the right fit. > > > Requirements: > > * Can handle full internet tables, both v4 and v6 with room for > reasonable growth over the next 5 years. > * VRF capability. > * About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if they > are 1Gb/10Gb select-rate ports.) > * Full-Feature BGP (address-families, communities, peer-groups, etc...) > * Used by carriers or large enterprises in a production role for at > least a year (and not causing ulcers) > * Affordable. I know that's subjective, but we need a solution that is > as close as possible to commodity-pricing if this modernization effort > balloons to include all of our data centers. > > We are open to named vendors and even so-called brite-box solutions. A > little nervous about fringe solutions like pure whitebox with Quagga, but > if the savings are there and people can vouch for it, we will consider it. > > In other words, if you've used it and stand by it, we value that input and > will put it on the initial list. Also, if you chose solution-X after > comparing it to solution-Y it would be very helpful to detail what you > tested and why you chose. > > Thanks in advance. > > From baldur.norddahl at gmail.com Thu May 4 21:12:12 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 4 May 2017 23:12:12 +0200 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: Message-ID: The ZTE 9000-2E4 might be fit for your requirements and affordable. http://wwwen.zte.com.cn/endata/magazine/ztetechnologies/2016/no5/articles/201609/t20160912_460444.html Den 4. maj 2017 22.40 skrev "c b" : We have a number of internet edge routers across several data centers approaching EOL/EOS, and are budgeting for replacements. Like most enterprises, we have been Cisco-centric in our routing/switching platforms. The ASR1Ks are too small for our needs and the ASR9Ks are prohibitively expensive and probably overkill. That being said, our IT staff is willing to look at other vendors if they are the right fit. Requirements: * Can handle full internet tables, both v4 and v6 with room for reasonable growth over the next 5 years. * VRF capability. * About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if they are 1Gb/10Gb select-rate ports.) * Full-Feature BGP (address-families, communities, peer-groups, etc...) * Used by carriers or large enterprises in a production role for at least a year (and not causing ulcers) * Affordable. I know that's subjective, but we need a solution that is as close as possible to commodity-pricing if this modernization effort balloons to include all of our data centers. We are open to named vendors and even so-called brite-box solutions. A little nervous about fringe solutions like pure whitebox with Quagga, but if the savings are there and people can vouch for it, we will consider it. In other words, if you've used it and stand by it, we value that input and will put it on the initial list. Also, if you chose solution-X after comparing it to solution-Y it would be very helpful to detail what you tested and why you chose. Thanks in advance. From saku at ytti.fi Thu May 4 21:43:16 2017 From: saku at ytti.fi (Saku Ytti) Date: Fri, 5 May 2017 00:43:16 +0300 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: Message-ID: On 4 May 2017 at 23:39, c b wrote: > * Affordable. I know that's subjective, but we need a solution that is as close as possible to commodity-pricing if this modernization effort balloons to include all of our data centers. How many? For any non-trivial volume devices with equal ports and features tend to cost the same from every vendor. Unfortunately your density requirements are very modest. Also are you sure you are as price sensitive as you think you are? I.e. maybe not look just your BU's budget, but impact on bottom line. Since saving here some, may end up costing in OPEX significantly more over time, and that case may be easier to make than you think. Usually router/switch CAPEX isn't even a blip in enterprises bottom line. But you probably should review at least: - Juniper MX204, MX480 - Cisco ASR9k - Huawei NE20, NE40 - Alcatel 7750SR Personally I'm bit worried about Cisco's transition to newish OS and new linecard architecture. Might come out good, might have some rearing issues. Alcatel is expensive to automate, as you cannot ship it new full config and have it roll-forward to it from old config. I am also worried that they are essentially developing their own booting OS, instead of developing routing suite on existing OS, I'm not sure if that is good investment of engineering hours, and if that's reason why they're stuck in PowerPC, while others rock XEON. However Alcatel's SMP capability is probably currently best of the bunch. All of the stated options are NPU/run-to-completion boxes which have higher port-price and better features than pipeline boxes. However pipeline boxes are far denser and cheaper per port, but from your POV they'll be even more expensive as your density requirement is so modest. You have no stated features which couldn't be met by their pipeline portfolios, so if you had the scale, pipeline box, like PTX1k or any of the BRCM Jericho boxes might be more interesting to you. -- ++ytti From bz_siege_01 at hotmail.com Thu May 4 22:04:21 2017 From: bz_siege_01 at hotmail.com (c b) Date: Thu, 4 May 2017 22:04:21 +0000 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: , Message-ID: The ASR9k is certainly up to the task and it's one of the few we looked at initially, but the pricing is nowhere near commodity even if we got a minimal build. As far as volume, the initial purchase for this round of budget will be an HA pair. If the solution works well, we have potential to replace 12 or so throughout FY17, maybe into FY18. Lots of responses very quickly, thanks. Definitely appreciate the suggestions from people who have selected and operated. ________________________________ From: Saku Ytti Sent: Thursday, May 4, 2017 2:43 PM To: c b Cc: nanog at nanog.org Subject: Re: Need recommendation on an affordable internet edge router On 4 May 2017 at 23:39, c b wrote: > * Affordable. I know that's subjective, but we need a solution that is as close as possible to commodity-pricing if this modernization effort balloons to include all of our data centers. How many? For any non-trivial volume devices with equal ports and features tend to cost the same from every vendor. Unfortunately your density requirements are very modest. Also are you sure you are as price sensitive as you think you are? I.e. maybe not look just your BU's budget, but impact on bottom line. Since saving here some, may end up costing in OPEX significantly more over time, and that case may be easier to make than you think. Usually router/switch CAPEX isn't even a blip in enterprises bottom line. But you probably should review at least: - Juniper MX204, MX480 - Cisco ASR9k - Huawei NE20, NE40 - Alcatel 7750SR Personally I'm bit worried about Cisco's transition to newish OS and new linecard architecture. Might come out good, might have some rearing issues. Alcatel is expensive to automate, as you cannot ship it new full config and have it roll-forward to it from old config. I am also worried that they are essentially developing their own booting OS, instead of developing routing suite on existing OS, I'm not sure if that is good investment of engineering hours, and if that's reason why they're stuck in PowerPC, while others rock XEON. However Alcatel's SMP capability is probably currently best of the bunch. All of the stated options are NPU/run-to-completion boxes which have higher port-price and better features than pipeline boxes. However pipeline boxes are far denser and cheaper per port, but from your POV they'll be even more expensive as your density requirement is so modest. You have no stated features which couldn't be met by their pipeline portfolios, so if you had the scale, pipeline box, like PTX1k or any of the BRCM Jericho boxes might be more interesting to you. -- ++ytti From saku at ytti.fi Thu May 4 22:10:29 2017 From: saku at ytti.fi (Saku Ytti) Date: Fri, 5 May 2017 01:10:29 +0300 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: Message-ID: On 5 May 2017 at 01:04, c b wrote: Hey, > The ASR9k is certainly up to the task and it's one of the few we looked at > initially, but the pricing is nowhere near commodity even if we got a > minimal build. What is commodity? Where are you comparing it to which satisfies your requirements? > As far as volume, the initial purchase for this round of budget will be an > HA pair. If the solution works well, we have potential to replace 12 or so > throughout FY17, maybe into FY18. Yeah sales droids likely won't be interested in 2 at all. But if you commit on those 12, even if you'll order them separately. I think that's something sales droid will care about, and you'll have negotiation leverage as you can keep bouncing between several vendors seeing who gets your business. You should really expect at least 70% discount on 12 units, 80% would be good. Under 70% would be walk out the room. -- ++ytti From draganj84 at gmail.com Thu May 4 22:20:16 2017 From: draganj84 at gmail.com (Dragan Jovicic) Date: Fri, 5 May 2017 00:20:16 +0200 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: Message-ID: Hi, > But you probably should review at least: > - Juniper MX204, MX480 > - Cisco ASR9k > - Huawei NE20, NE40 > - Alcatel 7750SR > Having all of these somewhere in our network, and my heart being with JNPR boxes, I'll say have a look at Huawei offerings. +Dragan On Fri, May 5, 2017 at 12:10 AM, Saku Ytti wrote: > On 5 May 2017 at 01:04, c b wrote: > > Hey, > > > The ASR9k is certainly up to the task and it's one of the few we looked > at > > initially, but the pricing is nowhere near commodity even if we got a > > minimal build. > > What is commodity? Where are you comparing it to which satisfies your > requirements? > > > As far as volume, the initial purchase for this round of budget will be > an > > HA pair. If the solution works well, we have potential to replace 12 or > so > > throughout FY17, maybe into FY18. > > Yeah sales droids likely won't be interested in 2 at all. But if you > commit on those 12, even if you'll order them separately. I think > that's something sales droid will care about, and you'll have > negotiation leverage as you can keep bouncing between several vendors > seeing who gets your business. > You should really expect at least 70% discount on 12 units, 80% would > be good. Under 70% would be walk out the room. > > -- > ++ytti > From bz_siege_01 at hotmail.com Thu May 4 22:26:08 2017 From: bz_siege_01 at hotmail.com (c b) Date: Thu, 4 May 2017 22:26:08 +0000 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: , Message-ID: Can someone toss in a brief testimonial for huawei? In the US, I never hear that name in enterprise space, only in carriers. No idea what day-to-day ops or support is like with that vendor. All the others I am quite familiar with to one degree or another. ________________________________ From: Dragan Jovicic Sent: Thursday, May 4, 2017 3:20 PM To: Saku Ytti Cc: c b; nanog at nanog.org Subject: Re: Need recommendation on an affordable internet edge router Hi, But you probably should review at least: - Juniper MX204, MX480 - Cisco ASR9k - Huawei NE20, NE40 - Alcatel 7750SR Having all of these somewhere in our network, and my heart being with JNPR boxes, I'll say have a look at Huawei offerings. +Dragan On Fri, May 5, 2017 at 12:10 AM, Saku Ytti > wrote: On 5 May 2017 at 01:04, c b > wrote: Hey, > The ASR9k is certainly up to the task and it's one of the few we looked at > initially, but the pricing is nowhere near commodity even if we got a > minimal build. What is commodity? Where are you comparing it to which satisfies your requirements? > As far as volume, the initial purchase for this round of budget will be an > HA pair. If the solution works well, we have potential to replace 12 or so > throughout FY17, maybe into FY18. Yeah sales droids likely won't be interested in 2 at all. But if you commit on those 12, even if you'll order them separately. I think that's something sales droid will care about, and you'll have negotiation leverage as you can keep bouncing between several vendors seeing who gets your business. You should really expect at least 70% discount on 12 units, 80% would be good. Under 70% would be walk out the room. -- ++ytti From tshaw at oitc.com Thu May 4 22:30:54 2017 From: tshaw at oitc.com (TR Shaw) Date: Thu, 4 May 2017 18:30:54 -0400 Subject: Geolocation of o3b satellite end user terminals In-Reply-To: References: Message-ID: <318333AD-D525-4E31-A8A4-C01057EC7125@oitc.com> My limited experience is that you get the location of the gateway the traffic it coming out of. This is very similar to the locations returned for Motorola Canopy, Ubiquity and other wireless networks. Similar to IP location for cell. > On May 4, 2017, at 2:33 PM, Eric Kuhnke wrote: > > Since today seems like the day for IP geolocation related topics... > > Does anyone have direct experience with third-party IP geolocation services > and o3b served enterprise/ISP-type high capacity customers? > > For those who are not familiar with them, o3b satellite terminals can be > located literally anywhere in the world below 45 degrees north or south > latitude, served from a fleet of MEO satellites. Each terminal is a twin > pair of motorized/tracking antennas and associated modems, etc with an > IP/Ethernet hand off to the customer. > > Their gateways to the Internet are located in about a dozen places around > the globe and ordinarily go out to the Internet through o3b's own IP > network. From math at sizone.org Thu May 4 23:25:18 2017 From: math at sizone.org (Ken Chase) Date: Thu, 4 May 2017 19:25:18 -0400 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: Message-ID: <20170504232518.GC5709@sizone.org> anyone have thoughts about/experience with the Arista 7280R / their flexroute engine? /kc On Thu, May 04, 2017 at 08:39:16PM +0000, c b said: >We have a number of internet edge routers across several data centers approaching EOL/EOS, and are budgeting for replacements. Like most enterprises, we have been Cisco-centric in our routing/switching platforms. The ASR1Ks are too small for our needs and the ASR9Ks are prohibitively expensive and probably overkill. That being said, our IT staff is willing to look at other vendors if they are the right fit. > > >Requirements: > > * Can handle full internet tables, both v4 and v6 with room for reasonable growth over the next 5 years. > * VRF capability. > * About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if they are 1Gb/10Gb select-rate ports.) > * Full-Feature BGP (address-families, communities, peer-groups, etc...) > * Used by carriers or large enterprises in a production role for at least a year (and not causing ulcers) > * Affordable. I know that's subjective, but we need a solution that is as close as possible to commodity-pricing if this modernization effort balloons to include all of our data centers. > >We are open to named vendors and even so-called brite-box solutions. A little nervous about fringe solutions like pure whitebox with Quagga, but if the savings are there and people can vouch for it, we will consider it. > >In other words, if you've used it and stand by it, we value that input and will put it on the initial list. Also, if you chose solution-X after comparing it to solution-Y it would be very helpful to detail what you tested and why you chose. > >Thanks in advance. > -- Ken Chase - math at sizone.org Guelph Canada From tyler at tgconrad.com Fri May 5 00:55:54 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Thu, 4 May 2017 18:55:54 -0600 Subject: Need recommendation on an affordable internet edge router In-Reply-To: <20170504232518.GC5709@sizone.org> References: <20170504232518.GC5709@sizone.org> Message-ID: I use the 7280R in production. Love it. Pros: Cheap, fantastic API, can take (current) full tables of v4 and v6. 6x100G w 48x1/10G gives lots of flexibility. Cons: Lack of proper VRF support and minimal bgp address families. (If you want strict isolation, or can use a separate device for route leaking, they can still do most of what we want). On Thursday, May 4, 2017, Ken Chase wrote: > anyone have thoughts about/experience with the Arista 7280R / their > flexroute engine? > > /kc > > On Thu, May 04, 2017 at 08:39:16PM +0000, c b said: > >We have a number of internet edge routers across several data centers > approaching EOL/EOS, and are budgeting for replacements. Like most > enterprises, we have been Cisco-centric in our routing/switching platforms. > The ASR1Ks are too small for our needs and the ASR9Ks are prohibitively > expensive and probably overkill. That being said, our IT staff is willing > to look at other vendors if they are the right fit. > > > > > >Requirements: > > > > * Can handle full internet tables, both v4 and v6 with room for > reasonable growth over the next 5 years. > > * VRF capability. > > * About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if > they are 1Gb/10Gb select-rate ports.) > > * Full-Feature BGP (address-families, communities, peer-groups, > etc...) > > * Used by carriers or large enterprises in a production role for at > least a year (and not causing ulcers) > > * Affordable. I know that's subjective, but we need a solution that > is as close as possible to commodity-pricing if this modernization effort > balloons to include all of our data centers. > > > >We are open to named vendors and even so-called brite-box solutions. A > little nervous about fringe solutions like pure whitebox with Quagga, but > if the savings are there and people can vouch for it, we will consider it. > > > >In other words, if you've used it and stand by it, we value that input > and will put it on the initial list. Also, if you chose solution-X after > comparing it to solution-Y it would be very helpful to detail what you > tested and why you chose. > > > >Thanks in advance. > > > > -- > Ken Chase - math at sizone.org Guelph Canada > From math at sizone.org Fri May 5 01:09:47 2017 From: math at sizone.org (Ken Chase) Date: Thu, 4 May 2017 21:09:47 -0400 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: <20170504232518.GC5709@sizone.org> Message-ID: <20170505010947.GF5709@sizone.org> hows the power footprint? i never understood why each prefix cost 1mW to handle on most routers (and still took 2-3 minutes to converge) /kc On Thu, May 04, 2017 at 06:55:54PM -0600, Tyler Conrad said: >I use the 7280R in production. Love it. > >Pros: Cheap, fantastic API, can take (current) full tables of v4 and v6. >6x100G w 48x1/10G gives lots of flexibility. > >Cons: Lack of proper VRF support and minimal bgp address families. (If you >want strict isolation, or can use a separate device for route leaking, they >can still do most of what we want). > >On Thursday, May 4, 2017, Ken Chase wrote: > >> anyone have thoughts about/experience with the Arista 7280R / their >> flexroute engine? >> >> /kc >> >> On Thu, May 04, 2017 at 08:39:16PM +0000, c b said: >> >We have a number of internet edge routers across several data centers >> approaching EOL/EOS, and are budgeting for replacements. Like most >> enterprises, we have been Cisco-centric in our routing/switching platforms. >> The ASR1Ks are too small for our needs and the ASR9Ks are prohibitively >> expensive and probably overkill. That being said, our IT staff is willing >> to look at other vendors if they are the right fit. >> > >> > >> >Requirements: >> > >> > * Can handle full internet tables, both v4 and v6 with room for >> reasonable growth over the next 5 years. >> > * VRF capability. >> > * About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if >> they are 1Gb/10Gb select-rate ports.) >> > * Full-Feature BGP (address-families, communities, peer-groups, >> etc...) >> > * Used by carriers or large enterprises in a production role for at >> least a year (and not causing ulcers) >> > * Affordable. I know that's subjective, but we need a solution that >> is as close as possible to commodity-pricing if this modernization effort >> balloons to include all of our data centers. >> > >> >We are open to named vendors and even so-called brite-box solutions. A >> little nervous about fringe solutions like pure whitebox with Quagga, but >> if the savings are there and people can vouch for it, we will consider it. >> > >> >In other words, if you've used it and stand by it, we value that input >> and will put it on the initial list. Also, if you chose solution-X after >> comparing it to solution-Y it would be very helpful to detail what you >> tested and why you chose. >> > >> >Thanks in advance. >> > >> >> -- >> Ken Chase - math at sizone.org Guelph Canada >> From tyler at tgconrad.com Fri May 5 01:18:18 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Thu, 4 May 2017 19:18:18 -0600 Subject: [NANOG] In-Reply-To: <20170505010947.GF5709@sizone.org> References: <20170504232518.GC5709@sizone.org> <20170505010947.GF5709@sizone.org> Message-ID: Mostly idle at around 102W atm. On Thursday, May 4, 2017, Ken Chase wrote: > hows the power footprint? i never understood why each prefix cost > 1mW to handle on most routers (and still took 2-3 minutes to converge) > > /kc > > > On Thu, May 04, 2017 at 06:55:54PM -0600, Tyler Conrad said: > >I use the 7280R in production. Love it. > > > >Pros: Cheap, fantastic API, can take (current) full tables of v4 and v6. > >6x100G w 48x1/10G gives lots of flexibility. > > > >Cons: Lack of proper VRF support and minimal bgp address families. (If > you > >want strict isolation, or can use a separate device for route leaking, > they > >can still do most of what we want). > > > >On Thursday, May 4, 2017, Ken Chase > > wrote: > > > >> anyone have thoughts about/experience with the Arista 7280R / their > >> flexroute engine? > >> > >> /kc > >> > >> On Thu, May 04, 2017 at 08:39:16PM +0000, c b said: > >> >We have a number of internet edge routers across several data > centers > >> approaching EOL/EOS, and are budgeting for replacements. Like most > >> enterprises, we have been Cisco-centric in our routing/switching > platforms. > >> The ASR1Ks are too small for our needs and the ASR9Ks are > prohibitively > >> expensive and probably overkill. That being said, our IT staff is > willing > >> to look at other vendors if they are the right fit. > >> > > >> > > >> >Requirements: > >> > > >> > * Can handle full internet tables, both v4 and v6 with room for > >> reasonable growth over the next 5 years. > >> > * VRF capability. > >> > * About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if > >> they are 1Gb/10Gb select-rate ports.) > >> > * Full-Feature BGP (address-families, communities, peer-groups, > >> etc...) > >> > * Used by carriers or large enterprises in a production role > for at > >> least a year (and not causing ulcers) > >> > * Affordable. I know that's subjective, but we need a solution > that > >> is as close as possible to commodity-pricing if this modernization > effort > >> balloons to include all of our data centers. > >> > > >> >We are open to named vendors and even so-called brite-box > solutions. A > >> little nervous about fringe solutions like pure whitebox with Quagga, > but > >> if the savings are there and people can vouch for it, we will > consider it. > >> > > >> >In other words, if you've used it and stand by it, we value that > input > >> and will put it on the initial list. Also, if you chose solution-X > after > >> comparing it to solution-Y it would be very helpful to detail what you > >> tested and why you chose. > >> > > >> >Thanks in advance. > >> > > >> > >> -- > >> Ken Chase - math at sizone.org Guelph > Canada > >> > > From holbor at sonss.net Fri May 5 06:19:48 2017 From: holbor at sonss.net (Richard Holbo) Date: Thu, 4 May 2017 23:19:48 -0700 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: Message-ID: I've had no issues with their gear and have used the NE40/80 routers, some of the switching gear and some FTTP, NE40e will do full tables. US support is in Texas and has been good. Mostly my experience with Huawei support has been that I don't need it. Once you get over the learning curve.. it mostly just makes sense and does what you think it ought to. /rh On Thu, May 4, 2017 at 3:26 PM, c b wrote: > Can someone toss in a brief testimonial for huawei? In the US, I never > hear that name in enterprise space, only in carriers. No idea what > day-to-day ops or support is like with that vendor. All the others I am > quite familiar with to one degree or another. > > > ________________________________ > From: Dragan Jovicic > Sent: Thursday, May 4, 2017 3:20 PM > To: Saku Ytti > Cc: c b; nanog at nanog.org > Subject: Re: Need recommendation on an affordable internet edge router > > Hi, > > But you probably should review at least: > - Juniper MX204, MX480 > - Cisco ASR9k > - Huawei NE20, NE40 > - Alcatel 7750SR > > Having all of these somewhere in our network, and my heart being with JNPR > boxes, I'll say have a look at Huawei offerings. > > +Dragan > > On Fri, May 5, 2017 at 12:10 AM, Saku Ytti ytti.fi>> wrote: > On 5 May 2017 at 01:04, c b bz_siege_01 at hotmail.com>> wrote: > > Hey, > > > The ASR9k is certainly up to the task and it's one of the few we looked > at > > initially, but the pricing is nowhere near commodity even if we got a > > minimal build. > > What is commodity? Where are you comparing it to which satisfies your > requirements? > > > As far as volume, the initial purchase for this round of budget will be > an > > HA pair. If the solution works well, we have potential to replace 12 or > so > > throughout FY17, maybe into FY18. > > Yeah sales droids likely won't be interested in 2 at all. But if you > commit on those 12, even if you'll order them separately. I think > that's something sales droid will care about, and you'll have > negotiation leverage as you can keep bouncing between several vendors > seeing who gets your business. > You should really expect at least 70% discount on 12 units, 80% would > be good. Under 70% would be walk out the room. > > -- > ++ytti > > From matt.torres at state.or.us Thu May 4 17:08:27 2017 From: matt.torres at state.or.us (Torres, Matt) Date: Thu, 4 May 2017 17:08:27 +0000 Subject: Ingress filtering from an external cloud service to the internal network In-Reply-To: References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3BEC0@ExchMBXProd02.win.lottery.state.or.us> Message-ID: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3C3B8@ExchMBXProd02.win.lottery.state.or.us> Unfortunately, a private connection or VPN to the cloud service provider is not available right now, but I can see how that could help solve my problem. :-) ~Matt > Is it possible for you to get a private/direct connect service from your network perimeter to the cloud provider and eliminate using the public connectivity? > >Or because its Internet-based you have to use public connectivity? From lists-nanog at schultz.top Thu May 4 20:49:21 2017 From: lists-nanog at schultz.top (Patrick Schultz) Date: Thu, 4 May 2017 22:49:21 +0200 Subject: Retarus (AS 48328) In-Reply-To: References: Message-ID: Hi Martin, the only address I can point you at is "support at retarus dot com". We once had to contact them about a SMTP problem and this was the only working contact. Best, Patrick Am 04.05.17 um 06:31 schrieb Martin Hannigan: > I hate to do this, but I have exhausted _all of my sources of data > including the SOA (points at VRSN) and domain name contact addresses for: > > Registrant Name: Retarus GmbH > Registrant Organization: Retarus GmbH > Registrant Street: Aschauerstrasse 30 > Registrant City: Muenchen > Registrant State/Province: Bav > Registrant Postal Code: 81549 > Registrant Country: DE > > I worked backwards from a domain name of RMX.DE. I don't know what the > distinction is other than this name perhaps being an operational domain for > their mail security services. > > If someone has a pointer or can do an offline introduction to someone in > tech-ops or networking there, I'd appreciate it. > > Best, > > -M< > From clint at clintarmstrong.net Fri May 5 01:03:51 2017 From: clint at clintarmstrong.net (Clint Armstrong) Date: Fri, 05 May 2017 01:03:51 +0000 Subject: TCP over fragmented IPv6 dropped in Comcast's network Message-ID: In troubleshooting why a DNS zone transfer fails over IPv6 from a DNS master hosted on a Comcast connection, I've discovered that a router in Comcast's network is IPv6 Fragments with TCP headers. More specifically it appears that this router silently drops any packet with a non-zero fragment offset, followed by a tcp header. Packets with a fragment offset followed by a udp header, or anything else, are passed just fine. Also, fragments sent in the opposite direction, from outside Comcast coming in, are passed just fine. I believe I was able to determine the problematic router by using the sendip tool to generate these dropped packets and increasing the TTL on the packet until I no longer got an ICMPv6 unreachable response from the next hop. If anyone else with a Comcast IPv6 connection would like to test and see if your connections are affected by this issue, here is how you can test. First you need sendip version 2.5-mec-3a2 with the frag.so module. Start tcpdump or wireshark looking for ICMPv6 Time Exceeded messages. Then send test packets to any destination IP you'd like to test a route to using the command `sendip -p ipv6 -6s -6h 2 -p frag -Fo 1 -p tcp` Increment the 6h value until you no longer get an ICMPv6 Time Exceeded response. At that point try removing the `-p tcp` parameter and see if that works. In my case, it does, demonstrating that this problematic router successfully passes IPv6 fragments without a TCP header. If anyone at Comcast would like to contact me off-list, I'll share more details of my findings, including the source address where I'm testing from, and what I believe is the problematic router. From hannigan at gmail.com Fri May 5 14:05:39 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 05 May 2017 14:05:39 +0000 Subject: Retarus (AS 48328) In-Reply-To: References: Message-ID: I heard from the team at Retarus. They were responsive. Much appreciated. Thanks all. On Fri, May 5, 2017 at 08:41 Patrick Schultz wrote: > Hi Martin, > the only address I can point you at is "support at retarus dot com". > We once had to contact them about a SMTP problem and this was the only > working contact. > > Best, > Patrick > > Am 04.05.17 um 06:31 schrieb Martin Hannigan: > > I hate to do this, but I have exhausted _all of my sources of data > > including the SOA (points at VRSN) and domain name contact addresses for: > > > > Registrant Name: Retarus GmbH > > Registrant Organization: Retarus GmbH > > Registrant Street: Aschauerstrasse 30 > > Registrant City: Muenchen > > Registrant State/Province: Bav > > Registrant Postal Code: 81549 > > Registrant Country: DE > > > > I worked backwards from a domain name of RMX.DE. I don't know what the > > distinction is other than this name perhaps being an operational domain > for > > their mail security services. > > > > If someone has a pointer or can do an offline introduction to someone in > > tech-ops or networking there, I'd appreciate it. > > > > Best, > > > > -M< > > > > From johnstong at westmancom.com Fri May 5 14:57:41 2017 From: johnstong at westmancom.com (Graham Johnston) Date: Fri, 5 May 2017 14:57:41 +0000 Subject: Static IP allocation schemes for end users (commercial) Message-ID: <82C0CE81789FE64D8F4D15263191829715C6D81D@MSG6.westman.int> I work for a cable MSO, meaning that our access network is DOCSIS based. 15 years ago when we had way more IP addresses than customers we had a static IP allocation scheme wherein we aligned a /24 with each node and reserved the first 20 or so IPs for static assignment, the rest being left for dynamic assignment. The primary reason behind this scheme was that as the network grew and a node moved from one CMTS to another we could pull the /24 with it and customers wouldn't have to re-address. As our network has grown, in terms of the number of nodes, as well as the number of IPs in use we've come to the obvious conclusion that the old scheme isn't workable into the future. For instance I will soon have more nodes in service than I have /24s allocated to me. Instead we are entertaining two basic options as an alternative. * Create static reservations, as required, within the otherwise dynamic range. * Whether or not the customer continues to DHCP or assigns the IP statically doesn't matter to me. * Move to having a single subnet, or portion therein, per CMTS. This keeps the process more or less identical to what we do now. Both of the schemes above would require the customer to undergo addressing changes in the event that we move their node between CMTSs in the future. Can anyone else share what they are doing or otherwise identify if there is a best practice in this area? Thanks, Graham From george.herbert at gmail.com Fri May 5 15:13:07 2017 From: george.herbert at gmail.com (George William Herbert) Date: Fri, 5 May 2017 08:13:07 -0700 Subject: Ingress filtering from an external cloud service to the internal network In-Reply-To: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3C3B8@ExchMBXProd02.win.lottery.state.or.us> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3BEC0@ExchMBXProd02.win.lottery.state.or.us> <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3C3B8@ExchMBXProd02.win.lottery.state.or.us> Message-ID: You can usually run OpenVPN from a cloud host. The source IP changing possibly should require only one open exception to the local VPN termination point. Better, find a cloud that doesn't do that shit with changing endpoints and gives you real VPNs. What sort of cloud doesn't these days?...?... Sent from my iPhone > On May 4, 2017, at 10:08 AM, Torres, Matt wrote: > > Unfortunately, a private connection or VPN to the cloud service provider is not available right now, but I can see how that could help solve my problem. :-) > ~Matt > >> Is it possible for you to get a private/direct connect service from your network perimeter to the cloud provider and eliminate using the public connectivity? >> >> Or because its Internet-based you have to use public connectivity? From matt.torres at state.or.us Fri May 5 15:36:31 2017 From: matt.torres at state.or.us (Torres, Matt) Date: Fri, 5 May 2017 15:36:31 +0000 Subject: Ingress filtering from an external cloud service to the internal network In-Reply-To: References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3BEC0@ExchMBXProd02.win.lottery.state.or.us> <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3C3B8@ExchMBXProd02.win.lottery.state.or.us> Message-ID: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3DE3E@ExchMBXProd02.win.lottery.state.or.us> According to my application guy, this is true of the Microsoft O365 hybrid solution. It requires direct inbound connections on various ports from largely undefined IP space. I imagine the private VPN limitation (i.e., not having a VPN) is on our side and MS provides something like this... >Better, find a cloud that doesn't do that shit with changing endpoints and gives you real VPNs. What sort of >cloud doesn't these days?...?... From yanf787 at gmail.com Fri May 5 14:11:23 2017 From: yanf787 at gmail.com (Yan Filyurin) Date: Fri, 5 May 2017 10:11:23 -0400 Subject: Ingress filtering from an external cloud service to the internal network In-Reply-To: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3C3B8@ExchMBXProd02.win.lottery.state.or.us> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3BEC0@ExchMBXProd02.win.lottery.state.or.us> <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3C3B8@ExchMBXProd02.win.lottery.state.or.us> Message-ID: Since you can't change the design you may not be able to put some kind of overlay solution in place, which is just a fancy way of saying a VPN solution. What if you look at it in a different way and put some kind of endpoint security cloud solution like Illumio. But if you at least had the freedom to put something like this: http://www.sproute.com/span in place or 20 other similar solutions. As in you do VPN, but right from the cloud instance itself or another instance. There is also a set of various solutions that do specialized metadata like Cilium, but they get into container networking and that is definitely application redesign. On Thu, May 4, 2017 at 1:08 PM, Torres, Matt wrote: > Unfortunately, a private connection or VPN to the cloud service provider > is not available right now, but I can see how that could help solve my > problem. :-) > ~Matt > > > Is it possible for you to get a private/direct connect service from your > network perimeter to the cloud provider and eliminate using the public > connectivity? > > > >Or because its Internet-based you have to use public connectivity? > From yanf787 at gmail.com Fri May 5 15:30:16 2017 From: yanf787 at gmail.com (Yan Filyurin) Date: Fri, 5 May 2017 11:30:16 -0400 Subject: Ingress filtering from an external cloud service to the internal network In-Reply-To: References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3BEC0@ExchMBXProd02.win.lottery.state.or.us> <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3C3B8@ExchMBXProd02.win.lottery.state.or.us> Message-ID: I just read an article about these people. They are even more interesting than Illumio or these other VPN solutions. The important part is that you get to stitch tunnels together on some other host, so the changing IP of endpoints is irrelevant. http://zentera.net/ On Fri, May 5, 2017 at 11:13 AM, George William Herbert < george.herbert at gmail.com> wrote: > You can usually run OpenVPN from a cloud host. The source IP changing > possibly should require only one open exception to the local VPN > termination point. > > Better, find a cloud that doesn't do that shit with changing endpoints and > gives you real VPNs. What sort of cloud doesn't these days?...?... > > > Sent from my iPhone > > > On May 4, 2017, at 10:08 AM, Torres, Matt > wrote: > > > > Unfortunately, a private connection or VPN to the cloud service provider > is not available right now, but I can see how that could help solve my > problem. :-) > > ~Matt > > > >> Is it possible for you to get a private/direct connect service from > your network perimeter to the cloud provider and eliminate using the public > connectivity? > >> > >> Or because its Internet-based you have to use public connectivity? > From bz_siege_01 at hotmail.com Fri May 5 16:55:36 2017 From: bz_siege_01 at hotmail.com (LF OD) Date: Fri, 5 May 2017 16:55:36 +0000 Subject: Question about experiences with BGP remote-AS Message-ID: We have a number of small routers in co-lo sites that peer with B2B partners. As more of our partners move to cloud, we are considering a consolidation effort and putting all of our peering routers in a cloud exchange site on a single HA pair of routers. Now, each existing B2B peering router uses a unique private ASN to EBGP peer with partners and they, in turn, EBGP peer with our extranet perimeter ASNs for security vetting and other stuff. We looked for a medium-density router (or L3-switch) that can replace multiple small routers (b2b-only, no internet), but we need to retain all of our existing ASNs and peerings. As it turns out, there are many routers that can do VRFs but you cannot put a unique ASN on each VRF so replicating the old environment isn't quite that straightforward. The BGP remote-as looks to be a possible alternative solution, but we've never used it in production and we are unsure of the caveats. Taken at face value, it looks like we can mimic the multi-router/unique-ASN environment we have today on a single platform. However, networking is rarely as smooth as that so I'm asking some of the BGP gurus... what are the pros/cons of doing using remote-as? If anyone here uses it extensively, we could really use some feedback if you run into challenges or hidden surprises that we wouldn't normally think of beforehand. Thanks in advance! LFOD From bryan at shout.net Fri May 5 17:16:33 2017 From: bryan at shout.net (Bryan Holloway) Date: Fri, 5 May 2017 12:16:33 -0500 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: <20170504232518.GC5709@sizone.org> Message-ID: +1 on the 7280R We just started deploying them on our edges for peering and port-density. Great little box. ... and their A-Care support has been good and responsive. On 5/4/17 7:55 PM, Tyler Conrad wrote: > I use the 7280R in production. Love it. > > Pros: Cheap, fantastic API, can take (current) full tables of v4 and v6. > 6x100G w 48x1/10G gives lots of flexibility. > > Cons: Lack of proper VRF support and minimal bgp address families. (If you > want strict isolation, or can use a separate device for route leaking, they > can still do most of what we want). > > On Thursday, May 4, 2017, Ken Chase wrote: > >> anyone have thoughts about/experience with the Arista 7280R / their >> flexroute engine? >> >> /kc >> >> On Thu, May 04, 2017 at 08:39:16PM +0000, c b said: >> >We have a number of internet edge routers across several data centers >> approaching EOL/EOS, and are budgeting for replacements. Like most >> enterprises, we have been Cisco-centric in our routing/switching platforms. >> The ASR1Ks are too small for our needs and the ASR9Ks are prohibitively >> expensive and probably overkill. That being said, our IT staff is willing >> to look at other vendors if they are the right fit. >> > >> > >> >Requirements: >> > >> > * Can handle full internet tables, both v4 and v6 with room for >> reasonable growth over the next 5 years. >> > * VRF capability. >> > * About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if >> they are 1Gb/10Gb select-rate ports.) >> > * Full-Feature BGP (address-families, communities, peer-groups, >> etc...) >> > * Used by carriers or large enterprises in a production role for at >> least a year (and not causing ulcers) >> > * Affordable. I know that's subjective, but we need a solution that >> is as close as possible to commodity-pricing if this modernization effort >> balloons to include all of our data centers. >> > >> >We are open to named vendors and even so-called brite-box solutions. A >> little nervous about fringe solutions like pure whitebox with Quagga, but >> if the savings are there and people can vouch for it, we will consider it. >> > >> >In other words, if you've used it and stand by it, we value that input >> and will put it on the initial list. Also, if you chose solution-X after >> comparing it to solution-Y it would be very helpful to detail what you >> tested and why you chose. >> > >> >Thanks in advance. >> > >> >> -- >> Ken Chase - math at sizone.org Guelph Canada >> From cscora at apnic.net Fri May 5 18:02:39 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 May 2017 04:02:39 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170505180239.2AACFC44D5@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 06 May, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 647110 Prefixes after maximum aggregation (per Origin AS): 252103 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 311926 Total ASes present in the Internet Routing Table: 57065 Prefixes per ASN: 11.34 Origin-only ASes present in the Internet Routing Table: 49371 Origin ASes announcing only one prefix: 21886 Transit ASes present in the Internet Routing Table: 7694 Transit-only ASes present in the Internet Routing Table: 219 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 40 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 71 Numnber of instances of unregistered ASNs: 75 Number of 32-bit ASNs allocated by the RIRs: 18434 Number of 32-bit ASNs visible in the Routing Table: 14310 Prefixes from 32-bit ASNs in the Routing Table: 57955 Number of bogon 32-bit ASNs visible in the Routing Table: 45 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 409 Number of addresses announced to Internet: 2843460964 Equivalent to 169 /8s, 123 /16s and 197 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.6 Total number of prefixes smaller than registry allocations: 216869 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 176804 Total APNIC prefixes after maximum aggregation: 50891 APNIC Deaggregation factor: 3.47 Prefixes being announced from the APNIC address blocks: 175990 Unique aggregates announced from the APNIC address blocks: 72729 APNIC Region origin ASes present in the Internet Routing Table: 8063 APNIC Prefixes per ASN: 21.83 APNIC Region origin ASes announcing only one prefix: 2243 APNIC Region transit ASes present in the Internet Routing Table: 1131 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2888 Number of APNIC addresses announced to Internet: 763094372 Equivalent to 45 /8s, 123 /16s and 229 /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: 197305 Total ARIN prefixes after maximum aggregation: 94097 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 199402 Unique aggregates announced from the ARIN address blocks: 91373 ARIN Region origin ASes present in the Internet Routing Table: 17899 ARIN Prefixes per ASN: 11.14 ARIN Region origin ASes announcing only one prefix: 6640 ARIN Region transit ASes present in the Internet Routing Table: 1780 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1953 Number of ARIN addresses announced to Internet: 1108934048 Equivalent to 66 /8s, 24 /16s and 253 /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: 174832 Total RIPE prefixes after maximum aggregation: 85064 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 170401 Unique aggregates announced from the RIPE address blocks: 102059 RIPE Region origin ASes present in the Internet Routing Table: 23966 RIPE Prefixes per ASN: 7.11 RIPE Region origin ASes announcing only one prefix: 11062 RIPE Region transit ASes present in the Internet Routing Table: 3404 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5787 Number of RIPE addresses announced to Internet: 711675008 Equivalent to 42 /8s, 107 /16s and 76 /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: 81148 Total LACNIC prefixes after maximum aggregation: 18204 LACNIC Deaggregation factor: 4.46 Prefixes being announced from the LACNIC address blocks: 82370 Unique aggregates announced from the LACNIC address blocks: 38448 LACNIC Region origin ASes present in the Internet Routing Table: 5852 LACNIC Prefixes per ASN: 14.08 LACNIC Region origin ASes announcing only one prefix: 1620 LACNIC Region transit ASes present in the Internet Routing Table: 1079 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3370 Number of LACNIC addresses announced to Internet: 169866464 Equivalent to 10 /8s, 31 /16s and 244 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16916 Total AfriNIC prefixes after maximum aggregation: 3786 AfriNIC Deaggregation factor: 4.47 Prefixes being announced from the AfriNIC address blocks: 18538 Unique aggregates announced from the AfriNIC address blocks: 6966 AfriNIC Region origin ASes present in the Internet Routing Table: 1039 AfriNIC Prefixes per ASN: 17.84 AfriNIC Region origin ASes announcing only one prefix: 321 AfriNIC Region transit ASes present in the Internet Routing Table: 207 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 312 Number of AfriNIC addresses announced to Internet: 89454848 Equivalent to 5 /8s, 84 /16s and 249 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5567 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3785 393 271 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2932 901 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2762 11150 758 KIXS-AS-KR Korea Telecom, KR 9829 2732 1499 539 BSNL-NIB National Internet Backbone, IN 9808 2212 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2079 421 222 TATACOMM-AS TATA Communications formerl 45899 1983 1388 110 VNPT-AS-VN VNPT Corp, VN 7552 1588 1101 55 VIETEL-AS-AP Viettel Corporation, VN 9583 1573 121 541 SIFY-AS-IN Sify Limited, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 4008 2969 153 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3361 1333 80 SHAW - Shaw Communications Inc., CA 18566 2182 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2069 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2006 2153 405 CHARTER-NET-HKY-NC - Charter Communicat 209 1828 5067 633 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1786 3422 571 AMAZON-02 - Amazon.com, Inc., US 30036 1751 322 338 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1692 854 230 ITCDELTA - Earthlink, Inc., US 701 1567 10579 639 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3224 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2880 1006 2063 AKAMAI-ASN1, US 9121 2659 1691 18 TTNET, TR 34984 2007 328 385 TELLCOM-AS, TR 13188 1596 99 56 TRIOLAN, UA 12479 1566 1044 52 UNI2-AS, ES 12389 1484 1357 610 ROSTELECOM-AS, RU 9198 1322 352 25 KAZTELECOM-AS, KZ 6849 1226 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3536 544 172 Telmex Colombia S.A., CO 8151 2517 3396 562 Uninet S.A. de C.V., MX 11830 2081 369 57 Instituto Costarricense de Electricidad 7303 1557 1005 247 Telecom Argentina S.A., AR 6503 1540 437 53 Axtel, S.A.B. de C.V., MX 6147 1267 377 27 Telefonica del Peru S.A.A., PE 28573 1083 2286 179 CLARO S.A., BR 3816 1018 495 186 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 921 126 80 Alestra, S. de R.L. de C.V., MX 18881 892 1052 23 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1209 398 48 LINKdotNET-AS, EG 36903 712 357 134 MT-MPLS, MA 37611 704 67 7 Afrihost, ZA 36992 625 1375 26 ETISALAT-MISR, EG 24835 496 722 14 RAYA-AS, EG 37492 408 319 74 ORANGE-, TN 8452 407 1730 17 TE-AS TE-AS, EG 29571 367 36 10 CITelecom-AS, CI 15399 348 35 7 WANANCHI-, KE 2018 287 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5567 4190 74 ERX-CERNET-BKB China Education and Rese 22773 4008 2969 153 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3785 393 271 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3536 544 172 Telmex Colombia S.A., CO 6327 3361 1333 80 SHAW - Shaw Communications Inc., CA 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3224 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 17974 2932 901 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2880 1006 2063 AKAMAI-ASN1, US 4766 2762 11150 758 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 4008 3855 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3785 3514 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3536 3364 Telmex Colombia S.A., CO 39891 3338 3316 ALJAWWALSTC-AS, SA 6327 3361 3281 SHAW - Shaw Communications Inc., CA 8551 3224 3183 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2932 2853 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2659 2641 TTNET, TR 9829 2732 2193 BSNL-NIB National Internet Backbone, IN 9808 2212 2179 CMNET-GD Guangdong Mobile Communication Co.Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.167.128.0/24 395774 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 36.255.248.0/24 64091 CORONET-BD Coronet Corporation Ltd., BD 36.255.250.0/24 64091 CORONET-BD Coronet Corporation Ltd., BD 41.76.232.0/21 203496 AB-TELECOM, RU 41.77.248.0/21 203496 AB-TELECOM, RU 41.78.12.0/23 203496 AB-TELECOM, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM, RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:103 /12:280 /13:545 /14:1043 /15:1841 /16:13455 /17:7571 /18:13417 /19:24717 /20:38416 /21:41248 /22:76405 /23:63583 /24:362203 /25:846 /26:620 /27:627 /28:44 /29:29 /30:25 /31:1 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 3162 4008 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 6327 3155 3361 SHAW - Shaw Communications Inc., CA 39891 2898 3338 ALJAWWALSTC-AS, SA 8551 2686 3224 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2075 2182 MEGAPATH5-US - MegaPath Corporation, US 9121 1905 2659 TTNET, TR 30036 1554 1751 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1475 2081 Instituto Costarricense de Electricidad y Telec 10620 1464 3536 Telmex Colombia S.A., CO 6389 1375 2069 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1607 2:817 4:26 5:2438 6:34 8:1077 12:1833 13:116 14:1786 15:26 16:2 17:121 18:120 19:1 20:56 23:2256 24:1864 25:2 27:2412 31:1915 32:89 33:7 35:20 36:398 37:2581 38:1348 39:44 40:97 41:3006 42:468 43:1909 44:72 45:2565 46:2744 47:116 49:1195 50:976 51:18 52:807 54:360 55:4 56:4 57:41 58:1581 59:1039 60:387 61:1907 62:1532 63:1919 64:4580 65:2212 66:4556 67:2239 68:1227 69:3350 70:1317 71:583 72:2193 74:2666 75:382 76:427 77:1484 78:1657 79:2067 80:1376 81:1410 82:985 83:729 84:869 85:1798 86:481 87:1159 88:836 89:2078 90:169 91:6162 92:1009 93:2386 94:2328 95:2859 96:606 97:359 98:1005 99:85 100:156 101:1260 103:14549 104:2862 105:177 106:498 107:1640 108:811 109:3421 110:1330 111:1738 112:1174 113:1216 114:1036 115:1785 116:1777 117:1724 118:2157 119:1581 120:1006 121:1101 122:2236 123:1786 124:1540 125:1870 128:744 129:627 130:440 131:1391 132:526 133:190 134:620 135:219 136:515 137:435 138:1932 139:476 140:375 141:564 142:741 143:972 144:780 145:177 146:1036 147:659 148:1387 149:568 150:710 151:957 152:754 153:297 154:793 155:740 156:581 157:621 158:448 159:1444 160:581 161:748 162:2488 163:524 164:793 165:1201 166:385 167:1246 168:2608 169:779 170:3197 171:300 172:979 173:1855 174:819 175:735 176:1840 177:4109 178:2468 179:1144 180:2196 181:1857 182:2330 183:983 184:856 185:9555 186:3202 187:2231 188:2631 189:1793 190:8149 191:1317 192:9380 193:5785 194:4651 195:3847 196:2080 197:1239 198:5516 199:5881 200:7340 201:4332 202:10342 203:9865 204:4468 205:2798 206:3009 207:3129 208:4015 209:3970 210:3957 211:2134 212:2815 213:2496 214:878 215:65 216:5768 217:2079 218:839 219:608 220:1653 221:908 222:758 223:1177 End of report From tyler at tgconrad.com Fri May 5 19:14:50 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Fri, 5 May 2017 13:14:50 -0600 Subject: Question about experiences with BGP remote-AS In-Reply-To: References: Message-ID: Neighbor x.x.x.x local-as {whateverasn} no-prepend replace-as On Friday, May 5, 2017, LF OD wrote: > We have a number of small routers in co-lo sites that peer with B2B > partners. As more of our partners move to cloud, we are considering a > consolidation effort and putting all of our peering routers in a cloud > exchange site on a single HA pair of routers. Now, each existing B2B > peering router uses a unique private ASN to EBGP peer with partners and > they, in turn, EBGP peer with our extranet perimeter ASNs for security > vetting and other stuff. > > > We looked for a medium-density router (or L3-switch) that can replace > multiple small routers (b2b-only, no internet), but we need to retain all > of our existing ASNs and peerings. As it turns out, there are many routers > that can do VRFs but you cannot put a unique ASN on each VRF so replicating > the old environment isn't quite that straightforward. The BGP remote-as > looks to be a possible alternative solution, but we've never used it in > production and we are unsure of the caveats. Taken at face value, it looks > like we can mimic the multi-router/unique-ASN environment we have today on > a single platform. However, networking is rarely as smooth as that so I'm > asking some of the BGP gurus... what are the pros/cons of doing using > remote-as? If anyone here uses it extensively, we could really use some > feedback if you run into challenges or hidden surprises that we wouldn't > normally think of beforehand. > > > Thanks in advance! > > > LFOD > From nanog at radu-adrian.feurdean.net Fri May 5 19:29:26 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Fri, 05 May 2017 21:29:26 +0200 Subject: Question about experiences with BGP remote-AS In-Reply-To: References: Message-ID: <1494012566.2734315.967268864.53703EA7@webmail.messagingengine.com> On Fri, May 5, 2017, at 18:55, LF OD wrote: > of our existing ASNs and peerings. As it turns out, there are many > routers that can do VRFs but you cannot put a unique ASN on each VRF so > replicating the old environment isn't quite that straightforward. The BGP > remote-as looks to be a possible alternative solution, but we've never You mean *local-as*, right ? Otherwise, there was a vendor that allowed different ASN per VRF but only with non-MPLS vrfs, and that product line is both end-of-sale and major overkill for your set-up. From tony at wicks.co.nz Fri May 5 22:15:12 2017 From: tony at wicks.co.nz (Tony Wicks) Date: Sat, 6 May 2017 10:15:12 +1200 Subject: Question about experiences with BGP remote-AS In-Reply-To: References: Message-ID: <001101d2c5ed$125afe80$3710fb80$@wicks.co.nz> JunOS has three different modes for Virtual routers depending on your situation requirements. I would suggest that something in the QFX or ACX range will be able to replicate what you are after. Otherwise the entry level MX will certainly do the job for a little more outlay. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of LF OD Sent: Saturday, 6 May 2017 4:56 AM To: nanog at nanog.org Subject: Question about experiences with BGP remote-AS We have a number of small routers in co-lo sites that peer with B2B partners. As more of our partners move to cloud, we are considering a consolidation effort and putting all of our peering routers in a cloud exchange site on a single HA pair of routers. Now, each existing B2B peering router uses a unique private ASN to EBGP peer with partners and they, in turn, EBGP peer with our extranet perimeter ASNs for security vetting and other stuff. We looked for a medium-density router (or L3-switch) that can replace multiple small routers (b2b-only, no internet), but we need to retain all of our existing ASNs and peerings. As it turns out, there are many routers that can do VRFs but you cannot put a unique ASN on each VRF so replicating the old environment isn't quite that straightforward. The BGP remote-as looks to be a possible alternative solution, but we've never used it in production and we are unsure of the caveats. Taken at face value, it looks like we can mimic the multi-router/unique-ASN environment we have today on a single platform. However, networking is rarely as smooth as that so I'm asking some of the BGP gurus... what are the pros/cons of doing using remote-as? If anyone here uses it extensively, we could really use some feedback if you run into challenges or hidden surprises that we wouldn't normally think of beforehand. Thanks in advance! LFOD From matt.torres at state.or.us Fri May 5 23:57:08 2017 From: matt.torres at state.or.us (Torres, Matt) Date: Fri, 5 May 2017 23:57:08 +0000 Subject: Ingress filtering from an external cloud service to the internal network In-Reply-To: References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3BEC0@ExchMBXProd02.win.lottery.state.or.us> <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3C3B8@ExchMBXProd02.win.lottery.state.or.us> Message-ID: <4E275B0B9F6F5445ACE48FBBB2AC3B14CAD3EE6D@ExchMBXProd02.win.lottery.state.or.us> NANOG, Thank you all. I have more than enough research to do now to further learn about everyone?s suggestions. ~Matt >But if you at least had the freedom to put something like this: > >http://www.sproute.com/span > >in place or 20 other similar solutions. As in you do VPN, but right from the cloud instance itself or >another instance. There is also a set of various solutions that do specialized metadata like Cilium, but >they get into container networking and that is definitely application redesign. From code at joelwhitehouse.com Fri May 5 23:27:10 2017 From: code at joelwhitehouse.com (Joel Whitehouse) Date: Fri, 5 May 2017 18:27:10 -0500 Subject: IPv6 first hop security on a budget? Message-ID: What's a good budget option for switching a small lab or office ipv6 with RA Guard, DHCP6 snooping, and ICMP6 snooping? From james.braunegg at micron21.com Sat May 6 12:46:23 2017 From: james.braunegg at micron21.com (James Braunegg) Date: Sat, 6 May 2017 12:46:23 +0000 Subject: Need recommendation on an affordable internet edge router In-Reply-To: References: Message-ID: <10439c5c408d44549c1670716cbcc109@EX-01.m21.local> Dear All I would add the Brocade MLXe-4/8/16 (Soon to be Extreme) to the list depending how many ports you need. The 20 x 10G X2 line cards support up to 2 million routes, well worth looking at. Kindest Regards, James Braunegg 1300 769 972 / 0488 997 207 james at micron21.com https://www.micron21.com/ddos-protection Follow us on Twitter for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dragan Jovicic Sent: Friday, 5 May 2017 8:20 AM To: Saku Ytti Cc: nanog at nanog.org Subject: Re: Need recommendation on an affordable internet edge router Hi, > But you probably should review at least: > - Juniper MX204, MX480 > - Cisco ASR9k > - Huawei NE20, NE40 > - Alcatel 7750SR > Having all of these somewhere in our network, and my heart being with JNPR boxes, I'll say have a look at Huawei offerings. +Dragan On Fri, May 5, 2017 at 12:10 AM, Saku Ytti > wrote: > On 5 May 2017 at 01:04, c b > wrote: > > Hey, > > > The ASR9k is certainly up to the task and it's one of the few we > > looked > at > > initially, but the pricing is nowhere near commodity even if we got > > a minimal build. > > What is commodity? Where are you comparing it to which satisfies your > requirements? > > > As far as volume, the initial purchase for this round of budget will > > be > an > > HA pair. If the solution works well, we have potential to replace 12 > > or > so > > throughout FY17, maybe into FY18. > > Yeah sales droids likely won't be interested in 2 at all. But if you > commit on those 12, even if you'll order them separately. I think > that's something sales droid will care about, and you'll have > negotiation leverage as you can keep bouncing between several vendors > seeing who gets your business. > You should really expect at least 70% discount on 12 units, 80% would > be good. Under 70% would be walk out the room. > > -- > ++ytti > From colton.conor at gmail.com Sat May 6 14:46:00 2017 From: colton.conor at gmail.com (Colton Conor) Date: Sat, 6 May 2017 09:46:00 -0500 Subject: SD-WAN for enlightened In-Reply-To: References: <001401d2b78f$a5b69b60$f123d220$@sdnessentials.com> <132301d2c36b$cec21ab0$6c465010$@sdnessentials.com> Message-ID: What I don't understand is how do all these newer, SD-WAN vendors, differ from any of the managed FireWall companies that have nice pretty GUI's and web management? For example, Sophos, Meraki, Fortinet, and the other large firewall vendors that do dual wan, virus filtering, remote management, etc? On Tue, May 2, 2017 at 1:19 PM, Stefan wrote: > As of this announcement: > > http://investor.cisco.com/investor-relations/news-and- > events/news/news-details/2017/Cisco-Announces-Intent-to- > Acquire-Viptela/default.aspx > > there will be one less than before :-) > > Seriously - when I first learned about them, upon service inclusion of the > Viptela products into the VzB SD-WAN offering, they (Viptela - > http://blog.ipspace.net/2014/11/viptela-sen-hybrid-wan-connectivity.html) > looked very nice, already, as standalone products. And that was a few years > back. > > ***Stefan > > On Tue, May 2, 2017 at 12:44 PM, Doug Marschke > wrote: > >> Too many to list. I don?t know who is ?winning? in market share right >> now, as I am sure each vendor tracks their wins differently. >> >> There are definitely a few making more noise than others. >> >> Doug Marschke >> >> CTO >> >> www.sdnessentials.com >> >> JNCIE-SP #41, JNCIE-ENT #3 >> >> 415-902-5702 (cell) >> >> 415-340-3112 (office) >> >> >> >> From: Colton Conor [mailto:colton.conor at gmail.com] >> Sent: Thursday, April 27, 2017 6:26 PM >> To: Doug Marschke >> Cc: Kasper Adel ; NANOG list >> Subject: Re: SD-WAN for enlightened >> >> >> >> So who are the big SD-WAN players out there? >> >> >> >> On Mon, Apr 17, 2017 at 10:31 AM, Doug Marschke > > wrote: >> >> Hello Kasper, >> >> I will do my best to answer your SD-WAN question, but as you mentioned it >> is a buzzword that has a bit of confusion in its definitions. I would say >> that a SD-WAN solution should have the following elements: >> >> 1.) Ability to manage multiple WAN connection and choose the path based >> on user and machine criteria (The Hybrid WAN) >> 2.) A controller to manage the polices and operations of the SD-WAN >> devices >> 3.) Analytics on the network and application level >> 4.) A software overlay that abstracts and secures the underlying networks >> >> Currently there are a lot of solutions out there by many vendors. Some >> do all of these and some a subset, so it make the landscape a bit >> confusing. Lots of times vendors use SD-WAN when they are really just >> talking about Hybrid WAN (multiple connections) or WAN optimization. >> >> >> >> >> >> Doug Marschke >> CTO >> www.sdnessentials.com >> JNCIE-SP #41, JNCIE-ENT #3 >> 415-902-5702 (cell) >> 415-340-3112 (office) >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org > nanog-bounces at nanog.org> ] On Behalf Of Kasper Adel >> Sent: Sunday, April 16, 2017 1:14 PM >> To: NANOG list > >> Subject: SD-WAN for enlightened >> >> Hi, >> >> I'm not sure if the buzzword SD-WAN is used to compensate for another >> buzzword that got over-utilized (SDN) or it is a true 'new and improved' >> way of doing things that has some innovation into it. >> >> I heard different explanation from different vendors: >> >> 1) appliances (+ controller) placed in-line to put traffic in tunnels >> based on policy, with some DPI and traffic tagging...(to do >> performance/policy based routing) over an expensive link (MPLS) and a cheap >> one (broadband) with some 'firewall-like' filtering capabilities. >> 2) same as above, with a flavor of 'machine learning' to find a pattern >> for traffic to optimize utilization. >> 3) a controller that instantiates and tears down tunnels from 'classic >> routers' based on external policies and Network based features to do >> performance based routing over an expensive link (MPLS) and a cheap one >> (broadband) with encryption. >> >> Is the above a decent high-level summary? >> >> Has anyone tried any of these solutions, any general feedback ? >> >> Cheers, >> Kim >> >> >> >> > From henson at acm.org Sat May 6 23:27:16 2017 From: henson at acm.org (Paul B. Henson) Date: Sat, 6 May 2017 16:27:16 -0700 Subject: Socal Frontier static IP cutover? (+OT fee bitch) Message-ID: <20170506232716.GG2183@bender.unx.cpp.edu> I was wondering if anybody has been contacted yet about cutting over their static IP addresses for Frontier business FIOS? Last year my understanding was that they were lent Verizon IP space for one year and everyone needed to be cutover by 4/2017; here it is 5/2017 and I've still heard nothing of it. Did they end up permanently aquiring the IP space from Verizon? Did the cutover get pushed back? I tried calling customer service and didn't really get an answer. On another Frontier note, I got a paper bill recently, which was surprising as I've been on paperless billing forever. I noticed this gem on the bill, which is presumably why it warranted being sent physically: "Effective May 15, 2017, a Business High Speed Internet Fee of $1.99 will be added to your bill." Fucking sleezy telcos. It's the only industry that can get away with basically charging you a fee for the privilege of providing you the service you're already paying them for 8-/. Could you imagine going to McDonalds and paying $1.99 for your happy meal + a $.50 Fast Food Service Fee? Getting your house painted for $500 + a $75 Paintbrush Bristle Motion Fee? I called to ask about it and the excuse was that it's to cover "maintainance of the network". Really? So what's the other $130 a month I'm already paying you guys cover? Raise you prices if you got to raise your prices to cover costs, but again, telcos are pretty much the only industry that tags on random extra "fees" to cover basic costs of doing business. Meh, maybe it's time to see how comparatively evil the cable company is nowadays . Maybe if that $1.99 a month would actually result in IPv6 this decade... From lost at l-w.ca Mon May 8 17:59:49 2017 From: lost at l-w.ca (William Astle) Date: Mon, 8 May 2017 11:59:49 -0600 Subject: Clueful contact at Microsoft needed Message-ID: <41e41545-b23b-de89-4bb8-7e628a2956e6@l-w.ca> Apologies if this is off topic for NANOG. I need to contact someone at Microsoft who can correct problems with Microsoft accounts. I've been trying unsuccessfully to disavow a Microsoft account for some time. Note this an account someone has managed to associate with one of my email addresses. The Microsoft account does not belong to me. I've been unable to contact the account holder. I've been through their support site and system which has been singularly unhelpful (and also requires a Microsoft account just to contact anyone). It's clear the support people don't understand the problem. I mean, how does logging into the settings on my (non-microsoft) email account help solve a problem with the settings on a Microsoft account? From kemp at network-services.uoregon.edu Mon May 8 18:35:13 2017 From: kemp at network-services.uoregon.edu (John Kemp) Date: Mon, 8 May 2017 11:35:13 -0700 Subject: Interconnection Track In-Reply-To: References: Message-ID: Scheduling question: I assume this is the slot on the agenda that say: "NANOG 70 Peering Coordination Forum" I'm not seeing it on the schedule. Has a lot been assigned? John Kemp On 4/17/17 6:03 AM, Bevan Slattery wrote: > Hi! Love the interconnection track. Great stuff. But I can't help but think limiting interconnection to the peering/IXP view seems to be looking at interconnection from the rear view mirror. > > I just think that changing the track name from peering/IXP to "Interconnection" has the optionality to be a bit more looking forward. Interconnection in the network world is becoming more sophisticated and important than just old school peering (hearing the gasps of horror from the Nanog peering cabal at that statement) ;) > > Cheers > > [b] > >> On 17 Apr 2017, at 9:52 pm, Mehmet Akcin wrote: >> >> Thank you very much for sending privately and publicly an overwhelming >> number of suggestions. I do appreciate you taking time and writing things >> up in detail. I am doing my best with help of Greg H from PC to put these >> thoughts on paper. >> >> It looks like there is a great interest to make this track focusing on >> tooling and automation as well as introductions of new game changing ixps. >> >> I would like to invite all new IXPs to come and talk about what they offer >> (ie denver-ix) >> >> I also would like to invite any existing IXPs to announce price discounts >> to their services. This is the only update we will have time in this >> interconnection track. Unfortunately no graphs, other updates. >> >> Few questions, Seattle is beautiful in summer and I hope to have many of >> you in person in beautiful washington state, but for those who can't >> travel, should we record / live stream this session? (Historically we did >> keep peering track off the grid... i believe) >> >> Would it be interesting to focus on peering challenges globally or strictly >> focus on north america? >> >> Last but not least, If you have a tool you want to talk about in >> interconnection track that is directly involved with peering setup, etc. >> please do contact me offlist. >> >> Cheers! Looking forward to it. >> >>> On Sat, Apr 1, 2017 at 1:36 PM Mehmet Akcin wrote: >>> >>> Hello, >>> >>> As promised few months ago publically I have volunteered to bring together >>> content to have Peering Track back to agenda. Now called "Interconnection >>> Track" >>> >>> I would like to ask those who will attend, have attended in person in the >>> past or those who have organized similar events to chime in and help >>> suggest topics to cover in this 90 min session. >>> >>> I must say, Interconnection Track has been a major part if NANOG for many >>> years. We have watched those who we consider as legends to discuss very >>> important topics there. >>> >>> Please try to make your suggestion in order of importance for you as well >>> as from community. >>> >>> I can try to do my best with help of few folks to bring this track back >>> but you can help make it even better so please take a moment and send me >>> your suggestions. >>> >>> Thanks in advance! >>> >>> Mehmet >>> From liam at fedney.org Mon May 8 20:14:38 2017 From: liam at fedney.org (L Sean Kennedy) Date: Mon, 8 May 2017 16:14:38 -0400 Subject: Interconnection Track In-Reply-To: References: Message-ID: John, The "Peering Coordination Forum" is a dedicated session for peering or interconnection discussions. It is a more formalized version of "peering personals" which were part of the old peering BoF and are also featured at GPF as well as other events. In other words if you are interested in soliciting new peers you provide some basic information such as ASN, Peering Policy, if caching is offered, and URL to peering policy or solicitation request. NANOG is providing tables to approximately 25 organizations, will project the information provided on slides and table locations, and you can conduct bi-lateral discussions. If you are interested in peering with those networks, you find them in that forum. There is also open meeting space with tables for the whole conference for bi-lateral discussions between networks and organizations, plus the NANOG board tasked the staff to evaluate tools for scheduling meetings for future meetings. The Peering Coordination Forum is open for registration: https://nanog.org/meetings/nanog70/pcf Mehmet has submitted a proposed agenda for the Interconnection track as, which the NANOG Program Committee has to evaluate through its peer review process. We received that submission today which is somewhat late in our review cycle, so there will probably be more information after the PC meets this Thursday, but it is not currently posted to the agenda. We will be posting approved submissions and their associated time-slots to the agenda this week. Please note that we are holding a hackathon at NANOG 70 Sunday and the "challenge" is o develop tools around Peering/Interconnection automation and there will be a short tutorial on the same theme. https://nanog.org/meetings/nanog70/hackathon Sean (on behalf of the NANOG PC) 2017-05-08 14:35 GMT-04:00 John Kemp : > > Scheduling question: I assume this is the slot on the agenda that say: > "NANOG 70 Peering Coordination Forum" > > I'm not seeing it on the schedule. Has a lot been assigned? > > John Kemp > > On 4/17/17 6:03 AM, Bevan Slattery wrote: > > Hi! Love the interconnection track. Great stuff. But I can't help but > think limiting interconnection to the peering/IXP view seems to be looking > at interconnection from the rear view mirror. > > > > I just think that changing the track name from peering/IXP to > "Interconnection" has the optionality to be a bit more looking forward. > Interconnection in the network world is becoming more sophisticated and > important than just old school peering (hearing the gasps of horror from > the Nanog peering cabal at that statement) ;) > > > > Cheers > > > > [b] > > > >> On 17 Apr 2017, at 9:52 pm, Mehmet Akcin wrote: > >> > >> Thank you very much for sending privately and publicly an overwhelming > >> number of suggestions. I do appreciate you taking time and writing > things > >> up in detail. I am doing my best with help of Greg H from PC to put > these > >> thoughts on paper. > >> > >> It looks like there is a great interest to make this track focusing on > >> tooling and automation as well as introductions of new game changing > ixps. > >> > >> I would like to invite all new IXPs to come and talk about what they > offer > >> (ie denver-ix) > >> > >> I also would like to invite any existing IXPs to announce price > discounts > >> to their services. This is the only update we will have time in this > >> interconnection track. Unfortunately no graphs, other updates. > >> > >> Few questions, Seattle is beautiful in summer and I hope to have many of > >> you in person in beautiful washington state, but for those who can't > >> travel, should we record / live stream this session? (Historically we > did > >> keep peering track off the grid... i believe) > >> > >> Would it be interesting to focus on peering challenges globally or > strictly > >> focus on north america? > >> > >> Last but not least, If you have a tool you want to talk about in > >> interconnection track that is directly involved with peering setup, etc. > >> please do contact me offlist. > >> > >> Cheers! Looking forward to it. > >> > >>> On Sat, Apr 1, 2017 at 1:36 PM Mehmet Akcin wrote: > >>> > >>> Hello, > >>> > >>> As promised few months ago publically I have volunteered to bring > together > >>> content to have Peering Track back to agenda. Now called > "Interconnection > >>> Track" > >>> > >>> I would like to ask those who will attend, have attended in person in > the > >>> past or those who have organized similar events to chime in and help > >>> suggest topics to cover in this 90 min session. > >>> > >>> I must say, Interconnection Track has been a major part if NANOG for > many > >>> years. We have watched those who we consider as legends to discuss very > >>> important topics there. > >>> > >>> Please try to make your suggestion in order of importance for you as > well > >>> as from community. > >>> > >>> I can try to do my best with help of few folks to bring this track back > >>> but you can help make it even better so please take a moment and send > me > >>> your suggestions. > >>> > >>> Thanks in advance! > >>> > >>> Mehmet > >>> > From KShah at primustel.ca Mon May 8 20:54:45 2017 From: KShah at primustel.ca (Krunal Shah) Date: Mon, 8 May 2017 20:54:45 +0000 Subject: IPv6 first hop security on a budget? In-Reply-To: References: Message-ID: http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-2960-x-series-switches/data_sheet_c78-728232.html Krunal Shah Network Analyst, IP & Transport Network Engineering O: 416-855-1805 kshah at primustel.ca -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joel Whitehouse Sent: Friday, May 05, 2017 7:27 PM To: nanog at nanog.org Subject: IPv6 first hop security on a budget? What's a good budget option for switching a small lab or office ipv6 with RA Guard, DHCP6 snooping, and ICMP6 snooping? -------------------------------- This electronic message contains information from Primus Management ULC ("PRIMUS") , which may be legally privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail (to the number or address above) immediately. Any views, opinions or advice expressed in this electronic message are not necessarily the views, opinions or advice of PRIMUS. It is the responsibility of the recipient to ensure that any attachments are virus free and PRIMUS bears no responsibility for any loss or damage arising in any way from the use thereof.The term "PRIMUS" includes its affiliates. -------------------------------- Pour la version en fran?ais de ce message, veuillez voir http://www.primustel.ca/fr/legal/cs.htm From randy at psg.com Mon May 8 21:06:19 2017 From: randy at psg.com (Randy Bush) Date: Mon, 08 May 2017 23:06:19 +0200 Subject: outage Message-ID: cf brian nisbet's talk this (cest) afternoon: a fair number of researchers are obsessed with outage detection. they have a problem; outages where one can know the 'ground truth' (operator confirmation of what actually happened down to the links and times) is very hard to get. so, it would be helpful if some core networks would either report the details of an outage every week or so, or create a nice variety of planned outages and descrive the details. randy From bob at FiberInternetCenter.com Tue May 9 04:27:34 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 8 May 2017 21:27:34 -0700 Subject: Anyone here from ihotelier.com or travelclcik.com or gramtel.net Message-ID: Hello, I have 3 customers experiencing routing issues all day to admin.ihotelier.com When the problem occurs the trace stops and drops at a gramtel.net router or server. That traces through GTT then Zayo and halts at gramtel.net. When I put in a temp static around it via another transit it hops through PNAP.net and works fine. I would like to get rid of my temp route for the admin.ihotelier.com /24 range. Thanks Bob Evans CTO From bob at FiberInternetCenter.com Tue May 9 17:57:25 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 9 May 2017 10:57:25 -0700 Subject: Any one here from CyrusOne ? Message-ID: <61138cfe0340c356e867167e45be1cfb.squirrel@66.201.44.180> Hi, Looking for off-line CyrusOne NOC assistance to help our mutual customers reach each others servers. I do not think the issue is CyrusOne's , but it is most likely a CyrusOne customer's that has no network people that comprehend routing issues. 2 days now , I need a little insight. My work around is via a transit provider that does not go through a Cyrusone hop. Whenever Cyrusone and gramtel.net hop appears customer packets drop at gramtel.net hop. On GTT from Amsterdam to ihotelier.com IPv4 traceroute to 199.167.220.52 HOST: cr2-ams1-re1 Loss% Snt Last Avg Best Wrst StDev 1. lag-12.ear3.Amsterdam1.Level 0.0% 5 601.2 121.0 0.8 601.2 268.4 2. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 3. CYRUSONE-LL.ear2.Chicago2.Le 0.0% 5 94.3 94.4 94.2 94.7 0.2 4. 169.64.242.209.gt001.gramtel 0.0% 5 95.6 94.8 94.4 95.6 0.5 5. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 >From Chicago ... IPv4 traceroute to 199.167.220.52 HOST: cr1-chi1-re1 Loss% Snt Last Avg Best Wrst StDev 1. as3356.chi11.ip4.gtt.net 20.0% 5 8.4 3.0 1.0 8.4 3.6 2. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 3. CYRUSONE-LL.ear2.Chicago2.Le 0.0% 5 1.9 1.9 1.9 2.0 0.0 4. 169.64.242.209.gt001.gramtel 0.0% 5 2.1 2.4 2.1 3.1 0.5 5. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 On Hurricain Electric from Fremont to ihotelier.com hits and stops at gramtel.com core1.fmt1.he.net> traceroute 199.167.220.57 source-ip 216.218.252.161 numeric Target 199.167.220.57 1 1 ms <1 ms <1 ms 10ge7-3.core1.sjc2.he.net (72.52.92.110) 2 <1 ms <1 ms 14 ms asn-qwest-us-as209.10gigabitethernet10-10.core1.sjc2.he.net (216.218.230.250) 3 51 ms 89 ms 61 ms cer-edge-19.inet.qwest.net (67.14.122.141) 4 132 ms 48 ms 59 ms 65.123.102.162 5 63 ms 48 ms 52 ms 209.242.80.97 6 48 ms 49 ms 50 ms 169.64.242.209.gt001.gramtel.net (209.242.64.169) 7 * * * ? 8 * * Thank You Bob Evans CTO From chkuhtz at microsoft.com Tue May 9 23:58:00 2017 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Tue, 9 May 2017 23:58:00 +0000 Subject: Clueful contact at Microsoft needed In-Reply-To: <41e41545-b23b-de89-4bb8-7e628a2956e6@l-w.ca> References: <41e41545-b23b-de89-4bb8-7e628a2956e6@l-w.ca> Message-ID: William, I just got word from an internal team I had reached out to yesterday, and they told me they've just sent you an email to see how to resolve. Hope that gets you on the path to resolution. Best regards, Christian -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Astle Sent: Monday, May 8, 2017 11:00 AM To: nanog at nanog.org Subject: Clueful contact at Microsoft needed Apologies if this is off topic for NANOG. I need to contact someone at Microsoft who can correct problems with Microsoft accounts. I've been trying unsuccessfully to disavow a Microsoft account for some time. Note this an account someone has managed to associate with one of my email addresses. The Microsoft account does not belong to me. I've been unable to contact the account holder. I've been through their support site and system which has been singularly unhelpful (and also requires a Microsoft account just to contact anyone). It's clear the support people don't understand the problem. I mean, how does logging into the settings on my (non-microsoft) email account help solve a problem with the settings on a Microsoft account? From boards188 at gmail.com Tue May 9 19:13:45 2017 From: boards188 at gmail.com (Jason Pope) Date: Tue, 9 May 2017 14:13:45 -0500 Subject: Spectrum/TimeWarner IPv6 routing issue Message-ID: All, I apologize for doing this, but is there anyone on the list with Spectrum/TimeWarner that would be willing to discuss (via e-mail) an IPv6 routing issue to a cable modem? I can't put more time in with the normal support gauntlet. Thanks in advance! Jason From mrp at mrp.net Tue May 9 02:41:07 2017 From: mrp at mrp.net (Mark Prior) Date: Tue, 9 May 2017 12:11:07 +0930 Subject: AusNOG 2017 Call for Presentations Message-ID: <7cd7612d-04f7-4697-de69-92158eb78a56@mrp.net> The next AusNOG conference is only four months away, scheduled to be held at The Langham, Melbourne, on 7 & 8 September 2017, so we are making our first call for presentations of interest to the Internet operations community. Previous feedback has suggested that attendees would like more content from the community so we'd like to encourage members of the community to submit more proposals, especially if you haven't previously presented! Internet operations is a broad topic but some areas of interest are: * Improving the redundancy/resiliency/sustainability of your network * Using automation to improve service reliability * Taking the network operations BCP to the next level * Using 'offline' communications tools to keep the network working * Evolution in network architectures and scaling issues * Analysis of relevant major operational events of the year Naturally other topics that are of interest to the network operator community are also welcome but presentations of a purely marketing nature are not welcome at this technical event. Notes to presenters =-=-=-=-=-=-=-=-=-= Preference will be given to presentations that result in actual operational outcomes. Session speakers should be prepared to present for 30 minutes. Keynote speakers will be expected to present for 45 minutes to 1 hour. Short presentations of strong operational content are also acceptable. Please note any timing constraints when submitting a presentation. By submitting a presentation for consideration in the AusNOG 2017 programme, and if selected the presenter will allow AusNOG to: * Take photographs of the presentation and presenter * Record and rebroadcast video and audio of the presentation and presenter * Redistribute the presentation slides, audio, video, and photographs electronically, on the AusNOG website, or otherwise but leaving all intellectual property in the hands of presenter or rightful property holder[1]. Deadlines =-=-=-=-= 12 June: Submission of presentation title, presentation description (300 words), and presenter biography (200-400 words) 10 July: Presenters notified of their acceptance status as an AusNOG 2017 presentation. 30 August: Submission of final presentation slides as Portable Document Format (pdf), PowerPoint, or Keynote. Provision of a recent digital photograph (<500k) of the presenter. All submissions must be sent by email to organisers AT ausnog DOT net. A separate call for lightning talks will be made closer to the AusNOG 2017 event. As in previous years you must be registered to attend AusNOG 2017 in order to be considered for a lightning talk. [1]: AusNOG accepts that some speakers are unable to allow us to archive their presentation due to company or corporate policy, and if the situation arises AusNOG will delete all copies in its possession after the presentation. From lost at l-w.ca Wed May 10 19:38:27 2017 From: lost at l-w.ca (William Astle) Date: Wed, 10 May 2017 13:38:27 -0600 Subject: Clueful contact at Microsoft needed In-Reply-To: References: <41e41545-b23b-de89-4bb8-7e628a2956e6@l-w.ca> Message-ID: <7fa255a0-6c24-c4e2-78a5-84ffa6ed8b1d@l-w.ca> Thank you for that. The problem is resolved now. On 2017-05-09 05:58 PM, Christian Kuhtz via NANOG wrote: > William, > > I just got word from an internal team I had reached out to yesterday, and they told me they've just sent you an email to see how to resolve. Hope that gets you on the path to resolution. > > Best regards, > Christian > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Astle > Sent: Monday, May 8, 2017 11:00 AM > To: nanog at nanog.org > Subject: Clueful contact at Microsoft needed > > Apologies if this is off topic for NANOG. I need to contact someone at Microsoft who can correct problems with Microsoft accounts. > > I've been trying unsuccessfully to disavow a Microsoft account for some time. Note this an account someone has managed to associate with one of my email addresses. The Microsoft account does not belong to me. > > I've been unable to contact the account holder. I've been through their support site and system which has been singularly unhelpful (and also requires a Microsoft account just to contact anyone). It's clear the support people don't understand the problem. I mean, how does logging into the settings on my (non-microsoft) email account help solve a problem with the settings on a Microsoft account? > From nanog2011 at yahoo.com Thu May 11 15:34:59 2017 From: nanog2011 at yahoo.com (T Kawasaki) Date: Thu, 11 May 2017 15:34:59 +0000 (UTC) Subject: any known outage in BR? References: <1574900827.9109821.1494516899059.ref@mail.yahoo.com> Message-ID: <1574900827.9109821.1494516899059@mail.yahoo.com> does anyone know of any outage in BR, perhaps associate ATT? From listas at kurtkraut.net Thu May 11 18:19:41 2017 From: listas at kurtkraut.net (Kurt Kraut) Date: Thu, 11 May 2017 15:19:41 -0300 Subject: any known outage in BR? In-Reply-To: <1574900827.9109821.1494516899059@mail.yahoo.com> References: <1574900827.9109821.1494516899059.ref@mail.yahoo.com> <1574900827.9109821.1494516899059@mail.yahoo.com> Message-ID: Hello, Do you mean Brazil? Can you provide further details, traceroute, IPs etc.? Best Regards, Kurt Kraut 2017-05-11 12:34 GMT-03:00 T Kawasaki via NANOG : > does anyone know of any outage in BR, perhaps associate ATT? > From A.J.Caines at halplant.com Thu May 11 19:18:14 2017 From: A.J.Caines at halplant.com (Andrew J. Caines) Date: Thu, 11 May 2017 15:18:14 -0400 Subject: any known outage in BR? In-Reply-To: References: <1574900827.9109821.1494516899059.ref@mail.yahoo.com> <1574900827.9109821.1494516899059@mail.yahoo.com> Message-ID: On 05/11/2017 02:19 PM, Kurt Kraut wrote: > Do you mean Brazil? If there isn't a SANOG, there is an Outages list[1]. "Where would we be if we didn't follow the correct procedures?" - Sam Lowry [1] https://puck.nether.net/mailman/listinfo/outages -- -Andrew J. Caines- Unix Systems Architect A.J.Caines at halplant.com "Machines take me by surprise with great frequency" - Alan Turing From rubensk at gmail.com Thu May 11 20:54:53 2017 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 11 May 2017 22:54:53 +0200 Subject: any known outage in BR? In-Reply-To: References: <1574900827.9109821.1494516899059.ref@mail.yahoo.com> <1574900827.9109821.1494516899059@mail.yahoo.com> Message-ID: I'm not aware of a South America NOG list, and South Asia already uses SANOG... but there is one outages-like list for Brazil called Caiu (Portuguese for "dropped down") at https://eng.registro.br/mailman/listinfo/caiu) and there is a NOG list for Latin America called LACNOG at https://mail.lacnic.net/mailman/listinfo/lacnog . Rubens On Thu, May 11, 2017 at 9:18 PM, Andrew J. Caines wrote: > On 05/11/2017 02:19 PM, Kurt Kraut wrote: > > Do you mean Brazil? > > If there isn't a SANOG, there is an Outages list[1]. > > "Where would we be if we didn't follow the correct procedures?" - > Sam Lowry > > > [1] https://puck.nether.net/mailman/listinfo/outages > > -- > -Andrew J. Caines- Unix Systems Architect A.J.Caines at halplant.com > "Machines take me by surprise with great frequency" - Alan Turing > From nanog at afxr.net Fri May 12 00:48:23 2017 From: nanog at afxr.net (Randy) Date: Thu, 11 May 2017 19:48:23 -0500 Subject: Spectrum/TimeWarner IPv6 routing issue In-Reply-To: References: Message-ID: <4b758c4e-864c-6dda-b07c-1bcd0a2e4246@afxr.net> On 5/9/2017 2:13 PM, Jason Pope wrote: > All, > > I apologize for doing this, but is there anyone on the list with > Spectrum/TimeWarner that would be willing to discuss (via e-mail) an IPv6 > routing issue to a cable modem? I can't put more time in with the normal > support gauntlet. > > Thanks in advance! > Jason Not sure if this helps, but I had an issue with ipv6 routing on my TWc modem. It turns out I derped and accidentally enabled a firewall option to block multicast. This prevents your modem from seeing ipv6 routing solicitations, ie the modem won't be able to see what your prefix is and respond to it. If that isn't it, you'll have to do the gauntlet. From trelane at trelane.net Fri May 12 01:47:43 2017 From: trelane at trelane.net (Andrew Kirch) Date: Thu, 11 May 2017 21:47:43 -0400 Subject: Spectrum/TimeWarner IPv6 routing issue In-Reply-To: References: Message-ID: I'm a Time Warner/Spectrum customer and to date haven't been able to discern that they have any clue what IPv6 is. If it's available please contact me off list and tell me how to get it. Andrew On Tue, May 9, 2017 at 3:13 PM, Jason Pope wrote: > All, > > I apologize for doing this, but is there anyone on the list with > Spectrum/TimeWarner that would be willing to discuss (via e-mail) an IPv6 > routing issue to a cable modem? I can't put more time in with the normal > support gauntlet. > > Thanks in advance! > Jason > From cb.list6 at gmail.com Fri May 12 17:35:10 2017 From: cb.list6 at gmail.com (Ca By) Date: Fri, 12 May 2017 17:35:10 +0000 Subject: Please run windows update now Message-ID: This looks like a major worm that is going global Please run windows update as soon as possible and spread the word It may be worth also closing down ports 445 / 139 / 3389 http://www.npr.org/sections/thetwo-way/2017/05/12/528119808/large-cyber-attack-hits-englands-nhs-hospital-system-ransoms-demanded From outsider at scarynet.org Fri May 12 18:02:52 2017 From: outsider at scarynet.org (Alexander Maassen) Date: Fri, 12 May 2017 20:02:52 +0200 Subject: Please run windows update now In-Reply-To: References: Message-ID: Hail backups, and whoever keeps those ports accessible to the outside without a decent ACL in the firewall, or restricting it to (IPsec) VPN's should be shot on sight anyways. On Fri, May 12, 2017 7:35 pm, Ca By wrote: > This looks like a major worm that is going global > > Please run windows update as soon as possible and spread the word > > It may be worth also closing down ports 445 / 139 / 3389 > > http://www.npr.org/sections/thetwo-way/2017/05/12/528119808/large-cyber-attack-hits-englands-nhs-hospital-system-ransoms-demanded > From cscora at apnic.net Fri May 12 18:02:45 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 May 2017 04:02:45 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170512180245.65776C44D5@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 13 May, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 647949 Prefixes after maximum aggregation (per Origin AS): 252345 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 312474 Total ASes present in the Internet Routing Table: 57146 Prefixes per ASN: 11.34 Origin-only ASes present in the Internet Routing Table: 49440 Origin ASes announcing only one prefix: 21895 Transit ASes present in the Internet Routing Table: 7706 Transit-only ASes present in the Internet Routing Table: 225 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 40 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 70 Numnber of instances of unregistered ASNs: 74 Number of 32-bit ASNs allocated by the RIRs: 18557 Number of 32-bit ASNs visible in the Routing Table: 14400 Prefixes from 32-bit ASNs in the Routing Table: 58461 Number of bogon 32-bit ASNs visible in the Routing Table: 44 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 410 Number of addresses announced to Internet: 2844831332 Equivalent to 169 /8s, 144 /16s and 174 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.6 Total number of prefixes smaller than registry allocations: 216616 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 177386 Total APNIC prefixes after maximum aggregation: 51032 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 176560 Unique aggregates announced from the APNIC address blocks: 73228 APNIC Region origin ASes present in the Internet Routing Table: 8091 APNIC Prefixes per ASN: 21.82 APNIC Region origin ASes announcing only one prefix: 2256 APNIC Region transit ASes present in the Internet Routing Table: 1144 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2917 Number of APNIC addresses announced to Internet: 763012964 Equivalent to 45 /8s, 122 /16s and 167 /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: 197389 Total ARIN prefixes after maximum aggregation: 94167 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 199487 Unique aggregates announced from the ARIN address blocks: 91432 ARIN Region origin ASes present in the Internet Routing Table: 17904 ARIN Prefixes per ASN: 11.14 ARIN Region origin ASes announcing only one prefix: 6633 ARIN Region transit ASes present in the Internet Routing Table: 1784 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1968 Number of ARIN addresses announced to Internet: 1110060704 Equivalent to 66 /8s, 42 /16s and 46 /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: 174683 Total RIPE prefixes after maximum aggregation: 85117 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 170259 Unique aggregates announced from the RIPE address blocks: 102159 RIPE Region origin ASes present in the Internet Routing Table: 23987 RIPE Prefixes per ASN: 7.10 RIPE Region origin ASes announcing only one prefix: 11067 RIPE Region transit ASes present in the Internet Routing Table: 3393 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5809 Number of RIPE addresses announced to Internet: 711743872 Equivalent to 42 /8s, 108 /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: 81196 Total LACNIC prefixes after maximum aggregation: 18175 LACNIC Deaggregation factor: 4.47 Prefixes being announced from the LACNIC address blocks: 82436 Unique aggregates announced from the LACNIC address blocks: 38444 LACNIC Region origin ASes present in the Internet Routing Table: 5878 LACNIC Prefixes per ASN: 14.02 LACNIC Region origin ASes announcing only one prefix: 1621 LACNIC Region transit ASes present in the Internet Routing Table: 1090 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3396 Number of LACNIC addresses announced to Internet: 169891552 Equivalent to 10 /8s, 32 /16s and 86 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17191 Total AfriNIC prefixes after maximum aggregation: 3796 AfriNIC Deaggregation factor: 4.53 Prefixes being announced from the AfriNIC address blocks: 18797 Unique aggregates announced from the AfriNIC address blocks: 6848 AfriNIC Region origin ASes present in the Internet Routing Table: 1036 AfriNIC Prefixes per ASN: 18.14 AfriNIC Region origin ASes announcing only one prefix: 318 AfriNIC Region transit ASes present in the Internet Routing Table: 205 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 310 Number of AfriNIC addresses announced to Internet: 89683456 Equivalent to 5 /8s, 88 /16s and 118 /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 5570 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3829 394 282 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2986 903 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2766 11150 758 KIXS-AS-KR Korea Telecom, KR 9829 2731 1499 539 BSNL-NIB National Internet Backbone, IN 9808 2212 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2078 421 222 TATACOMM-AS TATA Communications formerl 45899 1985 1392 108 VNPT-AS-VN VNPT Corp, VN 7552 1604 1101 55 VIETEL-AS-AP Viettel Corporation, VN 9583 1576 121 542 SIFY-AS-IN Sify Limited, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 4015 2969 154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3337 1333 80 SHAW - Shaw Communications Inc., CA 18566 2181 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2069 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2007 2159 405 CHARTER-NET-HKY-NC - Charter Communicat 209 1820 5067 632 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1790 3439 574 AMAZON-02 - Amazon.com, Inc., US 30036 1759 323 327 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1692 854 230 ITCDELTA - Earthlink, Inc., US 701 1560 10578 639 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3220 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2892 1013 2070 AKAMAI-ASN1, US 9121 2360 1691 17 TTNET, TR 34984 2011 328 385 TELLCOM-AS, TR 13188 1596 99 56 TRIOLAN, UA 12479 1593 1044 52 UNI2-AS, ES 12389 1487 1362 612 ROSTELECOM-AS, RU 9198 1325 352 25 KAZTELECOM-AS, KZ 6849 1225 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3542 546 145 Telmex Colombia S.A., CO 8151 2515 3396 562 Uninet S.A. de C.V., MX 11830 2085 369 58 Instituto Costarricense de Electricidad 7303 1564 1008 251 Telecom Argentina S.A., AR 6503 1539 437 53 Axtel, S.A.B. de C.V., MX 6147 1166 377 27 Telefonica del Peru S.A.A., PE 3816 1018 496 183 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1011 2286 170 CLARO S.A., BR 11172 920 126 80 Alestra, S. de R.L. de C.V., MX 18881 893 1052 23 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1214 398 48 LINKdotNET-AS, EG 36903 713 358 123 MT-MPLS, MA 37611 705 67 7 Afrihost, ZA 36992 626 1375 26 ETISALAT-MISR, EG 24835 495 722 14 RAYA-AS, EG 29571 419 36 10 CITelecom-AS, CI 37492 406 319 74 ORANGE-, TN 8452 399 1730 17 TE-AS TE-AS, EG 15399 352 35 7 WANANCHI-, KE 2018 290 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5570 4190 74 ERX-CERNET-BKB China Education and Rese 22773 4015 2969 154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3829 394 282 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3542 546 145 Telmex Colombia S.A., CO 39891 3338 187 22 ALJAWWALSTC-AS, SA 6327 3337 1333 80 SHAW - Shaw Communications Inc., CA 8551 3220 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 17974 2986 903 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2892 1013 2070 AKAMAI-ASN1, US 4766 2766 11150 758 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 4015 3861 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3829 3547 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3542 3397 Telmex Colombia S.A., CO 39891 3338 3316 ALJAWWALSTC-AS, SA 6327 3337 3257 SHAW - Shaw Communications Inc., CA 8551 3220 3179 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2986 2913 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2360 2343 TTNET, TR 9829 2731 2192 BSNL-NIB National Internet Backbone, IN 9808 2212 2179 CMNET-GD Guangdong Mobile Communication Co.Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 36.255.248.0/24 64091 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM, RU 41.77.248.0/21 203496 AB-TELECOM, RU 41.78.12.0/23 203496 AB-TELECOM, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM, RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.141.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:280 /13:545 /14:1043 /15:1843 /16:13478 /17:7580 /18:13427 /19:24714 /20:38517 /21:41212 /22:76559 /23:63714 /24:362669 /25:840 /26:615 /27:625 /28:41 /29:25 /30:24 /31:1 /32:29 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 3168 4015 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 6327 3131 3337 SHAW - Shaw Communications Inc., CA 39891 2898 3338 ALJAWWALSTC-AS, SA 8551 2682 3220 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2074 2181 MEGAPATH5-US - MegaPath Corporation, US 9121 1678 2360 TTNET, TR 30036 1560 1759 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1474 2085 Instituto Costarricense de Electricidad y Telec 10620 1464 3542 Telmex Colombia S.A., CO 6389 1375 2069 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1606 2:827 4:27 5:2419 6:34 8:1089 12:1832 13:117 14:1789 15:26 16:2 17:121 18:120 20:54 23:2265 24:1853 25:2 27:2412 31:1923 32:89 33:8 35:20 36:398 37:2580 38:1343 39:44 40:97 41:3069 42:469 43:1924 44:71 45:2599 46:2735 47:117 49:1195 50:983 51:18 52:809 54:361 55:6 56:4 57:41 58:1574 59:1041 60:387 61:1935 62:1532 63:1921 64:4579 65:2199 66:4540 67:2257 68:1227 69:3361 70:1316 71:583 72:2189 74:2671 75:384 76:430 77:1491 78:1605 79:2045 80:1389 81:1411 82:986 83:721 84:864 85:1781 86:481 87:1161 88:791 89:2082 90:169 91:6156 92:1010 93:2382 94:2342 95:2806 96:608 97:360 98:997 99:90 100:157 101:1258 103:14651 104:2863 105:182 106:499 107:1634 108:814 109:3432 110:1339 111:1742 112:1174 113:1229 114:1041 115:1787 116:1782 117:1731 118:2159 119:1584 120:1007 121:1100 122:2261 123:1789 124:1531 125:1901 128:752 129:633 130:441 131:1384 132:524 133:190 134:622 135:223 136:455 137:442 138:1928 139:477 140:375 141:567 142:743 143:941 144:776 145:177 146:1043 147:664 148:1427 149:568 150:713 151:960 152:794 153:296 154:812 155:743 156:582 157:610 158:448 159:1449 160:647 161:752 162:2490 163:526 164:787 165:1200 166:377 167:1254 168:2641 169:781 170:3234 171:325 172:980 173:1866 174:830 175:736 176:1836 177:4080 178:2492 179:1159 180:2205 181:1856 182:2337 183:987 184:865 185:9595 186:3174 187:2220 188:2628 189:1790 190:8097 191:1308 192:9376 193:5794 194:4652 195:3848 196:2112 197:1280 198:5515 199:5885 200:7362 201:4310 202:10371 203:9878 204:4480 205:2788 206:3010 207:3146 208:4019 209:3968 210:3951 211:2133 212:2820 213:2506 214:878 215:65 216:5715 217:2080 218:835 219:607 220:1655 221:910 222:759 223:1148 End of report From royce at techsolvency.com Fri May 12 18:30:06 2017 From: royce at techsolvency.com (Royce Williams) Date: Fri, 12 May 2017 10:30:06 -0800 Subject: Please run windows update now In-Reply-To: References: Message-ID: My $0.02, for people doing internal/private triage: - If your use of IPv4 space is sparse by routes, dump your internal routing table and convert to summarized CIDR. - Feed your CIDRs to masscan [1] to scan for internal port 445 (masscan randomizes targets, so destination office WAN links won't saturate, but local/intermediate might if you're not careful, so tune): sudo masscan -p445 --rate=[packets-per-second safe for your network] -iL routes.list -oG masscan-445.out - Use https://github.com/RiskSense-Ops/MS17-010/tree/master/scanners (the python2 one, or the Metasploit one if you can use that internally) to detect vuln. the python one is not* a parallelized script, so consider breaking it into multiple parallel runners if you have a lot of scale. - If you're using SCCM/other, verify that MS17-010 was applied - but be mindful of Windows-based appliances not centrally patched, etc. Trust but verify. - In parallel, consider investigating low-hanging fruit by OU (workstations?) to disable SMBv1 entirely. Royce 1. https://github.com/robertdavidgraham/masscan On Fri, May 12, 2017 at 10:02 AM, Alexander Maassen wrote: > Hail backups, and whoever keeps those ports accessible to the outside > without a decent ACL in the firewall, or restricting it to (IPsec) VPN's > should be shot on sight anyways. > > On Fri, May 12, 2017 7:35 pm, Ca By wrote: > > This looks like a major worm that is going global > > > > Please run windows update as soon as possible and spread the word > > > > It may be worth also closing down ports 445 / 139 / 3389 > > > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > system-ransoms-demanded > > > > > From joesox at gmail.com Fri May 12 18:35:45 2017 From: joesox at gmail.com (JoeSox) Date: Fri, 12 May 2017 11:35:45 -0700 Subject: Please run windows update now In-Reply-To: References: Message-ID: Thanks for the headsup but I would expect to see some references to the patches that need to be installed to block the vulnerability (Sorry for sounding like a jerk). We all know to update systems ASAP. -- Later, Joe On Fri, May 12, 2017 at 10:35 AM, Ca By wrote: > This looks like a major worm that is going global > > Please run windows update as soon as possible and spread the word > > It may be worth also closing down ports 445 / 139 / 3389 > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > system-ransoms-demanded > From josh at imaginenetworksllc.com Fri May 12 18:44:33 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 12 May 2017 14:44:33 -0400 Subject: Please run windows update now In-Reply-To: References: Message-ID: MS17-010 https://technet.microsoft.com/en-us/library/security/ms17-010.aspx Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, May 12, 2017 at 2:35 PM, JoeSox wrote: > Thanks for the headsup but I would expect to see some references to the > patches that need to be installed to block the vulnerability (Sorry for > sounding like a jerk). > We all know to update systems ASAP. > > -- > Later, Joe > > On Fri, May 12, 2017 at 10:35 AM, Ca By wrote: > > > This looks like a major worm that is going global > > > > Please run windows update as soon as possible and spread the word > > > > It may be worth also closing down ports 445 / 139 / 3389 > > > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > > system-ransoms-demanded > > > From kauer at biplane.com.au Sat May 13 00:58:29 2017 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 13 May 2017 10:58:29 +1000 Subject: Please run windows update now In-Reply-To: References: Message-ID: <1494637109.2230.77.camel@biplane.com.au> On Fri, 2017-05-12 at 10:30 -0800, Royce Williams wrote: > - In parallel, consider investigating low-hanging fruit by OU > (workstations?) to disable SMBv1 entirely. Kaspersky reckons the exploit applies to SMBv2 as well: https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in -widespread-attacks-all-over-the-world/ I thought it was a typo in para 2 and the table, but they emailed back saying nope, SMBv2 is (was) also broken. However, they also say (same page) that the MS patch released in March this year fixes it. Assuming they are right, I wonder why Microsoft didn't mention SMBv2? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: A52E F6B9 708B 51C4 85E6?1634 0571 ADF9 3C1C 6A3A Old fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B From kmedcalf at dessus.com Sat May 13 04:43:25 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 12 May 2017 22:43:25 -0600 Subject: Please run windows update now In-Reply-To: <1494637109.2230.77.camel@biplane.com.au> Message-ID: <1a8d0cf0ce765143a1e64b5ae92b1c61@mail.dessus.com> The SMBv1 issue was disclosed a year or two ago and never patched. Anyone who was paying attention would already have disabled SMBv1. Thus is the danger and utter stupidity of "overloading" the function of service listeners with unassociated road-apples. Wait until the bad guys figure out that you can access the same "services" via a connection to the DNS port (UDP and TCP 53) on windows machines ... -- ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? > -----Original Message----- > From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com at nanog.org] On Behalf > Of Karl Auer > Sent: Friday, 12 May, 2017 18:58 > To: nanog at nanog.org > Subject: Re: Please run windows update now > > On Fri, 2017-05-12 at 10:30 -0800, Royce Williams wrote: > > - In parallel, consider investigating low-hanging fruit by OU > > (workstations?) to disable SMBv1 entirely. > > Kaspersky reckons the exploit applies to SMBv2 as well: > > https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in > -widespread-attacks-all-over-the-world/ > > I thought it was a typo in para 2 and the table, but they emailed back > saying nope, SMBv2 is (was) also broken. However, they also say (same > page) that the MS patch released in March this year fixes it. > > Assuming they are right, I wonder why Microsoft didn't mention SMBv2? > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: A52E F6B9 708B 51C4 85E6?1634 0571 ADF9 3C1C 6A3A > Old fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > From Nathan.Brookfield at simtronic.com.au Sat May 13 04:48:04 2017 From: Nathan.Brookfield at simtronic.com.au (Nathan Brookfield) Date: Sat, 13 May 2017 04:48:04 +0000 Subject: Please run windows update now In-Reply-To: <1a8d0cf0ce765143a1e64b5ae92b1c61@mail.dessus.com> References: <1494637109.2230.77.camel@biplane.com.au>, <1a8d0cf0ce765143a1e64b5ae92b1c61@mail.dessus.com> Message-ID: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> Well it was patched by Microsoft of March 14th, just clearly people running large amounts of probably Windows XP have been owned. Largely in Russia. Nathan Brookfield Chief Executive Officer Simtronic Technologies Pty Ltd http://www.simtronic.com.au On 13 May 2017, at 14:47, Keith Medcalf wrote: The SMBv1 issue was disclosed a year or two ago and never patched. Anyone who was paying attention would already have disabled SMBv1. Thus is the danger and utter stupidity of "overloading" the function of service listeners with unassociated road-apples. Wait until the bad guys figure out that you can access the same "services" via a connection to the DNS port (UDP and TCP 53) on windows machines ... -- ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? > -----Original Message----- > From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com at nanog.org] On Behalf > Of Karl Auer > Sent: Friday, 12 May, 2017 18:58 > To: nanog at nanog.org > Subject: Re: Please run windows update now > >> On Fri, 2017-05-12 at 10:30 -0800, Royce Williams wrote: >> - In parallel, consider investigating low-hanging fruit by OU >> (workstations?) to disable SMBv1 entirely. > > Kaspersky reckons the exploit applies to SMBv2 as well: > > https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in > -widespread-attacks-all-over-the-world/ > > I thought it was a typo in para 2 and the table, but they emailed back > saying nope, SMBv2 is (was) also broken. However, they also say (same > page) that the MS patch released in March this year fixes it. > > Assuming they are right, I wonder why Microsoft didn't mention SMBv2? > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: A52E F6B9 708B 51C4 85E6 1634 0571 ADF9 3C1C 6A3A > Old fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > From kmedcalf at dessus.com Sat May 13 04:56:47 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 12 May 2017 22:56:47 -0600 Subject: Please run windows update now In-Reply-To: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> Message-ID: Well, this one was patched (or more accurately, undone). Perhaps. Maybe. How many other "paid defects" do you estimate there are in Microsoft Windows waiting to be exploited when discovered (or disclosed) by someone other than the "Security Agency" buying the defect? Almost certainly more than just this one ... and almost certainly there is more than a single "payor agency" independently purchasing the deliberate introduction of code defects. -- ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? > -----Original Message----- > From: Nathan Brookfield [mailto:Nathan.Brookfield at simtronic.com.au] > Sent: Friday, 12 May, 2017 22:48 > To: Keith Medcalf > Cc: nanog at nanog.org > Subject: Re: Please run windows update now > > Well it was patched by Microsoft of March 14th, just clearly people > running large amounts of probably Windows XP have been owned. > > Largely in Russia. > > Nathan Brookfield > Chief Executive Officer > > Simtronic Technologies Pty Ltd > http://www.simtronic.com.au > > On 13 May 2017, at 14:47, Keith Medcalf wrote: > > > The SMBv1 issue was disclosed a year or two ago and never patched. > Anyone who was paying attention would already have disabled SMBv1. > > Thus is the danger and utter stupidity of "overloading" the function of > service listeners with unassociated road-apples. Wait until the bad guys > figure out that you can access the same "services" via a connection to the > DNS port (UDP and TCP 53) on windows machines ... > > -- > ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com at nanog.org] On > Behalf > > Of Karl Auer > > Sent: Friday, 12 May, 2017 18:58 > > To: nanog at nanog.org > > Subject: Re: Please run windows update now > > > >> On Fri, 2017-05-12 at 10:30 -0800, Royce Williams wrote: > >> - In parallel, consider investigating low-hanging fruit by OU > >> (workstations?) to disable SMBv1 entirely. > > > > Kaspersky reckons the exploit applies to SMBv2 as well: > > > > https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in > > -widespread-attacks-all-over-the-world/ > > > > I thought it was a typo in para 2 and the table, but they emailed back > > saying nope, SMBv2 is (was) also broken. However, they also say (same > > page) that the MS patch released in March this year fixes it. > > > > Assuming they are right, I wonder why Microsoft didn't mention SMBv2? > > > > Regards, K. > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Karl Auer (kauer at biplane.com.au) > > http://www.biplane.com.au/kauer > > http://twitter.com/kauer389 > > > > GPG fingerprint: A52E F6B9 708B 51C4 85E6 1634 0571 ADF9 3C1C 6A3A > > Old fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > > > > > From jbfixurpc at gmail.com Sat May 13 05:07:39 2017 From: jbfixurpc at gmail.com (Joe) Date: Sat, 13 May 2017 00:07:39 -0500 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> Message-ID: One word. Linux. After this we'll probably see (yet more) additional processes running on windows boxes safe guarding against issues like this, forcing windoze users to upgrade memory/processor/disk space. I, for one, am not looking at Windoze 10 S as it locks too many applications needed for work to the Windoze store. Getting kind of ridiculous if you ask me. -Joe On Fri, May 12, 2017 at 11:56 PM, Keith Medcalf wrote: > > Well, this one was patched (or more accurately, undone). Perhaps. Maybe. > > How many other "paid defects" do you estimate there are in Microsoft > Windows waiting to be exploited when discovered (or disclosed) by someone > other than the "Security Agency" buying the defect? > > Almost certainly more than just this one ... and almost certainly there is > more than a single "payor agency" independently purchasing the deliberate > introduction of code defects. > > -- > ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? > > > > -----Original Message----- > > From: Nathan Brookfield [mailto:Nathan.Brookfield at simtronic.com.au] > > Sent: Friday, 12 May, 2017 22:48 > > To: Keith Medcalf > > Cc: nanog at nanog.org > > Subject: Re: Please run windows update now > > > > Well it was patched by Microsoft of March 14th, just clearly people > > running large amounts of probably Windows XP have been owned. > > > > Largely in Russia. > > > > Nathan Brookfield > > Chief Executive Officer > > > > Simtronic Technologies Pty Ltd > > http://www.simtronic.com.au > > > > On 13 May 2017, at 14:47, Keith Medcalf wrote: > > > > > > The SMBv1 issue was disclosed a year or two ago and never patched. > > Anyone who was paying attention would already have disabled SMBv1. > > > > Thus is the danger and utter stupidity of "overloading" the function of > > service listeners with unassociated road-apples. Wait until the bad guys > > figure out that you can access the same "services" via a connection to > the > > DNS port (UDP and TCP 53) on windows machines ... > > > > -- > > ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? > > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com at nanog.org] On > > Behalf > > > Of Karl Auer > > > Sent: Friday, 12 May, 2017 18:58 > > > To: nanog at nanog.org > > > Subject: Re: Please run windows update now > > > > > >> On Fri, 2017-05-12 at 10:30 -0800, Royce Williams wrote: > > >> - In parallel, consider investigating low-hanging fruit by OU > > >> (workstations?) to disable SMBv1 entirely. > > > > > > Kaspersky reckons the exploit applies to SMBv2 as well: > > > > > > https://securelist.com/blog/incidents/78351/wannacry- > ransomware-used-in > > > -widespread-attacks-all-over-the-world/ > > > > > > I thought it was a typo in para 2 and the table, but they emailed back > > > saying nope, SMBv2 is (was) also broken. However, they also say (same > > > page) that the MS patch released in March this year fixes it. > > > > > > Assuming they are right, I wonder why Microsoft didn't mention SMBv2? > > > > > > Regards, K. > > > > > > -- > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~ > > > Karl Auer (kauer at biplane.com.au) > > > http://www.biplane.com.au/kauer > > > http://twitter.com/kauer389 > > > > > > GPG fingerprint: A52E F6B9 708B 51C4 85E6 1634 0571 ADF9 3C1C 6A3A > > > Old fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B > > > > > > > > > > > > > > From kmedcalf at dessus.com Sat May 13 05:21:51 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 12 May 2017 23:21:51 -0600 Subject: Please run windows update now In-Reply-To: Message-ID: <0b5c0b8b19c32d4bae35ae707cc3668d@mail.dessus.com> Not to mention of course that the version of Windows 10 that actually has all Microsoft's wonder-dunder-touted-all-and-fro security features is the one that most mere mortals cannot buy. I wunder. When there are these wunderful fluffings of the security of Windows 10, should one be suing Microsoft for not explicitly stating in the opening sentence that the features touted do not apply to any version of Windows that can be purchased at whim (ie, retail) and only applies to the "Enterprise" version which is *only* available with a minimum purchase quantity and the selling of the first (and second) born to Microsoft, and at that only after entering into a really nasty contract with Microsoft? Or should one be suing all the "security fools and newsfrothers" that promulgate the story without specifying that the emperors "new secure clothing" is only available to "Enterprise" customers with special contracts to Microsoft and failing to warn that Microsoft has deliberately left everyone else "naked and unprotected"? Or should one simply sue them all and let God (or a judge) sort it out? -- ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? > -----Original Message----- > From: Joe [mailto:jbfixurpc at gmail.com] > Sent: Friday, 12 May, 2017 23:08 > To: Keith Medcalf > Cc: nanog at nanog.org > Subject: Re: Please run windows update now > > One word. Linux. > > After this we'll probably see (yet more) additional processes running on > windows boxes safe guarding against issues like this, forcing windoze > users to upgrade memory/processor/disk space. I, for one, am not looking > at Windoze 10 S as it locks too many applications needed for work to the > Windoze store. > > > Getting kind of ridiculous if you ask me. > > > -Joe > > > On Fri, May 12, 2017 at 11:56 PM, Keith Medcalf > wrote: > > > > Well, this one was patched (or more accurately, undone). Perhaps. > Maybe. > > How many other "paid defects" do you estimate there are in Microsoft > Windows waiting to be exploited when discovered (or disclosed) by someone > other than the "Security Agency" buying the defect? > > Almost certainly more than just this one ... and almost certainly > there is more than a single "payor agency" independently purchasing the > deliberate introduction of code defects. > > -- > ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? > > > > -----Original Message----- > > From: Nathan Brookfield [mailto:Nathan.Brookfield at simtronic.com.au > ] > > Sent: Friday, 12 May, 2017 22:48 > > To: Keith Medcalf > > Cc: nanog at nanog.org > > Subject: Re: Please run windows update now > > > > Well it was patched by Microsoft of March 14th, just clearly > people > > running large amounts of probably Windows XP have been owned. > > > > Largely in Russia. > > > > Nathan Brookfield > > Chief Executive Officer > > > > Simtronic Technologies Pty Ltd > > http://www.simtronic.com.au > > > > On 13 May 2017, at 14:47, Keith Medcalf > wrote: > > > > > > The SMBv1 issue was disclosed a year or two ago and never patched. > > Anyone who was paying attention would already have disabled SMBv1. > > > > Thus is the danger and utter stupidity of "overloading" the > function of > > service listeners with unassociated road-apples. Wait until the > bad guys > > figure out that you can access the same "services" via a > connection to the > > DNS port (UDP and TCP 53) on windows machines ... > > > > -- > > ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? > > > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces+kmedcalf bounces%2Bkmedcalf> =dessus.com at nanog.org] On > > Behalf > > > Of Karl Auer > > > Sent: Friday, 12 May, 2017 18:58 > > > To: nanog at nanog.org > > > Subject: Re: Please run windows update now > > > > > >> On Fri, 2017-05-12 at 10:30 -0800, Royce Williams wrote: > > >> - In parallel, consider investigating low-hanging fruit by OU > > >> (workstations?) to disable SMBv1 entirely. > > > > > > Kaspersky reckons the exploit applies to SMBv2 as well: > > > > > > https://securelist.com/blog/incidents/78351/wannacry-ransomware- > used-in used-in> > > > -widespread-attacks-all-over-the-world/ > > > > > > I thought it was a typo in para 2 and the table, but they > emailed back > > > saying nope, SMBv2 is (was) also broken. However, they also say > (same > > > page) that the MS patch released in March this year fixes it. > > > > > > Assuming they are right, I wonder why Microsoft didn't mention > SMBv2? > > > > > > Regards, K. > > > > > > -- > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > Karl Auer (kauer at biplane.com.au) > > > http://www.biplane.com.au/kauer > > > > http://twitter.com/kauer389 > > > > > > GPG fingerprint: A52E F6B9 708B 51C4 85E6 1634 0571 ADF9 3C1C > 6A3A > > > Old fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB > C38B > > > > > > > > > > > > > > > From sh.vahabzadeh at gmail.com Sat May 13 10:15:51 2017 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sat, 13 May 2017 14:45:51 +0430 Subject: IRNOG1 Meeting Message-ID: Hello Hello, Proudly I want to announce that 1st IRNOG Meeting will launch at 24th of May in Tehran. In the first day of public announce we had near 90 people registered to attend the meeting. Hope to find this meeting useful in Iranian Community. It would be great to get your ideas about the experiences of coordinating such a meetings. http://ir-nog.com Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator PGP Key Fingerprint = 1C43 988E 01A8 4D95 B662 9118 CD94 9F10 4DF4 6163 From mattlists at rivervalleyinternet.net Sat May 13 15:44:14 2017 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sat, 13 May 2017 11:44:14 -0400 Subject: Carrier classification Message-ID: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> Are the terms tier-1,2,3 dead terms or still valid ways to define carriers? From cb.list6 at gmail.com Sat May 13 15:52:38 2017 From: cb.list6 at gmail.com (Ca By) Date: Sat, 13 May 2017 15:52:38 +0000 Subject: Carrier classification In-Reply-To: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> Message-ID: On Sat, May 13, 2017 at 8:45 AM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Are the terms tier-1,2,3 dead terms or still valid ways to define carriers? > Yes, pretty much dead. There are networks that meet your price / performance, and those that don't. From mattlists at rivervalleyinternet.net Sat May 13 15:55:14 2017 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sat, 13 May 2017 11:55:14 -0400 Subject: Carrier classification In-Reply-To: References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> Message-ID: <7F4ECBB5-319F-40C1-A849-9B6AFD970274@rivervalleyinternet.net> So there are now Carrier Class carriers and Food Grade Carriers? Who in the greater community defines terms like this? > On May 13, 2017, at 11:52 AM, Ca By wrote: > > >> On Sat, May 13, 2017 at 8:45 AM Matt Hoppes wrote: >> Are the terms tier-1,2,3 dead terms or still valid ways to define carriers? > > Yes, pretty much dead. > > There are networks that meet your price / performance, and those that don't. From nanog at ics-il.net Sat May 13 15:56:28 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 13 May 2017 10:56:28 -0500 (CDT) Subject: Carrier classification In-Reply-To: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> Message-ID: <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> This debate has spilled onto NANOG from Facebook now... My point is that while the term tier-1 (meaning no transit) isn't wrong, that the whole system is now irrelevant. Look at the Wikipedia list of "Tier 1" networks and then look at CAIDA, Dyn, QRator, HE's BGP Report, etc. There's some overlap between the historical "tier 1s" and the other rankings of usefulness, but the "tier 1s" are no longer the dominate networks they once were. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Matt Hoppes" To: nanog at nanog.org Sent: Saturday, May 13, 2017 10:44:14 AM Subject: Carrier classification Are the terms tier-1,2,3 dead terms or still valid ways to define carriers? From cb.list6 at gmail.com Sat May 13 16:21:06 2017 From: cb.list6 at gmail.com (Ca By) Date: Sat, 13 May 2017 16:21:06 +0000 Subject: Carrier classification In-Reply-To: <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> Message-ID: On Sat, May 13, 2017 at 9:01 AM Mike Hammett wrote: > This debate has spilled onto NANOG from Facebook now... > > My point is that while the term tier-1 (meaning no transit) isn't wrong, > that the whole system is now irrelevant. Look at the Wikipedia list of > "Tier 1" networks and then look at CAIDA, Dyn, QRator, HE's BGP Report, > etc. There's some overlap between the historical "tier 1s" and the other > rankings of usefulness, but the "tier 1s" are no longer the dominate > networks they once were. > > True. For me the distinction is nearly all carriers provide full access to the internet, -- that is their job and the product they sell. While HE and Cogent only provide a subset. In the case of Cogent, they provide an even smaller subset since they don't provide access to Google on their ISP service. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Matt Hoppes" > To: nanog at nanog.org > Sent: Saturday, May 13, 2017 10:44:14 AM > Subject: Carrier classification > > Are the terms tier-1,2,3 dead terms or still valid ways to define carriers? > > From mark.tinka at seacom.mu Sun May 14 07:18:13 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 14 May 2017 09:18:13 +0200 Subject: Carrier classification In-Reply-To: <7F4ECBB5-319F-40C1-A849-9B6AFD970274@rivervalleyinternet.net> References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> <7F4ECBB5-319F-40C1-A849-9B6AFD970274@rivervalleyinternet.net> Message-ID: <0abb5132-7308-6d9e-5432-a8840d347c71@seacom.mu> On 5/13/17 5:55 PM, Matt Hoppes wrote: > So there are now Carrier Class carriers and Food Grade Carriers? > > Who in the greater community defines terms like this? Your Sales & Marketing teams :-)... Mark. From mark.tinka at seacom.mu Sun May 14 07:24:18 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 14 May 2017 09:24:18 +0200 Subject: Carrier classification In-Reply-To: <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> Message-ID: <773d1e05-3eb2-a91d-c07d-2a35fc7e9d54@seacom.mu> On 5/13/17 5:56 PM, Mike Hammett wrote: > This debate has spilled onto NANOG from Facebook now... > > My point is that while the term tier-1 (meaning no transit) isn't wrong, that the whole system is now irrelevant. Look at the Wikipedia list of "Tier 1" networks and then look at CAIDA, Dyn, QRator, HE's BGP Report, etc. There's some overlap between the historical "tier 1s" and the other rankings of usefulness, but the "tier 1s" are no longer the dominate networks they once were. What I witnessed in Asia-Pac, Africa and parts of Europe, is that inexperienced engineers as well as sales & marketing people would use the term "Tier 1" to refer to incumbent telecoms providers, especially if they are either a monopoly or had the largest customer base in that country and/or region. Nowadays, I'm hearing this less and less, but it's not completely gone. Mark. From ekgermann at semperen.com Sun May 14 13:29:45 2017 From: ekgermann at semperen.com (Eric Germann) Date: Sun, 14 May 2017 09:29:45 -0400 Subject: BCP for securing IPv6 Linux end node in AWS Message-ID: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> Good morning all, I?m looking for some guidance on best practices to secure IPv6 on Linux end nodes parked in AWS. Boxes will be running various services (DNS for starters) and I?m looking to secure mainly ICMP at this point. Service filtering is fairly cut and dried. I?ve reviewed some of the stuff out there, but apparently I?m catching too many of the ICMP types in the rejection as routing eventually breaks. My guess is router discovery gets broken by too tight of filters. Thanks for any guidance. EKG -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3705 bytes Desc: not available URL: From alarig at swordarmor.fr Sun May 14 13:42:26 2017 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Sun, 14 May 2017 15:42:26 +0200 Subject: BCP for securing IPv6 Linux end node in AWS In-Reply-To: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> References: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> Message-ID: <20170514134225.fh2n3oxglh5wgd5a@mew.swordarmor.fr> On dim. 14 mai 09:29:45 2017, Eric Germann wrote: > Good morning all, > > I?m looking for some guidance on best practices to secure IPv6 on > Linux end nodes parked in AWS. > > Boxes will be running various services (DNS for starters) and I?m > looking to secure mainly ICMP at this point. Service filtering is > fairly cut and dried. > > I?ve reviewed some of the stuff out there, but apparently I?m catching > too many of the ICMP types in the rejection as routing eventually > breaks. My guess is router discovery gets broken by too tight of > filters. > > Thanks for any guidance. > > EKG Hi, Filtering ICMP breaks Internet and it is even more true with IPv6 as almost all the bootstrap is based on ICMP (ND, RD, RA, etc.). Plus, you will break connections where there is a MTU change on the path. So, my advise is simply to not filter ICMP and ICMPv6. And by the way, why do want to filter ICMP? You will not be DDoSed with pings. -- alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From bjorn at mork.no Sun May 14 13:54:29 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sun, 14 May 2017 15:54:29 +0200 Subject: BCP for securing IPv6 Linux end node in AWS In-Reply-To: <20170514134225.fh2n3oxglh5wgd5a@mew.swordarmor.fr> (Alarig Le Lay's message of "Sun, 14 May 2017 15:42:26 +0200") References: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> <20170514134225.fh2n3oxglh5wgd5a@mew.swordarmor.fr> Message-ID: <87mvafk0h6.fsf@miraculix.mork.no> Alarig Le Lay writes: > So, my advise is simply to not filter ICMP and ICMPv6. And by the way, > why do want to filter ICMP? You will not be DDoSed with pings. I tend to agree. But if you still want to do it, then there is some advice in https://tools.ietf.org/html/rfc4890 Bj?rn From ekgermann at semperen.com Sun May 14 13:49:44 2017 From: ekgermann at semperen.com (Eric Germann) Date: Sun, 14 May 2017 09:49:44 -0400 Subject: BCP for securing IPv6 Linux end node in AWS In-Reply-To: <20170514134225.fh2n3oxglh5wgd5a@mew.swordarmor.fr> References: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> <20170514134225.fh2n3oxglh5wgd5a@mew.swordarmor.fr> Message-ID: <63A90001-3D33-4A6C-8782-575004F6A528@semperen.com> The goal isn?t to filter _all_ ICMP. The goal is to permit ICMP that is needed for correct operation across the global network while protecting from externally spoofed packets. For example, on the IPv4 side, there arguably is no value to timestamp requests and address mask requests externally, so dump them. Thoughts? EKG > On May 14, 2017, at 9:42 AM, Alarig Le Lay wrote: > > On dim. 14 mai 09:29:45 2017, Eric Germann wrote: >> Good morning all, >> >> I?m looking for some guidance on best practices to secure IPv6 on >> Linux end nodes parked in AWS. >> >> Boxes will be running various services (DNS for starters) and I?m >> looking to secure mainly ICMP at this point. Service filtering is >> fairly cut and dried. >> >> I?ve reviewed some of the stuff out there, but apparently I?m catching >> too many of the ICMP types in the rejection as routing eventually >> breaks. My guess is router discovery gets broken by too tight of >> filters. >> >> Thanks for any guidance. >> >> EKG > > Hi, > > Filtering ICMP breaks Internet and it is even more true with IPv6 as > almost all the bootstrap is based on ICMP (ND, RD, RA, etc.). Plus, you > will break connections where there is a MTU change on the path. > > So, my advise is simply to not filter ICMP and ICMPv6. And by the way, > why do want to filter ICMP? You will not be DDoSed with pings. > > -- > alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3705 bytes Desc: not available URL: From erey at ernw.de Sun May 14 14:12:13 2017 From: erey at ernw.de (Enno Rey) Date: Sun, 14 May 2017 16:12:13 +0200 Subject: BCP for securing IPv6 Linux end node in AWS In-Reply-To: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> References: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> Message-ID: <20170514141213.GA73879@ernw.de> Hi Eric, in addition to RFC 4980 mentioned in another post you might consider the following sources as a starting point: https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-3-traffic-filtering-in-ipv6-networks-i/ https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-4-traffic-filtering-in-ipv6-networks-ii/ https://www.troopers.de/media/filer_public/85/be/85bef719-59a4-4567-aebb-ce01f9484f4d/ernw_tr16_ipv6secsummit_enterprise_security_strategy_final.pdf https://www.ernw.de/download/ERNW_Guide_to_Securely_Configure_Linux_Servers_For_IPv6_v1_0.pdf cheers Enno On Sun, May 14, 2017 at 09:29:45AM -0400, Eric Germann wrote: > Good morning all, > > I???m looking for some guidance on best practices to secure IPv6 on Linux end nodes parked in AWS. > > Boxes will be running various services (DNS for starters) and I???m looking to secure mainly ICMP at this point. Service filtering is fairly cut and dried. > > I???ve reviewed some of the stuff out there, but apparently I???m catching too many of the ICMP types in the rejection as routing eventually breaks. My guess is router discovery gets broken by too tight of filters. > > Thanks for any guidance. > > EKG > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From saku at ytti.fi Sun May 14 14:30:12 2017 From: saku at ytti.fi (Saku Ytti) Date: Sun, 14 May 2017 17:30:12 +0300 Subject: BCP for securing IPv6 Linux end node in AWS In-Reply-To: <63A90001-3D33-4A6C-8782-575004F6A528@semperen.com> References: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> <20170514134225.fh2n3oxglh5wgd5a@mew.swordarmor.fr> <63A90001-3D33-4A6C-8782-575004F6A528@semperen.com> Message-ID: On 14 May 2017 at 16:49, Eric Germann wrote: Hey, > For example, on the IPv4 side, there arguably is no value to timestamp requests and address mask requests externally, so dump them. It's very dangerous proposal when we start considering everything 0 value which isn't value to ourselves currently. Is ICMP TS known attack vector? It has one particularly useful diagnostic purpose, you can use it to measure unidirectional latencies up-to 1ms accuracy. It has on occasions reduced needed troubleshooting time and reduced amount of people who need to look into the problem. -- ++ytti From mark.tinka at seacom.mu Sun May 14 16:16:56 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 14 May 2017 18:16:56 +0200 Subject: SAFNOG-3: 4th - 7th September, 2017 - Durban, South Africa! Message-ID: <51cd14e7-3bbc-ff1a-b0db-db7dceb216bc@seacom.mu> Hello all. It gives me great pleasure to announce that SAFNOG-3 will be held between the 4th - 7th September, 2017, in the warm and sunny city of Durban, South Africa. The meeting will be held at the Southern Sun Elangeni and Maharani, a spectacular landmark on the Golden Mile. What is exciting about this year's SAFNOG meeting is that it will be partnering with iWeek 2017. Both SAFNOG and iWeek will run together, side-by-side. Details about registration and the program agenda will be made available on both the SAFNOG and iWeek web sites, as well as this mailing list. Please mark your calendars. To stay in the loop, please keep tabs on: http://safnog.org/ SAFNOG and iWeek look forward to seeing you in Durban. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From starwars1070 at gmail.com Sun May 14 19:28:15 2017 From: starwars1070 at gmail.com (Samual Carman) Date: Sun, 14 May 2017 19:28:15 +0000 Subject: Charter engineer Message-ID: Can a charter engineer please contact me off list I am getting slammed from a charter ip address on a local cable node and normal support channels have been unhelpful at bet and unwilling to escalate the issue if anyone else has any suggestion please feel free to contact Contact may be delayed as I will flying back from Dubai today In addition would a charter voice /internet engineer please contact me off list or someone who specialize in fax machines on the charter network Thanks Sam Mettai Inc Yakima, Branch Sent from my home please excuse grammar and spelling issues Sent from my iPhone Get Outlook for iOS From rsk at gsp.org Mon May 15 06:12:27 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 15 May 2017 02:12:27 -0400 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> Message-ID: <20170515061227.GA13866@gsp.org> On Sat, May 13, 2017 at 12:07:39AM -0500, Joe wrote: > One word. Linux. Or BSD, or anything but Windows. Anyone running Microsoft products is quite clearly an unprofessional, unethical moron and fully deserves all the pain they get -- including being sued into oblivion by their customers and clients for their obvious incompetence and negligence. ---rsk From valdis.kletnieks at vt.edu Mon May 15 07:47:22 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 15 May 2017 03:47:22 -0400 Subject: Please run windows update now In-Reply-To: <20170515061227.GA13866@gsp.org> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> Message-ID: <59140.1494834442@turing-police.cc.vt.edu> On Mon, 15 May 2017 02:12:27 -0400, Rich Kulawiec said: > Or BSD, or anything but Windows. Anyone running Microsoft products > is quite clearly an unprofessional, unethical moron and fully deserves > all the pain they get Tell you what. Go over to http://line6.com/software/ - You convince them to produce a Linux version of the software for their musician's gear, and I'll get rid of the Toshiba laptop running Windows. Alternatively, find me an OSX laptop that costs anywhere near the $400 I paid for the Toshiba Satellite. (And yes, I already tried running their software in a VM, neither VirtualBox or VMWare does a good enough job of emulating MIDI-over-USB2 to let the drivers in the VM connect to my Pod HD, so don't bother suggesting that). You want to repeat your claim that I'm an unprofessional, unethical moron because I have a fully patched Windows 10 laptop that's backed up on a regular basis because there's no realistic alternative? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From randy at psg.com Mon May 15 08:48:51 2017 From: randy at psg.com (Randy Bush) Date: Mon, 15 May 2017 17:48:51 +0900 Subject: Please run windows update now In-Reply-To: <20170515061227.GA13866@gsp.org> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> Message-ID: > Or BSD, or anything but Windows. Anyone running Microsoft products > is quite clearly an unprofessional, unethical moron and fully deserves > all the pain they get -- including being sued into oblivion by their > customers and clients for their obvious incompetence and negligence. aside from being grossly rude, hyperbolic, and uninteligent, this rant ignores reality enough to make you a viable presidential candidate. 80% of desk/laptops run windows. get over it. windows is embedded in many systems which will be hard to update in an hour or 100 hours. and rude ranting is not doing one micron to help deal with it. embedded systems are very hard to update, think special drivers, kinky mods, ... aside from the long softdev time, how much time do you think QA will take for moving a piece of medical equipment from xp to win10, let alone bsd? and the state of the bsd update process is not something to describe in polite company. we have a vulnerable chain from weak software (which is improving, and msoft has been in the lead there for a decade), to nsa/cia not disclosing, to people choosing or having to run old versions (of whatever (and linux/bsd are not immune) for financial or technical reasons, to the conservative or lazy logistics of patching. we can try to improve things at each link. but this is gonna be slow. though this ransomware attack is not really that much larger than other attacks in the past (and the future is not cheering), at least it has reached the front pages and maybe people will patch more and vendors will issue more/better updates. but, as @zeynep says, the lack of liability along the chain above allows bad practices to continue. in the meantime, backup, backup and take it offline so it does not get encrypted for you, patch, turn off unnecessary services/options, rinse repeat. and try to promote prudent use among friends, family, and workplace. randy From rsk at gsp.org Mon May 15 10:37:26 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 15 May 2017 06:37:26 -0400 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> Message-ID: <20170515103726.GA1204@gsp.org> You make some excellent points: but I grow very, very tired of having to spend my time and my energy -- note timestamp on my message -- dealing with the fallout. It should be painfully clear to everyone that there is no such thing as a secure Windows system. [1] It should have been painfully clear after Code Red, after the rise of bots, and after a hundred other incidents before/since of varying severity and duration. But apparently it's not and so despite the impact of this current one -- including large-scale disruption of healthcare in the UK -- this will keep happening over and over again. And even those of us who have the good judgment to never use Microsoft products have to pay the price for the poor decision-making of others. Again. And again. It's getting old. Just like all the other things that people do (many of which have been discussed here at great length) that cause problems for others who are making an earnest attempt to do things right. How bad do things have to get before the people who are stubbornly clinging to this finally let go? Does someone have to die? Because -- again, see healthcare provider impact in the UK -- we're not that far from it. ---rsk [1] There may be no such thing as a secure system, period. But it would be better to deploy things that may have a fighting chance instead of things that have long since proven to have none at all. From rsk at gsp.org Mon May 15 10:57:09 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 15 May 2017 06:57:09 -0400 Subject: BCP for securing IPv6 Linux end node in AWS In-Reply-To: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> References: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> Message-ID: <20170515105709.GA4589@gsp.org> On Sun, May 14, 2017 at 09:29:45AM -0400, Eric Germann wrote: > I???ve reviewed some of the stuff out there, but apparently I???m > catching too many of the ICMP types in the rejection as routing eventually > breaks. My guess is router discovery gets broken by too tight of filters. That's a good guess, but I would also guess that path MTU discovery may be breaking. (Or not.) I think you may want to implement RFC 4890, with a look at RFC 4443. ---rsk From jordi.palet at consulintel.es Mon May 15 11:18:29 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 15 May 2017 13:18:29 +0200 Subject: BCP for securing IPv6 Linux end node in AWS In-Reply-To: <20170515105709.GA4589@gsp.org> References: <30DE8DBE-D609-492C-A0F6-E65543AD0BC9@semperen.com> <20170515105709.GA4589@gsp.org> Message-ID: <03688C7E-0FDF-461E-8B6E-EBD24333C654@consulintel.es> Just make sure that nothing breaks PTB as it happens if you don?t pay attention to ECMP. RFC7690 1&1 in Germany has this issue since at least 18-24 months ago, so all their customers with IPv6 enabled are *broken* for anyone having a smaller MTU because tunnels or the ISP technology, etc. They are aware of that, I told them for many months, but is not yet fixed, so make sure you don?t use those data centers if you want to enable IPv6. You can check this with any of their IPv6 enabled sites (thousands I guess), for example http://diskmakerx.com/ And a nice tool to check it: https://nat64check.go6lab.si/ Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Rich Kulawiec Responder a: Fecha: lunes, 15 de mayo de 2017, 12:57 Para: nanog list Asunto: Re: BCP for securing IPv6 Linux end node in AWS On Sun, May 14, 2017 at 09:29:45AM -0400, Eric Germann wrote: > I???ve reviewed some of the stuff out there, but apparently I???m > catching too many of the ICMP types in the rejection as routing eventually > breaks. My guess is router discovery gets broken by too tight of filters. That's a good guess, but I would also guess that path MTU discovery may be breaking. (Or not.) I think you may want to implement RFC 4890, with a look at RFC 4443. ---rsk ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From mdavids at forfun.net Mon May 15 11:31:12 2017 From: mdavids at forfun.net (Marco Davids (Private)) Date: Mon, 15 May 2017 13:31:12 +0200 Subject: Question to Google Message-ID: Hi, Anyone knows why coogle.com only have IPv4-adresses on their authoritative DNS? https://ip6.nl/#!google.com Are there any plans to fix this? -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3823 bytes Desc: S/MIME Cryptographic Signature URL: From randy at psg.com Mon May 15 11:44:40 2017 From: randy at psg.com (Randy Bush) Date: Mon, 15 May 2017 20:44:40 +0900 Subject: Please run windows update now In-Reply-To: <20170515103726.GA1204@gsp.org> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> Message-ID: fyi, current opinion in the security community seems to be that win10 is better secured than linuxes, bsds, ... see http://cyber-itl.org/; still pretty sparse, but getting flushed out. randy From marka at isc.org Mon May 15 12:30:52 2017 From: marka at isc.org (Mark Andrews) Date: Mon, 15 May 2017 22:30:52 +1000 Subject: Question to Google In-Reply-To: Your message of "Mon, 15 May 2017 13:31:12 +0200." References: Message-ID: <20170515123052.661246EB8DD9@rock.dv.isc.org> In message , "Marco Davids (Pr ivate)" writes: > > Hi, > > Anyone knows why coogle.com only have IPv4-adresses on their > authoritative DNS? > > https://ip6.nl/#!google.com > > Are there any plans to fix this? > > -- > Marco Lorenzo's reply to this statement Google isn't reachable. ?? There are no IPv6 servers for google.com. was Unfortunately, every time we've looked at the data, the conclusion has been that it would cause unwarranted user impact. IIRC the most recent blocker was a major US ISP whose clients would experience breakage if even just one NS record was dual-stacked. It's not an infrastructure problem: the servers have supported IPv6 for years, and some zones like google.fi do have IPv6 NS records. See Message-ID: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bortzmeyer at nic.fr Mon May 15 12:43:59 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 15 May 2017 14:43:59 +0200 Subject: Question to Google In-Reply-To: <20170515123052.661246EB8DD9@rock.dv.isc.org> References: <20170515123052.661246EB8DD9@rock.dv.isc.org> Message-ID: <20170515124359.a3o7evaostrvm3tk@nic.fr> > Unfortunately, every time we've looked at the data, the > conclusion has been that it would cause unwarranted user > impact. IIRC the most recent blocker was a major US ISP whose > clients would experience breakage if even just one NS record > was dual-stacked. There are many zones (including your isc.org) that have several name servers dual-stacked, and they didn't notice a problem. Furthermore, since the DNS is a tree, resolution of google.com requires a proper resolution of the root and .com, both having IPv6 name servers. So, this answer is at least insufficient. From marka at isc.org Mon May 15 13:00:31 2017 From: marka at isc.org (Mark Andrews) Date: Mon, 15 May 2017 23:00:31 +1000 Subject: Question to Google In-Reply-To: Your message of "Mon, 15 May 2017 14:43:59 +0200." <20170515124359.a3o7evaostrvm3tk@nic.fr> References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> Message-ID: <20170515130031.3AF0A6EB92B9@rock.dv.isc.org> In message <20170515124359.a3o7evaostrvm3tk at nic.fr>, Stephane Bortzmeyer writes : > > Unfortunately, every time we've looked at the data, the > > conclusion has been that it would cause unwarranted user > > impact. IIRC the most recent blocker was a major US ISP whose > > clients would experience breakage if even just one NS record > > was dual-stacked. > > There are many zones (including your isc.org) that have several name > servers dual-stacked, and they didn't notice a problem. Furthermore, > since the DNS is a tree, resolution of google.com requires a proper > resolution of the root and .com, both having IPv6 name servers. > > So, this answer is at least insufficient. It wouldn't suprise me if the dispute between Google and Cogent was not part of the issue. Pure speculation on my part. I could be completely off base. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From toddunder at gmail.com Mon May 15 13:20:17 2017 From: toddunder at gmail.com (Todd Underwood) Date: Mon, 15 May 2017 09:20:17 -0400 Subject: Question to Google In-Reply-To: <20170515124359.a3o7evaostrvm3tk@nic.fr> References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> Message-ID: On Mon, May 15, 2017 at 8:43 AM, Stephane Bortzmeyer wrote: > > There are many zones (including your isc.org) that have several name > servers dual-stacked, and they didn't notice a problem. Furthermore, > since the DNS is a tree, resolution of google.com requires a proper > resolution of the root and .com, both having IPv6 name servers. > "didn't notice a problem" is woefully insufficient here. how carefully was this measured? how was it measured? across what diversity of traffic. what was the threshold for "a problem" here. different use cases have different tolerances for the kinds of bad user experience that google is concerned about here, both in terms of percentage and in amount of impact. please note that google has been super aggressively implementing and promoting IPv6 for years, so implications that this is somehow related to Google dragging their feet are silly. t > > So, this answer is at least insufficient. > From randy at psg.com Mon May 15 13:33:10 2017 From: randy at psg.com (Randy Bush) Date: Mon, 15 May 2017 22:33:10 +0900 Subject: Question to Google In-Reply-To: <20170515130031.3AF0A6EB92B9@rock.dv.isc.org> References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> <20170515130031.3AF0A6EB92B9@rock.dv.isc.org> Message-ID: > It wouldn't suprise me if the dispute between Google and Cogent was > not part of the issue. Pure speculation on my part. I could be > completely off base. here in japan, if you are using ntt bflets layer two, your layer three provider is likely to present you with a dns server which does not return AAAAs because the v6 connectivity over ntt bflets transport sucks caterpillar snot. it's a whacky world. as geoff said long ago, if there ever is real money counting on v6 transport, these messes will straighten out. randy From toddunder at gmail.com Mon May 15 13:47:22 2017 From: toddunder at gmail.com (Todd Underwood) Date: Mon, 15 May 2017 09:47:22 -0400 Subject: Question to Google In-Reply-To: References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> <20170515130031.3AF0A6EB92B9@rock.dv.isc.org> Message-ID: On Mon, May 15, 2017 at 9:33 AM, Randy Bush wrote: > > it's a whacky world. as geoff said long ago, if there ever is real > money counting on v6 transport, these messes will straighten out. > totally agree. and i'd like someone else to volunteer the "real money" traffic, please. :-) t From bjorn at mork.no Mon May 15 13:49:55 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Mon, 15 May 2017 15:49:55 +0200 Subject: Question to Google In-Reply-To: (Todd Underwood's message of "Mon, 15 May 2017 09:20:17 -0400") References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> Message-ID: <877f1ii60s.fsf@miraculix.mork.no> Todd Underwood writes: > On Mon, May 15, 2017 at 8:43 AM, Stephane Bortzmeyer > wrote: > >> >> There are many zones (including your isc.org) that have several name >> servers dual-stacked, and they didn't notice a problem. Furthermore, >> since the DNS is a tree, resolution of google.com requires a proper >> resolution of the root and .com, both having IPv6 name servers. >> > > "didn't notice a problem" is woefully insufficient here. > > how carefully was this measured? how was it measured? across what > diversity of traffic. what was the threshold for "a problem" here. Agreed. Most domain owners/zone admins probably would not notice this, even if it was a very real problem for one or two ISPs. But given that, I do wonder how such an ISP could provide any service at all. As pointed out by Stephane, there are so many zones having dual stacked DNS servers nowadays that one more or less makes little difference. Even if that zone is google.com. The rest of the world are dual stacked wrt DNS, with very few exceptions. What about the root zone? Or microsoft.com? Or facebook.com? No users interested in either of those? Only google.com? Sorry, I do not buy the excuse. Bj?rn From bortzmeyer at nic.fr Mon May 15 14:06:54 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 15 May 2017 16:06:54 +0200 Subject: Question to Google In-Reply-To: References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> Message-ID: <20170515140654.oad6pvxz27wq46rj@nic.fr> On Mon, May 15, 2017 at 09:20:17AM -0400, Todd Underwood wrote a message of 66 lines which said: > so implications that this is somehow related to Google dragging > their feet are silly. Implying that the root name server operators, or Verisign (manager of the .com name servers) did not test very thoroughly that everything is fine with their DNS service is just as silly. From morrowc.lists at gmail.com Mon May 15 14:31:19 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 May 2017 10:31:19 -0400 Subject: Question to Google In-Reply-To: <20170515140654.oad6pvxz27wq46rj@nic.fr> References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> <20170515140654.oad6pvxz27wq46rj@nic.fr> Message-ID: On Mon, May 15, 2017 at 10:06 AM, Stephane Bortzmeyer wrote: > On Mon, May 15, 2017 at 09:20:17AM -0400, > Todd Underwood wrote > a message of 66 lines which said: > > > so implications that this is somehow related to Google dragging > > their feet are silly. > > Implying that the root name server operators, or Verisign (manager of > the .com name servers) did not test very thoroughly that everything is > fine with their DNS service is just as silly. > I don't think that was todd's implication. I had thought i saw lorenzo/erik with some presentation materials about how ipv6 (and dns) can go wrong. I know geoff has presentation work on this matter, which he's given at least at IEPG meetings in the past. there is work ongoing though, it seems: ;; ANSWER SECTION: google.fi. 345600 IN NS ns2.google.com. google.fi. 345600 IN NS ns4.google.com. google.fi. 345600 IN NS ns1.google.com. google.fi. 300 IN NS ns3ds.google.com. ;; Query time: 10 msec ;; SERVER: 4.2.2.2#53(4.2.2.2) ;; ANSWER SECTION: ns3ds.google.com. 300 IN AAAA 2001:4860:4802:36::a -chris From andrew at thekerrs.ca Fri May 12 21:05:44 2017 From: andrew at thekerrs.ca (Andrew Kerr) Date: Fri, 12 May 2017 21:05:44 +0000 Subject: Please run windows update now In-Reply-To: References: Message-ID: Just a note folks that while this particular ransomware is using the MS17-010 exploit to help spread, it does not rely on it. This is still a regular piece of ransomware that if someone opens the malicious file, will encrypt files. SANS has some IoCs and more information: https://isc.sans.edu/forums/diary/Massive+wave+of+ransomware+ongoing/22412/ On Fri, 12 May 2017 at 11:45 Josh Luthman wrote: > MS17-010 > https://technet.microsoft.com/en-us/library/security/ms17-010.aspx > > > Josh Luthman > Office: 937-552-2340 <(937)%20552-2340> > Direct: 937-552-2343 <(937)%20552-2343> > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Fri, May 12, 2017 at 2:35 PM, JoeSox wrote: > > > Thanks for the headsup but I would expect to see some references to the > > patches that need to be installed to block the vulnerability (Sorry for > > sounding like a jerk). > > We all know to update systems ASAP. > > > > -- > > Later, Joe > > > > On Fri, May 12, 2017 at 10:35 AM, Ca By wrote: > > > > > This looks like a major worm that is going global > > > > > > Please run windows update as soon as possible and spread the word > > > > > > It may be worth also closing down ports 445 / 139 / 3389 > > > > > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > > > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > > > system-ransoms-demanded > > > > > > From jmamodio at gmail.com Mon May 15 09:21:45 2017 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 15 May 2017 04:21:45 -0500 Subject: Please run windows update now In-Reply-To: <20170515061227.GA13866@gsp.org> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> Message-ID: With that kind of attitude and disconnect from reality I wonder who is the unprofessional moron... - Jorge (mobile) > On May 15, 2017, at 1:12 AM, Rich Kulawiec wrote: > >> On Sat, May 13, 2017 at 12:07:39AM -0500, Joe wrote: >> One word. Linux. > > Or BSD, or anything but Windows. Anyone running Microsoft products > is quite clearly an unprofessional, unethical moron and fully deserves > all the pain they get -- including being sued into oblivion by their > customers and clients for their obvious incompetence and negligence. > > ---rsk From nefink at gmail.com Sat May 13 06:07:20 2017 From: nefink at gmail.com (Nathan Fink) Date: Sat, 13 May 2017 01:07:20 -0500 Subject: Please run windows update now In-Reply-To: References: Message-ID: I show MS17-010 as already superseded in SCCM On Fri, May 12, 2017 at 1:44 PM, Josh Luthman wrote: > MS17-010 > https://technet.microsoft.com/en-us/library/security/ms17-010.aspx > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Fri, May 12, 2017 at 2:35 PM, JoeSox wrote: > > > Thanks for the headsup but I would expect to see some references to the > > patches that need to be installed to block the vulnerability (Sorry for > > sounding like a jerk). > > We all know to update systems ASAP. > > > > -- > > Later, Joe > > > > On Fri, May 12, 2017 at 10:35 AM, Ca By wrote: > > > > > This looks like a major worm that is going global > > > > > > Please run windows update as soon as possible and spread the word > > > > > > It may be worth also closing down ports 445 / 139 / 3389 > > > > > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > > > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > > > system-ransoms-demanded > > > > > > From mattmathis at google.com Mon May 15 14:11:56 2017 From: mattmathis at google.com (Matt Mathis) Date: Mon, 15 May 2017 07:11:56 -0700 Subject: Question to Google In-Reply-To: References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> <20170515130031.3AF0A6EB92B9@rock.dv.isc.org> Message-ID: One badly configured mid sized ISP might blow search's entire failure budget. (Read the SRE book.) I have been trying for years to get somebody to do a measurement to show that properly configured dual stack generally has better user QoE than either protocol alone, largely because CGN doesn't scale well enough. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, May 15, 2017 at 6:33 AM, Randy Bush wrote: > > It wouldn't suprise me if the dispute between Google and Cogent was > > not part of the issue. Pure speculation on my part. I could be > > completely off base. > > here in japan, if you are using ntt bflets layer two, your layer three > provider is likely to present you with a dns server which does not > return AAAAs because the v6 connectivity over ntt bflets transport sucks > caterpillar snot. > > it's a whacky world. as geoff said long ago, if there ever is real > money counting on v6 transport, these messes will straighten out. > > randy > From josh at imaginenetworksllc.com Mon May 15 14:44:35 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 15 May 2017 10:44:35 -0400 Subject: Please run windows update now In-Reply-To: References: Message-ID: Link? I only posted it as reference to the vulnerability. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, May 13, 2017 at 2:07 AM, Nathan Fink wrote: > I show MS17-010 as already superseded in SCCM > > On Fri, May 12, 2017 at 1:44 PM, Josh Luthman > > wrote: > > > MS17-010 > > https://technet.microsoft.com/en-us/library/security/ms17-010.aspx > > > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > > On Fri, May 12, 2017 at 2:35 PM, JoeSox wrote: > > > > > Thanks for the headsup but I would expect to see some references to the > > > patches that need to be installed to block the vulnerability (Sorry for > > > sounding like a jerk). > > > We all know to update systems ASAP. > > > > > > -- > > > Later, Joe > > > > > > On Fri, May 12, 2017 at 10:35 AM, Ca By wrote: > > > > > > > This looks like a major worm that is going global > > > > > > > > Please run windows update as soon as possible and spread the word > > > > > > > > It may be worth also closing down ports 445 / 139 / 3389 > > > > > > > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > > > > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > > > > system-ransoms-demanded > > > > > > > > > > From damian at google.com Mon May 15 14:55:41 2017 From: damian at google.com (Damian Menscher) Date: Mon, 15 May 2017 07:55:41 -0700 Subject: Question to Google In-Reply-To: <20170515140654.oad6pvxz27wq46rj@nic.fr> References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> <20170515140654.oad6pvxz27wq46rj@nic.fr> Message-ID: On Mon, May 15, 2017 at 7:06 AM, Stephane Bortzmeyer wrote: > On Mon, May 15, 2017 at 09:20:17AM -0400, > Todd Underwood wrote > a message of 66 lines which said: > > > so implications that this is somehow related to Google dragging > > their feet are silly. > > Implying that the root name server operators, or Verisign (manager of > the .com name servers) did not test very thoroughly that everything is > fine with their DNS service is just as silly. > I guess it's obvious they had different techniques for measuring the impact of their changes.... Can you point to published studies where the root and .com server operators analyzed Todd's questions? """ "didn't notice a problem" is woefully insufficient here. how carefully was this measured? how was it measured? across what diversity of traffic. what was the threshold for "a problem" here. different use cases have different tolerances for the kinds of bad user experience that google is concerned about here, both in terms of percentage and in amount of impact. """ As others have said, things will improve as more sites go dual-stack, and google.com will enable dual-stack as soon as it's viable. In the meantime, we encourage our competitors to try. ;) Damian From brad at shub-internet.org Mon May 15 14:57:28 2017 From: brad at shub-internet.org (Brad Knowles) Date: Mon, 15 May 2017 09:57:28 -0500 Subject: Please run windows update now In-Reply-To: <20170515103726.GA1204@gsp.org> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> Message-ID: <754D32AB-54FC-4B9B-954F-B00C39E2A97A@shub-internet.org> On May 15, 2017, at 5:37 AM, Rich Kulawiec wrote: > [1] There may be no such thing as a secure system, period. But it > would be better to deploy things that may have a fighting chance > instead of things that have long since proven to have none at all. As much as I hate, loathe, and despise Microsoft, there's always going to be someone/something out there that is "the worst". Eliminate the current "worst", and there will be another one right behind them. I do believe that Microsoft is directly responsible for trillions of dollars/euros of damage done to economies worldwide, due to their lax security practices over the years. Their advances have only come at the cost of great pain on the part of others, and they have been kicking and screaming all the while being dragged into the modern world. The rest of us will continue to bear the pain and anguish that they create. That's just the way things are. Not the way they should be, but the way they are. -- Brad Knowles From bortzmeyer at nic.fr Mon May 15 15:07:11 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 15 May 2017 17:07:11 +0200 Subject: Question to Google In-Reply-To: References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> <20170515140654.oad6pvxz27wq46rj@nic.fr> Message-ID: <20170515150711.kjv4udwlmi4woctn@nic.fr> On Mon, May 15, 2017 at 07:55:41AM -0700, Damian Menscher wrote a message of 82 lines which said: > Can you point to published studies where the root and .com server > operators analyzed Todd's questions? For the root, the most comprehensive one is probably SAC 18 A good summary is From joquendo at e-fensive.net Mon May 15 15:08:19 2017 From: joquendo at e-fensive.net (J. Oquendo) Date: Mon, 15 May 2017 10:08:19 -0500 Subject: Please run windows update now In-Reply-To: <754D32AB-54FC-4B9B-954F-B00C39E2A97A@shub-internet.org> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <754D32AB-54FC-4B9B-954F-B00C39E2A97A@shub-internet.org> Message-ID: <20170515150819.GA31705@e-fensive.net> On Mon, 15 May 2017, Brad Knowles wrote: > As much as I hate, loathe, and despise Microsoft, there's always going to be someone/something out there that is "the worst". Eliminate the current "worst", and there will be another one right behind them. > > I do believe that Microsoft is directly responsible for trillions of dollars/euros of damage done to economies worldwide, due to their lax security practices over the years. Their advances have only come at the cost of great pain on the part of others, and they have been kicking and screaming all the while being dragged into the modern world. > > The rest of us will continue to bear the pain and anguish that they create. That's just the way things are. Not the way they should be, but the way they are. > > -- > Brad Knowles Spot on. Shame on Microsoft for releasing patches and not forcing the installation versus letting security managers open up ISC^, and other nonsensical frameworks to do things like "change/patch management" tasks. I mean, who cares if one little patch knocks a business out of existence. I do believe Microsoft is directly responsible for making people such daft "To patch or not to patch" admins. Force feed patches on everyone! Then your next message will be: "I believe Microsoft is responsible for trillions of dollars by pushing out patches forcefully and negatively impacting businesses worldwide." Pain and anguish? I'm smiling and drinking coffee. I adore when security shenanigas occur. That is the sound of a cash register to me. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From timrutherford at c4.net Mon May 15 15:11:59 2017 From: timrutherford at c4.net (timrutherford at c4.net) Date: Mon, 15 May 2017 11:11:59 -0400 Subject: Please run windows update now In-Reply-To: References: Message-ID: <00b401d2cd8d$996595a0$cc30c0e0$@c4.net> They even released updates for XP & 2003 http://www.catalog.update.microsoft.com/search.aspx?q=4012598 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman Sent: Monday, May 15, 2017 10:45 AM To: Nathan Fink Cc: nanog at nanog.org Subject: Re: Please run windows update now Link? I only posted it as reference to the vulnerability. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, May 13, 2017 at 2:07 AM, Nathan Fink wrote: > I show MS17-010 as already superseded in SCCM > > On Fri, May 12, 2017 at 1:44 PM, Josh Luthman > > > wrote: > > > MS17-010 > > https://technet.microsoft.com/en-us/library/security/ms17-010.aspx > > > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > > On Fri, May 12, 2017 at 2:35 PM, JoeSox wrote: > > > > > Thanks for the headsup but I would expect to see some references > > > to the patches that need to be installed to block the > > > vulnerability (Sorry for sounding like a jerk). > > > We all know to update systems ASAP. > > > > > > -- > > > Later, Joe > > > > > > On Fri, May 12, 2017 at 10:35 AM, Ca By wrote: > > > > > > > This looks like a major worm that is going global > > > > > > > > Please run windows update as soon as possible and spread the > > > > word > > > > > > > > It may be worth also closing down ports 445 / 139 / 3389 > > > > > > > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > > > > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > > > > system-ransoms-demanded > > > > > > > > > > From timrutherford at c4.net Mon May 15 15:22:42 2017 From: timrutherford at c4.net (timrutherford at c4.net) Date: Mon, 15 May 2017 11:22:42 -0400 Subject: Please run windows update now References: Message-ID: <00c201d2cd8f$192f18a0$4b8d49e0$@c4.net> I should clarify, the link in my email below is only for windows versions that are considered unsupported. This one has links for the currently supported versions of windows https://support.microsoft.com/en-us/help/4013389/title -----Original Message----- From: timrutherford at c4.net [mailto:timrutherford at c4.net] Sent: Monday, May 15, 2017 11:12 AM To: 'Josh Luthman' ; 'Nathan Fink' Cc: 'nanog at nanog.org' Subject: RE: Please run windows update now They even released updates for XP & 2003 http://www.catalog.update.microsoft.com/search.aspx?q=4012598 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman Sent: Monday, May 15, 2017 10:45 AM To: Nathan Fink Cc: nanog at nanog.org Subject: Re: Please run windows update now Link? I only posted it as reference to the vulnerability. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, May 13, 2017 at 2:07 AM, Nathan Fink wrote: > I show MS17-010 as already superseded in SCCM > > On Fri, May 12, 2017 at 1:44 PM, Josh Luthman > > > wrote: > > > MS17-010 > > https://technet.microsoft.com/en-us/library/security/ms17-010.aspx > > > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > > On Fri, May 12, 2017 at 2:35 PM, JoeSox wrote: > > > > > Thanks for the headsup but I would expect to see some references > > > to the patches that need to be installed to block the > > > vulnerability (Sorry for sounding like a jerk). > > > We all know to update systems ASAP. > > > > > > -- > > > Later, Joe > > > > > > On Fri, May 12, 2017 at 10:35 AM, Ca By wrote: > > > > > > > This looks like a major worm that is going global > > > > > > > > Please run windows update as soon as possible and spread the > > > > word > > > > > > > > It may be worth also closing down ports 445 / 139 / 3389 > > > > > > > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > > > > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > > > > system-ransoms-demanded > > > > > > > > > > From kmedcalf at dessus.com Mon May 15 15:44:28 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 15 May 2017 09:44:28 -0600 Subject: Please run windows update now In-Reply-To: <00c201d2cd8f$192f18a0$4b8d49e0$@c4.net> Message-ID: <2263139745685a44881de63a174558fa@mail.dessus.com> I do not see any links to actually download the actual patches. Just a bunch of text drivel. -- ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > timrutherford at c4.net > Sent: Monday, 15 May, 2017 09:23 > To: 'Josh Luthman'; 'Nathan Fink' > Cc: nanog at nanog.org > Subject: RE: Please run windows update now > > I should clarify, the link in my email below is only for windows versions > that are considered unsupported. > > This one has links for the currently supported versions of windows > > https://support.microsoft.com/en-us/help/4013389/title > > > -----Original Message----- > From: timrutherford at c4.net [mailto:timrutherford at c4.net] > Sent: Monday, May 15, 2017 11:12 AM > To: 'Josh Luthman' ; 'Nathan Fink' > > Cc: 'nanog at nanog.org' > Subject: RE: Please run windows update now > > They even released updates for XP & 2003 > > http://www.catalog.update.microsoft.com/search.aspx?q=4012598 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman > Sent: Monday, May 15, 2017 10:45 AM > To: Nathan Fink > Cc: nanog at nanog.org > Subject: Re: Please run windows update now > > Link? > > I only posted it as reference to the vulnerability. > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Sat, May 13, 2017 at 2:07 AM, Nathan Fink wrote: > > > I show MS17-010 as already superseded in SCCM > > > > On Fri, May 12, 2017 at 1:44 PM, Josh Luthman > > > > > > wrote: > > > > > MS17-010 > > > https://technet.microsoft.com/en-us/library/security/ms17-010.aspx > > > > > > > > > Josh Luthman > > > Office: 937-552-2340 > > > Direct: 937-552-2343 > > > 1100 Wayne St > > > Suite 1337 > > > Troy, OH 45373 > > > > > > On Fri, May 12, 2017 at 2:35 PM, JoeSox wrote: > > > > > > > Thanks for the headsup but I would expect to see some references > > > > to the patches that need to be installed to block the > > > > vulnerability (Sorry for sounding like a jerk). > > > > We all know to update systems ASAP. > > > > > > > > -- > > > > Later, Joe > > > > > > > > On Fri, May 12, 2017 at 10:35 AM, Ca By wrote: > > > > > > > > > This looks like a major worm that is going global > > > > > > > > > > Please run windows update as soon as possible and spread the > > > > > word > > > > > > > > > > It may be worth also closing down ports 445 / 139 / 3389 > > > > > > > > > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > > > > > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > > > > > system-ransoms-demanded > > > > > > > > > > > > > > > From Charles.Manser at charter.com Mon May 15 15:40:40 2017 From: Charles.Manser at charter.com (Manser, Charles J) Date: Mon, 15 May 2017 15:40:40 +0000 Subject: Charter engineer In-Reply-To: References: Message-ID: <52e0238bd3214abb8abe6ab93cad42f8@SC58MEXGP036.CORP.CHARTERCOM.com> Mr. Carman, Did someone already reach out to you off-list? Charles Manser | Principal Engineer I, Network Security | [c] 813-422-4281 14810 Grasslands Dr, Englewood, CO 80112 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Samual Carman Sent: Sunday, May 14, 2017 1:28 PM To: nanog at nanog.org Subject: Charter engineer Can a charter engineer please contact me off list I am getting slammed from a charter ip address on a local cable node and normal support channels have been unhelpful at bet and unwilling to escalate the issue if anyone else has any suggestion please feel free to contact Contact may be delayed as I will flying back from Dubai today In addition would a charter voice /internet engineer please contact me off list or someone who specialize in fax machines on the charter network Thanks Sam Mettai Inc Yakima, Branch Sent from my home please excuse grammar and spelling issues Sent from my iPhone Get Outlook for iOS 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 keiths at neilltech.com Mon May 15 15:48:37 2017 From: keiths at neilltech.com (Keith Stokes) Date: Mon, 15 May 2017 15:48:37 +0000 Subject: Please run windows update now In-Reply-To: <2263139745685a44881de63a174558fa@mail.dessus.com> References: <2263139745685a44881de63a174558fa@mail.dessus.com> Message-ID: https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/ Look near the bottom under Further Resources. On May 15, 2017, at 10:44 AM, Keith Medcalf > wrote: I do not see any links to actually download the actual patches. Just a bunch of text drivel. -- ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of timrutherford at c4.net Sent: Monday, 15 May, 2017 09:23 To: 'Josh Luthman'; 'Nathan Fink' Cc: nanog at nanog.org Subject: RE: Please run windows update now I should clarify, the link in my email below is only for windows versions that are considered unsupported. This one has links for the currently supported versions of windows https://support.microsoft.com/en-us/help/4013389/title -----Original Message----- From: timrutherford at c4.net [mailto:timrutherford at c4.net] Sent: Monday, May 15, 2017 11:12 AM To: 'Josh Luthman' ; 'Nathan Fink' Cc: 'nanog at nanog.org' Subject: RE: Please run windows update now They even released updates for XP & 2003 http://www.catalog.update.microsoft.com/search.aspx?q=4012598 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman Sent: Monday, May 15, 2017 10:45 AM To: Nathan Fink Cc: nanog at nanog.org Subject: Re: Please run windows update now Link? I only posted it as reference to the vulnerability. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, May 13, 2017 at 2:07 AM, Nathan Fink wrote: I show MS17-010 as already superseded in SCCM On Fri, May 12, 2017 at 1:44 PM, Josh Luthman wrote: Thanks for the headsup but I would expect to see some references to the patches that need to be installed to block the vulnerability (Sorry for sounding like a jerk). We all know to update systems ASAP. -- Later, Joe On Fri, May 12, 2017 at 10:35 AM, Ca By wrote: This looks like a major worm that is going global Please run windows update as soon as possible and spread the word It may be worth also closing down ports 445 / 139 / 3389 http://www.npr.org/sections/thetwo-way/2017/05/12/ 528119808/large-cyber-attack-hits-englands-nhs-hospital- system-ransoms-demanded --- Keith Stokes From brad at shub-internet.org Mon May 15 15:48:46 2017 From: brad at shub-internet.org (Brad Knowles) Date: Mon, 15 May 2017 10:48:46 -0500 Subject: Please run windows update now In-Reply-To: <20170515150819.GA31705@e-fensive.net> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <754D32AB-54FC-4B9B-954F-B00C39E2A97A@shub-internet.org> <20170515150819.GA31705@e-fensive.net> Message-ID: On May 15, 2017, at 10:08 AM, J. Oquendo wrote: > Spot on. Shame on Microsoft for releasing patches and not > forcing the installation versus letting security managers > open up ISC^, and other nonsensical frameworks to do things > like "change/patch management" tasks. I mean, who cares if > one little patch knocks a business out of existence. If Microsoft didn't open the security hole in the first place, then there wouldn't be a need to patch it afterwards. Of course, there will always be patches that need to be applied, and people do have to decide what is a sane patching process. But if a patch can be completely avoided because they were more careful and rigorous in their development to begin with, then as a whole the world would be better off. > I do believe Microsoft is directly responsible for making > people such daft "To patch or not to patch" admins. Force > feed patches on everyone! Then your next message will be: > "I believe Microsoft is responsible for trillions of > dollars by pushing out patches forcefully and negatively > impacting businesses worldwide." An ounce of prevention on their part would prevent a pound of cure having to be applied by everyone else in the world. But then Microsoft couldn't extract their value from selling that pound of cure, so that would be another problem. > Pain and anguish? I'm smiling and drinking coffee. I adore > when security shenanigas occur. That is the sound of a cash > register to me. Not everyone licks their chops and thinks "fresh meat" when they see worldwide panic that results from a massive security hole like this. Some of us just want to get regular work done. -- Brad Knowles From joquendo at e-fensive.net Mon May 15 16:21:35 2017 From: joquendo at e-fensive.net (J. Oquendo) Date: Mon, 15 May 2017 11:21:35 -0500 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <754D32AB-54FC-4B9B-954F-B00C39E2A97A@shub-internet.org> <20170515150819.GA31705@e-fensive.net> Message-ID: <20170515162135.GA32144@e-fensive.net> On Mon, 15 May 2017, Brad Knowles wrote: > If Microsoft didn't open the security hole in the first place, then there wouldn't be a need to patch it afterwards. You are very correct. Microsoft opened the hole because they had nothing better to do. Or, could it be that these things happen, akin to a car having to perform a recall. I am sure (with the exception of Volkswagen's clusterf^W) no vendor in any vertical wants to put out subpar products (call me a dreamer.) > Of course, there will always be patches that need to be applied, and people do have to decide what is a sane patching process. But if a patch can be completely avoided because they were more careful and rigorous in their development to begin with, then as a whole the world would be better off. Rigorous in development means little. Go pick an RFC and you will find that over time, even the foundations have at some point or another been broken/circumvented. I have a mental running joke "Blame Paul Vixie!!!" (Sorry Paul :)) When the world lost their ability to use common sense, anything related to DNS became a blame Paul for writing BIND. No... Old saying: "Any time you point the finger, remember, there are more of your fingers pointing back at you." Organizations do perform testing, and some don't. Just because some don't does not mean the industry as a whole won't, or doesn't do it. The fact MS went out of their way to make patches for systems they SPECIFICALLY stated they would not support no more gives them kudos across the board. > An ounce of prevention on their part would prevent a pound of cure having to be applied by everyone else in the world. With 20/20 vision, should that mean I should be expected to see someone throwing a 100MPH fastball at me from my back? Would my pound of cure be ESP for seeing the future? > But then Microsoft couldn't extract their value from selling that pound of cure, so that would be another problem. Sorry to tell you this, that comment makes little sense. I didn't know Microsft sold that pound of cure (patch). > Not everyone licks their chops and thinks "fresh meat" when they see worldwide panic that results from a massive security hole like this. Jump in the security space, where we may gladly trade our cats and dogs for Porsche Panameras > Some of us just want to get regular work done. And some of us find that life goes on. This is no different than Nimda, and other minor fiascos that occur every once in a while. With the exception of Morris. No one, not even the worms in the dirt like him. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From brad at shub-internet.org Mon May 15 16:32:06 2017 From: brad at shub-internet.org (Brad Knowles) Date: Mon, 15 May 2017 11:32:06 -0500 Subject: Please run windows update now In-Reply-To: <20170515162135.GA32144@e-fensive.net> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <754D32AB-54FC-4B9B-954F-B00C39E2A97A@shub-internet.org> <20170515150819.GA31705@e-fensive.net> <20170515162135.GA32144@e-fensive.net> Message-ID: <6C135CFE-6E2A-43BE-88A6-84D3C6960F8F@shub-internet.org> On May 15, 2017, at 11:21 AM, J. Oquendo wrote: >> Not everyone licks their chops and thinks "fresh meat" when they see worldwide panic that results from a massive security hole like this. > > Jump in the security space, where we may gladly trade our > cats and dogs for Porsche Panameras Thanks, but no. I am already forced to do much more in the security space than I would like. And I love my little miracle kitty very much. I wouldn't trade her for any kind of vehicle in this world. I am rather less materialistic than that. -- Brad Knowles From damian at google.com Mon May 15 17:25:37 2017 From: damian at google.com (Damian Menscher) Date: Mon, 15 May 2017 10:25:37 -0700 Subject: Question to Google In-Reply-To: <20170515150711.kjv4udwlmi4woctn@nic.fr> References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> <20170515140654.oad6pvxz27wq46rj@nic.fr> <20170515150711.kjv4udwlmi4woctn@nic.fr> Message-ID: On Mon, May 15, 2017 at 8:07 AM, Stephane Bortzmeyer wrote: > On Mon, May 15, 2017 at 07:55:41AM -0700, > Damian Menscher wrote > a message of 82 lines which said: > > > Can you point to published studies where the root and .com server > > operators analyzed Todd's questions? > > For the root, the most comprehensive one is probably SAC 18 > A good summary is > > Thanks for sharing. From my quick read, it looks like this was a careful analysis of the expected impact, not a review of the actual impact. It reminds me of an instructive joke: "In theory, theory and practice are the same. In practice, they are not." Damian From nanog at incomingmta.com Mon May 15 16:36:46 2017 From: nanog at incomingmta.com (Phillip White) Date: Mon, 15 May 2017 10:36:46 -0600 Subject: Please run windows update now In-Reply-To: <20170515103726.GA1204@gsp.org> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> Message-ID: <030901d2cd99$725d1940$57174bc0$@incomingmta.com> You, sir, are to be congratulated! I have been on this list for many years - mainly to keep in the loop. Up until today the list went to a catch-all account as I have never felt the need to post. Today, though, I felt the need to create the mailbox just so I could reply since your posts have been the most irritating I have ever seen on this list. The complete ineptness in any of the points you shared was astonishing. If you are on this list you are most likely in some business associated with the Internet so if you are like some of those that "just want to get some regular work done" let me remind you that this _is_ regular work. Get it done. Microsoft isn't to blame here. It's the people who refuse to upgrade their Operating Systems or patch religiously who are (read: IT departments here too). A lot more of the world use Microsoft products than you seem to think - it is the dominant and it's not going away. If this causes you more work than the random scripts you google on the Internet to run on your *nix boxes perhaps your time in the business is up. I too prefer and enjoy running all sorts of flavors of unix/Linux and sometimes you will find that I bash the occasional Windows user for being less than diligent but there is a limit to this bashing and you, Rich, have well exceeded that IMO. For those of you on this list that feel that this post was not necessary, I am sorry and would normally agree with you and I hardly think it will happen again. Phillip White -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rich Kulawiec Sent: Monday, May 15, 2017 4:37 AM To: nanog at nanog.org Subject: Re: Please run windows update now You make some excellent points: but I grow very, very tired of having to spend my time and my energy -- note timestamp on my message -- dealing with the fallout. It should be painfully clear to everyone that there is no such thing as a secure Windows system. [1] It should have been painfully clear after Code Red, after the rise of bots, and after a hundred other incidents before/since of varying severity and duration. But apparently it's not and so despite the impact of this current one -- including large-scale disruption of healthcare in the UK -- this will keep happening over and over again. And even those of us who have the good judgment to never use Microsoft products have to pay the price for the poor decision-making of others. Again. And again. It's getting old. Just like all the other things that people do (many of which have been discussed here at great length) that cause problems for others who are making an earnest attempt to do things right. How bad do things have to get before the people who are stubbornly clinging to this finally let go? Does someone have to die? Because -- again, see healthcare provider impact in the UK -- we're not that far from it. ---rsk [1] There may be no such thing as a secure system, period. But it would be better to deploy things that may have a fighting chance instead of things that have long since proven to have none at all. From morrowc.lists at gmail.com Mon May 15 17:43:02 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 May 2017 13:43:02 -0400 Subject: Question to Google In-Reply-To: References: <20170515123052.661246EB8DD9@rock.dv.isc.org> <20170515124359.a3o7evaostrvm3tk@nic.fr> <20170515140654.oad6pvxz27wq46rj@nic.fr> <20170515150711.kjv4udwlmi4woctn@nic.fr> Message-ID: On Mon, May 15, 2017 at 1:25 PM, Damian Menscher via NANOG wrote: > On Mon, May 15, 2017 at 8:07 AM, Stephane Bortzmeyer > wrote: > > > On Mon, May 15, 2017 at 07:55:41AM -0700, > > Damian Menscher wrote > > a message of 82 lines which said: > > > > > Can you point to published studies where the root and .com server > > > operators analyzed Todd's questions? > > > > For the root, the most comprehensive one is probably SAC 18 > > A good summary is > > > > > > Thanks for sharing. From my quick read, it looks like this was a careful > analysis of the expected impact, not a review of the actual impact. It > reminds me of an instructive joke: "In theory, theory and practice are the > same. In practice, they are not." > > > also, a BUNCH has changed since 2007... with respect to the ipv4/ipv6 landscape. From eliezer at ngtech.co.il Mon May 15 18:18:32 2017 From: eliezer at ngtech.co.il (Eliezer Croitoru) Date: Mon, 15 May 2017 21:18:32 +0300 Subject: Please run windows update now In-Reply-To: <59140.1494834442@turing-police.cc.vt.edu> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <59140.1494834442@turing-police.cc.vt.edu> Message-ID: <013501d2cda7$a93067c0$fb913740$@ngtech.co.il> Calling someone who uses Windows un-professional would be a "gossip" style phrase. This is a piece of software which can be tested and compared to others. Would Android be better then windows only because it is based on the Linux kernel or since it's based on the full engineering it was invested from the bottom up? So from my point of view on things: Windows is good Linux is good BSD is good Mac is good Others, good... But depends on what you need. If you need to work with a system that has a specific compatibility or usability levels then this is what you need. If it works for me it doesn't mean that it's either good or bad for me and others! I love Linux based systems but they all need some "magic hands" on them to convert them from Linux to "something better". So with this in mind: If you are a magician and Linux feels good for you it doesn't mean that everybody should be magicians! All The Bests, Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer at ngtech.co.il -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of valdis.kletnieks at vt.edu Sent: Monday, May 15, 2017 10:47 AM To: Rich Kulawiec Cc: nanog at nanog.org Subject: Re: Please run windows update now On Mon, 15 May 2017 02:12:27 -0400, Rich Kulawiec said: > Or BSD, or anything but Windows. Anyone running Microsoft products is > quite clearly an unprofessional, unethical moron and fully deserves > all the pain they get Tell you what. Go over to http://line6.com/software/ - You convince them to produce a Linux version of the software for their musician's gear, and I'll get rid of the Toshiba laptop running Windows. Alternatively, find me an OSX laptop that costs anywhere near the $400 I paid for the Toshiba Satellite. (And yes, I already tried running their software in a VM, neither VirtualBox or VMWare does a good enough job of emulating MIDI-over-USB2 to let the drivers in the VM connect to my Pod HD, so don't bother suggesting that). You want to repeat your claim that I'm an unprofessional, unethical moron because I have a fully patched Windows 10 laptop that's backed up on a regular basis because there's no realistic alternative? From timrutherford at c4.net Mon May 15 18:22:59 2017 From: timrutherford at c4.net (timrutherford at c4.net) Date: Mon, 15 May 2017 14:22:59 -0400 Subject: Please run windows update now In-Reply-To: References: <2263139745685a44881de63a174558fa@mail.dessus.com> Message-ID: <010401d2cda8$482bde40$d8839ac0$@c4.net> >> https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/ >> Look near the bottom under Further Resources. Those are the links appear to be patches for older versions of Windows. The link that Josh sent initially is probably the most straight forward for currently supported versions. https://technet.microsoft.com/en-us/library/security/ms17-010.aspx Scroll down below ?Affected Software and Vulnerability Severity Ratings? and click on the link in the left column it will being you to the MS Update Catalog download page for the patch in question. Keep in mind that since MS started doing monthly patch rollups instead of individual patches, they are listing a ?rollup? KB# and ?security only? KB# for each version of Windows. For example, look at Windows 2012/2012R2 above ? there are four different KB#s depending on the OS version and update method being used. KB4012217 : ?monthly rollup? version for 2012 (gets delivered via windows update - contains this patch and several others) KB4012214 : ?security only? version for 2012 for this one patch KB4012216 : 2012R2 version of the rollup KB4012213 : 2012R2 version of the security only patch -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Keith Stokes Sent: Monday, May 15, 2017 11:49 AM To: Keith Medcalf Cc: nanog at nanog.org Subject: Re: Please run windows update now https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/ Look near the bottom under Further Resources. On May 15, 2017, at 10:44 AM, Keith Medcalf < kmedcalf at dessus.com> wrote: I do not see any links to actually download the actual patches. Just a bunch of text drivel. -- ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? -----Original Message----- From: NANOG [ mailto:nanog-bounces at nanog.org] On Behalf Of timrutherford at c4.net Sent: Monday, 15 May, 2017 09:23 To: 'Josh Luthman'; 'Nathan Fink' Cc: nanog at nanog.org Subject: RE: Please run windows update now I should clarify, the link in my email below is only for windows versions that are considered unsupported. This one has links for the currently supported versions of windows https://support.microsoft.com/en-us/help/4013389/title -----Original Message----- From: timrutherford at c4.net [ mailto:timrutherford at c4.net] Sent: Monday, May 15, 2017 11:12 AM To: 'Josh Luthman' < josh at imaginenetworksllc.com>; 'Nathan Fink' < nefink at gmail.com> Cc: 'nanog at nanog.org' < nanog at nanog.org> Subject: RE: Please run windows update now They even released updates for XP & 2003 http://www.catalog.update.microsoft.com/search.aspx?q=4012598 -----Original Message----- From: NANOG [ mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman Sent: Monday, May 15, 2017 10:45 AM To: Nathan Fink < nefink at gmail.com> Cc: nanog at nanog.org Subject: Re: Please run windows update now Link? I only posted it as reference to the vulnerability. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, May 13, 2017 at 2:07 AM, Nathan Fink < nefink at gmail.com> wrote: I show MS17-010 as already superseded in SCCM On Fri, May 12, 2017 at 1:44 PM, Josh Luthman https://technet.microsoft.com/en-us/library/security/ms17-010.aspx Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, May 12, 2017 at 2:35 PM, JoeSox < joesox at gmail.com> wrote: Thanks for the headsup but I would expect to see some references to the patches that need to be installed to block the vulnerability (Sorry for sounding like a jerk). We all know to update systems ASAP. -- Later, Joe On Fri, May 12, 2017 at 10:35 AM, Ca By < cb.list6 at gmail.com> wrote: This looks like a major worm that is going global Please run windows update as soon as possible and spread the word It may be worth also closing down ports 445 / 139 / 3389 http://www.npr.org/sections/thetwo-way/2017/05/12/ 528119808/large-cyber-attack-hits-englands-nhs-hospital- system-ransoms-demanded --- Keith Stokes From bzs at theworld.com Mon May 15 19:45:26 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Mon, 15 May 2017 15:45:26 -0400 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> Message-ID: <22810.1366.444562.174279@gargle.gargle.HOWL> Since everyone else is bloviating I may as well also... The underlying problem is that Microsoft tried to produce basically one operating system for both servers and end-users and most anything in between. Putting some lipstick on them and names such as "server 2008" doesn't negate that. Ok so did everyone, sort of (does Apple even make servers? ok ok I know the response, cylindrical things.) But others, which means the un*x sphere, at least had the excuse that they were practically unfunded with a few notable exceptions (but Sun is gone no sense beating the dead.) MS has about $100B cash on hand and has generally been a quite profitable enterprise for longer than probably most people on this list have been alive. So for example why does a client OS produced with that much money available even allow things like wholesale encryption of files without at least popping up one of those warnings to confirm that you really meant to run a program on $THRESHOLD files, opening them for update etc, not just read? Even backup doesn't do that. I suppose update does but that and similar could be handled specially. Why? Because it would be annoying to their server customers if they interfered and it seems that's how decisions are made. Over and over. And over. What we really have is the end result of a company spending as little as possible on their product and optimizing their bottom line because no one has any power to make them produce anything better. One code base to rule them all, One code base to sell them, One code base to bring them all, And in their darkness bind them. That's what MS needs to be held accountable for, sucking literally hundreds of billions from companies and consumers (that is, no lack of money) and passing the pain of an inferior product to those consumers much like the car industry did until Ralph Nader ("Unsafe At Any Speed") and others began pointing this out in the 1960s and action was taken and we got some omg seat belts and attention paid to how easily a car of that era could roll over on a turn at 25mph, etc. I think making feelgood comments like one has to be an idiot to run Windows is a huge waste of time at this point. That horse is out of the barn, has sailed, the barn door is still wide open, and it's become too way late to fret over saving nine except forward. -- -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 valdis.kletnieks at vt.edu Mon May 15 20:17:53 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 15 May 2017 16:17:53 -0400 Subject: Please run windows update now In-Reply-To: <22810.1366.444562.174279@gargle.gargle.HOWL> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> Message-ID: <17509.1494879473@turing-police.cc.vt.edu> On Mon, 15 May 2017 15:45:26 -0400, bzs at theworld.com said: > So for example why does a client OS produced with that much money > available even allow things like wholesale encryption of files without > at least popping up one of those warnings to confirm that you really > meant to run a program on $THRESHOLD files, opening them for update > etc, not just read? Well Barry, I can tell you why, with examples from the Unix world. for i in *; do encrypt < $i > $i.new; mv $i.new $i; done How do you throw a pop-up warning for that? Pre-run it and see how many > might get executed? And how do you tell that the sequence ends up destroying the file rather than creating a new one? OK. How about this one? cat > ./wombat << EOF ##!/bin/bash encrypt < $1 > $1.new; mv $1.new $1 EOF chmod +x ./wombat for i in *; do ./wombat $i; done Now convert that to C and bury that whole thing inside a binary. How does the operating system detect that and throw a pop-up *before* that executes? It's a lot harder problem than you think. Hint: Fred Cohen's PhD thesis showed that detecting malware is isomorphic to the Turing Halting Problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From wwaites at tardis.ed.ac.uk Mon May 15 20:43:43 2017 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Mon, 15 May 2017 21:43:43 +0100 Subject: Please run windows update now In-Reply-To: <17509.1494879473@turing-police.cc.vt.edu> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> Message-ID: > On May 15, 2017, at 21:17, valdis.kletnieks at vt.edu wrote: > >> So for example why does[n?t] a client OS confirm that you really >> meant to run a program on $THRESHOLD files? > How does the operating system detect that and throw a pop-up > *before* that executes? > > It's a lot harder problem than you think. Hint: Fred Cohen's PhD > thesis showed that detecting malware is isomorphic to the Turing > Halting Problem. The general problem might well be that hard, I don?t know, it seems plausible. However Barry?s suggestion doesn?t seem impossible. One strategy is as follows. Have a counter in the kernel about writes to files. Have some sort of log-structured filesystem with checkpoints or whatever. When the counter goes too fast, show Barry?s dialog box and if the user says no, roll back the filesystem to the time just before the process (or its parent, or its parent?s parent, ?) started. There are details to be ironed out, of course, but there?s no reason in principle that it couldn?t be done like this. The reason that you don?t have to make the operating system solve the halting problem is because you ask the user. William Waites Laboratory for Foundations of Computer Science School of Informatics, University of Edinburgh Informatics Forum 5.38, 10 Crichton St. Edinburgh, EH8 9AB, Scotland The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From arshad.rad at gmail.com Mon May 15 18:31:42 2017 From: arshad.rad at gmail.com (Mehrdad Arshad Rad) Date: Mon, 15 May 2017 11:31:42 -0700 Subject: vFlow :: IPFIX, sFlow and Netflow collector Message-ID: Hi all, I just wanted to share the vFlow - IPFIX, sFlow and Netflow collector, it's scalable and reliable, written by pure Golang! It doesn't have any library dependency and works w/ Kafka and NSQ (you can write your own MQ plugin). https://github.com/VerizonDigital/vflow For more information https://www.linkedin.com/pulse/high-performance-scalable-reliable-ipfix-sflow-open-arshad-rad It can be able to integrate w/ MemSQL easy and you can have kind of below SQL query: memsql> select * from samples order by bytes desc limit 20; +----------------+-----------------+-----------------+--------+--------+-------+---------+---------+----------+--------+---------------------+ | device | src | dst | srcASN | dstASN | proto | srcPort | dstPort | tcpFlags | bytes | datetime | +----------------+-----------------+-----------------+--------+--------+-------+---------+---------+----------+--------+---------------------+ | 192.129.230.0 | 87.11.81.121 | 61.231.215.18 | 131780 | 21773 | 6 | 80 | 64670 | 0x10 | 342000 | 2017-04-27 22:05:55 | | 52.20.79.116 | 87.11.81.100 | 216.38.140.154 | 41171 | 7994 | 6 | 443 | 26798 | 0x18 | 283364 | 2017-04-27 22:06:00 | | 52.20.79.116 | 192.229.211.70 | 50.240.197.150 | 41171 | 33651 | 6 | 80 | 23397 | 0x10 | 216000 | 2017-04-27 22:05:55 | | 108.161.249.16 | 152.125.33.113 | 74.121.78.10 | 13768 | 9551 | 6 | 80 | 49217 | 0x18 | 196500 | 2017-04-27 22:05:59 | | 192.229.130.0 | 87.21.81.254 | 94.56.54.135 | 132780 | 21773 | 6 | 80 | 52853 | 0x18 | 165000 | 2017-04-27 22:05:55 | | 108.161.229.96 | 93.184.215.169 | 152.157.32.200 | 12768 | 11430 | 6 | 443 | 50488 | 0x18 | 86400 | 2017-04-27 22:06:01 | | 52.22.49.106 | 122.229.210.189 | 99.31.208.183 | 22171 | 8018 | 6 | 443 | 33059 | 0x18 | 73500 | 2017-04-27 22:05:55 | | 52.22.49.126 | 81.21.81.131 | 66.215.169.120 | 22171 | 20115 | 6 | 80 | 57468 | 0x10 | 66000 | 2017-04-27 22:05:59 | | 108.160.149.96 | 94.184.215.151 | 123.90.233.120 | 16768 | 14476 | 6 | 80 | 63905 | 0x18 | 65540 | 2017-04-27 22:05:57 | | 52.22.79.116 | 162.129.210.181 | 60.180.253.156 | 21271 | 31651 | 6 | 443 | 59652 | 0x18 | 64805 | 2017-04-27 22:06:00 | | 108.161.149.90 | 93.184.215.169 | 80.96.58.146 | 13868 | 22394 | 6 | 443 | 1151 | 0x18 | 59976 | 2017-04-27 22:05:54 | | 102.232.179.20 | 111.18.232.131 | 121.62.44.149 | 24658 | 4771 | 6 | 80 | 61076 | 0x10 | 59532 | 2017-04-27 22:05:54 | | 102.232.179.20 | 192.129.145.6 | 110.49.221.232 | 24658 | 4804 | 6 | 443 | 50002 | 0x10 | 58500 | 2017-04-27 22:05:55 | | 102.232.179.20 | 192.129.232.112 | 124.132.217.101 | 24658 | 43124 | 6 | 443 | 37686 | 0x10 | 57000 | 2017-04-27 22:06:00 | | 192.229.230.0 | 87.11.81.253 | 219.147.144.22 | 132380 | 2900 | 6 | 80 | 25202 | 0x18 | 56120 | 2017-04-27 22:05:58 | | 192.129.130.0 | 87.21.11.200 | 180.239.187.151 | 132380 | 8151 | 6 | 443 | 55062 | 0x18 | 52220 | 2017-04-27 22:05:59 | | 52.12.79.126 | 87.21.11.254 | 64.30.125.221 | 21071 | 14051 | 6 | 80 | 57072 | 0x10 | 51000 | 2017-04-27 22:05:54 | | 192.229.110.1 | 150.195.33.40 | 98.171.170.51 | 132980 | 28773 | 6 | 80 | 53270 | 0x18 | 51000 | 2017-04-27 22:05:57 | | 192.229.110.1 | 87.21.81.254 | 68.96.162.21 | 132980 | 28773 | 6 | 80 | 46727 | 0x18 | 49500 | 2017-04-27 22:06:01 | | 52.22.59.110 | 192.129.210.181 | 151.203.130.228 | 21271 | 12452 | 6 | 80 | 43720 | 0x18 | 49500 | 2017-04-27 22:05:55 | +----------------+-----------------+-----------------+--------+--------+-------+---------+---------+----------+--------+---------------------+ 20 rows in set (0.06 sec) Please let me know if you have any questions. Thanks, Mehrdad -- *M*ehrdad Arshad Rad *P*rincipal Software Engineer https://www.linkedin.com/in/mehrdadrad From bzs at theworld.com Mon May 15 21:03:15 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Mon, 15 May 2017 17:03:15 -0400 Subject: Please run windows update now In-Reply-To: <17509.1494879473@turing-police.cc.vt.edu> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> Message-ID: <22810.6035.234891.956277@gargle.gargle.HOWL> On May 15, 2017 at 16:17 valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) wrote: > On Mon, 15 May 2017 15:45:26 -0400, bzs at theworld.com said: > > > So for example why does a client OS produced with that much money > > available even allow things like wholesale encryption of files without > > at least popping up one of those warnings to confirm that you really > > meant to run a program on $THRESHOLD files, opening them for update > > etc, not just read? > > Well Barry, I can tell you why, with examples from the Unix world. > > for i in *; do encrypt < $i > $i.new; mv $i.new $i; done Oh great a design review! Hello Valdis, I am Barry Shein. I've done decades of internals and kernel work. Ever use any Windows since about Vista? It throws up those warning pop-ups when you're about to do something it decides needs confirmation? That was almost certainly my invention. I described the idea on an anti-spam list and two Microsoft engineers contacted me to discuss whether this is feasible etc. Never got a thank you tho. > > How do you throw a pop-up warning for that? Pre-run it and see how many > > might get executed? And how do you tell that the sequence ends up destroying > the file rather than creating a new one? You count the number of destructive opens in the kernel and if it exceeds a threshold (for example) you stop it and pop up a warning. For example. As I said this is the sort of thing which is suitable for an end-user OS and no doubt annoying in a server OS. > > OK. How about this one? > > cat > ./wombat << EOF > ##!/bin/bash > encrypt < $1 > $1.new; mv $1.new $1 > EOF > chmod +x ./wombat > for i in *; do ./wombat $i; done > > Now convert that to C and bury that whole thing inside a binary. How does the > operating system detect that and throw a pop-up *before* that executes? > > It's a lot harder problem than you think. Hint: Fred Cohen's PhD thesis > showed that detecting malware is isomorphic to the Turing Halting Problem. > > > x[DELETED ATTACHMENT , application/pgp-signature] You don't seem to understand how OS's work which surprises me in your case. -- -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 royce at techsolvency.com Mon May 15 21:06:09 2017 From: royce at techsolvency.com (Royce Williams) Date: Mon, 15 May 2017 13:06:09 -0800 Subject: Please run windows update now In-Reply-To: References: Message-ID: On Fri, May 12, 2017 at 10:30 AM, Royce Williams wrote: > My $0.02, for people doing internal/private triage: > > - If your use of IPv4 space is sparse by routes, dump your internal > routing table and convert to summarized CIDR. > > - Feed your CIDRs to masscan [1] to scan for internal port 445 (masscan > randomizes targets, so destination office WAN links won't saturate, but > local/intermediate might if you're not careful, so tune): > > sudo masscan -p445 --rate=[packets-per-second safe for your network] > -iL routes.list -oG masscan-445.out > > - Use https://github.com/RiskSense-Ops/MS17-010/tree/master/scanners (the > python2 one, or the Metasploit one if you can use that internally) to > detect vuln. the python one is not* a parallelized script, so consider > breaking it into multiple parallel runners if you have a lot of scale. > Note - I've learned that the detection rate for the Python script above is *much* lower than this nmap script. I recommend using the nmap script instead: https://github.com/cldrn/nmap-nse-scripts/blob/master/scripts/smb-vuln-ms17-010.nse > - If you're using SCCM/other, verify that MS17-010 was applied - but be > mindful of Windows-based appliances not centrally patched, etc. Trust but > verify. > > - In parallel, consider investigating low-hanging fruit by OU > (workstations?) to disable SMBv1 entirely. > > Royce > > 1. https://github.com/robertdavidgraham/masscan > > From joquendo at e-fensive.net Mon May 15 21:48:21 2017 From: joquendo at e-fensive.net (J. Oquendo) Date: Mon, 15 May 2017 16:48:21 -0500 Subject: Please run windows update now In-Reply-To: <22810.6035.234891.956277@gargle.gargle.HOWL> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> <22810.6035.234891.956277@gargle.gargle.HOWL> Message-ID: <20170515214821.GA41289@e-fensive.net> On Mon, 15 May 2017, bzs at theworld.com wrote: > Oh great a design review! > > Hello Valdis, I am Barry Shein. I've done decades of internals and > kernel work. > > Ever use any Windows since about Vista? It throws up those warning > pop-ups when you're about to do something it decides needs > confirmation? > > That was almost certainly my invention. > > I described the idea on an anti-spam list and two Microsoft engineers > contacted me to discuss whether this is feasible etc. > > Never got a thank you tho. > > > > > How do you throw a pop-up warning for that? Pre-run it and see how many > > > might get executed? And how do you tell that the sequence ends up destroying > > the file rather than creating a new one? > > You count the number of destructive opens in the kernel and if it > exceeds a threshold (for example) you stop it and pop up a warning. > > For example. > > As I said this is the sort of thing which is suitable for an end-user > OS and no doubt annoying in a server OS. > *popcorn* ... What was the original thread about? Because once upon a time as a proof of concept for "undetectable" viruses on *nix, (was for a competition where I was not allowed to be play post disclosure of PoC), anyway, I created a really really bad mechanism to negatively impact ALL BSDs, Solaris, Linux, it was *nix agnostic. Bigger takeaway, malware/scumware/whateverware authors target Windows because there are more users. For someone dealing with security 24x7x365, I can state MS has come a very long way from what they were, including dealing with MSRC and other departments. Do you have any idea how difficult it is to deal with certain *nix projects? Freshmeat? Github, hobby... Apples and oranges. And I CAN COUNT the number of destructive opens read, and write on any nix system, so perhaps we should kill this thread before it becomes: my NetBSD toaster is better than your windows powered refrigetor. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From aaron at heyaaron.com Mon May 15 23:19:37 2017 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Mon, 15 May 2017 16:19:37 -0700 Subject: Please run windows update now In-Reply-To: <20170515214821.GA41289@e-fensive.net> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> <22810.6035.234891.956277@gargle.gargle.HOWL> <20170515214821.GA41289@e-fensive.net> Message-ID: On Mon, May 15, 2017 at 2:48 PM, J. Oquendo wrote: > On Mon, 15 May 2017, bzs at theworld.com wrote: >> You count the number of destructive opens in the kernel and if it >> exceeds a threshold (for example) you stop it and pop up a warning. That's basically what I did. I got tired of users constantly opening any attachment that came at them through e-mail and encrypting all the files on their systems and other network systems....so...I installed a Linux box running Samba backed by a ZFS file store. Samba spits out syslog records on file writes. Combine that with fail2ban. When one user has more than 60 writes in 60 seconds *or* a write contains a well-known cryptolocker name (i.e. *DECRYPT_INSTRUCT*) it immediately blocks their IP on the server, looks up their MAC address, scans the switch for their MAC, and disables the switch port. Then I have a list of files in syslog that were encrypted and ZFS snapshots I can restore from. Additionally, some of the workstations were PXE or iSCSI booted from the NAS so it was as simple as "Hold down the power button to turn off your computer. Ok, let me 'zfs rollback' your machine image...ok, now turn your computer back on. All set." Plus adding new workstations was as easy as getting the MAC address and doing a 'zfs clone' of a clean machine image. Upgrades are easy too--boot a VM, install the latest version of WIndows, update drivers, install software packages, then shutdown, snapshot and clone. Tell the user to reboot their PC and they are now running the newer OS. Windows isn't hard if you have Linux and Unix running underneath, behind, and between everything. ;) -A From surfer at mauigateway.com Tue May 16 01:12:12 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 15 May 2017 18:12:12 -0700 Subject: Please run windows update now Message-ID: <20170515181212.841A37F3@m0087795.ppops.net> --- nanog at incomingmta.com wrote: From: "Phillip White" ...I have been on this list for many years...Today, though, I felt the need to create the mailbox just so I could reply since your posts have been the most irritating I have ever seen on this list. -------------------------------------- "the most irritating I have ever seen on this list" You can't have been on this list very long, then... ;-) scott From bhuffake at caida.org Mon May 15 22:05:30 2017 From: bhuffake at caida.org (Bradley Huffaker) Date: Mon, 15 May 2017 15:05:30 -0700 Subject: Carrier classification In-Reply-To: <773d1e05-3eb2-a91d-c07d-2a35fc7e9d54@seacom.mu> References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> <773d1e05-3eb2-a91d-c07d-2a35fc7e9d54@seacom.mu> Message-ID: <20170515220528.GD67218@caida.org> On Sun, May 14, 2017 at 09:24:18AM +0200, Mark Tinka wrote: > > Nowadays, I'm hearing this less and less, but it's not completely gone. Putting aside the question of their importance, there is a small number of ISPs that do no pay for transit. If you don't call them Tier 1, what do you call them? Transit Free Providers (TFPs)? -- the value of a world model is not how accurately it captures reality but how often it leads us to take appropriate action From jonathan.roach at oracle.com Mon May 15 21:31:46 2017 From: jonathan.roach at oracle.com (Jonathan Roach) Date: Mon, 15 May 2017 22:31:46 +0100 Subject: Please run windows update now In-Reply-To: <17509.1494879473@turing-police.cc.vt.edu> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> Message-ID: <7795b8ef-a738-75d6-f427-dc0ba9dabc4b@oracle.com> Microsoft aren't stupid. They have learned lessons from the days in the 90s and early 2000s when they were a laughing stock in terms of security, and since then Windows security has improved enormously. OK, so it's not perfect, but what software is? Dirty Cow, Shellshock and Heartbleed for example weren't exactly minor flaws, but the world moved on. What's key is that administrators need to know how to secure their estates. If they've failed to apply the patch, that's their failure, not Microsoft's, but patching was not the only way to have curtailed this weekend's outbreak. Admins may have had their reasons for not patching - maybe to do so would have invalidated some kind of certification on an embedded system for example - but there should have been other controls in place to limit the spread of this outbreak or others like it. Something that's puzzled me about events this weekend is that hardly anyone is mentioning firewalling. Servers generally need ports 135-139/445 to be accessible in order to act as, well, servers - but workstations don't. Why aren't people - even cash-starved organisations like the NHS - using the Windows firewall to protect at least their workstations on an ongoing basis? How did this infection spread between organisations without being stopped by a border firewall at any point? Was nothing learned from the Blaster days? (I don't have the answer.) Although the malware was probably injected into multiple organisations in numerous countries via multiple phishing attacks, the spread as reported seemed too fast between organisations and countries for it to have been driven by phishing attacks alone, and I haven't seen any reports showing people how to spot the phishing attempts. So I'm guessing a lot of the propagation even between orgs was by MS17-010. It would be interesting to find out if anyone saw unusual spikes in SMB traffic over the weekend? Or if there are insights into any of the semi-rhetorical questions I posed above? Cheers, Jon From cb.list6 at gmail.com Tue May 16 02:27:42 2017 From: cb.list6 at gmail.com (Ca By) Date: Tue, 16 May 2017 02:27:42 +0000 Subject: Carrier classification In-Reply-To: <20170515220528.GD67218@caida.org> References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> <773d1e05-3eb2-a91d-c07d-2a35fc7e9d54@seacom.mu> <20170515220528.GD67218@caida.org> Message-ID: On Mon, May 15, 2017 at 6:44 PM Bradley Huffaker wrote: > On Sun, May 14, 2017 at 09:24:18AM +0200, Mark Tinka wrote: > > > > Nowadays, I'm hearing this less and less, but it's not completely gone. > > Putting aside the question of their importance, there is a small number > of ISPs that do no pay for transit. If you don't call them Tier 1, what > do you call them? Transit Free Providers (TFPs)? I think the broader and more relevant question is -- Does it matter who pays who ? Why name an irrelevant characteristic? Cogent may not buy transit but i would not purchase their service since they fail to have full internet reach (google and HE) And xyz incumbent may have a poor network, but they may get free peering or may get paid-peering because of their incumbent / monopoly status... that is not a reason for me to purchase from them or think they are an elite tier 1. The dynamica of the day are more around reach and quality, not some legacy measure of how market-failure facilitate anti-social behavior > > -- > the value of a world model is not how accurately it captures reality > but how often it leads us to take appropriate action > From jbfixurpc at gmail.com Tue May 16 02:39:30 2017 From: jbfixurpc at gmail.com (Joe) Date: Mon, 15 May 2017 21:39:30 -0500 Subject: Please run windows update now In-Reply-To: <20170515181212.841A37F3@m0087795.ppops.net> References: <20170515181212.841A37F3@m0087795.ppops.net> Message-ID: Hi Scott As with any open forum you take the good with the bad. I've been on this list since 2001, you learn to dump the static and learn from the good advise. Too much information (whether good or bad) is better than none. -Joe On Mon, May 15, 2017 at 8:12 PM, Scott Weeks wrote: > > > --- nanog at incomingmta.com wrote: > From: "Phillip White" > > ...I have been on this list for many years...Today, though, > I felt the need to create the mailbox just so I could reply > since your posts have been the most irritating I have ever > seen on this list. > -------------------------------------- > > > "the most irritating I have ever seen on this list" > > You can't have been on this list very long, then... ;-) > > scott > From jbfixurpc at gmail.com Tue May 16 02:40:14 2017 From: jbfixurpc at gmail.com (Joe) Date: Mon, 15 May 2017 21:40:14 -0500 Subject: Please run windows update now In-Reply-To: <20170515181212.841A37F3@m0087795.ppops.net> References: <20170515181212.841A37F3@m0087795.ppops.net> Message-ID: Hi Scott As with any open forum you take the good with the bad. I've been on this list since 2001, you learn to dump the static and learn from the good advise. Too much information (whether good or bad) is better than none. -Joe On Mon, May 15, 2017 at 8:12 PM, Scott Weeks wrote: > > > --- nanog at incomingmta.com wrote: > From: "Phillip White" > > ...I have been on this list for many years...Today, though, > I felt the need to create the mailbox just so I could reply > since your posts have been the most irritating I have ever > seen on this list. > -------------------------------------- > > > "the most irritating I have ever seen on this list" > > You can't have been on this list very long, then... ;-) > > scott > From large.hadron.collider at gmx.com Tue May 16 02:56:14 2017 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Mon, 15 May 2017 19:56:14 -0700 Subject: Carrier classification In-Reply-To: References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> <773d1e05-3eb2-a91d-c07d-2a35fc7e9d54@seacom.mu> <20170515220528.GD67218@caida.org> Message-ID: My terminology of tiers are: Tier 1 - is in few or no major disputes, has no transit, and is able to access over three nines percent of the internet Tier 2 - as Tier 1, but has transit. Cogent is neither on v6, and I have no clue about v4. HE is probably Tier 2 on v4, and is Tier 1 on v6. On 15/05/2017 19:27, Ca By wrote: > On Mon, May 15, 2017 at 6:44 PM Bradley Huffaker wrote: > >> On Sun, May 14, 2017 at 09:24:18AM +0200, Mark Tinka wrote: >>> Nowadays, I'm hearing this less and less, but it's not completely gone. >> Putting aside the question of their importance, there is a small number >> of ISPs that do no pay for transit. If you don't call them Tier 1, what >> do you call them? Transit Free Providers (TFPs)? > > I think the broader and more relevant question is -- Does it matter who > pays who ? Why name an irrelevant characteristic? > > Cogent may not buy transit but i would not purchase their service since > they fail to have full internet reach (google and HE) > > And xyz incumbent may have a poor network, but they may get free peering or > may get paid-peering because of their incumbent / monopoly status... that > is not a reason for me to purchase from them or think they are an elite > tier 1. > > The dynamica of the day are more around reach and quality, not some legacy > measure of how market-failure facilitate anti-social behavior > > > >> -- >> the value of a world model is not how accurately it captures reality >> but how often it leads us to take appropriate action >> From math at sizone.org Tue May 16 03:01:36 2017 From: math at sizone.org (Ken Chase) Date: Mon, 15 May 2017 23:01:36 -0400 Subject: Carrier classification In-Reply-To: References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> <773d1e05-3eb2-a91d-c07d-2a35fc7e9d54@seacom.mu> <20170515220528.GD67218@caida.org> Message-ID: <20170516030136.GE15247@sizone.org> so cogent has no routes to some amount of v6? ie no routes to some prefixes? /kc On Mon, May 15, 2017 at 07:56:14PM -0700, Large Hadron Collider said: >My terminology of tiers are: > >Tier 1 - is in few or no major disputes, has no transit, and is able to >access over three nines percent of the internet > >Tier 2 - as Tier 1, but has transit. > >Cogent is neither on v6, and I have no clue about v4. > >HE is probably Tier 2 on v4, and is Tier 1 on v6. > > >On 15/05/2017 19:27, Ca By wrote: >> On Mon, May 15, 2017 at 6:44 PM Bradley Huffaker wrote: >> >>> On Sun, May 14, 2017 at 09:24:18AM +0200, Mark Tinka wrote: >>>> Nowadays, I'm hearing this less and less, but it's not completely gone. >>> Putting aside the question of their importance, there is a small number >>> of ISPs that do no pay for transit. If you don't call them Tier 1, what >>> do you call them? Transit Free Providers (TFPs)? >> >> I think the broader and more relevant question is -- Does it matter who >> pays who ? Why name an irrelevant characteristic? >> >> Cogent may not buy transit but i would not purchase their service since >> they fail to have full internet reach (google and HE) >> >> And xyz incumbent may have a poor network, but they may get free peering or >> may get paid-peering because of their incumbent / monopoly status... that >> is not a reason for me to purchase from them or think they are an elite >> tier 1. >> >> The dynamica of the day are more around reach and quality, not some legacy >> measure of how market-failure facilitate anti-social behavior >> >> >> >>> -- >>> the value of a world model is not how accurately it captures reality >>> but how often it leads us to take appropriate action >>> > -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From joelja at bogus.com Tue May 16 04:10:53 2017 From: joelja at bogus.com (joel jaeggli) Date: Mon, 15 May 2017 21:10:53 -0700 Subject: Carrier classification In-Reply-To: <20170516030136.GE15247@sizone.org> References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> <773d1e05-3eb2-a91d-c07d-2a35fc7e9d54@seacom.mu> <20170515220528.GD67218@caida.org> <20170516030136.GE15247@sizone.org> Message-ID: On 5/15/17 10:01 PM, Ken Chase wrote: > so cogent has no routes to some amount of v6? ie no routes > to some prefixes? it's easy enough to test Test Router Location Hostname / IP Address 2607:f8b0:4005:801::200e Go! Tue May 16 04:00:27.010 UTC % Network not in table http://www.cogentco.com/en/network/looking-glass They're not the sole provider with a hole in their routing table, nor is that the only hole. I would probably choose not to single home behind any nominally SFI carrier, but on the other hand how useful such carrier is in the first place has a lot to do with can they offload the traffic you choose to send them, which is a different problem and should be assessed accordingly. > /kc > > On Mon, May 15, 2017 at 07:56:14PM -0700, Large Hadron Collider said: > >My terminology of tiers are: > > > >Tier 1 - is in few or no major disputes, has no transit, and is able to > >access over three nines percent of the internet > > > >Tier 2 - as Tier 1, but has transit. > > > >Cogent is neither on v6, and I have no clue about v4. > > > >HE is probably Tier 2 on v4, and is Tier 1 on v6. > > > > > >On 15/05/2017 19:27, Ca By wrote: > >> On Mon, May 15, 2017 at 6:44 PM Bradley Huffaker wrote: > >> > >>> On Sun, May 14, 2017 at 09:24:18AM +0200, Mark Tinka wrote: > >>>> Nowadays, I'm hearing this less and less, but it's not completely gone. > >>> Putting aside the question of their importance, there is a small number > >>> of ISPs that do no pay for transit. If you don't call them Tier 1, what > >>> do you call them? Transit Free Providers (TFPs)? > >> > >> I think the broader and more relevant question is -- Does it matter who > >> pays who ? Why name an irrelevant characteristic? > >> > >> Cogent may not buy transit but i would not purchase their service since > >> they fail to have full internet reach (google and HE) > >> > >> And xyz incumbent may have a poor network, but they may get free peering or > >> may get paid-peering because of their incumbent / monopoly status... that > >> is not a reason for me to purchase from them or think they are an elite > >> tier 1. > >> > >> The dynamica of the day are more around reach and quality, not some legacy > >> measure of how market-failure facilitate anti-social behavior > >> > >> > >> > >>> -- > >>> the value of a world model is not how accurately it captures reality > >>> but how often it leads us to take appropriate action > >>> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Tue May 16 04:52:42 2017 From: randy at psg.com (Randy Bush) Date: Tue, 16 May 2017 13:52:42 +0900 Subject: Carrier classification In-Reply-To: <20170515220528.GD67218@caida.org> References: <07F5F811-BEBF-4F85-9A48-877CE676D05C@rivervalleyinternet.net> <1883825586.6314.1494690988323.JavaMail.mhammett@ThunderFuck> <773d1e05-3eb2-a91d-c07d-2a35fc7e9d54@seacom.mu> <20170515220528.GD67218@caida.org> Message-ID: > Putting aside the question of their importance, there is a small number > of ISPs that do no pay for transit. If you don't call them Tier 1, what > do you call them? Transit Free Providers (TFPs)? LFB, late for breakfast From valdis.kletnieks at vt.edu Tue May 16 06:06:30 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 16 May 2017 02:06:30 -0400 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> <22810.6035.234891.956277@gargle.gargle.HOWL> <20170515214821.GA41289@e-fensive.net> Message-ID: <20725.1494914790@turing-police.cc.vt.edu> On Mon, 15 May 2017 16:19:37 -0700, "Aaron C. de Bruyn via NANOG" said: > Combine that with fail2ban. When one user has more than 60 writes in > 60 seconds *or* a write contains a well-known cryptolocker name (i.e. > *DECRYPT_INSTRUCT*) Oddly enough, we've seen *lots* of spammers that are *totally* able to auto-tune their spew rate to whatever you set the knob to. Set it to 3,293, and it will quickly adjust to 3,250 or so. Knock the knob down to 67, it will tune down to 65. There's no reason to expect that the same methods won't be used again. If it's an entire network of vulnerable systems, it's perfectly reasonable for malware to pick one system (the one with the least number of likely-valuable files) as a sacrificial goat and burn it down, just to see where you've set the knobs, and then fly under the radar for the rest of the network. If malware waits till 5:01PM Friday or whenever it detects the user has left for the weekend, and does a careful search of file extensions for files most likely to be valuable enough to make the victim pay the ransom, and does them at 3 per minute, how bad is the situation Monday morning? So you restrict file change rate to 1 per hour or something draconian when the user isn't at the keyboard. What is the likely amount of time the malware can get away with doing 3 files a minute in the background while the user *is* using the system, before they hit an encrypted file and realize there's a problem (hint - avoid files modified in the last few days and target more static files)? What is the likely amount of time you can restrict the user to 2 files per minute before they come looking for you with an ax? Remember - the first rule of designing security is that if you haven't already thought through the first several iterations of blatantly obvious ways to work around your proposal, and dealt with them, it's guaranteed that the bad guys will do so for you. Remember this as well - the entire reason why Snowden walked away with so many files was because the NSA was not using all the available security features *because it put too much of a crimp in legitimate analyst activity*. It's also why almost nobody outside military and spook systems actually deploys MLS/MCS security. Given that we've been at this for well over 4 decades now, and we *still* can't actually do it right, you should be *very* suspicious of any proposal that says "Just count the number of opens, tie it to fail2ban, handwave yadda yadda handwave *SECURE*". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From brad at shub-internet.org Tue May 16 15:33:20 2017 From: brad at shub-internet.org (Brad Knowles) Date: Tue, 16 May 2017 10:33:20 -0500 Subject: Please run windows update now In-Reply-To: <7795b8ef-a738-75d6-f427-dc0ba9dabc4b@oracle.com> References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> <7795b8ef-a738-75d6-f427-dc0ba9dabc4b@oracle.com> Message-ID: On May 15, 2017, at 4:31 PM, Jonathan Roach wrote: > What's key is that administrators need to know how to secure their > estates. If they've failed to apply the patch, that's their failure, not > Microsoft's, but patching was not the only way to have curtailed this > weekend's outbreak. But their failure leads to further intrusions elsewhere. Their failure has consequences beyond their own borders. IMO, this is a herd immunity problem that Microsoft needs to get better at. The analogy I would make here is the German versus the American approaches to road fatalities. In the German approach, if there are significant road fatalities in a given location, then that implies there is a failure with the way the road system is engineered, and it needs to be fixed so that the number of fatalities is brought down. No blame is automatically assumed on the part of the drivers who failed at that location. In the American approach, if there are a significant number of road fatalities, then it's the drivers own fault and they should have taken more care. They are automatically to blame for their own failure. But if you're one of the other drivers out there who might be impacted by the lack of due diligence practiced by another driver on the road, which approach are you going to want to see implemented? -- Brad Knowles From nvitaly at gmail.com Tue May 16 15:04:42 2017 From: nvitaly at gmail.com (Vitaly Nikolaev) Date: Tue, 16 May 2017 11:04:42 -0400 Subject: vFlow :: IPFIX, sFlow and Netflow collector In-Reply-To: References: Message-ID: Hello, Interesting, what receives and where do you keep flows at the other end of messaging bus ? PS: in my case I am talking about hundreds of kilo flows/s that I would like to keep for at least few weeks, so MemSQL or any other SQLs are out of the picture. Thank you On Mon, May 15, 2017 at 2:31 PM, Mehrdad Arshad Rad wrote: > Hi all, > > I just wanted to share the vFlow - IPFIX, sFlow and Netflow collector, it's > scalable and reliable, written by pure Golang! > It doesn't have any library dependency and works w/ Kafka and NSQ (you can > write your own MQ plugin). > > https://github.com/VerizonDigital/vflow > > For more information > https://www.linkedin.com/pulse/high-performance- > scalable-reliable-ipfix-sflow-open-arshad-rad > > It can be able to integrate w/ MemSQL easy and you can have kind of below > SQL query: > > memsql> select * from samples order by bytes desc limit 20; > +----------------+-----------------+-----------------+------ > --+--------+-------+---------+---------+----------+--------+ > ---------------------+ > | device | src | dst | srcASN | dstASN > | proto | srcPort | dstPort | tcpFlags | bytes | datetime > | > +----------------+-----------------+-----------------+------ > --+--------+-------+---------+---------+----------+--------+ > ---------------------+ > | 192.129.230.0 | 87.11.81.121 | 61.231.215.18 | 131780 | 21773 > | 6 | 80 | 64670 | 0x10 | 342000 | 2017-04-27 22:05:55 > | > | 52.20.79.116 | 87.11.81.100 | 216.38.140.154 | 41171 | 7994 > | 6 | 443 | 26798 | 0x18 | 283364 | 2017-04-27 22:06:00 > | > | 52.20.79.116 | 192.229.211.70 | 50.240.197.150 | 41171 | 33651 > | 6 | 80 | 23397 | 0x10 | 216000 | 2017-04-27 22:05:55 > | > | 108.161.249.16 | 152.125.33.113 | 74.121.78.10 | 13768 | 9551 > | 6 | 80 | 49217 | 0x18 | 196500 | 2017-04-27 22:05:59 > | > | 192.229.130.0 | 87.21.81.254 | 94.56.54.135 | 132780 | 21773 > | 6 | 80 | 52853 | 0x18 | 165000 | 2017-04-27 22:05:55 > | > | 108.161.229.96 | 93.184.215.169 | 152.157.32.200 | 12768 | 11430 > | 6 | 443 | 50488 | 0x18 | 86400 | 2017-04-27 22:06:01 > | > | 52.22.49.106 | 122.229.210.189 | 99.31.208.183 | 22171 | 8018 > | 6 | 443 | 33059 | 0x18 | 73500 | 2017-04-27 22:05:55 > | > | 52.22.49.126 | 81.21.81.131 | 66.215.169.120 | 22171 | 20115 > | 6 | 80 | 57468 | 0x10 | 66000 | 2017-04-27 22:05:59 > | > | 108.160.149.96 | 94.184.215.151 | 123.90.233.120 | 16768 | 14476 > | 6 | 80 | 63905 | 0x18 | 65540 | 2017-04-27 22:05:57 > | > | 52.22.79.116 | 162.129.210.181 | 60.180.253.156 | 21271 | 31651 > | 6 | 443 | 59652 | 0x18 | 64805 | 2017-04-27 22:06:00 > | > | 108.161.149.90 | 93.184.215.169 | 80.96.58.146 | 13868 | 22394 > | 6 | 443 | 1151 | 0x18 | 59976 | 2017-04-27 22:05:54 > | > | 102.232.179.20 | 111.18.232.131 | 121.62.44.149 | 24658 | 4771 > | 6 | 80 | 61076 | 0x10 | 59532 | 2017-04-27 22:05:54 > | > | 102.232.179.20 | 192.129.145.6 | 110.49.221.232 | 24658 | 4804 > | 6 | 443 | 50002 | 0x10 | 58500 | 2017-04-27 22:05:55 > | > | 102.232.179.20 | 192.129.232.112 | 124.132.217.101 | 24658 | 43124 > | 6 | 443 | 37686 | 0x10 | 57000 | 2017-04-27 22:06:00 > | > | 192.229.230.0 | 87.11.81.253 | 219.147.144.22 | 132380 | 2900 > | 6 | 80 | 25202 | 0x18 | 56120 | 2017-04-27 22:05:58 > | > | 192.129.130.0 | 87.21.11.200 | 180.239.187.151 | 132380 | 8151 > | 6 | 443 | 55062 | 0x18 | 52220 | 2017-04-27 22:05:59 > | > | 52.12.79.126 | 87.21.11.254 | 64.30.125.221 | 21071 | 14051 > | 6 | 80 | 57072 | 0x10 | 51000 | 2017-04-27 22:05:54 > | > | 192.229.110.1 | 150.195.33.40 | 98.171.170.51 | 132980 | 28773 > | 6 | 80 | 53270 | 0x18 | 51000 | 2017-04-27 22:05:57 > | > | 192.229.110.1 | 87.21.81.254 | 68.96.162.21 | 132980 | 28773 > | 6 | 80 | 46727 | 0x18 | 49500 | 2017-04-27 22:06:01 > | > | 52.22.59.110 | 192.129.210.181 | 151.203.130.228 | 21271 | 12452 > | 6 | 80 | 43720 | 0x18 | 49500 | 2017-04-27 22:05:55 > | > +----------------+-----------------+-----------------+------ > --+--------+-------+---------+---------+----------+--------+ > ---------------------+ > 20 rows in set (0.06 sec) > > > Please let me know if you have any questions. > > Thanks, > Mehrdad > > -- > *M*ehrdad Arshad Rad > *P*rincipal Software Engineer > https://www.linkedin.com/in/mehrdadrad > -- -- Vitaly Nikolaev From joesox at gmail.com Tue May 16 16:40:50 2017 From: joesox at gmail.com (JoeSox) Date: Tue, 16 May 2017 09:40:50 -0700 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> <7795b8ef-a738-75d6-f427-dc0ba9dabc4b@oracle.com> Message-ID: On Tue, May 16, 2017 at 8:33 AM, Brad Knowles wrote: > On May 15, 2017, at 4:31 PM, Jonathan Roach > wrote: > > > What's key is that administrators need to know how to secure their > > estates. If they've failed to apply the patch, that's their failure, not > > Microsoft's, but patching was not the only way to have curtailed this > > weekend's outbreak. > > But their failure leads to further intrusions elsewhere. Their failure > has consequences beyond their own borders. > > IMO, this is a herd immunity problem that Microsoft needs to get better at. > > > The analogy I would make here is the German versus the American approaches > to road fatalities. > > In the German approach, if there are significant road fatalities in a > given location, then that implies there is a failure with the way the road > system is engineered, and it needs to be fixed so that the number of > fatalities is brought down. No blame is automatically assumed on the part > of the drivers who failed at that location. > > In the American approach, if there are a significant number of road > fatalities, then it's the drivers own fault and they should have taken more > care. They are automatically to blame for their own failure. > > But if you're one of the other drivers out there who might be impacted by > the lack of due diligence practiced by another driver on the road, which > approach are you going to want to see implemented? > LOL. I think that is a really bad example and I see many facilities in it, including a hasty generalization, as intersections, and roads for that matter, in America have been resigned to improve safety. Isn't it true, with any tech product, the more complex features, the less secure it is? Ask yourself why this is the case, and I believe the true issue with tech lays there. If a country must build a China Wall duplicate in 300 days (for some reason, to save money lets say), unless the team can pull it off and depending upon how long it must be, the wall you end up with will probably have some holes in it or pieces of it may collapse at later dates. I don't know. It is hard to imagine a professional IT nowadays, seriously blaming Microsoft for every bad thing out there. What would be more of an interesting discussion, to me, would be why doesn't Microsoft know about these hoarding of vulnerabilities by State actors and plug them up? Are they really that clever of vulnerabilities? Does Microsoft not have the resources? Is Windows like the ocean, where there are just hundreds of new species awaiting to be discovered? Did Microsoft at least know of the NSA vulnerabilities, for example, and kept it classified until NSA told them to plug them up? -- Later, Joe From brad at shub-internet.org Tue May 16 17:23:36 2017 From: brad at shub-internet.org (Brad Knowles) Date: Tue, 16 May 2017 12:23:36 -0500 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> <7795b8ef-a738-75d6-f427-dc0ba9dabc4b@oracle.com> Message-ID: On May 16, 2017, at 11:40 AM, JoeSox wrote: > LOL. I think that is a really bad example and I see many facilities in it, > including a hasty generalization, as intersections, and roads for that > matter, in America have been resigned to improve safety. So, if you want to talk about roads in the US, the first thing you have to do is look at the budgets. There are trillions of dollars worth of road improvements that should have been made over the past decades, but which haven't. You'd have to ask the politicians as to what they think the real reasons are, but my guess is that they were unwilling to make long-term investment on critical infrastructure, because it was seen as being too expensive in the short-term. And I definitely see a strong analogy there with what Microsoft has/has not done. > Isn't it true, with any tech product, the more complex features, the less > secure it is? Ask yourself why this is the case, and I believe the true > issue with tech lays there. To a degree, this is true. But there are more iOS devices out there than there are Windows boxes, and while iOS certainly isn't perfect, it definitely has a much better security posture. So, there is at least one other company out there that can do the job. I have to believe that there is more than just one. > I don't know. It is hard to imagine a professional IT nowadays, seriously > blaming Microsoft for every bad thing out there. I don't blame Microsoft for every bad thing out there. I do think they are, by far, the worst of the Fortune 25. But there are 24 other companies on that list who all have their own part to play -- including Apple. > What would be more of an interesting discussion, to me, would be why > doesn't Microsoft know about these hoarding of vulnerabilities by State > actors and plug them up? Well, this one is actually an old vulnerability, right? One that Microsoft supposedly fixed years ago? So, why didn't they fix it properly back then? > Are they really that clever of vulnerabilities? Does Microsoft not have the > resources? Is Windows like the ocean, where there are just hundreds of new > species awaiting to be discovered? > Did Microsoft at least know of the NSA vulnerabilities, for example, and > kept it classified until NSA told them to plug them up? Good conspiracy questions to ask. But frankly, I don't care that Microsoft wants to blame the NSA for hoarding vulnerabilities. If Microsoft had spent more time/money/effort to get their crap right the first time, then we wouldn't have this mess. We might have a different mess, but we wouldn't have this one. -- Brad Knowles From bryan at shout.net Tue May 16 17:28:43 2017 From: bryan at shout.net (Bryan Holloway) Date: Tue, 16 May 2017 12:28:43 -0500 Subject: Yahoo mail / DNS admin on the list? Message-ID: Having an intermittent issue where Yahoo's mail-servers keep complaining about not finding MX records for a small handful of customers (and always the same customers.) Tried submitting a ticket through the postmaster web-site but haven't gotten any response. Could someone contact me off-list? It would be greatly appreciated. Thanks! - bryan From large.hadron.collider at gmx.com Tue May 16 17:35:29 2017 From: large.hadron.collider at gmx.com (LHC (k9m)) Date: Tue, 16 May 2017 10:35:29 -0700 Subject: IRNOG1 Meeting In-Reply-To: References: Message-ID: <63B137E2-052A-454C-942A-87374DDE4FD8@gmx.com> Make it fun, with cake and for the apostates, bacon On May 13, 2017 3:15:51 AM PDT, Shahab Vahabzadeh wrote: >Hello Hello, >Proudly I want to announce that 1st IRNOG Meeting will launch at 24th >of >May in Tehran. >In the first day of public announce we had near 90 people registered to >attend the meeting. >Hope to find this meeting useful in Iranian Community. It would be >great to >get your ideas about the experiences of coordinating such a meetings. > >http://ir-nog.com > >Thanks > >-- >Regards, >Shahab Vahabzadeh, Network Engineer and System Administrator > >PGP Key Fingerprint = 1C43 988E 01A8 4D95 B662 9118 CD94 9F10 4DF4 6163 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From valdis.kletnieks at vt.edu Tue May 16 17:36:20 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 16 May 2017 13:36:20 -0400 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> <7795b8ef-a738-75d6-f427-dc0ba9dabc4b@oracle.com> Message-ID: <10612.1494956180@turing-police.cc.vt.edu> On Tue, 16 May 2017 12:23:36 -0500, Brad Knowles said: > On May 16, 2017, at 11:40 AM, JoeSox wrote: > > Isn't it true, with any tech product, the more complex features, the less > > secure it is? Ask yourself why this is the case, and I believe the true > > issue with tech lays there. > > To a degree, this is true. But there are more iOS devices out there than > there are Windows boxes, and while iOS certainly isn't perfect, it definitely > has a much better security posture. Note that most of iOS's improved security posture is due to its design as a launcher of apps from a tightly controlled source that tightly control the user experience. It's pretty damned easy to harden Windows as well, if you're going to hobble it into being a canned app launcher. Of course, that will piss off everybody who's using Windows as a base for a generalized computing environment rather than an app-launching kiosk, -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Tue May 16 17:37:01 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 16 May 2017 13:37:01 -0400 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> <7795b8ef-a738-75d6-f427-dc0ba9dabc4b@oracle.com> Message-ID: <10663.1494956221@turing-police.cc.vt.edu> On Tue, 16 May 2017 09:40:50 -0700, JoeSox said: > What would be more of an interesting discussion, to me, would be why > doesn't Microsoft know about these hoarding of vulnerabilities by State > actors and plug them up? It's pretty hard for Microsoft to know about an exploit the NSA is sitting on, until Shadow Brokers or similar spills the beans. > Are they really that clever of vulnerabilities? Does Microsoft not have the > resources? The talent pool for top-flight hackers is not all that large. And even if you acquire a large skilled team, there is *zero* guarantee that some other talented team won't find a hole that your team didn't spot. In fact, there's a lot of good reason to believe that exact situation happens *all the time*. > Is Windows like the ocean, where there are just hundreds of new > species awaiting to be discovered? Find statistics on average number of bugs per thousand lines of code. Find estimate of how many 10s of millions of lines of code ships as part of Windows. Do the math - and have alcohol handy for the almost certain drinking binge that the answer will inspire. > Did Microsoft at least know of the NSA vulnerabilities, for example, and > kept it classified until NSA told them to plug them up? There's lots of informed speculation on that one, but I can almost guarantee that you'll never get a definitive answer from somebody who actually know. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From large.hadron.collider at gmx.com Tue May 16 17:37:49 2017 From: large.hadron.collider at gmx.com (LHC (k9m)) Date: Tue, 16 May 2017 10:37:49 -0700 Subject: IRNOG1 Meeting In-Reply-To: <63B137E2-052A-454C-942A-87374DDE4FD8@gmx.com> References: <63B137E2-052A-454C-942A-87374DDE4FD8@gmx.com> Message-ID: <30453B0B-571D-42C1-A195-61A4B92CECE1@gmx.com> ... I'll show myself out. On May 16, 2017 10:35:29 AM PDT, "LHC (k9m)" wrote: >Make it fun, with cake and for the apostates, bacon > >On May 13, 2017 3:15:51 AM PDT, Shahab Vahabzadeh > wrote: >>Hello Hello, >>Proudly I want to announce that 1st IRNOG Meeting will launch at 24th >>of >>May in Tehran. >>In the first day of public announce we had near 90 people registered >to >>attend the meeting. >>Hope to find this meeting useful in Iranian Community. It would be >>great to >>get your ideas about the experiences of coordinating such a meetings. >> >>http://ir-nog.com >> >>Thanks >> >>-- >>Regards, >>Shahab Vahabzadeh, Network Engineer and System Administrator >> >>PGP Key Fingerprint = 1C43 988E 01A8 4D95 B662 9118 CD94 9F10 4DF4 >6163 > >-- >Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From bryan at shout.net Tue May 16 17:44:25 2017 From: bryan at shout.net (Bryan Holloway) Date: Tue, 16 May 2017 12:44:25 -0500 Subject: Yahoo mail / DNS admin on the list? In-Reply-To: References: Message-ID: <3524f499-381d-80f0-3ce5-ed8f5c518169@shout.net> Someone has already reached out ... thanks! On 5/16/17 12:28 PM, Bryan Holloway wrote: > Having an intermittent issue where Yahoo's mail-servers keep complaining > about not finding MX records for a small handful of customers (and > always the same customers.) > > Tried submitting a ticket through the postmaster web-site but haven't > gotten any response. > > Could someone contact me off-list? It would be greatly appreciated. > > Thanks! > - bryan From large.hadron.collider at gmx.com Tue May 16 18:01:20 2017 From: large.hadron.collider at gmx.com (LHC (k9m)) Date: Tue, 16 May 2017 11:01:20 -0700 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> Message-ID: <2AA620EB-AE01-4521-9C74-D77C87667D7D@gmx.com> YOU WENT THERE (ignores enough to run for president) On May 15, 2017 1:48:51 AM PDT, Randy Bush wrote: >> Or BSD, or anything but Windows. Anyone running Microsoft products >> is quite clearly an unprofessional, unethical moron and fully >deserves >> all the pain they get -- including being sued into oblivion by their >> customers and clients for their obvious incompetence and negligence. > >aside from being grossly rude, hyperbolic, and uninteligent, this rant >ignores reality enough to make you a viable presidential candidate. > >80% of desk/laptops run windows. get over it. windows is embedded in >many systems which will be hard to update in an hour or 100 hours. and >rude ranting is not doing one micron to help deal with it. > >embedded systems are very hard to update, think special drivers, kinky >mods, ... aside from the long softdev time, how much time do you think >QA will take for moving a piece of medical equipment from xp to win10, >let alone bsd? and the state of the bsd update process is not >something >to describe in polite company. > >we have a vulnerable chain from weak software (which is improving, and >msoft has been in the lead there for a decade), to nsa/cia not >disclosing, to people choosing or having to run old versions (of >whatever (and linux/bsd are not immune) for financial or technical >reasons, to the conservative or lazy logistics of patching. we can try >to improve things at each link. but this is gonna be slow. > >though this ransomware attack is not really that much larger than other >attacks in the past (and the future is not cheering), at least it has >reached the front pages and maybe people will patch more and vendors >will issue more/better updates. but, as @zeynep says, the lack of >liability along the chain above allows bad practices to continue. > >in the meantime, backup, backup and take it offline so it does not get >encrypted for you, patch, turn off unnecessary services/options, rinse >repeat. and try to promote prudent use among friends, family, and >workplace. > >randy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From freedman at freedman.net Tue May 16 19:34:39 2017 From: freedman at freedman.net (Avi Freedman) Date: Tue, 16 May 2017 15:34:39 -0400 (EDT) Subject: vFlow :: IPFIX, sFlow and Netflow collector In-Reply-To: References: Message-ID: <20170516193439.3D70CE502@freedman.net> > Hello, > > Interesting, what receives and where do you keep flows at the other end of > messaging bus ? > > PS: in my case I am talking about hundreds of kilo flows/s that I would > like to keep for at least few weeks, so MemSQL or any other SQLs are out of > the picture. > > Thank you I've seen a lot of different approaches for people trying to build their own at that scale (taking off of a bus and storing for medium-long term analysis), so I'll share some data re: what I've seen (not specific to vFlow). MemSQL as shown is one option, and is super fast even multi-tenant for the in-ram row store. They have a to-disk column store as well but it is less optimized for massively indexed retrieval. Still, it's worth noting that it's not only an in-RAM solution. And it does batched inserts from row to column store so can keep up with pretty high ingest rates to diskful column store. Another option in the "native" SQL-y space is citusdb, though the high ingest rate was an issue last I looked, and it didn't have multi-tenancy/ rate-limiting support so any 1 monster query could slow everything down. Both MemSQL and Citus are commercial, though a lot of Citus functionality is OSS. And for just forensics (vs ad hoc fast querying for operational or BI purposes), they can be a good augment, though, but are well behind on performance vs. at least one commercial solution, especially for multi-tenant use (reports, peering analysis, spelunking via portal use, alerting, DDoS detection, etc all going on at once). There are plenty of Hadoop-ecosystem column stores as well that can take directly from Kafka or with light translation: Presto, Impala, Drill, and others. Most of them can do multi-column indexing and support SQL as an interface, but multi-tenancy support is also lacking and if you don't get indexes right, many kinds of queries can take minutes to hours over months of data (even from a relatively few routers). But they can all do multi hundred k FPS from Kafka. You'll also need to run a Hadoop cluster. And there HDFS-topped column store implementations running at pretty large scale. Spark I've never seen people stick with - it can compute real-time aggregates with streaming, and if you try to store from RAM to disk, it's less badly slow than Hadoop for map/reduce patterns, but it's slower than just about every column store for accessing trillions of records and doing specific sub-selections to query or dynamically aggregate. Clickhouse from Yandex is interesting but for flow people generally get hung up on its single column for indexing. It can scan VERY fast though, but that still puts it a bit better at 100% forensics use cases for the data scale you're asking about. The leading DIY option we see for store-all is actually the Elastic stack. There are still issues with security (everyone who can access the Elastic backend can access all of the data), and it can require a tremendous # of machines to keep it fast - easily tens of machines for hundreds of k FPS over months. But it's doable and can be pretty fast, if a bit less network-savvy. There's some support for storing prefixes now but still lacks some network savviness (projecting across AS paths, multi hop lookup for finding ultimate exit, flexibility in variable prefixlen querying) and you need to frontend with something like pmacct to do fusion and then build that into an HA architecture if it's really important. But there are a number of DIY setups we've seen that are Elastic-based - more than that are Hadoop/SQL-based. And then, the biggest flow store I know of (1 or 2 carriers may want to argue but I haven't seen theirs) is at DISA for DoD - > a decade of un-sampled flow coming from SiLK. All stored in hourly un-indexed files, essentially nothing but CLI to access, and cluster-able with work (there is a non-OSS add-on to do it). But it works and is pretty neat in its own way, which is optimized around again a forensics-only set of queries (vs. operations, BGP, peering, cost analytics and optimization also). And it can certainly ingest at more than the scale you're talking about and is pretty efficient in storing it on disk. And if you ran it on top of a big MapR-ish NFS cluster (no flames please, though I'm not completely joking) you can effectively cluster it. Still will be pretty slow for anything but time-bounded forensic queries. And then (separate topic and equally long potential survey) there are a new wave of streaming databases that can be used, which can consume directly from Kafka. If you don't mind having to pre-define queries, or using it to augment a column store, they can be MUCH more lightweight than any of the above options, though also lacking in some networking primitives. And if you're running on sampled flow already, the extra lack of precision might not be an issue (they pretty much all use probabalistic data structures like HLLs to do count and topN). And MemSQL can operate in that mode as well though I don't think that was how Mehrdad was showing it working with vFlow. But again you can't ever go 'back in time' for an ad hoc query with them so it's probably more interesting as an augment and offloader for most uses where you'd normally think of storing many billions or a few trillion flows. Happy flow-ing... Avi Freedman CEO, Kentik From jloiacon at csc.com Tue May 16 20:08:44 2017 From: jloiacon at csc.com (Joe Loiacono) Date: Tue, 16 May 2017 16:08:44 -0400 Subject: vFlow :: IPFIX, sFlow and Netflow collector In-Reply-To: <20170516193439.3D70CE502@freedman.net> References: <20170516193439.3D70CE502@freedman.net> Message-ID: "NANOG" wrote on 05/16/2017 03:34:39 PM: > From: freedman at freedman.net (Avi Freedman) > To: Vitaly Nikolaev > Cc: nanog at nanog.org, Mehrdad Arshad Rad > Date: 05/16/2017 03:36 PM > Subject: Re: vFlow :: IPFIX, sFlow and Netflow collector > Sent by: "NANOG" > I've seen a lot of different approaches for people trying to build their > own at that scale (taking off of a bus and storing for medium-long term > analysis), so I'll share some data re: what I've seen (not specific to vFlow). Nice analysis of the current state of the art. > And then, the biggest flow store I know of (1 or 2 carriers may want to argue > but I haven't seen theirs) is at DISA for DoD - > a decade of un-sampled flow > coming from SiLK. All stored in hourly un-indexed files, essentially nothing > but CLI to access, FlowViewer provides a web GUI for invoking SiLK analysis tools. Provides textual and graphical analysis with the ability to track filtered subsets over time. Screenshots, etc.: https://sourceforge.net/projects/flowviewer/ Joe From freedman at freedman.net Tue May 16 20:40:03 2017 From: freedman at freedman.net (Avi Freedman) Date: Tue, 16 May 2017 16:40:03 -0400 (EDT) Subject: vFlow :: IPFIX, sFlow and Netflow collector In-Reply-To: References: <20170516193439.3D70CE502@freedman.net> Message-ID: <20170516204003.7E2EDE50C@freedman.net> > "NANOG" wrote on 05/16/2017 03:34:39 PM: > Nice analysis of the current state of the art. Thanks; of DIY for store-all approaches, at least :) Commercial options is a different thread and I'm conflicted so shouldn't try to summarize those... > > And then, the biggest flow store I know of (1 or 2 carriers may want to > argue > > but I haven't seen theirs) is at DISA for DoD - > a decade of un-sampled > flow > > coming from SiLK. All stored in hourly un-indexed files, essentially > nothing > > but CLI to access, > > FlowViewer provides a web GUI for invoking SiLK analysis tools. Provides > textual and graphical analysis with the ability to track filtered subsets > over time. Screenshots, etc.: > > https://sourceforge.net/projects/flowviewer/ Sorry, forgot about flowviewer - I've never seen it in use and asked at a bunch of Flocons - but it looks updated more recently than I had thought. On a related topic, I'd love to see NANOGers and general netops and perf-minded people go to Flocon (put on by CERT, and heavily but not exclusively SiLK- and security-focused). Cross-pollination of interests, tools, and techniques will help us all... > > Joe Thanks, Avi From kmedcalf at dessus.com Tue May 16 22:41:36 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 16 May 2017 16:41:36 -0600 Subject: Please run windows update now In-Reply-To: Message-ID: > What would be more of an interesting discussion, to me, would be why > doesn't Microsoft know about these hoarding of vulnerabilities by State > actors and plug them up? Some state actors they do know. They custom write the security flaws on the state actors request. > Are they really that clever of vulnerabilities? Does Microsoft not have > the resources? Is Windows like the ocean, where there are just hundreds of new > species awaiting to be discovered? > Did Microsoft at least know of the NSA vulnerabilities, for example, and > kept it classified until NSA told them to plug them up? Of course Microsoft knew, since they wrote in the backdoor in the first place. That is why when informed by their employers that the backdoor was going to be made public, they could undo the changes they had introduced so rapidly. From valdis.kletnieks at vt.edu Wed May 17 00:12:41 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 16 May 2017 20:12:41 -0400 Subject: Please run windows update now In-Reply-To: References: Message-ID: <47461.1494979961@turing-police.cc.vt.edu> On Tue, 16 May 2017 16:41:36 -0600, "Keith Medcalf" said: > Of course Microsoft knew, since they wrote in the backdoor in the first > place. That is why when informed by their employers that the backdoor was > going to be made public, they could undo the changes they had introduced so > rapidly. Do you have any actual evidence or citations that in fact, this was an intentionally inserted backdoor? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From mpalmer at hezmatt.org Wed May 17 02:43:48 2017 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 17 May 2017 12:43:48 +1000 Subject: Please run windows update now In-Reply-To: <47461.1494979961@turing-police.cc.vt.edu> References: <47461.1494979961@turing-police.cc.vt.edu> Message-ID: <20170517024348.GG13247@hezmatt.org> On Tue, May 16, 2017 at 08:12:41PM -0400, valdis.kletnieks at vt.edu wrote: > On Tue, 16 May 2017 16:41:36 -0600, "Keith Medcalf" said: > > Of course Microsoft knew, since they wrote in the backdoor in the first > > place. That is why when informed by their employers that the backdoor was > > going to be made public, they could undo the changes they had introduced so > > rapidly. > > Do you have any actual evidence or citations that in fact, this was an > intentionally inserted backdoor? You'll have to speak up, he can't hear you over the rustling of the tin foil. - Matt From joquendo at e-fensive.net Wed May 17 02:51:26 2017 From: joquendo at e-fensive.net (J. Oquendo) Date: Tue, 16 May 2017 21:51:26 -0500 Subject: Please run windows update now In-Reply-To: <20170517024348.GG13247@hezmatt.org> References: <47461.1494979961@turing-police.cc.vt.edu> <20170517024348.GG13247@hezmatt.org> Message-ID: <20170517025126.GA68090@e-fensive.net> On Wed, 17 May 2017, Matt Palmer wrote: > > > > Do you have any actual evidence or citations that in fact, this was an > > intentionally inserted backdoor? > > You'll have to speak up, he can't hear you over the rustling of the tin > foil. > > - Matt > Pretty low blow considering if I saw "greys" in my yard, I'd be all: "OMGF illuminati!" -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From kmedcalf at dessus.com Wed May 17 02:55:37 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 16 May 2017 20:55:37 -0600 Subject: Please run windows update now In-Reply-To: <47461.1494979961@turing-police.cc.vt.edu> Message-ID: <5ea5a0bdbe575f48b90e133f51c2d96d@mail.dessus.com> On Tuesday, 16 May, 2017 18:13, Valdis Kletnieks wrote: > On Tue, 16 May 2017 16:41:36 -0600, "Keith Medcalf" said: >> Of course Microsoft knew, since they wrote in the backdoor in the first >> place. That is why when informed by their employers that the backdoor >> was going to be made public, they could undo the changes they had >> introduced so rapidly. > Do you have any actual evidence or citations that in fact, this was an > intentionally inserted backdoor? Equal in quantity and quality to the evidence to the contrary. From valdis.kletnieks at vt.edu Wed May 17 03:39:25 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 16 May 2017 23:39:25 -0400 Subject: Please run windows update now In-Reply-To: <5ea5a0bdbe575f48b90e133f51c2d96d@mail.dessus.com> References: <5ea5a0bdbe575f48b90e133f51c2d96d@mail.dessus.com> Message-ID: <13236.1494992365@turing-police.cc.vt.edu> On Tue, 16 May 2017 20:55:37 -0600, "Keith Medcalf" said: > > On Tuesday, 16 May, 2017 18:13, Valdis Kletnieks wrote: > > On Tue, 16 May 2017 16:41:36 -0600, "Keith Medcalf" said: > > >> Of course Microsoft knew, since they wrote in the backdoor in the first > >> place. That is why when informed by their employers that the backdoor > >> was going to be made public, they could undo the changes they had > >> introduced so rapidly. > > > Do you have any actual evidence or citations that in fact, this was an > > intentionally inserted backdoor? > > Equal in quantity and quality to the evidence to the contrary. In that case, "Of course Microsoft didn't know" is equally probable. In fact, it's *more* probable, because if it was intentional, they'd have to have ways in place to make sure that if some random programmer managed to find it and report it, the bug wouldn't get fixed - and the fact that there was a long-standing bug not fixed didn't get noticed by the QA team and the rest. After all, once some TLA paid good money to get that backdoor installed, the *last* thing you want happening is the sentence, "What do you mean, you accidentally fixed it?" Plus, since "Microsoft didn't intentionally put the MS17-010 bug in as a backdoor" is the null hypothesis, it requires zero evidence, and it's your job to bring positive evidence for the non-null hypothesis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From josh at imaginenetworksllc.com Wed May 17 04:19:05 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 17 May 2017 00:19:05 -0400 Subject: Please run windows update now In-Reply-To: <13236.1494992365@turing-police.cc.vt.edu> References: <5ea5a0bdbe575f48b90e133f51c2d96d@mail.dessus.com> <13236.1494992365@turing-police.cc.vt.edu> Message-ID: Can we end this thread? I think the original intent has come and gone. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On May 16, 2017 11:40 PM, wrote: > On Tue, 16 May 2017 20:55:37 -0600, "Keith Medcalf" said: > > > > On Tuesday, 16 May, 2017 18:13, Valdis Kletnieks wrote: > > > On Tue, 16 May 2017 16:41:36 -0600, "Keith Medcalf" said: > > > > >> Of course Microsoft knew, since they wrote in the backdoor in the > first > > >> place. That is why when informed by their employers that the backdoor > > >> was going to be made public, they could undo the changes they had > > >> introduced so rapidly. > > > > > Do you have any actual evidence or citations that in fact, this was an > > > intentionally inserted backdoor? > > > > Equal in quantity and quality to the evidence to the contrary. > > In that case, "Of course Microsoft didn't know" is equally probable. > > In fact, it's *more* probable, because if it was intentional, they'd > have to have ways in place to make sure that if some random programmer > managed to find it and report it, the bug wouldn't get fixed - and the > fact that there was a long-standing bug not fixed didn't get noticed by > the QA team and the rest. After all, once some TLA paid good money to > get that backdoor installed, the *last* thing you want happening is the > sentence, "What do you mean, you accidentally fixed it?" > > Plus, since "Microsoft didn't intentionally put the MS17-010 bug in as > a backdoor" is the null hypothesis, it requires zero evidence, and it's > your job to bring positive evidence for the non-null hypothesis. > From carl at five-ten-sg.com Wed May 17 04:43:36 2017 From: carl at five-ten-sg.com (Carl Byington) Date: Tue, 16 May 2017 21:43:36 -0700 Subject: Please run windows update now In-Reply-To: References: <433F66FA-85E0-4F16-91CD-819700E0309D@simtronic.com.au> <20170515061227.GA13866@gsp.org> <20170515103726.GA1204@gsp.org> <22810.1366.444562.174279@gargle.gargle.HOWL> <17509.1494879473@turing-police.cc.vt.edu> <7795b8ef-a738-75d6-f427-dc0ba9dabc4b@oracle.com> Message-ID: <1494996216.21421.14.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tue, 2017-05-16 at 10:33 -0500, Brad Knowles wrote: > > In the American approach, if there are a significant number of road > fatalities, then it's the drivers own fault and they should have taken > more care. They are automatically to blame for their own failure. Not in all parts of America. Highway 18 here just got a full metal barrier separating the opposing traffic in much of the 4 lane section. 55 mph limit, lots of tight curves, about 18 inches separation between the opposing traffic, and a bunch of drivers that don't know how to drive around a curve. Someone got tired of all the head on crashes, so they "fixed" the road. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlkb1NQACgkQL6j7milTFsESFwCfY956WrGCswGc2CNPt1nHhGF0 WGYAnRsj+MZ937fiKjEbfNvCEiyUBx8o =T1L3 -----END PGP SIGNATURE----- From arshad.rad at gmail.com Tue May 16 17:33:37 2017 From: arshad.rad at gmail.com (Mehrdad Arshad Rad) Date: Tue, 16 May 2017 10:33:37 -0700 Subject: vFlow :: IPFIX, sFlow and Netflow collector In-Reply-To: References: Message-ID: I tried w/ standalone MemSQL w/ 100K IPFIX samples per second and it works. if you pay MemSQL license you can have more than one node (cluster). another solution is ClickHouse https://clickhouse.yandex/ but I'm gonna to test it soon :-) The MemSQL's nice feature is it has built in Kafka consumer w/ transform feature. On Tue, May 16, 2017 at 8:04 AM, Vitaly Nikolaev wrote: > Hello, > > Interesting, what receives and where do you keep flows at the other end of > messaging bus ? > > > PS: in my case I am talking about hundreds of kilo flows/s that I would > like to keep for at least few weeks, so MemSQL or any other SQLs are out of > the picture. > > Thank you > > > On Mon, May 15, 2017 at 2:31 PM, Mehrdad Arshad Rad > wrote: > >> Hi all, >> >> I just wanted to share the vFlow - IPFIX, sFlow and Netflow collector, >> it's >> scalable and reliable, written by pure Golang! >> It doesn't have any library dependency and works w/ Kafka and NSQ (you can >> write your own MQ plugin). >> >> https://github.com/VerizonDigital/vflow >> >> For more information >> https://www.linkedin.com/pulse/high-performance-scalable- >> reliable-ipfix-sflow-open-arshad-rad >> >> It can be able to integrate w/ MemSQL easy and you can have kind of below >> SQL query: >> >> memsql> select * from samples order by bytes desc limit 20; >> +----------------+-----------------+-----------------+------ >> --+--------+-------+---------+---------+----------+--------+ >> ---------------------+ >> | device | src | dst | srcASN | dstASN >> | proto | srcPort | dstPort | tcpFlags | bytes | datetime >> | >> +----------------+-----------------+-----------------+------ >> --+--------+-------+---------+---------+----------+--------+ >> ---------------------+ >> | 192.129.230.0 | 87.11.81.121 | 61.231.215.18 | 131780 | 21773 >> | 6 | 80 | 64670 | 0x10 | 342000 | 2017-04-27 22:05:55 >> | >> | 52.20.79.116 | 87.11.81.100 | 216.38.140.154 | 41171 | 7994 >> | 6 | 443 | 26798 | 0x18 | 283364 | 2017-04-27 22:06:00 >> | >> | 52.20.79.116 | 192.229.211.70 | 50.240.197.150 | 41171 | 33651 >> | 6 | 80 | 23397 | 0x10 | 216000 | 2017-04-27 22:05:55 >> | >> | 108.161.249.16 | 152.125.33.113 | 74.121.78.10 | 13768 | 9551 >> | 6 | 80 | 49217 | 0x18 | 196500 | 2017-04-27 22:05:59 >> | >> | 192.229.130.0 | 87.21.81.254 | 94.56.54.135 | 132780 | 21773 >> | 6 | 80 | 52853 | 0x18 | 165000 | 2017-04-27 22:05:55 >> | >> | 108.161.229.96 | 93.184.215.169 | 152.157.32.200 | 12768 | 11430 >> | 6 | 443 | 50488 | 0x18 | 86400 | 2017-04-27 22:06:01 >> | >> | 52.22.49.106 | 122.229.210.189 | 99.31.208.183 | 22171 | 8018 >> | 6 | 443 | 33059 | 0x18 | 73500 | 2017-04-27 22:05:55 >> | >> | 52.22.49.126 | 81.21.81.131 | 66.215.169.120 | 22171 | 20115 >> | 6 | 80 | 57468 | 0x10 | 66000 | 2017-04-27 22:05:59 >> | >> | 108.160.149.96 | 94.184.215.151 | 123.90.233.120 | 16768 | 14476 >> | 6 | 80 | 63905 | 0x18 | 65540 | 2017-04-27 22:05:57 >> | >> | 52.22.79.116 | 162.129.210.181 | 60.180.253.156 | 21271 | 31651 >> | 6 | 443 | 59652 | 0x18 | 64805 | 2017-04-27 22:06:00 >> | >> | 108.161.149.90 | 93.184.215.169 | 80.96.58.146 | 13868 | 22394 >> | 6 | 443 | 1151 | 0x18 | 59976 | 2017-04-27 22:05:54 >> | >> | 102.232.179.20 | 111.18.232.131 | 121.62.44.149 | 24658 | 4771 >> | 6 | 80 | 61076 | 0x10 | 59532 | 2017-04-27 22:05:54 >> | >> | 102.232.179.20 | 192.129.145.6 | 110.49.221.232 | 24658 | 4804 >> | 6 | 443 | 50002 | 0x10 | 58500 | 2017-04-27 22:05:55 >> | >> | 102.232.179.20 | 192.129.232.112 | 124.132.217.101 | 24658 | 43124 >> | 6 | 443 | 37686 | 0x10 | 57000 | 2017-04-27 22:06:00 >> | >> | 192.229.230.0 | 87.11.81.253 | 219.147.144.22 | 132380 | 2900 >> | 6 | 80 | 25202 | 0x18 | 56120 | 2017-04-27 22:05:58 >> | >> | 192.129.130.0 | 87.21.11.200 | 180.239.187.151 | 132380 | 8151 >> | 6 | 443 | 55062 | 0x18 | 52220 | 2017-04-27 22:05:59 >> | >> | 52.12.79.126 | 87.21.11.254 | 64.30.125.221 | 21071 | 14051 >> | 6 | 80 | 57072 | 0x10 | 51000 | 2017-04-27 22:05:54 >> | >> | 192.229.110.1 | 150.195.33.40 | 98.171.170.51 | 132980 | 28773 >> | 6 | 80 | 53270 | 0x18 | 51000 | 2017-04-27 22:05:57 >> | >> | 192.229.110.1 | 87.21.81.254 | 68.96.162.21 | 132980 | 28773 >> | 6 | 80 | 46727 | 0x18 | 49500 | 2017-04-27 22:06:01 >> | >> | 52.22.59.110 | 192.129.210.181 | 151.203.130.228 | 21271 | 12452 >> | 6 | 80 | 43720 | 0x18 | 49500 | 2017-04-27 22:05:55 >> | >> +----------------+-----------------+-----------------+------ >> --+--------+-------+---------+---------+----------+--------+ >> ---------------------+ >> 20 rows in set (0.06 sec) >> >> >> Please let me know if you have any questions. >> >> Thanks, >> Mehrdad >> >> -- >> *M*ehrdad Arshad Rad >> *P*rincipal Software Engineer >> https://www.linkedin.com/in/mehrdadrad >> > > > > -- > -- > Vitaly Nikolaev > -- *M*ehrdad Arshad Rad *P*rincipal Software Engineer https://www.linkedin.com/in/mehrdadrad From wblack at cenic.org Tue May 16 22:06:11 2017 From: wblack at cenic.org (Will Black) Date: Tue, 16 May 2017 15:06:11 -0700 Subject: NCS5508 for Agg/Core/Peering router Message-ID: <49013CA4-6E74-491E-9919-F93B18F575C0@cenic.org> Is anyone using the NCS5508 as the role of a backbone Core / Aggregation / Peering router? I understand these are generally different network models but we would be interested in hearing whether anyone is using these routers for all three roles. We flattened our network during our last refresh and are trying to do more with less (who isn?t these days?), so we?re trying to determine whether the NCS5508 would fit the bill that?s currently being served by our ASR9K?s. We would also be interested in hearing general observations and thoughts about the NCS5508 for any role. Thanks, Will Black From hugo at slabnet.com Wed May 17 14:14:11 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 17 May 2017 07:14:11 -0700 Subject: NCS5508 for Agg/Core/Peering router In-Reply-To: <49013CA4-6E74-491E-9919-F93B18F575C0@cenic.org> References: <49013CA4-6E74-491E-9919-F93B18F575C0@cenic.org> Message-ID: <665AE42E-ED32-4C17-85B6-1BBDD316D095@slabnet.com> OVH has, apparently, swapped at least some of their ASR9Ks for NCS5508: https://twitter.com/olesovhcom/status/864222277185019909 What exact roles they're serving, though, I don't know. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On May 16, 2017 3:06:11 PM PDT, Will Black wrote: >Is anyone using the NCS5508 as the role of a backbone Core / >Aggregation / Peering router? I understand these are generally >different network models but we would be interested in hearing whether >anyone is using these routers for all three roles. We flattened our >network during our last refresh and are trying to do more with less >(who isn?t these days?), so we?re trying to determine whether the >NCS5508 would fit the bill that?s currently being served by our >ASR9K?s. > >We would also be interested in hearing general observations and >thoughts about the NCS5508 for any role. > >Thanks, > >Will Black From imawsog at yahoo.com Wed May 17 15:48:26 2017 From: imawsog at yahoo.com (i mawsog) Date: Wed, 17 May 2017 15:48:26 +0000 (UTC) Subject: vFlow :: IPFIX, sFlow and Netflow collector In-Reply-To: References: Message-ID: <1839991928.1676778.1495036106121@mail.yahoo.com> A few questions and ?comments.? 1. Is there any ?good ?open repository of netwflow data ? ? ?? 2. How about open repository of raw packet capture ??3. There are many companies that help collect ?raw packet - ?Gigamon, BigSwitch, ... . ?Do folks on this list have any experiences ?with these vendors ??3. xFLows are ?apparently the only ? detailed metric collected on a wider scale. ?I heard even that is often considered a nuisance for the value it ?provides . ?What are the experiences of the the folks on this list ?? ? Where and how netflow is usually collected ?? SG From: Mehrdad Arshad Rad To: Vitaly Nikolaev Cc: nanog at nanog.org Sent: Wednesday, May 17, 2017 7:01 AM Subject: Re: vFlow :: IPFIX, sFlow and Netflow collector I tried w/ standalone MemSQL w/ 100K IPFIX samples per second and it works. if you pay MemSQL license you can have more than one node (cluster). another solution is ClickHouse https://clickhouse.yandex/ but I'm gonna to test it soon :-) The MemSQL's nice feature is it has built in Kafka consumer w/ transform feature. On Tue, May 16, 2017 at 8:04 AM, Vitaly Nikolaev wrote: > Hello, > > Interesting, what receives and where do you keep flows at the other end of > messaging bus ? > > > PS: in my case I am talking about hundreds of kilo flows/s that I would > like to keep for at least few weeks, so MemSQL or any other SQLs are out of > the picture. > > Thank you > > > On Mon, May 15, 2017 at 2:31 PM, Mehrdad Arshad Rad > wrote: > >> Hi all, >> >> I just wanted to share the vFlow - IPFIX, sFlow and Netflow collector, >> it's >> scalable and reliable, written by pure Golang! >> It doesn't have any library dependency and works w/ Kafka and NSQ (you can >> write your own MQ plugin). >> >> https://github.com/VerizonDigital/vflow >> >> For more information >> https://www.linkedin.com/pulse/high-performance-scalable- >> reliable-ipfix-sflow-open-arshad-rad >> >> It can be able to integrate w/ MemSQL easy and you can have kind of below >> SQL query: >> >> memsql> select * from samples order by bytes desc limit 20; >> +----------------+-----------------+-----------------+------ >> --+--------+-------+---------+---------+----------+--------+ >> ---------------------+ >> | device? ? ? ? | src? ? ? ? ? ? | dst? ? ? ? ? ? | srcASN | dstASN >> | proto | srcPort | dstPort | tcpFlags | bytes? | datetime >> | >> +----------------+-----------------+-----------------+------ >> --+--------+-------+---------+---------+----------+--------+ >> ---------------------+ >> | 192.129.230.0? | 87.11.81.121? ? | 61.231.215.18? | 131780 |? 21773 >> |? ? 6 |? ? ? 80 |? 64670 | 0x10? ? | 342000 | 2017-04-27 22:05:55 >> | >> | 52.20.79.116? | 87.11.81.100? ? | 216.38.140.154? |? 41171 |? 7994 >> |? ? 6 |? ? 443 |? 26798 | 0x18? ? | 283364 | 2017-04-27 22:06:00 >> | >> | 52.20.79.116? | 192.229.211.70? | 50.240.197.150? |? 41171 |? 33651 >> |? ? 6 |? ? ? 80 |? 23397 | 0x10? ? | 216000 | 2017-04-27 22:05:55 >> | >> | 108.161.249.16 | 152.125.33.113? | 74.121.78.10? ? |? 13768 |? 9551 >> |? ? 6 |? ? ? 80 |? 49217 | 0x18? ? | 196500 | 2017-04-27 22:05:59 >> | >> | 192.229.130.0? | 87.21.81.254? ? | 94.56.54.135? ? | 132780 |? 21773 >> |? ? 6 |? ? ? 80 |? 52853 | 0x18? ? | 165000 | 2017-04-27 22:05:55 >> | >> | 108.161.229.96 | 93.184.215.169? | 152.157.32.200? |? 12768 |? 11430 >> |? ? 6 |? ? 443 |? 50488 | 0x18? ? |? 86400 | 2017-04-27 22:06:01 >> | >> | 52.22.49.106? | 122.229.210.189 | 99.31.208.183? |? 22171 |? 8018 >> |? ? 6 |? ? 443 |? 33059 | 0x18? ? |? 73500 | 2017-04-27 22:05:55 >> | >> | 52.22.49.126? | 81.21.81.131? ? | 66.215.169.120? |? 22171 |? 20115 >> |? ? 6 |? ? ? 80 |? 57468 | 0x10? ? |? 66000 | 2017-04-27 22:05:59 >> | >> | 108.160.149.96 | 94.184.215.151? | 123.90.233.120? |? 16768 |? 14476 >> |? ? 6 |? ? ? 80 |? 63905 | 0x18? ? |? 65540 | 2017-04-27 22:05:57 >> | >> | 52.22.79.116? | 162.129.210.181 | 60.180.253.156? |? 21271 |? 31651 >> |? ? 6 |? ? 443 |? 59652 | 0x18? ? |? 64805 | 2017-04-27 22:06:00 >> | >> | 108.161.149.90 | 93.184.215.169? | 80.96.58.146? ? |? 13868 |? 22394 >> |? ? 6 |? ? 443 |? ? 1151 | 0x18? ? |? 59976 | 2017-04-27 22:05:54 >> | >> | 102.232.179.20 | 111.18.232.131? | 121.62.44.149? |? 24658 |? 4771 >> |? ? 6 |? ? ? 80 |? 61076 | 0x10? ? |? 59532 | 2017-04-27 22:05:54 >> | >> | 102.232.179.20 | 192.129.145.6? | 110.49.221.232? |? 24658 |? 4804 >> |? ? 6 |? ? 443 |? 50002 | 0x10? ? |? 58500 | 2017-04-27 22:05:55 >> | >> | 102.232.179.20 | 192.129.232.112 | 124.132.217.101 |? 24658 |? 43124 >> |? ? 6 |? ? 443 |? 37686 | 0x10? ? |? 57000 | 2017-04-27 22:06:00 >> | >> | 192.229.230.0? | 87.11.81.253? ? | 219.147.144.22? | 132380 |? 2900 >> |? ? 6 |? ? ? 80 |? 25202 | 0x18? ? |? 56120 | 2017-04-27 22:05:58 >> | >> | 192.129.130.0? | 87.21.11.200? ? | 180.239.187.151 | 132380 |? 8151 >> |? ? 6 |? ? 443 |? 55062 | 0x18? ? |? 52220 | 2017-04-27 22:05:59 >> | >> | 52.12.79.126? | 87.21.11.254? ? | 64.30.125.221? |? 21071 |? 14051 >> |? ? 6 |? ? ? 80 |? 57072 | 0x10? ? |? 51000 | 2017-04-27 22:05:54 >> | >> | 192.229.110.1? | 150.195.33.40? | 98.171.170.51? | 132980 |? 28773 >> |? ? 6 |? ? ? 80 |? 53270 | 0x18? ? |? 51000 | 2017-04-27 22:05:57 >> | >> | 192.229.110.1? | 87.21.81.254? ? | 68.96.162.21? ? | 132980 |? 28773 >> |? ? 6 |? ? ? 80 |? 46727 | 0x18? ? |? 49500 | 2017-04-27 22:06:01 >> | >> | 52.22.59.110? | 192.129.210.181 | 151.203.130.228 |? 21271 |? 12452 >> |? ? 6 |? ? ? 80 |? 43720 | 0x18? ? |? 49500 | 2017-04-27 22:05:55 >> | >> +----------------+-----------------+-----------------+------ >> --+--------+-------+---------+---------+----------+--------+ >> ---------------------+ >> 20 rows in set (0.06 sec) >> >> >> Please let me know if you have any questions. >> >> Thanks, >> Mehrdad >> >> -- >> *M*ehrdad Arshad Rad >> *P*rincipal Software Engineer >> https://www.linkedin.com/in/mehrdadrad >> > > > > -- > -- > Vitaly Nikolaev > -- *M*ehrdad Arshad Rad *P*rincipal Software Engineer https://www.linkedin.com/in/mehrdadrad From johnl at iecc.com Thu May 18 01:27:44 2017 From: johnl at iecc.com (John Levine) Date: 18 May 2017 01:27:44 -0000 Subject: Please run windows update now In-Reply-To: Message-ID: <20170518012744.9170.qmail@ary.lan> In article you write: >fyi, current opinion in the security community seems to be that win10 is >better secured than linuxes, bsds, ... see http://cyber-itl.org/; still >pretty sparse, but getting flushed out. Not against Microsoft. R's, John From ESundberg at nitelusa.com Thu May 18 13:21:37 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Thu, 18 May 2017 13:21:37 +0000 Subject: Cisco NCS5501 as a P Router Message-ID: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> We're at the growing point where we need a dedicated P router for a core device. We are taking a serious look at the NCS5501. Is there anyone else using a NCS5501 as P Router or just general feedback on the NCS5501 if you are using it? The big downside is it's only has a single processor I Can't justify a ASR9K or NCS5500 Chassis yet. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From michalis.bersimis at hq.cyta.gr Thu May 18 13:31:07 2017 From: michalis.bersimis at hq.cyta.gr (michalis.bersimis at hq.cyta.gr) Date: Thu, 18 May 2017 13:31:07 +0000 Subject: Cisco NCS5501 as a P Router In-Reply-To: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> Message-ID: ? would be interested to use NCS5501 as a core or aggregation P router to aggregate smaller PE routers. Its low cost (compared to ASR9K) and the small features that one can need in order to run a P router it makes the platform attractive. I would like to hear other use case (eg. Internet peering routers) Best Regards, Michalis Bersimis -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Erik Sundberg Sent: Thursday, May 18, 2017 4:22 PM To: nanog at nanog.org Subject: Cisco NCS5501 as a P Router **This message triggered one or more security rules. Proceed with caution** We're at the growing point where we need a dedicated P router for a core device. We are taking a serious look at the NCS5501. Is there anyone else using a NCS5501 as P Router or just general feedback on the NCS5501 if you are using it? The big downside is it's only has a single processor I Can't justify a ASR9K or NCS5500 Chassis yet. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From saku at ytti.fi Thu May 18 13:36:39 2017 From: saku at ytti.fi (Saku Ytti) Date: Thu, 18 May 2017 16:36:39 +0300 Subject: Cisco NCS5501 as a P Router In-Reply-To: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> Message-ID: On 18 May 2017 at 16:21, Erik Sundberg wrote: Hey, > We're at the growing point where we need a dedicated P router for a core device. We are taking a serious look at the NCS5501. Is there anyone else using a NCS5501 as P Router or just general feedback on the NCS5501 if you are using it? > > The big downside is it's only has a single processor P would be the position I'd be most comfortable with NCS5501. Particularly BGP free core and Internet-in-VRF. Single control-plane does not seem problematic, usually design should allow any single core node to be taken out of service without customer impact. Please talk to your account team about roadmap, what features are coming in which release in next 3 years. And ask them what are their plans with this IP http://www.cisco.com/c/en/us/about/corporate-strategy-office/acquisitions/leaba.html -- ++ytti From rakartch at cert.org Thu May 18 13:12:53 2017 From: rakartch at cert.org (Rachel Kartch) Date: Thu, 18 May 2017 13:12:53 +0000 Subject: FloCon 2018 [Was: Re: vFlow :: IPFIX, sFlow and Netflow collector] Message-ID: <829B4B56-7A6C-4600-89D0-369289AA41F7@cert.org> On May 16, 2017, at 4:40 PM, Avi Freedman wrote: >On a related topic, I'd love to see NANOGers and general netops and perf-minded >people go to Flocon (put on by CERT, and heavily but not exclusively SiLK- and >security-focused). >Cross-pollination of interests, tools, and techniques will help us all... As a two-decades-or-so lurker on this list (since back when I was a wee thing at ATHY/NYSERNet), I?m going to finally break out of lurk mode to thank Avi for his mention of FloCon, and take advantage of this opportunity to tell you all about a conference that might be of interest. For those who aren?t familiar with it, FloCon is an annual conference organized by CERT, historically focused on network flow and flow data analysis, and particularly its use to support security. (I should note we are *not* US-CERT?we?re the CERT Division of the Software Engineering Institute, operated by Carnegie Mellon University.) I said ?historically focused on network flow? above because one of the changes for 2018 is that we?re expanding the scope of FloCon. This is in response to the trend in the types of submissions we?re receiving for the conference, and in the types of work we at CERT see our sponsors (and the rest of the world) interested in. The new scope for FloCon is data analysis in support of security operations?so, all types of data now, not just flow data or network data. We still anticipate that network data analysis will be a significant part of FloCon because of its central place in security operations, but we?re hopeful that the expanded scope will allow participants to share new and exciting ways of fusing all sorts of data. (Network flow? Pcap? Passive DNS? Building access data? Incident report contents? Biometric data? Malware hashes? Bring it, whatever it is.) We tend to get a good mix of security practitioners, tool builders, and researchers each year. I would love to see more people from the ops world join us, since I think the best advances in the state of the practice will come from bringing the brains of all of these groups together. More information about the conference, including the call for participation, can be found here: https://resources.sei.cmu.edu/news-events/events/flocon/ As the chair for FloCon 2018, I?d be happy to take any questions off-list about the conference. Thanks, Rachel A. Kartch Software Engineering Institute | CERT 4500 Fifth Avenue Pittsburgh, PA 15213 rakartch at cert.org From eric.kuhnke at gmail.com Fri May 19 00:33:36 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 18 May 2017 17:33:36 -0700 Subject: Dotster/domain.com contact Message-ID: I'm looking for a technical contact at dotster/domain.com to address an ongoing issue with their registrar service's lack of compliance with a very clear ICANN policy. Email me off-list. From josivan.barbosa01 at gmail.com Thu May 18 21:14:04 2017 From: josivan.barbosa01 at gmail.com (Josivan Barbosa) Date: Thu, 18 May 2017 18:14:04 -0300 Subject: Unable to assign an IP address to the sub-interface in Huawei S6720 Message-ID: Hello, I follow the steps described in "8.6 Configuring a Dot1q Termination Sub-interface to Implement Inter-VLAN Communication" avaliable in http://support.huawei.com/enterprise/br/doc/DOC1000112303 but dont work. Says "Error: Unrecognized command found at '^' position" in ip address command. Has anyone managed to configure sub-interface on the Huawei S6720 switch? -- Att Josivan Barbosa From josivan.barbosa01 at gmail.com Fri May 19 16:09:13 2017 From: josivan.barbosa01 at gmail.com (Josivan Barbosa) Date: Fri, 19 May 2017 13:09:13 -0300 Subject: Unable to assign an IP address to the sub-interface in Huawei S6720 In-Reply-To: References: Message-ID: Hi Carlos Thank you for the response. It's not working for me: display version Huawei Versatile Routing Platform Software VRP (R) software, Version 5.160 (S6720 V200R008C00SPC500) Copyright (C) 2000-2015 HUAWEI TECH CO., LTD HUAWEI S6720-30C-EI-24S-AC Routing Switch uptime is 36 weeks, 6 days, 3 hours, 27 minutes ES5D2S26Q002 0(Master) : uptime is 36 weeks, 6 days, 3 hours, 27 minutes 2048M bytes DDR Memory 446M bytes FLASH Pcb Version : VER.B Basic BootROM Version : 0208.0001 Compiled at Oct 13 2015, 14:15:20 BootLoad Version : 0208.0001 Compiled at Oct 24 2015, 02:02:20 CPLD Version : 0107 Software Version : VRP (R) Software, Version 5.160 (V200R008C00SPC500) CARD1 information Pcb Version : ES5D21Q04Q01 VER.A CPLD Version : 0104 PWR1 information Pcb Version : PWR VER.A PWR2 information Pcb Version : PWR VER.B FAN1 information Pcb Version : NA system-view Enter system view, return user view with Ctrl+Z. [CR03-CGE]interface XGigabitEthernet 0/0/24 [CR03-CGE-XGigabitEthernet0/0/24]port link-type hybrid Info: This operation may take a few seconds. Please wait for a moment...done. [CR03-CGE-XGigabitEthernet0/0/24]undo port hybrid vlan 1 Info: This operation may take a few seconds. Please wait a moment...done. [CR03-CGE-XGigabitEthernet0/0/24]port hybrid tagged vlan 21 Info: This operation may take a few seconds. Please wait a moment...done. [CR03-CGE-XGigabitEthernet0/0/24]quit [CR03-CGE]interface XGigabitEthernet 0/0/24.500 [CR03-CGE-XGigabitEthernet0/0/24.500]dot1q termination vid 500 Info: This operation may take a few seconds. Please wait a moment... [CR03-CGE-XGigabitEthernet0/0/24.500]ip address 10.50.0.1 255.255.255.252 ^ Error: Unrecognized command found at '^' position. 2017-05-19 10:14 GMT-03:00 Carlos Fraga : > Hi Josivan, > > It works for me (Huawei S6700): > > dis Ver ---> > > Huawei Versatile Routing Platform Software > VRP (R) software, Version 5.150 (S6700 V200R005C00SPC500) > Copyright (C) 2000-2015 HUAWEI TECH CO., LTD > *Quidway S6700-24-EI *Routing Switch uptime is 66 weeks, 1 day, 9 hours, > 52 minutes > > LS61S24N 0(Master) : uptime is 66 weeks, 1 day, 9 hours, 51 minutes > 512M bytes DDR Memory > 64M bytes FLASH > Pcb Version : VER.B > Basic BOOTROM Version : 186 Compiled at Jul 2 2015, 17:00:04 > CPLD Version : 261 > Software Version : VRP (R) Software, Version 5.150 (V200R005C00SPC500) > FANCARD I information > Pcb Version : FAN VER.B > PWRCARD I information > Pcb Version : PWR VER.C > PWRCARD II information > Pcb Version : PWR VER.C > FANCARD II information > Pcb Version : FAN VER.B > > > Here is my config: > > interface XGigabitEthernet0/0/16 > port link-type hybrid > undo port hybrid vlan 1 > port hybrid tagged vlan 2200 > > # > interface XGigabitEthernet0/0/16.2235 > > (x.2235 is the client vlan) > > > I hope this helps you. > > Best Regards, > > *_____________________________* > > *Carlos Fraga* > > > 2017-05-18 23:14 GMT+02:00 Josivan Barbosa : > >> Hello, >> >> I follow the steps described in "8.6 Configuring a Dot1q Termination >> Sub-interface to Implement Inter-VLAN Communication" avaliable in >> http://support.huawei.com/enterprise/br/doc/DOC1000112303 >> >> > 20ebde91d879e?url=http%3A%2F%2Fsupport.huawei.com%2Fenterpri >> se%2Fbr%2Fdoc%2FDOC1000112303&userId=948086&signature=7608d90d5dd77e0c >> >> > >> but dont work. Says "Error: Unrecognized command found at '^' position" >> in >> ip address command. >> >> Has anyone managed to configure sub-interface on the Huawei S6720 switch? >> >> >> -- >> Att >> >> Josivan Barbosa >> > > -- Att Josivan Barbosa From cscora at apnic.net Fri May 19 18:02:43 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 May 2017 04:02:43 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170519180243.D09B6C44D5@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 20 May, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 649251 Prefixes after maximum aggregation (per Origin AS): 252620 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 313178 Total ASes present in the Internet Routing Table: 57256 Prefixes per ASN: 11.34 Origin-only ASes present in the Internet Routing Table: 49539 Origin ASes announcing only one prefix: 21952 Transit ASes present in the Internet Routing Table: 7717 Transit-only ASes present in the Internet Routing Table: 217 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 35 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 77 Numnber of instances of unregistered ASNs: 81 Number of 32-bit ASNs allocated by the RIRs: 18671 Number of 32-bit ASNs visible in the Routing Table: 14487 Prefixes from 32-bit ASNs in the Routing Table: 58732 Number of bogon 32-bit ASNs visible in the Routing Table: 57 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 371 Number of addresses announced to Internet: 2846412964 Equivalent to 169 /8s, 168 /16s and 208 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.6 Total number of prefixes smaller than registry allocations: 217271 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 177851 Total APNIC prefixes after maximum aggregation: 51195 APNIC Deaggregation factor: 3.47 Prefixes being announced from the APNIC address blocks: 177020 Unique aggregates announced from the APNIC address blocks: 73447 APNIC Region origin ASes present in the Internet Routing Table: 8116 APNIC Prefixes per ASN: 21.81 APNIC Region origin ASes announcing only one prefix: 2265 APNIC Region transit ASes present in the Internet Routing Table: 1146 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 35 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2935 Number of APNIC addresses announced to Internet: 763518564 Equivalent to 45 /8s, 130 /16s and 94 /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: 197546 Total ARIN prefixes after maximum aggregation: 94188 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 199697 Unique aggregates announced from the ARIN address blocks: 91577 ARIN Region origin ASes present in the Internet Routing Table: 17909 ARIN Prefixes per ASN: 11.15 ARIN Region origin ASes announcing only one prefix: 6629 ARIN Region transit ASes present in the Internet Routing Table: 1783 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1978 Number of ARIN addresses announced to Internet: 1110224096 Equivalent to 66 /8s, 44 /16s and 172 /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: 175369 Total RIPE prefixes after maximum aggregation: 85260 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 170937 Unique aggregates announced from the RIPE address blocks: 102368 RIPE Region origin ASes present in the Internet Routing Table: 24028 RIPE Prefixes per ASN: 7.11 RIPE Region origin ASes announcing only one prefix: 11095 RIPE Region transit ASes present in the Internet Routing Table: 3398 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5832 Number of RIPE addresses announced to Internet: 711689088 Equivalent to 42 /8s, 107 /16s and 131 /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: 81243 Total LACNIC prefixes after maximum aggregation: 18141 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 82478 Unique aggregates announced from the LACNIC address blocks: 38585 LACNIC Region origin ASes present in the Internet Routing Table: 5913 LACNIC Prefixes per ASN: 13.95 LACNIC Region origin ASes announcing only one prefix: 1640 LACNIC Region transit ASes present in the Internet Routing Table: 1097 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3427 Number of LACNIC addresses announced to Internet: 170601696 Equivalent to 10 /8s, 43 /16s and 44 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17123 Total AfriNIC prefixes after maximum aggregation: 3785 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 18748 Unique aggregates announced from the AfriNIC address blocks: 6877 AfriNIC Region origin ASes present in the Internet Routing Table: 1046 AfriNIC Prefixes per ASN: 17.92 AfriNIC Region origin ASes announcing only one prefix: 322 AfriNIC Region transit ASes present in the Internet Routing Table: 206 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 315 Number of AfriNIC addresses announced to Internet: 89956864 Equivalent to 5 /8s, 92 /16s and 162 /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 5570 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3896 400 342 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2987 903 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2770 11150 760 KIXS-AS-KR Korea Telecom, KR 9829 2693 1492 541 BSNL-NIB National Internet Backbone, IN 9808 2212 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2084 422 222 TATACOMM-AS TATA Communications formerl 45899 1988 1392 108 VNPT-AS-VN VNPT Corp, VN 7552 1608 1101 62 VIETEL-AS-AP Viettel Corporation, VN 9583 1575 121 542 SIFY-AS-IN Sify Limited, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 4104 2970 155 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3378 1333 80 SHAW - Shaw Communications Inc., CA 18566 2180 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2068 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2004 2158 410 CHARTER-NET-HKY-NC - Charter Communicat 209 1817 5068 637 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1792 3439 578 AMAZON-02 - Amazon.com, Inc., US 30036 1763 323 326 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1692 854 230 ITCDELTA - Earthlink, Inc., US 701 1560 10578 638 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8551 3613 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 39891 3338 187 22 ALJAWWALSTC-AS, SA 20940 2898 1012 2075 AKAMAI-ASN1, US 9121 2364 1691 17 TTNET, TR 34984 2014 328 387 TELLCOM-AS, TR 13188 1596 99 56 TRIOLAN, UA 12479 1585 1044 52 UNI2-AS, ES 12389 1491 1370 612 ROSTELECOM-AS, RU 9198 1324 352 25 KAZTELECOM-AS, KZ 6849 1225 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3545 546 147 Telmex Colombia S.A., CO 8151 2520 3400 566 Uninet S.A. de C.V., MX 11830 2086 369 58 Instituto Costarricense de Electricidad 7303 1570 1009 246 Telecom Argentina S.A., AR 6503 1540 437 53 Axtel, S.A.B. de C.V., MX 6147 1175 377 27 Telefonica del Peru S.A.A., PE 3816 1014 496 183 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1013 2285 175 CLARO S.A., BR 11172 921 126 80 Alestra, S. de R.L. de C.V., MX 18881 892 1052 23 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1212 398 48 LINKdotNET-AS, EG 36903 712 358 127 MT-MPLS, MA 37611 711 67 7 Afrihost, ZA 36992 628 1375 26 ETISALAT-MISR, EG 24835 495 722 14 RAYA-AS, EG 29571 419 36 10 CITelecom-AS, CI 37492 406 319 74 ORANGE-, TN 8452 405 1730 17 TE-AS TE-AS, EG 15399 352 35 7 WANANCHI-, KE 2018 292 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5570 4190 74 ERX-CERNET-BKB China Education and Rese 22773 4104 2970 155 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3896 400 342 TPG-INTERNET-AP TPG Telecom Limited, AU 8551 3613 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 10620 3545 546 147 Telmex Colombia S.A., CO 6327 3378 1333 80 SHAW - Shaw Communications Inc., CA 39891 3338 187 22 ALJAWWALSTC-AS, SA 17974 2987 903 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2898 1012 2075 AKAMAI-ASN1, US 4766 2770 11150 760 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 4104 3949 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3613 3573 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7545 3896 3554 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3545 3398 Telmex Colombia S.A., CO 39891 3338 3316 ALJAWWALSTC-AS, SA 6327 3378 3298 SHAW - Shaw Communications Inc., CA 17974 2987 2914 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2364 2347 TTNET, TR 9808 2212 2179 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2693 2152 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 266562 UNALLOCATED 45.65.164.0/22 25933 Sul Americana Tecnologia e Inf Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.15.0/24 55427 BROADLINK-AS-AP Broadlink Nepal, NP 27.100.7.0/24 56096 UNKNOWN 36.255.248.0/24 64091 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM, RU 41.77.248.0/21 203496 AB-TELECOM, RU 41.78.12.0/23 203496 AB-TELECOM, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM, RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:280 /13:545 /14:1045 /15:1849 /16:13482 /17:7619 /18:13396 /19:24732 /20:38493 /21:41159 /22:76717 /23:63881 /24:363683 /25:837 /26:614 /27:632 /28:41 /29:25 /30:24 /31:1 /32:28 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 3256 4104 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 6327 3172 3378 SHAW - Shaw Communications Inc., CA 8551 3078 3613 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 39891 2898 3338 ALJAWWALSTC-AS, SA 18566 2073 2180 MEGAPATH5-US - MegaPath Corporation, US 9121 1682 2364 TTNET, TR 30036 1562 1763 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1474 2086 Instituto Costarricense de Electricidad y Telec 10620 1467 3545 Telmex Colombia S.A., CO 6389 1375 2068 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1600 2:830 4:27 5:2439 6:34 8:1089 12:1827 13:118 14:1784 15:26 16:2 17:121 18:120 20:55 23:2279 24:1843 25:2 27:2422 31:1913 32:83 33:7 35:20 36:403 37:2582 38:1341 39:42 40:97 41:3058 42:470 43:1912 44:73 45:2606 46:2743 47:120 49:1196 50:984 51:19 52:811 54:363 55:5 56:4 57:42 58:1584 59:1039 60:387 61:1940 62:1542 63:1919 64:4574 65:2203 66:4557 67:2261 68:1228 69:3378 70:1318 71:583 72:2224 74:2672 75:383 76:432 77:1490 78:1605 79:2441 80:1387 81:1415 82:987 83:721 84:869 85:1779 86:481 87:1157 88:792 89:2069 90:169 91:6167 92:1012 93:2388 94:2319 95:2809 96:606 97:359 98:1032 99:90 100:158 101:1255 103:14778 104:2893 105:182 106:499 107:1640 108:819 109:3448 110:1322 111:1745 112:1176 113:1228 114:1033 115:1795 116:1781 117:1730 118:2160 119:1589 120:1018 121:1107 122:2286 123:1799 124:1535 125:1906 128:771 129:638 130:439 131:1379 132:525 133:191 134:636 135:222 136:455 137:437 138:1939 139:478 140:376 141:566 142:748 143:924 144:784 145:181 146:985 147:666 148:1429 149:573 150:714 151:968 152:796 153:298 154:818 155:737 156:588 157:631 158:449 159:1455 160:630 161:753 162:2505 163:529 164:784 165:1202 166:380 167:1257 168:2646 169:786 170:3253 171:326 172:1022 173:1858 174:841 175:747 176:1841 177:4077 178:2483 179:1179 180:2201 181:1862 182:2317 183:990 184:869 185:9638 186:3125 187:2191 188:2670 189:1810 190:8086 191:1330 192:9382 193:5787 194:4649 195:3866 196:2123 197:1239 198:5506 199:5884 200:7379 201:4304 202:10378 203:9938 204:4463 205:2796 206:3010 207:3137 208:4013 209:3976 210:3957 211:2138 212:2815 213:2511 214:888 215:66 216:5716 217:2078 218:839 219:604 220:1649 221:910 222:757 223:1179 End of report From kilobit at gmail.com Fri May 19 18:08:11 2017 From: kilobit at gmail.com (bas) Date: Fri, 19 May 2017 20:08:11 +0200 Subject: Arista hardware health and environmental nagios plugin Message-ID: Hello All, Does anyone have a ready to use nagios/icinga plugin for hardware health and temperature monitoring of arista devices that they are willing to share? (7050, 7280 and 7500) With google searches I can't find any available. Arista TAC replied: "nagios does snmp, so that should fit you needs" There is https://github.com/ncsa/nagios-plugins which should be able to be augmented to do the extra checks. And with pyeapi it shouldn't be rocket science either. (for a developer, which I am not) If I were to request our devops department to build it it would probably put in back of a very long queue. So if there is anyone out there that is willing to share it would be greatly appreciated. Thanks, Bas From list at satchell.net Fri May 19 19:21:14 2017 From: list at satchell.net (Stephen Satchell) Date: Fri, 19 May 2017 12:21:14 -0700 Subject: Arista hardware health and environmental nagios plugin In-Reply-To: References: Message-ID: <1feec0d2-7e6c-9416-f416-6292390eea9d@satchell.net> Get the MIBS of the devices you want to monitor, then build SNMP sense programs to pull the information you need. The NAGIOS manuals should describe how to do this. On 05/19/2017 11:08 AM, bas wrote: > Hello All, > > Does anyone have a ready to use nagios/icinga plugin for hardware health > and temperature monitoring of arista devices that they are willing to > share? (7050, 7280 and 7500) > > With google searches I can't find any available. > > Arista TAC replied: "nagios does snmp, so that should fit you needs" > > There is https://github.com/ncsa/nagios-plugins which should be able to be > augmented to do the extra checks. > And with pyeapi it shouldn't be rocket science either. (for a developer, > which I am not) > > If I were to request our devops department to build it it would probably > put in back of a very long queue. > > So if there is anyone out there that is willing to share it would be > greatly appreciated. > > Thanks, > > Bas > From kilobit at gmail.com Fri May 19 19:34:20 2017 From: kilobit at gmail.com (bas) Date: Fri, 19 May 2017 21:34:20 +0200 Subject: Arista hardware health and environmental nagios plugin In-Reply-To: <1feec0d2-7e6c-9416-f416-6292390eea9d@satchell.net> References: <1feec0d2-7e6c-9416-f416-6292390eea9d@satchell.net> Message-ID: Hello All, Thanks for your replies. Especially the lmgtfy and RTFM.. most helpful. :-) I had hoped not to have to re-invent the wheel. Bas On Fri, May 19, 2017 at 9:21 PM, Stephen Satchell wrote: > Get the MIBS of the devices you want to monitor, then build SNMP sense > programs to pull the information you need. The NAGIOS manuals should > describe how to do this. > > > On 05/19/2017 11:08 AM, bas wrote: > > Hello All, > > > > Does anyone have a ready to use nagios/icinga plugin for hardware health > > and temperature monitoring of arista devices that they are willing to > > share? (7050, 7280 and 7500) > > > > With google searches I can't find any available. > > > > Arista TAC replied: "nagios does snmp, so that should fit you needs" > > > > There is https://github.com/ncsa/nagios-plugins which should be able to > be > > augmented to do the extra checks. > > And with pyeapi it shouldn't be rocket science either. (for a developer, > > which I am not) > > > > If I were to request our devops department to build it it would probably > > put in back of a very long queue. > > > > So if there is anyone out there that is willing to share it would be > > greatly appreciated. > > > > Thanks, > > > > Bas > > > > From jhellenthal at dataix.net Fri May 19 23:20:44 2017 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Fri, 19 May 2017 18:20:44 -0500 Subject: IPv6 Connectivity at Specific Datacenter location. Message-ID: <20170519232044.A105A7E54B1A@localhost> I need to get in touch with a NOC/IP tech for Level3 previously TW/Telecom. Informative only. We have a /25 block of shared IPv4 at a local Datacenter in a Brookfield, WI located datacenter owned by Level3 and I would like to add V6 connectivity at our edge but I cannot seem to find a proper contact to inquire with. Were currently hosting a one off solution at Rackspace just for V6 and Apple requirements and Id like to discuss what its going to take to get that connectivity moved to our datacenter edge. Open for off list contact. Non time sensitive matter but would like to handle ASAP. Thanks From ahebert at pubnix.net Sun May 21 19:43:33 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Sun, 21 May 2017 15:43:33 -0400 Subject: Arista hardware health and environmental nagios plugin In-Reply-To: References: <1feec0d2-7e6c-9416-f416-6292390eea9d@satchell.net> Message-ID: See it as tweaking the wheel... Now a perl script (with caching) to monitor VCP ports on QFX5100's is re-inventing the wheel, just because their engineers opted out of the usual way to handle network interfaces. They could have simply named them VCP-/0/x instead of naming them all VCP-255/0/x ----- 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/19/17 15:34, bas wrote: > Hello All, > > Thanks for your replies. > > Especially the lmgtfy and RTFM.. most helpful. :-) > > I had hoped not to have to re-invent the wheel. > > Bas > > On Fri, May 19, 2017 at 9:21 PM, Stephen Satchell wrote: > >> Get the MIBS of the devices you want to monitor, then build SNMP sense >> programs to pull the information you need. The NAGIOS manuals should >> describe how to do this. >> >> >> On 05/19/2017 11:08 AM, bas wrote: >>> Hello All, >>> >>> Does anyone have a ready to use nagios/icinga plugin for hardware health >>> and temperature monitoring of arista devices that they are willing to >>> share? (7050, 7280 and 7500) >>> >>> With google searches I can't find any available. >>> >>> Arista TAC replied: "nagios does snmp, so that should fit you needs" >>> >>> There is https://github.com/ncsa/nagios-plugins which should be able to >> be >>> augmented to do the extra checks. >>> And with pyeapi it shouldn't be rocket science either. (for a developer, >>> which I am not) >>> >>> If I were to request our devops department to build it it would probably >>> put in back of a very long queue. >>> >>> So if there is anyone out there that is willing to share it would be >>> greatly appreciated. >>> >>> Thanks, >>> >>> Bas >>> >> From piotr.iwanejko at gmail.com Mon May 22 07:10:36 2017 From: piotr.iwanejko at gmail.com (Piotr Iwanejko) Date: Mon, 22 May 2017 09:10:36 +0200 Subject: Arista hardware health and environmental nagios plugin In-Reply-To: References: <1feec0d2-7e6c-9416-f416-6292390eea9d@satchell.net> Message-ID: <958DBC2F-6A4E-4C04-B8BB-374155C8E22B@gmail.com> Hello, > Wiadomo?? napisana przez bas w dniu 19.05.2017, o godz. 21:34: > > I had hoped not to have to re-invent the wheel. Some custom scripts I use on 7050SX: https://github.com/piwanejko/Arista-monitoring-tools Nagios checks: CPU1 temperature check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.4.100006001'!'550'!'600' CPU1 load check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.25.3.3.1.2.1'!'70'!'90' CPU2 temperature check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.4.100006002'!'550'!'600' CPU2 load check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.25.3.3.1.2.2'!'70'!'90' CPU3 temperature check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.4.100006003'!'550'!'600' CPU3 load check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.25.3.3.1.2.3'!'70'!'90' CPU4 temperature check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.4.100006004'!'550'!'600' CPU4 load check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.25.3.3.1.2.4'!'70'!'90' Fan tray 1 status check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.5.100601111'!''!'1' Fan tray 2 status check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.5.100602111'!''!'1' Fan tray 3 status check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.5.100603111'!''!'1' Fan tray 4 status check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.5.100604111'!''!'1' Lower board temperature check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.4.100006011'!'500'!'600' PSU1 fan status check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.5.100711211'!''!'1' PSU1 in current status check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.5.100711103'!''!'1' PSU1 in voltage status check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.5.100711105'!''!'1' PSU2 fan status check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.5.100721211'!''!'1' PSU2 in current status check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.5.100721103'!''!'1' PSU2 in voltage status check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.5.100721105'!''!'1' SUP temperature check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.4.100006005'!'550'!'600' Upper board temperature check_snmp_sw!2c!'public'!'.1.3.6.1.2.1.99.1.1.1.4.100006009'!'500'!'600' Uptime check_snmp_sw!'2c'!'public'!'.1.3.6.1.2.1.1.3.0'!'@60000:70000'!'60000:' check_snmp_sw -> check_snmp -H $HOSTADDRESS$ -P $ARG1$ -C $ARG2$ -o $ARG3$ -w $ARG4$ -c $ARG5$ I also made custom script to check discs and memory utilization, but it's too old and terribly written to be shared. Best regards, From nathan at schrenk.org Fri May 19 22:15:14 2017 From: nathan at schrenk.org (Nathan Schrenk) Date: Fri, 19 May 2017 17:15:14 -0500 Subject: Arista hardware health and environmental nagios plugin In-Reply-To: References: Message-ID: Bas, Arista EOS supports ENTITY-SENSOR-MIB and exposes temperature sensors, etc, via that MIB so you should be able to use any NAGIOS plugins that can pull ENTITY-SENSOR-MIB data for environmental monitoring. For example, https://exchange.nagios.org/directory/Plugins/Hardware/Others/check_ entPhySensorValue/details I haven't used that specific NAGIOS plugin myself -- it just turned up when I searched and looked like it would do the job. To find the index of the temp sensor(s) you want to monitor (e.g. CPU, back panel, front panel, etc) you can drop into a bash shell on your Arista switches and run something like "snmptable localhost ENTITY-MIB::entPhysicalTable" and look at the entPhysicalDescr column to see the available sensors. The actual sensor values are provided in ENTITY-SENSOR-MIB::entPhySensorTable. The indices in entPhySensorTable are constructed by adding entPhysicalContainedIn + entPhysicalParentRelPos. For example, on my switch I see a sensor named "Back-panel temp sensor" with entPhysicalContainedIn=1100006000 and entPhysicalParentRelPos=3 so the index into the ENTITY-SENSOR-MIB::entPhySensorTable would be 1100006000+3 = 1100006003: $ snmpwalk localhost ENTITY-SENSOR-MIB::entPhySensorTable |grep 100006003 ENTITY-SENSOR-MIB::entPhySensorType.100006003 = INTEGER: celsius(8) ENTITY-SENSOR-MIB::entPhySensorScale.100006003 = INTEGER: units(9) ENTITY-SENSOR-MIB::entPhySensorPrecision.100006003 = INTEGER: 1 ENTITY-SENSOR-MIB::entPhySensorValue.100006003 = INTEGER: 326 ENTITY-SENSOR-MIB::entPhySensorOperStatus.100006003 = INTEGER: ok(1) ENTITY-SENSOR-MIB::entPhySensorUnitsDisplay.100006003 = STRING: Celsius ENTITY-SENSOR-MIB::entPhySensorValueTimeStamp.100006003 = Timeticks: (1063007379) 123 days, 0:47:53.79 ENTITY-SENSOR-MIB::entPhySensorValueUpdateRate.100006003 = Gauge32: 5000 milliseconds The entPhySensorValue value of 326 means 32.6 degrees Celsius because entSensorPrecision=1 (meaning entPhySensorValue equals "degrees C times 10"). Nathan On Fri, May 19, 2017 at 1:08 PM, bas wrote: > Hello All, > > Does anyone have a ready to use nagios/icinga plugin for hardware health > and temperature monitoring of arista devices that they are willing to > share? (7050, 7280 and 7500) > > With google searches I can't find any available. > > Arista TAC replied: "nagios does snmp, so that should fit you needs" > > There is https://github.com/ncsa/nagios-plugins which should be able to be > augmented to do the extra checks. > And with pyeapi it shouldn't be rocket science either. (for a developer, > which I am not) > > If I were to request our devops department to build it it would probably > put in back of a very long queue. > > So if there is anyone out there that is willing to share it would be > greatly appreciated. > > Thanks, > > Bas > From jason at schwerberg.com Mon May 22 23:35:31 2017 From: jason at schwerberg.com (Jason Schwerberg) Date: Mon, 22 May 2017 16:35:31 -0700 Subject: AT&T NOC contact? Message-ID: <5942b328-e1e0-3519-d58e-1f256875a580@schwerberg.com> Can someone from AT&T's NOC contact me off-list? Been dealing with an open ticket on a T1 line for three weeks, and CIRMs and our account manager don't seem to have a clue...just need someone to verify and bounce the encapsulation... Thanks From hartleyc at gmail.com Mon May 22 23:59:59 2017 From: hartleyc at gmail.com (Chris Hartley) Date: Mon, 22 May 2017 19:59:59 -0400 Subject: AT&T NOC contact? In-Reply-To: <5942b328-e1e0-3519-d58e-1f256875a580@schwerberg.com> References: <5942b328-e1e0-3519-d58e-1f256875a580@schwerberg.com> Message-ID: Well, I have some thicker sand blast resist that has very poor adhesion. I could see trying that for, as you say, simple designs. More complex designs could theoretically have tabs added connecting smaller features - that kind of sucks, but ... cutting, weeding and applying every vinyl stencil is quite tedious! Chris On Mon, May 22, 2017 at 7:35 PM, Jason Schwerberg wrote: > Can someone from AT&T's NOC contact me off-list? Been dealing with an > open ticket on a T1 line for three weeks, and CIRMs and our account > manager don't seem to have a clue...just need someone to verify and > bounce the encapsulation... > > Thanks > > From s at xopher.net Tue May 23 07:10:25 2017 From: s at xopher.net (Scott Christopher) Date: Tue, 23 May 2017 10:10:25 +0300 Subject: Cogent BGP Hijack Message-ID: <1495523425.1755173.985505112.40C5677D@webmail.messagingengine.com> https://www.lowendtalk.com/discussion/114865/hetzner-and-other-traffic-passing-cogent-rerouted-over-moscow#latest A report that all Cogent traffic got re-routed into Moscow. Looks innocent but happened right after UA blocked RU websites (e.g., VKontakte, Yandex, etc) Any thoughts ? -- Regards, S.C. From valdis.kletnieks at vt.edu Tue May 23 17:32:01 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 23 May 2017 13:32:01 -0400 Subject: Cogent BGP Hijack In-Reply-To: <1495523425.1755173.985505112.40C5677D@webmail.messagingengine.com> References: <1495523425.1755173.985505112.40C5677D@webmail.messagingengine.com> Message-ID: <7010.1495560721@turing-police.cc.vt.edu> On Tue, 23 May 2017 10:10:25 +0300, Scott Christopher said: > https://www.lowendtalk.com/discussion/114865/hetzner-and-other-traffic-passin g-cogent-rerouted-over-moscow#latest > > A report that all Cogent traffic got re-routed into Moscow. Looks > innocent but happened right after UA blocked RU websites (e.g., > VKontakte, Yandex, etc) > > Any thoughts ? Similar happened like 3 weeks ago. Big collective yawn when I posted about it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From pbmarcos at inf.ufrgs.br Tue May 23 18:07:14 2017 From: pbmarcos at inf.ufrgs.br (Pedro de Botelho Marcos) Date: Tue, 23 May 2017 15:07:14 -0300 Subject: Making interconnection agreements between networks more dynamic Message-ID: Hello, We are a group of networking researchers from UFRGS, UCLouvain and KAUST. We are working towards an approach to make interconnection agreements between networks more dynamic. The current approach for establishing agreements is cumbersome, typically requiring lengthy discussions. To accommodate the expected growth of traffic demands, network operators need to over-provision. Even so, operators miss the ability to quickly respond when facing unforeseen traffic demands, because agreements have static characteristics and changes could take days or weeks to be implemented. Dynamic agreements offer many opportunities. For example, consider acquiring extra "bandwidth as a service" that is available on demand just when one needs it, similarly to how one might spin up extra VMs in the cloud to handle high loads. We are interested in collecting some anecdotal evidence that dynamic agreements could solve real-world problems. Has any member of the forum faced any scenario where the kind of dynamism described above could be helpful? Many thanks for your inputs, -- Pedro de Botelho Marcos PhD Student Computer Networks Research Group Federal University of Rio Grande do Sul - UFRGS From nick at foobar.org Tue May 23 19:02:20 2017 From: nick at foobar.org (Nick Hilliard) Date: Tue, 23 May 2017 20:02:20 +0100 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: References: Message-ID: <5924873C.3020701@foobar.org> Pedro de Botelho Marcos wrote: > The current approach for establishing > agreements is cumbersome, typically requiring lengthy discussions. i'm not sure the available data supports this conclusion: > http://berec.europa.eu/eng/document_register/subject_matter/berec/download/0/6574-2016-survey-of-internet-carrier-intercon_0.pdf which notes: > Of the total analyzed agreements, 1,347 (0.07%) were formalized in > written contracts. This is down from 0.49% in 2011. The remaining > 1,934,166 (99.93%) were ?handshake? agreements in which the parties > agreed to informal or commonly understood terms without creating a > written document. Nick From aaron1 at gvtc.com Tue May 23 19:09:46 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 23 May 2017 14:09:46 -0500 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: References: Message-ID: <001401d2d3f8$24fbfd50$6ef3f7f0$@gvtc.com> This sounds something like the MEF Third Network type stuff.... I mean the ability to setup connection dynamically across network boundaries on-the-fly, via an ordering system... that has always sounded awesome to me... and I've wondered how we could actually get there one day. Sounds like a lot of initial cooperation -Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Pedro de Botelho Marcos Sent: Tuesday, May 23, 2017 1:07 PM To: nanog at nanog.org Subject: Making interconnection agreements between networks more dynamic Hello, We are a group of networking researchers from UFRGS, UCLouvain and KAUST. We are working towards an approach to make interconnection agreements between networks more dynamic. The current approach for establishing agreements is cumbersome, typically requiring lengthy discussions. To accommodate the expected growth of traffic demands, network operators need to over-provision. Even so, operators miss the ability to quickly respond when facing unforeseen traffic demands, because agreements have static characteristics and changes could take days or weeks to be implemented. Dynamic agreements offer many opportunities. For example, consider acquiring extra "bandwidth as a service" that is available on demand just when one needs it, similarly to how one might spin up extra VMs in the cloud to handle high loads. We are interested in collecting some anecdotal evidence that dynamic agreements could solve real-world problems. Has any member of the forum faced any scenario where the kind of dynamism described above could be helpful? Many thanks for your inputs, -- Pedro de Botelho Marcos PhD Student Computer Networks Research Group Federal University of Rio Grande do Sul - UFRGS From valdis.kletnieks at vt.edu Tue May 23 19:10:52 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 23 May 2017 15:10:52 -0400 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: References: Message-ID: <15739.1495566652@turing-police.cc.vt.edu> On Tue, 23 May 2017 15:07:14 -0300, Pedro de Botelho Marcos said: > Dynamic agreements offer many opportunities. For example, consider > acquiring extra "bandwidth as a service" that is available on demand just > when one needs it, similarly to how one might spin up extra VMs in the > cloud to handle high loads. In computer science, all problems can be solved by adding a level of indirection. You've now changed it from lengthy discussion about the connection, to lengthy discussion about which dynamic agreements both sides are willing to support. Hint: You can't discuss "bandwidth as a service" without both sides talking about how much burst capacity might be needed, because the capacity would *still* require over-provisioning in order to be available if needed. If both ends of the link have 1G optics, you're not going to burst to 10G no matter how many dynamic agreements you have. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From randy at psg.com Tue May 23 22:04:49 2017 From: randy at psg.com (Randy Bush) Date: Wed, 24 May 2017 07:04:49 +0900 Subject: Cogent BGP Hijack In-Reply-To: <1495523425.1755173.985505112.40C5677D@webmail.messagingengine.com> References: <1495523425.1755173.985505112.40C5677D@webmail.messagingengine.com> Message-ID: > A report that all Cogent traffic got re-routed into Moscow. Looks > innocent but happened right after UA blocked RU websites (e.g., > VKontakte, Yandex, etc) a peering war between the martians and the venusians? From randy at psg.com Tue May 23 22:06:32 2017 From: randy at psg.com (Randy Bush) Date: Wed, 24 May 2017 07:06:32 +0900 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: <001401d2d3f8$24fbfd50$6ef3f7f0$@gvtc.com> References: <001401d2d3f8$24fbfd50$6ef3f7f0$@gvtc.com> Message-ID: > This sounds something like the MEF Third Network type stuff.... I mean > the ability to setup connection dynamically across network boundaries > on-the-fly, via an ordering system... that has always sounded awesome > to me... and I've wondered how we could actually get there one day. to me, this was the dream of optical switching and gmpls (which is not mpls) randy From large.hadron.collider at gmx.com Tue May 23 22:15:16 2017 From: large.hadron.collider at gmx.com (LHC (k9m)) Date: Tue, 23 May 2017 15:15:16 -0700 Subject: AT&T NOC contact? In-Reply-To: References: <5942b328-e1e0-3519-d58e-1f256875a580@schwerberg.com> Message-ID: <1FEF2F05-D1B0-4E6D-B09B-0B040634A7FE@gmx.com> you just won the internet. On May 22, 2017 4:59:59 PM PDT, Chris Hartley wrote: >Well, I have some thicker sand blast resist that has very poor >adhesion. I >could see trying that for, as you say, simple designs. More complex >designs could theoretically have tabs added connecting smaller features >- >that kind of sucks, but ... cutting, weeding and applying every vinyl >stencil is quite tedious! > >Chris > >On Mon, May 22, 2017 at 7:35 PM, Jason Schwerberg > >wrote: > >> Can someone from AT&T's NOC contact me off-list? Been dealing with >an >> open ticket on a T1 line for three weeks, and CIRMs and our account >> manager don't seem to have a clue...just need someone to verify and >> bounce the encapsulation... >> >> Thanks >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From large.hadron.collider at gmx.com Tue May 23 22:16:39 2017 From: large.hadron.collider at gmx.com (LHC (k9m)) Date: Tue, 23 May 2017 15:16:39 -0700 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: <15739.1495566652@turing-police.cc.vt.edu> References: <15739.1495566652@turing-police.cc.vt.edu> Message-ID: <3BA2B13C-69BC-426E-9421-9039B8A41567@gmx.com> You need an extra 9 lines to handle the overrun. On May 23, 2017 12:10:52 PM PDT, valdis.kletnieks at vt.edu wrote: >On Tue, 23 May 2017 15:07:14 -0300, Pedro de Botelho Marcos said: > >> Dynamic agreements offer many opportunities. For example, consider >> acquiring extra "bandwidth as a service" that is available on demand >just >> when one needs it, similarly to how one might spin up extra VMs in >the >> cloud to handle high loads. > >In computer science, all problems can be solved by adding a level of >indirection. > >You've now changed it from lengthy discussion about the connection, to >lengthy >discussion about which dynamic agreements both sides are willing to >support. > >Hint: You can't discuss "bandwidth as a service" without both sides >talking >about how much burst capacity might be needed, because the capacity >would *still* >require over-provisioning in order to be available if needed. If both >ends >of the link have 1G optics, you're not going to burst to 10G no matter >how >many dynamic agreements you have. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From kmedcalf at dessus.com Tue May 23 22:52:21 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 23 May 2017 16:52:21 -0600 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: Message-ID: > > This sounds something like the MEF Third Network type stuff.... I mean > > the ability to setup connection dynamically across network boundaries > > on-the-fly, via an ordering system... that has always sounded awesome > > to me... and I've wondered how we could actually get there one day. > to me, this was the dream of optical switching and gmpls (which is not > mpls) And, pray tell, what is the use of me setting up "peering" between myself and a network on the other side of the world when the data still has to flow over the same connections, merely encapsulated inside a tunnel? Reminds me of the old days when you could directly connect "Chicago" to "Denver" using a direct connection over a PVC that was routed Chicago -> New York -> Miami -> Los Angeles -> Denver. Sure, it looks like a direct connection, but ... Or will this magical interface also deploy robots to build the physical layer? From tom at cloudflare.com Tue May 23 23:16:12 2017 From: tom at cloudflare.com (Tom Paseka) Date: Tue, 23 May 2017 16:16:12 -0700 Subject: Cogent BGP Hijack In-Reply-To: <7010.1495560721@turing-police.cc.vt.edu> References: <1495523425.1755173.985505112.40C5677D@webmail.messagingengine.com> <7010.1495560721@turing-police.cc.vt.edu> Message-ID: Looking at bgplay data, Hetzner possibly had some outages at the time? Cogent isn't quick at withdrawing routes and will often blackhole inside their network, but i can't see a large leak/hijack as happened. On Tue, May 23, 2017 at 10:32 AM, wrote: > On Tue, 23 May 2017 10:10:25 +0300, Scott Christopher said: > > https://www.lowendtalk.com/discussion/114865/hetzner-and- > other-traffic-passin > g-cogent-rerouted-over-moscow#latest > > > > A report that all Cogent traffic got re-routed into Moscow. Looks > > innocent but happened right after UA blocked RU websites (e.g., > > VKontakte, Yandex, etc) > > > > Any thoughts ? > > Similar happened like 3 weeks ago. Big collective yawn when I posted > about it. > From sjt5atra at gmail.com Tue May 23 23:18:33 2017 From: sjt5atra at gmail.com (Steven Tardy) Date: Tue, 23 May 2017 19:18:33 -0400 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: References: Message-ID: <86D8B832-34F3-4268-A45D-8D73DEEE5343@gmail.com> > On May 23, 2017, at 2:07 PM, Pedro de Botelho Marcos wrote: > > consider > acquiring extra "bandwidth as a service" that is available on demand just > when one needs it, Wasn't this the initial promise of SDN? Hand wave. Magically connected endpoints. All QoS'd and bandwidth-guaranteed configuration completed perfectly every time across disparate networks/equipment. From randy at psg.com Tue May 23 23:27:29 2017 From: randy at psg.com (Randy Bush) Date: Wed, 24 May 2017 08:27:29 +0900 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: References: Message-ID: >> to me, this was the dream of optical switching and gmpls (which is >> not mpls) > And, pray tell, what is the use of me setting up "peering" between > myself and a network on the other side of the world when the data > still has to flow over the same connections, merely encapsulated > inside a tunnel? read "which is not mpls" a few more times. than maybe read a bit on gmpls and optical switching. you may find https://en.wikipedia.org/wiki/Generalized_Multi-Protocol_Label_Switching a reasonable place to start. randy From kmedcalf at dessus.com Tue May 23 23:40:11 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 23 May 2017 17:40:11 -0600 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: Message-ID: > >> to me, this was the dream of optical switching and gmpls (which is > >> not mpls) > > And, pray tell, what is the use of me setting up "peering" between > > myself and a network on the other side of the world when the data > > still has to flow over the same connections, merely encapsulated > > inside a tunnel? > read "which is not mpls" a few more times. than maybe read a bit on > gmpls and optical switching. you may find > https://en.wikipedia.org/wiki/Generalized_Multi-Protocol_Label_Switching > a reasonable place to start. Ok, but does this still not pre-suppose that an appropriate physical path that has sufficient available bandwidth/slots is already present? From randy at psg.com Wed May 24 00:00:10 2017 From: randy at psg.com (Randy Bush) Date: Wed, 24 May 2017 09:00:10 +0900 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: References: Message-ID: >> read "which is not mpls" a few more times. than maybe read a bit on >> gmpls and optical switching. you may find >> https://en.wikipedia.org/wiki/Generalized_Multi-Protocol_Label_Switching >> a reasonable place to start. > Ok, but does this still not pre-suppose that an appropriate physical > path that has sufficient available bandwidth/slots is already present? not *a* physical path, but a swath of paths from which sufficient capacity can be configured. sadly, gmpls over optical has not yet defied the laws of physics. randy From morrowc.lists at gmail.com Wed May 24 01:49:34 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 23 May 2017 21:49:34 -0400 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: <5924873C.3020701@foobar.org> References: <5924873C.3020701@foobar.org> Message-ID: On Tue, May 23, 2017 at 3:02 PM, Nick Hilliard wrote: > Pedro de Botelho Marcos wrote: > > The current approach for establishing > > agreements is cumbersome, typically requiring lengthy discussions. > > i'm not sure the available data supports this conclusion: > > > http://berec.europa.eu/eng/document_register/subject_ > matter/berec/download/0/6574-2016-survey-of-internet- > carrier-intercon_0.pdf > > which notes: > > > Of the total analyzed agreements, 1,347 (0.07%) were formalized in > > written contracts. This is down from 0.49% in 2011. The remaining > > 1,934,166 (99.93%) were ?handshake? agreements in which the parties > > agreed to informal or commonly understood terms without creating a > > written document. > > it's totally possible that the OP was not talking about "peering" as interconnection (entirely) but also 'customer interconnect' as interconnection. So... "I have 1gbps of traffic I need to send to elbonia-telcom (today) , and tomorrow maybe 3?" means provision a 10g link with 1g commit and burst at X cents/mbps... or whatever... and that works 'today'. Tomorrow you realized 'whoops, by 3gbps I really meant 13... err, now I need to provision a 100g link or add another 10g and LAG... which means 90day telco turnaround on link provisioning... -chris From aaron1 at gvtc.com Wed May 24 14:25:36 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 24 May 2017 09:25:36 -0500 Subject: Making interconnection agreements between networks more dynamic In-Reply-To: References: Message-ID: <000201d2d499$9cd204e0$d6760ea0$@gvtc.com> Sdn/nfv for the physical layer... c'mon man, don't you know we are going to have virtual-fiber too , LOL , jk of course -Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Keith Medcalf Sent: Tuesday, May 23, 2017 5:52 PM To: nanog at nanog.org Subject: RE: Making interconnection agreements between networks more dynamic > > This sounds something like the MEF Third Network type stuff.... I > > mean the ability to setup connection dynamically across network > > boundaries on-the-fly, via an ordering system... that has always > > sounded awesome to me... and I've wondered how we could actually get there one day. > to me, this was the dream of optical switching and gmpls (which is not > mpls) And, pray tell, what is the use of me setting up "peering" between myself and a network on the other side of the world when the data still has to flow over the same connections, merely encapsulated inside a tunnel? Reminds me of the old days when you could directly connect "Chicago" to "Denver" using a direct connection over a PVC that was routed Chicago -> New York -> Miami -> Los Angeles -> Denver. Sure, it looks like a direct connection, but ... Or will this magical interface also deploy robots to build the physical layer? From ccp at atcnet.net Tue May 23 20:13:57 2017 From: ccp at atcnet.net (Robert Peterson) Date: Tue, 23 May 2017 14:13:57 -0600 Subject: Linux container (Docker) or linux VM RFC2544/EtherSAM appliance In-Reply-To: <9D1503ED-3593-48E4-9D0C-29A0FA13D181@lixfeld.ca> References: <9D1503ED-3593-48E4-9D0C-29A0FA13D181@lixfeld.ca> Message-ID: <1d219bda-9569-6d2b-ca7e-85b96c672579@atcnet.net> Group, We are looking for options or opinions on a cost effective RFC2544/EtherSAM appliance we can run on a VM and/or as a Linux container on equipment being placed at the premise. See http://www.vg-labs.com/ for an explanation of the device we would like to run these appliances on. Thanks in advance. From mike at m5hosting.com Wed May 24 08:49:27 2017 From: mike at m5hosting.com (Michael J McCafferty) Date: Wed, 24 May 2017 01:49:27 -0700 Subject: euNetworks, DE-CIX Message-ID: <5BA8686D-6CCF-4061-9BDC-35D24B16361F@m5hosting.com> Operators, We are a US hosting company, expanding in to Europe. In the US we use Level 3 and AIS (AS6130) and Cogent. We planned to use Level 3 and Cogent in EU as well, but our experience with Level 3 support has been less than stellar. I am looking for an Internet provider with whom we can receive full tables, announce our AS/IP space, RTBH, and get a 10G port. Prefer someone that will not have peering fights (we already have that with Cogent). I am interested in feedback from anyone with similar service with euNetworks in Europe (especially Germany). By extension, we will be moving some data through the DE-CIX. Any first-hand experience you might have to share is greatly appreciated, in public or private replies. Thank you very much! Mike ************************************************************ Michael J. McCafferty M5 Hosting http://www.m5hosting.com Like us on Facebook for updates and photos: https://www.facebook.com/m5hosting ************************************************************ From magicsata at gmail.com Wed May 24 17:53:00 2017 From: magicsata at gmail.com (Alistair Mackenzie) Date: Wed, 24 May 2017 18:53:00 +0100 Subject: euNetworks, DE-CIX In-Reply-To: <5BA8686D-6CCF-4061-9BDC-35D24B16361F@m5hosting.com> References: <5BA8686D-6CCF-4061-9BDC-35D24B16361F@m5hosting.com> Message-ID: Which location? On 24 May 2017 at 09:49, Michael J McCafferty wrote: > Operators, > We are a US hosting company, expanding in to Europe. In the US we > use Level 3 and AIS (AS6130) and Cogent. We planned to use Level 3 and > Cogent in EU as well, but our experience with Level 3 support has been less > than stellar. I am looking for an Internet provider with whom we can > receive full tables, announce our AS/IP space, RTBH, and get a 10G port. > Prefer someone that will not have peering fights (we already have that with > Cogent). I am interested in feedback from anyone with similar service with > euNetworks in Europe (especially Germany). > By extension, we will be moving some data through the DE-CIX. > > Any first-hand experience you might have to share is greatly > appreciated, in public or private replies. > > Thank you very much! > Mike > ************************************************************ > Michael J. McCafferty > M5 Hosting > http://www.m5hosting.com > > Like us on Facebook for updates and photos: > https://www.facebook.com/m5hosting > ************************************************************ > > From mike at m5computersecurity.com Wed May 24 17:59:16 2017 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Wed, 24 May 2017 10:59:16 -0700 Subject: euNetworks, DE-CIX Message-ID: Munich. Sent from my Verizon, Samsung Galaxy smartphone -------- Original message -------- From: Alistair Mackenzie Date: 5/24/17 10:53 AM (GMT-08:00) To: Michael J McCafferty Cc: nanog at nanog.org Subject: Re: euNetworks, DE-CIX Which location? On 24 May 2017 at 09:49, Michael J McCafferty wrote: > Operators, >???????? We are a US hosting company, expanding in to Europe. In the US we > use Level 3 and AIS (AS6130) and Cogent. We planned to use Level 3 and > Cogent in EU as well, but our experience with Level 3 support has been less > than stellar. I am looking for an Internet provider with whom we can > receive full tables, announce our AS/IP space, RTBH, and get a 10G port. > Prefer someone that will not have peering fights (we already have that with > Cogent). I am interested in feedback from anyone with similar service with > euNetworks in Europe (especially Germany). >???????? By extension, we will be moving some data through the DE-CIX. > >???????? Any first-hand experience you might have to share is greatly > appreciated, in public or private replies. > > Thank you very much! > Mike > ************************************************************ > Michael J. McCafferty > M5 Hosting > http://www.m5hosting.com > > Like us on Facebook for updates and photos: > https://www.facebook.com/m5hosting > ************************************************************ > > From jk at ip-clear.de Wed May 24 18:12:36 2017 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Wed, 24 May 2017 20:12:36 +0200 Subject: euNetworks, DE-CIX In-Reply-To: References: Message-ID: <302E92C9-0180-4DE3-8A75-A990C2E28E56@ip-clear.de> Hello Michael, we (AS196922) do have 10g transit links in Munich from AS33891 and I can recommended it: http://www.core-backbone.de/, http://bgp.he.net/AS33891, pricing and quality especially for German and European networks are fine. If you can pm me your exact location, I could also cross check the availability. J?rg On 24 May 2017, at 19:59, Michael J McCafferty wrote: > Munich. > > > Sent from my Verizon, Samsung Galaxy smartphone > > -------- Original message -------- > From: Alistair Mackenzie > Date: 5/24/17 10:53 AM (GMT-08:00) > To: Michael J McCafferty > Cc: nanog at nanog.org > Subject: Re: euNetworks, DE-CIX > > Which location? > > On 24 May 2017 at 09:49, Michael J McCafferty > wrote: > >> Operators, >> ???????? We are a US hosting company, expanding in to Europe. >> In the US we >> use Level 3 and AIS (AS6130) and Cogent. We planned to use Level 3 >> and >> Cogent in EU as well, but our experience with Level 3 support has >> been less >> than stellar. I am looking for an Internet provider with whom we can >> receive full tables, announce our AS/IP space, RTBH, and get a 10G >> port. >> Prefer someone that will not have peering fights (we already have >> that with >> Cogent). I am interested in feedback from anyone with similar service >> with >> euNetworks in Europe (especially Germany). >> ???????? By extension, we will be moving some data through >> the DE-CIX. >> >> ???????? Any first-hand experience you might have to share is >> greatly >> appreciated, in public or private replies. >> >> Thank you very much! >> Mike >> ************************************************************ >> Michael J. McCafferty >> M5 Hosting >> http://www.m5hosting.com >> >> Like us on Facebook for updates and photos: >> https://www.facebook.com/m5hosting >> >> ************************************************************ >> >> From rod.beck at unitedcablecompany.com Wed May 24 19:03:19 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 24 May 2017 19:03:19 +0000 Subject: Lille, France Message-ID: Hi, I am looking for insight into which carriers have metropolitan or last mile networks in this city. Preferably connected to Paris. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Kir?ly utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From large.hadron.collider at gmx.com Thu May 25 00:43:30 2017 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Wed, 24 May 2017 17:43:30 -0700 Subject: I'm getting these bounce messages for some bizarre reason. In-Reply-To: <201705241901.v4OJ1TVV022410@b1.c1.bise7.blackberry> References: <201705241901.v4OJ1TVV022410@b1.c1.bise7.blackberry> Message-ID: <71bfa34a-dbb4-24df-da56-320e1d7c6d8d@gmx.com> Would you on the fine mailing list be able to find out what's going on here? -------- Forwarded Message -------- Subject: Delivery Status Notification(Failure) Date: Wed, 24 May 2017 19:01:29 GMT From: postmaster at o2email.co.uk To: large.hadron.collider at gmx.com Your message: To: piers.sturley at o2email.co.uk Subject: Re: Please run windows update now Sent Date: Tue May 16 18:04:19 2017 +0000 has not been delivered to the recipient's BlackBerry Handheld. From trelane at trelane.net Thu May 25 01:53:10 2017 From: trelane at trelane.net (Andrew Kirch) Date: Wed, 24 May 2017 21:53:10 -0400 Subject: I'm getting these bounce messages for some bizarre reason. In-Reply-To: <71bfa34a-dbb4-24df-da56-320e1d7c6d8d@gmx.com> References: <201705241901.v4OJ1TVV022410@b1.c1.bise7.blackberry> <71bfa34a-dbb4-24df-da56-320e1d7c6d8d@gmx.com> Message-ID: It's probably subspace interference caused by high levels of neutrinos. On Wed, May 24, 2017 at 8:43 PM, Large Hadron Collider < large.hadron.collider at gmx.com> wrote: > Would you on the fine mailing list be able to find out what's going on > here? > > > > -------- Forwarded Message -------- > Subject: Delivery Status Notification(Failure) > Date: Wed, 24 May 2017 19:01:29 GMT > From: postmaster at o2email.co.uk > To: large.hadron.collider at gmx.com > > > > Your message: > To: piers.sturley at o2email.co.uk > Subject: Re: Please run windows update now > Sent Date: Tue May 16 18:04:19 2017 +0000 > has not been delivered to the recipient's BlackBerry Handheld. > > > > From jerome at fleury.net Thu May 25 06:15:49 2017 From: jerome at fleury.net (=?UTF-8?B?SsOpcsO0bWUgRmxldXJ5?=) Date: Wed, 24 May 2017 23:15:49 -0700 Subject: Lille, France In-Reply-To: References: Message-ID: Hi Rod, SFR (soon to be renamed Altice) and Orange for sure have metropolitan networks in Lille. There might be others depending on your needs. On Wed, May 24, 2017 at 12:03 PM, Rod Beck wrote: > Hi, > > > I am looking for insight into which carriers have metropolitan or last > mile networks in this city. Preferably connected to Paris. > > > Roderick Beck > > Director of Global Sales > > United Cable Company > > www.unitedcablecompany.com > > 85 Kir?ly utca, 1077 Budapest > > rod.beck at unitedcablecompany.com > > 36-30-859-5144 > > > [1467221477350_image005.png] > From jwbensley at gmail.com Thu May 25 07:39:10 2017 From: jwbensley at gmail.com (James Bensley) Date: Thu, 25 May 2017 08:39:10 +0100 Subject: Linux container (Docker) or linux VM RFC2544/EtherSAM appliance In-Reply-To: <1d219bda-9569-6d2b-ca7e-85b96c672579@atcnet.net> References: <9D1503ED-3593-48E4-9D0C-29A0FA13D181@lixfeld.ca> <1d219bda-9569-6d2b-ca7e-85b96c672579@atcnet.net> Message-ID: I think you can do this with either of Pktgen[1] or Moongen[2] which both use DPDK. Cheers, James. [1] http://dpdk.org/download [2] https://github.com/emmericp/MoonGen From rod.beck at unitedcablecompany.com Thu May 25 11:14:49 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 25 May 2017 11:14:49 +0000 Subject: Lille, France In-Reply-To: References: , Message-ID: Altice is in the States and going public soon. They have been producing superior financial results. Appears to know how to run these cable networks better than the standard American management. ________________________________ From: jeje at jeje.org on behalf of J?r?me Fleury Sent: Thursday, May 25, 2017 8:15 AM To: Rod Beck Cc: nanog at nanog.org Subject: Re: Lille, France Hi Rod, SFR (soon to be renamed Altice) and Orange for sure have metropolitan networks in Lille. There might be others depending on your needs. On Wed, May 24, 2017 at 12:03 PM, Rod Beck > wrote: Hi, I am looking for insight into which carriers have metropolitan or last mile networks in this city. Preferably connected to Paris. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Kir?ly utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From edugas at unknowndevice.ca Thu May 25 12:42:50 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Thu, 25 May 2017 12:42:50 +0000 Subject: Lille, France In-Reply-To: References: Message-ID: From olivier.benghozi at wifirst.fr Thu May 25 13:51:15 2017 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Thu, 25 May 2017 15:51:15 +0200 Subject: Lille, France In-Reply-To: References: Message-ID: <7050CE19-C9E0-40AD-8262-EB50939222B4@wifirst.fr> There's also Eurafibre, I guess. > Le 25 mai 2017 ? 08:15, J?r?me Fleury a ?crit : > > SFR (soon to be renamed Altice) and Orange for sure have metropolitan > networks in Lille. > > There might be others depending on your needs. > > On Wed, May 24, 2017 at 12:03 PM, Rod Beck > wrote: > >> I am looking for insight into which carriers have metropolitan or last >> mile networks in this city. Preferably connected to Paris. From reed at reedloden.com Wed May 24 20:33:29 2017 From: reed at reedloden.com (Reed Loden) Date: Wed, 24 May 2017 13:33:29 -0700 Subject: Managed VPN vendors Message-ID: Greetings, I'm looking for vendors who can provide managed VPN services. Key requirements: * Users would be assigned their own globally-routable IP (or shared with a small number of other users) * Can QoS outgoing connectivity (or at least monitor it to prevent abuse) * Split tunnel with only routes to specific netblocks/IPs (not redirect-gateway) * Egress IPs would need to be dedicated (as in, not shared with any other customers or people) * Ease of administration (adding/removing users) is key (preferably an API!) My Google foo is weak on this (cannot find anything like what I'm looking for), so hoping somebody can help me out or at least point me in the right direction. So much of the search results are about using a VPN to hide your IP and/or protect privacy, which isn't what I am looking for. If you know of anything, please hit me up OOB. Thank you so much in advance! ~reed From john at vanoppen.com Thu May 25 04:06:18 2017 From: john at vanoppen.com (John van Oppen) Date: Thu, 25 May 2017 04:06:18 +0000 Subject: Cisco NCS5501 as a P Router In-Reply-To: References: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> Message-ID: We were looking at them for the same role as well, P router makes a lot of sense in places where the network comes together (for us often ahead of CMTS boxes etc) but routing is still required due to many paths being available. We are using juniper ACX5000s for this as well currently. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Saku Ytti Sent: Thursday, May 18, 2017 6:37 AM To: Erik Sundberg Cc: nanog at nanog.org Subject: Re: Cisco NCS5501 as a P Router On 18 May 2017 at 16:21, Erik Sundberg wrote: Hey, > We're at the growing point where we need a dedicated P router for a core device. We are taking a serious look at the NCS5501. Is there anyone else using a NCS5501 as P Router or just general feedback on the NCS5501 if you are using it? > > The big downside is it's only has a single processor P would be the position I'd be most comfortable with NCS5501. Particularly BGP free core and Internet-in-VRF. Single control-plane does not seem problematic, usually design should allow any single core node to be taken out of service without customer impact. Please talk to your account team about roadmap, what features are coming in which release in next 3 years. And ask them what are their plans with this IP http://www.cisco.com/c/en/us/about/corporate-strategy-office/acquisitions/leaba.html -- ++ytti From jacques.latour at cira.ca Fri May 26 13:42:36 2017 From: jacques.latour at cira.ca (Jacques Latour) Date: Fri, 26 May 2017 13:42:36 +0000 Subject: Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017 Message-ID: [with apologies to those who see this on multiple lists] Call For Presentations The DNS-OARC 27th Workshop will take place in San Jose, CA, USA on September 29th and 30th 2017, the Friday and Saturday preceding NANOG 71.? The Workshop's Program Committee is now requesting proposals for presentations.? All DNS-related subjects are welcome. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we can accommodate those talks during the Members Only session on the morning of September 29th.? A timeslot will also be available for lightning talks (5-10 minutes) on Saturday September 30th, for which submissions will be accepted during Friday 29th. Workshop Milestones: ? 26 May 2017, Call for Presentations posted and open for submissions ? 28 July 2017, Deadline for submission ? 11 August 2017, Draft Programme published ? 01 September 2017, Final Program published ? 15 September 2017, Final deadline for slideset submission Details for presentation submission will be published here: ????https://indico.dns-oarc.net/event/27/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. If you have questions or concerns you can contact the Programme Committee: ????https://www.dns-oarc.net/oarc/programme via Ray Bellis, for the OARC Programme Committee OARC depends on sponorship 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.) From johnstong at westmancom.com Fri May 26 15:39:29 2017 From: johnstong at westmancom.com (Graham Johnston) Date: Fri, 26 May 2017 15:39:29 +0000 Subject: BCP38/84 and DDoS ACLs Message-ID: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> I really did try looking before I sent the email but couldn't quickly find what I was looking for. I am looking for information regarding standard ACLs that operators may be using at the internet edge of their network, on peering and transit connections, wherein you are filtering ingress packets such as those sourced from UDP port 19 for instance. I've found incomplete conceptual discussions about it nothing that seemed concrete or complete. This doesn't seem quite like it is BCP38 and more like this is BCP84, but it only talks about use of ACLs in section 2.1 without providing any examples. Given that it is also 13 years old I thought there might be fresher information out there. Thanks, graham From Rich.Compton at charter.com Fri May 26 16:01:26 2017 From: Rich.Compton at charter.com (Compton, Rich A) Date: Fri, 26 May 2017 16:01:26 +0000 Subject: BCP38/84 and DDoS ACLs In-Reply-To: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> Message-ID: To block UDP port 19 you can add something like: deny udp any eq 19 any deny udp any any eq 19 This will prevent the DDoS attack traffic entering your network (source port 19) as well as the hosts scanning around looking for hosts on your network that can be used in amplification attacks (destination port 19). Please note that this will not block the UDP fragments that come with these attacks which have no L4 port to block. You can possibly do policing on UDP fragments to address this. I?d also suggest adding: deny udp any eq 17 any deny udp any any eq 17 deny udp any eq 123 any packet-length eq 468 deny udp any eq 520 any deny udp any any eq 520 deny udp any eq 1900 any deny udp any any eq 1900 Some people will complain that you shouldn?t block UDP port 1900 because it?s above 1023 but believe me it?s worth it. also to block invalid source IPs to prevent some spoofed traffic from coming into your network: deny ipv4 0.0.0.0 0.255.255.255 any deny ipv4 10.0.0.0 0.255.255.255 any deny ipv4 11.0.0.0 0.255.255.255 any deny ipv4 22.0.0.0 0.255.255.255 any deny ipv4 30.0.0.0 0.255.255.255 any deny ipv4 100.64.0.0 0.63.255.255 any deny ipv4 127.0.0.0 0.255.255.255 any deny ipv4 169.254.0.0 0.0.255.255 any deny ipv4 172.16.0.0 0.15.255.255 any deny ipv4 192.0.0.0 0.0.0.255 any deny ipv4 192.0.2.0 0.0.0.255 any deny ipv4 192.168.0.0 0.0.255.255 any deny ipv4 198.18.0.0 0.1.255.255 any deny ipv4 198.51.0.0 0.0.0.255 any deny ipv4 203.0.113.0 0.0.0.255 any deny ipv4 224.0.0.0 31.255.255.255 any For BCP38 and 84 you would want to enable uRPF https://en.wikipedia.org/wiki/Reverse_path_forwarding https://tools.ietf.org/html/rfc3704 Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr, Englewood, CO 80112 On 5/26/17, 11:39 AM, "NANOG on behalf of Graham Johnston" wrote: >I really did try looking before I sent the email but couldn't quickly >find what I was looking for. > >I am looking for information regarding standard ACLs that operators may >be using at the internet edge of their network, on peering and transit >connections, wherein you are filtering ingress packets such as those >sourced from UDP port 19 for instance. I've found incomplete conceptual >discussions about it nothing that seemed concrete or complete. > >This doesn't seem quite like it is BCP38 and more like this is BCP84, but >it only talks about use of ACLs in section 2.1 without providing any >examples. Given that it is also 13 years old I thought there might be >fresher information out there. > >Thanks, >graham 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 rdobbins at arbor.net Fri May 26 17:19:34 2017 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 May 2017 00:19:34 +0700 Subject: BCP38/84 and DDoS ACLs In-Reply-To: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> Message-ID: <7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net> On 26 May 2017, at 22:39, Graham Johnston wrote: > I am looking for information regarding standard ACLs that operators > may be using at the internet edge of their network, on peering and > transit connections, These .pdf presos may be of interest: They talk about iACL and tACL design philosophy. What traffic you should permit/deny on your network is, of course, situationally-specific. Depends on what kind of network it is, what servers/services/applications/users you have, et. al. You may need one set of ACLs at the peering/transit edge, and other, more specific ACLs, at the IDC distribution gateway, customer aggregation gateway, et. al. ----------------------------------- Roland Dobbins From kvicknair at reservetele.com Fri May 26 17:24:52 2017 From: kvicknair at reservetele.com (Kody Vicknair) Date: Fri, 26 May 2017 17:24:52 +0000 Subject: BCP38/84 and DDoS ACLs In-Reply-To: <7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net> References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> <7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net> Message-ID: <3979AE529B56AB47942E2423B707F16E64C0285A@RTC-EXCH01.RESERVE.LDS> When I was doing some research in regards to the same subject I ran across this doc. I've found it to be very helpful. http://nabcop.org/index.php/DDoS-DoS-attack-BCOP Kody Vicknair Network Engineer Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces+kvicknair=reservetele.com at nanog.org] On Behalf Of Roland Dobbins Sent: Friday, May 26, 2017 12:20 PM To: nanog at nanog.org Subject: Re: BCP38/84 and DDoS ACLs On 26 May 2017, at 22:39, Graham Johnston wrote: > I am looking for information regarding standard ACLs that operators > may be using at the internet edge of their network, on peering and > transit connections, These .pdf presos may be of interest: They talk about iACL and tACL design philosophy. What traffic you should permit/deny on your network is, of course, situationally-specific. Depends on what kind of network it is, what servers/services/applications/users you have, et. al. You may need one set of ACLs at the peering/transit edge, and other, more specific ACLs, at the IDC distribution gateway, customer aggregation gateway, et. al. ----------------------------------- Roland Dobbins From valdis.kletnieks at vt.edu Fri May 26 17:54:28 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 26 May 2017 13:54:28 -0400 Subject: BCP38/84 and DDoS ACLs In-Reply-To: <7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net> References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> <7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net> Message-ID: <10987.1495821268@turing-police.cc.vt.edu> On Sat, 27 May 2017 00:19:34 +0700, Roland Dobbins said: > servers/services/applications/users you have, et. al. You may need one > set of ACLs at the peering/transit edge, and other, more specific ACLs, > at the IDC distribution gateway, customer aggregation gateway, et. al. I'll go out on a limb and suggest that except for a very basic home/SOHO network, "You may need" should be "You will probably need". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From cscora at apnic.net Fri May 26 18:02:40 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 May 2017 04:02:40 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170526180240.4A52DC44D5@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 27 May, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 648754 Prefixes after maximum aggregation (per Origin AS): 253024 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 313436 Total ASes present in the Internet Routing Table: 57333 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 49627 Origin ASes announcing only one prefix: 21973 Transit ASes present in the Internet Routing Table: 7706 Transit-only ASes present in the Internet Routing Table: 219 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 75 Numnber of instances of unregistered ASNs: 79 Number of 32-bit ASNs allocated by the RIRs: 18760 Number of 32-bit ASNs visible in the Routing Table: 14576 Prefixes from 32-bit ASNs in the Routing Table: 58938 Number of bogon 32-bit ASNs visible in the Routing Table: 62 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 358 Number of addresses announced to Internet: 2847714468 Equivalent to 169 /8s, 188 /16s and 172 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.6 Total number of prefixes smaller than registry allocations: 216335 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 178024 Total APNIC prefixes after maximum aggregation: 51257 APNIC Deaggregation factor: 3.47 Prefixes being announced from the APNIC address blocks: 177223 Unique aggregates announced from the APNIC address blocks: 73267 APNIC Region origin ASes present in the Internet Routing Table: 8135 APNIC Prefixes per ASN: 21.79 APNIC Region origin ASes announcing only one prefix: 2280 APNIC Region transit ASes present in the Internet Routing Table: 1140 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2959 Number of APNIC addresses announced to Internet: 763318372 Equivalent to 45 /8s, 127 /16s and 80 /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: 197715 Total ARIN prefixes after maximum aggregation: 94329 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 199790 Unique aggregates announced from the ARIN address blocks: 91726 ARIN Region origin ASes present in the Internet Routing Table: 17910 ARIN Prefixes per ASN: 11.16 ARIN Region origin ASes announcing only one prefix: 6628 ARIN Region transit ASes present in the Internet Routing Table: 1780 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1992 Number of ARIN addresses announced to Internet: 1110674400 Equivalent to 66 /8s, 51 /16s and 139 /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: 174659 Total RIPE prefixes after maximum aggregation: 85397 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 170272 Unique aggregates announced from the RIPE address blocks: 102587 RIPE Region origin ASes present in the Internet Routing Table: 24057 RIPE Prefixes per ASN: 7.08 RIPE Region origin ASes announcing only one prefix: 11101 RIPE Region transit ASes present in the Internet Routing Table: 3395 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5858 Number of RIPE addresses announced to Internet: 711906176 Equivalent to 42 /8s, 110 /16s and 211 /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: 81034 Total LACNIC prefixes after maximum aggregation: 18186 LACNIC Deaggregation factor: 4.46 Prefixes being announced from the LACNIC address blocks: 82282 Unique aggregates announced from the LACNIC address blocks: 38694 LACNIC Region origin ASes present in the Internet Routing Table: 5939 LACNIC Prefixes per ASN: 13.85 LACNIC Region origin ASes announcing only one prefix: 1640 LACNIC Region transit ASes present in the Internet Routing Table: 1096 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3454 Number of LACNIC addresses announced to Internet: 170647520 Equivalent to 10 /8s, 43 /16s and 223 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17205 Total AfriNIC prefixes after maximum aggregation: 3805 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 18829 Unique aggregates announced from the AfriNIC address blocks: 6841 AfriNIC Region origin ASes present in the Internet Routing Table: 1045 AfriNIC Prefixes per ASN: 18.02 AfriNIC Region origin ASes announcing only one prefix: 323 AfriNIC Region transit ASes present in the Internet Routing Table: 203 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 20 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 313 Number of AfriNIC addresses announced to Internet: 90746880 Equivalent to 5 /8s, 104 /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 5571 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3935 402 370 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2987 903 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2752 11136 758 KIXS-AS-KR Korea Telecom, KR 9829 2736 1499 539 BSNL-NIB National Internet Backbone, IN 9808 2214 8699 34 CMNET-GD Guangdong Mobile Communication 4755 2088 422 224 TATACOMM-AS TATA Communications formerl 45899 1990 1392 108 VNPT-AS-VN VNPT Corp, VN 7552 1614 1100 66 VIETEL-AS-AP Viettel Corporation, VN 9583 1575 121 542 SIFY-AS-IN Sify Limited, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 4103 2969 154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3409 1333 80 SHAW - Shaw Communications Inc., CA 18566 2181 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2068 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2006 2166 417 CHARTER-NET-HKY-NC - Charter Communicat 209 1819 5068 639 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1803 3440 582 AMAZON-02 - Amazon.com, Inc., US 30036 1772 324 317 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1691 854 230 ITCDELTA - Earthlink, Inc., US 701 1560 10578 638 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3185 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2891 1001 2072 AKAMAI-ASN1, US 34984 2013 328 386 TELLCOM-AS, TR 9121 1979 1691 17 TTNET, TR 13188 1596 99 56 TRIOLAN, UA 12479 1594 1044 52 UNI2-AS, ES 12389 1502 1398 620 ROSTELECOM-AS, RU 9198 1323 352 25 KAZTELECOM-AS, KZ 6849 1157 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3542 545 156 Telmex Colombia S.A., CO 8151 2520 3403 566 Uninet S.A. de C.V., MX 11830 2085 369 57 Instituto Costarricense de Electricidad 7303 1571 1009 248 Telecom Argentina S.A., AR 6503 1540 437 53 Axtel, S.A.B. de C.V., MX 6147 1175 377 27 Telefonica del Peru S.A.A., PE 3816 1015 496 183 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1009 2284 175 CLARO S.A., BR 11172 921 126 79 Alestra, S. de R.L. de C.V., MX 18881 894 1052 23 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1256 398 48 LINKdotNET-AS, EG 36903 713 358 123 MT-MPLS, MA 37611 711 67 7 Afrihost, ZA 36992 628 1375 26 ETISALAT-MISR, EG 24835 496 850 15 RAYA-AS, EG 29571 419 36 10 CITelecom-AS, CI 37492 406 319 74 ORANGE-, TN 8452 397 1730 17 TE-AS TE-AS, EG 15399 352 35 7 WANANCHI-, KE 2018 296 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5571 4190 74 ERX-CERNET-BKB China Education and Rese 22773 4103 2969 154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3935 402 370 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3542 545 156 Telmex Colombia S.A., CO 6327 3409 1333 80 SHAW - Shaw Communications Inc., CA 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3185 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 17974 2987 903 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2891 1001 2072 AKAMAI-ASN1, US 4766 2752 11136 758 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 4103 3949 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3935 3565 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3542 3386 Telmex Colombia S.A., CO 6327 3409 3329 SHAW - Shaw Communications Inc., CA 39891 3338 3316 ALJAWWALSTC-AS, SA 8551 3185 3145 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2987 2915 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9829 2736 2197 BSNL-NIB National Internet Backbone, IN 9808 2214 2180 CMNET-GD Guangdong Mobile Communication Co.Ltd. 18566 2181 2072 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 66255 UNALLOCATED 45.6.244.0/22 16735 ALGAR TELECOM S/A, BR Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.15.0/24 55427 BROADLINK-AS-AP Broadlink Nepal, NP 27.100.7.0/24 56096 UNKNOWN 36.255.248.0/24 64091 UNKNOWN 36.255.250.0/24 64091 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM, RU 41.77.248.0/21 203496 AB-TELECOM, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM, RU 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.241.246.0/24 132122 ANJNAY-IN Anjnay Information Technology India (P) L Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:104 /12:280 /13:546 /14:1045 /15:1851 /16:13491 /17:7620 /18:13382 /19:24721 /20:38519 /21:41070 /22:76799 /23:63885 /24:363158 /25:827 /26:619 /27:641 /28:45 /29:32 /30:26 /31:1 /32:28 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 3256 4103 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 6327 3203 3409 SHAW - Shaw Communications Inc., CA 39891 2898 3338 ALJAWWALSTC-AS, SA 8551 2650 3185 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2074 2181 MEGAPATH5-US - MegaPath Corporation, US 30036 1569 1772 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1474 2085 Instituto Costarricense de Electricidad y Telec 10620 1468 3542 Telmex Colombia S.A., CO 6389 1375 2068 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 9121 1374 1979 TTNET, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1605 2:842 4:27 5:2424 6:34 8:1093 12:1825 13:119 14:1779 15:26 16:2 17:122 18:121 20:57 23:2286 24:1840 25:2 27:2407 31:1911 32:83 33:9 35:20 36:407 37:2582 38:1331 39:42 40:97 41:3016 42:471 43:1919 44:73 45:2681 46:2733 47:120 49:1201 50:985 51:19 52:816 54:363 55:4 56:4 57:42 58:1587 59:1039 60:391 61:1945 62:1541 63:1920 64:4575 65:2210 66:4530 67:2256 68:1230 69:3373 70:1321 71:584 72:2226 74:2676 75:385 76:433 77:1485 78:1447 79:2438 80:1394 81:1405 82:989 83:721 84:871 85:1748 86:483 87:1157 88:762 89:2065 90:172 91:6173 92:1019 93:2389 94:2330 95:2750 96:608 97:352 98:1033 99:90 100:158 101:1252 103:14811 104:2898 105:182 106:486 107:1645 108:815 109:3014 110:1416 111:1745 112:1177 113:1227 114:1031 115:1729 116:1786 117:1719 118:2154 119:1590 120:1024 121:1107 122:2307 123:1810 124:1529 125:1908 128:757 129:643 130:441 131:1357 132:526 133:192 134:639 135:222 136:455 137:434 138:1955 139:479 140:379 141:568 142:749 143:934 144:785 145:182 146:1028 147:670 148:1435 149:578 150:712 151:970 152:798 153:297 154:822 155:743 156:593 157:636 158:449 159:1457 160:637 161:754 162:2514 163:525 164:789 165:1204 166:382 167:1258 168:2609 169:781 170:3297 171:320 172:1017 173:1879 174:840 175:751 176:1842 177:4016 178:2487 179:1139 180:2199 181:1867 182:2353 183:998 184:866 185:9727 186:3073 187:2200 188:2701 189:1812 190:7910 191:1322 192:9409 193:5789 194:4657 195:3868 196:2130 197:1263 198:5524 199:5884 200:7362 201:4286 202:10370 203:9969 204:4475 205:2803 206:3015 207:3141 208:3983 209:4003 210:3955 211:2138 212:2828 213:2496 214:879 215:66 216:5725 217:2076 218:842 219:602 220:1655 221:911 222:758 223:1179 End of report From rdobbins at arbor.net Fri May 26 18:04:00 2017 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 May 2017 01:04:00 +0700 Subject: BCP38/84 and DDoS ACLs In-Reply-To: <10987.1495821268@turing-police.cc.vt.edu> References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> <7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net> <10987.1495821268@turing-police.cc.vt.edu> Message-ID: On 27 May 2017, at 0:54, valdis.kletnieks at vt.edu wrote: > I'll go out on a limb and suggest that except for a very basic home/SOHO > network, "You may need" should be "You will probably need". Concur, heh. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Fri May 26 18:09:51 2017 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 27 May 2017 01:09:51 +0700 Subject: BCP38/84 and DDoS ACLs In-Reply-To: <7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net> References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> <7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net> Message-ID: <261BE93D-1E52-4F9F-8C47-49D842134226@arbor.net> On 27 May 2017, at 0:19, Roland Dobbins wrote: > This is the correct URI for the first preso, apologies: ----------------------------------- Roland Dobbins From me at anuragbhatia.com Fri May 26 18:40:56 2017 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 27 May 2017 00:10:56 +0530 Subject: What happened to BGP Update Report? Message-ID: Hello, everyone. I wonder if anyone is aware of what happened to BGP Update Report which was being published to most of NOG mailing lists? I see the last one is from 7th Dec 2016. BGP Update Report was the one which provided unstable origin ASNs etc. I still do see the weekly routing table report with other data. Thanks. -- Anurag Bhatia anuragbhatia.com From lathama at gmail.com Fri May 26 18:51:21 2017 From: lathama at gmail.com (Andrew Latham) Date: Fri, 26 May 2017 13:51:21 -0500 Subject: What happened to BGP Update Report? In-Reply-To: References: Message-ID: Just bookmark http://bgpupdates.potaroo.net/instability/bgpupd.html if you like the report. On Fri, May 26, 2017 at 1:40 PM, Anurag Bhatia wrote: > Hello, everyone. > > > I wonder if anyone is aware of what happened to BGP Update Report which was > being published to most of NOG mailing lists? > > I see the last one is from 7th Dec 2016. BGP Update Report was the one > which provided unstable origin ASNs etc. I still do see the weekly routing > table report with other data. > > > > > Thanks. > -- > > > Anurag Bhatia > anuragbhatia.com > -- - Andrew "lathama" Latham - From randy at psg.com Fri May 26 23:07:57 2017 From: randy at psg.com (Randy Bush) Date: Sat, 27 May 2017 08:07:57 +0900 Subject: BCP38/84 and DDoS ACLs In-Reply-To: <261BE93D-1E52-4F9F-8C47-49D842134226@arbor.net> References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> <7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net> <261BE93D-1E52-4F9F-8C47-49D842134226@arbor.net> Message-ID: to be honest, i do not block chargen etc at my borders; i scan hosts and turn off silly services on the hosts. but i do not have myriads of hosts in a soft gooey inside. what i block at my borders are 135-139, 161 (except for holes for measurement stations), 445, 514, stuff such as that. ykmv randy From joelja at bogus.com Sat May 27 00:44:18 2017 From: joelja at bogus.com (joel jaeggli) Date: Fri, 26 May 2017 17:44:18 -0700 Subject: BCP38/84 and DDoS ACLs In-Reply-To: <3979AE529B56AB47942E2423B707F16E64C0285A@RTC-EXCH01.RESERVE.LDS> References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> <7BB753C8-7F99-4129-9E5B-97225866922B@arbor.net> <3979AE529B56AB47942E2423B707F16E64C0285A@RTC-EXCH01.RESERVE.LDS> Message-ID: On 5/26/17 10:24, Kody Vicknair wrote: > When I was doing some research in regards to the same subject I ran across this doc. I've found it to be very helpful. > > http://nabcop.org/index.php/DDoS-DoS-attack-BCOP Causally applied RPF checks applied to transit and peer interfaces especially exchange fabrics have a very high-liklihood of blackholing traffic you wanted particularly during maintenance if not casually implemented. A very careful read rfc3704/bcp 84 is a necessary part of implementing bcp 38 filters. > > > Kody Vicknair > Network Engineer > > Tel: 985.536.1214 > Fax: 985.536.0300 > Email: kvicknair at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > _________________________________________________________________________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+kvicknair=reservetele.com at nanog.org] On Behalf Of Roland Dobbins > Sent: Friday, May 26, 2017 12:20 PM > To: nanog at nanog.org > Subject: Re: BCP38/84 and DDoS ACLs > > > On 26 May 2017, at 22:39, Graham Johnston wrote: > >> I am looking for information regarding standard ACLs that operators >> may be using at the internet edge of their network, on peering and >> transit connections, > These .pdf presos may be of interest: > > > > > > They talk about iACL and tACL design philosophy. > > What traffic you should permit/deny on your network is, of course, situationally-specific. Depends on what kind of network it is, what servers/services/applications/users you have, et. al. You may need one set of ACLs at the peering/transit edge, and other, more specific ACLs, at the IDC distribution gateway, customer aggregation gateway, et. al. > > ----------------------------------- > Roland Dobbins > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From jamesl at mythostech.com Sat May 27 06:49:08 2017 From: jamesl at mythostech.com (James Laszko) Date: Sat, 27 May 2017 06:49:08 +0000 Subject: EQUIPMENT NEEDED: PRI/SIP Gateway (Adtran) Message-ID: <9F5E1E62-2E47-4CAE-87BD-71B250A1F132@mythostech.com> Hi everyone- Had a new Adtran TA908e going into service tonight for a customer move and something went wrong and it physically blew up on us. Customer going live Tuesday morning, located in San Diego. Anyone have a compatible unit we can rent or buy until we get a replacement? Only really need 1 PRI with 23 SIP trunk capability. I appreciate any help that may be available and Happy Memorial Day! Thanks, James Laszko Mythos Technology Inc jamesl at mythostech.com Sent from my iPhone From nanog at radu-adrian.feurdean.net Sat May 27 09:30:41 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sat, 27 May 2017 11:30:41 +0200 Subject: Cisco NCS5501 as a P Router In-Reply-To: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> Message-ID: <1495877441.2205042.990222424.4D07C5D7@webmail.messagingengine.com> On Thu, May 18, 2017, at 15:21, Erik Sundberg wrote: > We're at the growing point where we need a dedicated P router for a core > device. We are taking a serious look at the NCS5501. Is there anyone else > using a NCS5501 as P Router or just general feedback on the NCS5501 if > you are using it? Hi, While we're not using the NCS5501, we do use the "previous version", NCS5001. We're not yet at a point to care about the minuscule buffers. Set-up : initially P-router in a very small BGP-free core (ISIS + LDP), then added route-reflector functionality too. As a P-router they usually behave correctly, except for the some cases where they start routing incorrectly (according to Cisco, the wrong label is programmed into hardware). That should have been fixed with 6.1.2, which we have deployed, until we recently had the same issue on 6.1.2, on the exact same box. We expect having some fun with the TAC about that. > The big downside is it's only has a single processor Yes, but: - it's powerful enough (we ended-up using them as RR too, and ~1.2M routes in RIB pose no problem) - ours being about half the price of a 5501, we have 2 of them on every site. If you can afford the same (2 / site) do it; If you don't - review the copy so that you can (Brocade SLX 9540 looks like a good alternative). From me at geordish.org Sat May 27 09:54:15 2017 From: me at geordish.org (Dave Bell) Date: Sat, 27 May 2017 10:54:15 +0100 Subject: BCP38/84 and DDoS ACLs In-Reply-To: References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> Message-ID: Your bogon list has a few non-bogons, and is missing a few current bogon. Team Cymru keep a good resource for this: http://www.team-cymru. org/bogon-dotted-decimal.html Regards, Dave On 26 May 2017 5:01 pm, "Compton, Rich A" wrote: > To block UDP port 19 you can add something like: > deny udp any eq 19 any > deny udp any any eq 19 > > This will prevent the DDoS attack traffic entering your network (source > port 19) as well as the hosts scanning around looking for hosts on your > network that can be used in amplification attacks (destination port 19). > Please note that this will not block the UDP fragments that come with > these attacks which have no L4 port to block. You can possibly do > policing on UDP fragments to address this. > > I?d also suggest adding: > deny udp any eq 17 any > deny udp any any eq 17 > > deny udp any eq 123 any packet-length eq 468 > > deny udp any eq 520 any > deny udp any any eq 520 > > deny udp any eq 1900 any > deny udp any any eq 1900 > > Some people will complain that you shouldn?t block UDP port 1900 because > it?s above 1023 but believe me it?s worth it. > > > > also to block invalid source IPs to prevent some spoofed traffic from > coming into your network: > > deny ipv4 0.0.0.0 0.255.255.255 any > deny ipv4 10.0.0.0 0.255.255.255 any > deny ipv4 11.0.0.0 0.255.255.255 any > deny ipv4 22.0.0.0 0.255.255.255 any > deny ipv4 30.0.0.0 0.255.255.255 any > deny ipv4 100.64.0.0 0.63.255.255 any > deny ipv4 127.0.0.0 0.255.255.255 any > deny ipv4 169.254.0.0 0.0.255.255 any > deny ipv4 172.16.0.0 0.15.255.255 any > deny ipv4 192.0.0.0 0.0.0.255 any > deny ipv4 192.0.2.0 0.0.0.255 any > deny ipv4 192.168.0.0 0.0.255.255 any > deny ipv4 198.18.0.0 0.1.255.255 any > deny ipv4 198.51.0.0 0.0.0.255 any > deny ipv4 203.0.113.0 0.0.0.255 any > deny ipv4 224.0.0.0 31.255.255.255 any > > > For BCP38 and 84 you would want to enable uRPF > https://en.wikipedia.org/wiki/Reverse_path_forwarding > https://tools.ietf.org/html/rfc3704 > > > > Rich Compton | Principal Eng | 314.596.2828 > 14810 Grasslands Dr, Englewood, CO 80112 > > > > > > > On 5/26/17, 11:39 AM, "NANOG on behalf of Graham Johnston" > wrote: > > >I really did try looking before I sent the email but couldn't quickly > >find what I was looking for. > > > >I am looking for information regarding standard ACLs that operators may > >be using at the internet edge of their network, on peering and transit > >connections, wherein you are filtering ingress packets such as those > >sourced from UDP port 19 for instance. I've found incomplete conceptual > >discussions about it nothing that seemed concrete or complete. > > > >This doesn't seem quite like it is BCP38 and more like this is BCP84, but > >it only talks about use of ACLs in section 2.1 without providing any > >examples. Given that it is also 13 years old I thought there might be > >fresher information out there. > > > >Thanks, > >graham > > 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 gustav.ulander at telecomputing.se Sat May 27 14:42:37 2017 From: gustav.ulander at telecomputing.se (Gustav Ulander) Date: Sat, 27 May 2017 14:42:37 +0000 Subject: SV: Cisco NCS5501 as a P Router In-Reply-To: <1495877441.2205042.990222424.4D07C5D7@webmail.messagingengine.com> References: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> <1495877441.2205042.990222424.4D07C5D7@webmail.messagingengine.com> Message-ID: Hello. We are running 5001 also and we have the same issue with it programming the wrong entry into the hardware. Interesting to hear that the issue is still in 6.1.2 since we were thinking about upgrading to that one to see if it fixes the issue but I think we will give it a pass. Seems the BU cant find why its happening only that it indeed is happening. They don?t seem to be able to duplicate it in the lab either last we heard. /Gustav -----Ursprungligt meddelande----- Fr?n: NANOG [mailto:nanog-bounces at nanog.org] F?r Radu-Adrian Feurdean Skickat: den 27 maj 2017 11:31 Till: nanog at nanog.org ?mne: Re: Cisco NCS5501 as a P Router On Thu, May 18, 2017, at 15:21, Erik Sundberg wrote: > We're at the growing point where we need a dedicated P router for a > core device. We are taking a serious look at the NCS5501. Is there > anyone else using a NCS5501 as P Router or just general feedback on > the NCS5501 if you are using it? Hi, While we're not using the NCS5501, we do use the "previous version", NCS5001. We're not yet at a point to care about the minuscule buffers. Set-up : initially P-router in a very small BGP-free core (ISIS + LDP), then added route-reflector functionality too. As a P-router they usually behave correctly, except for the some cases where they start routing incorrectly (according to Cisco, the wrong label is programmed into hardware). That should have been fixed with 6.1.2, which we have deployed, until we recently had the same issue on 6.1.2, on the exact same box. We expect having some fun with the TAC about that. > The big downside is it's only has a single processor Yes, but: - it's powerful enough (we ended-up using them as RR too, and ~1.2M routes in RIB pose no problem) - ours being about half the price of a 5501, we have 2 of them on every site. If you can afford the same (2 / site) do it; If you don't - review the copy so that you can (Brocade SLX 9540 looks like a good alternative). From me at anuragbhatia.com Sat May 27 17:54:02 2017 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 27 May 2017 23:24:02 +0530 Subject: What happened to BGP Update Report? In-Reply-To: References: Message-ID: Seems good. Thanks for sharing! On Sat, May 27, 2017 at 12:21 AM, Andrew Latham wrote: > Just bookmark http://bgpupdates.potaroo.net/instability/bgpupd.html if you > like the report. > > On Fri, May 26, 2017 at 1:40 PM, Anurag Bhatia > wrote: > > > Hello, everyone. > > > > > > I wonder if anyone is aware of what happened to BGP Update Report which > was > > being published to most of NOG mailing lists? > > > > I see the last one is from 7th Dec 2016. BGP Update Report was the one > > which provided unstable origin ASNs etc. I still do see the weekly > routing > > table report with other data. > > > > > > > > > > Thanks. > > -- > > > > > > Anurag Bhatia > > anuragbhatia.com > > > > > > -- > - Andrew "lathama" Latham - > -- Anurag Bhatia anuragbhatia.com From aaron1 at gvtc.com Sat May 27 19:14:11 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Sat, 27 May 2017 14:14:11 -0500 Subject: Cisco NCS5501 as a P Router In-Reply-To: <1495877441.2205042.990222424.4D07C5D7@webmail.messagingengine.com> References: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> <1495877441.2205042.990222424.4D07C5D7@webmail.messagingengine.com> Message-ID: <000d01d2d71d$6cb2b440$46181cc0$@gvtc.com> Hi Radu-Adrian, have you done any MPLS PE functions on the NCS5001 ? ...like MPLS/VPLS L2VPN, or L3VPN ? I'm asking because I tried a NCS5001 in my lab about a year or 2 ago and it was pretty bad. At which point I was told to only try it as a P box from a Cisco engineer....at which point it dropped from my consideration since I needed to replace lots of Cisco ME3600's with mpls edge functions, and I ended up settling on the Juniper ACX5048. I'm wondering if Cisco improved that NCS5001 in more recent versions of XR to included functional MPLS L2 and L3 vpn's. -Aaron From bryan at shout.net Sat May 27 20:31:38 2017 From: bryan at shout.net (Bryan Holloway) Date: Sat, 27 May 2017 15:31:38 -0500 Subject: EQUIPMENT NEEDED: PRI/SIP Gateway (Adtran) In-Reply-To: <9F5E1E62-2E47-4CAE-87BD-71B250A1F132@mythostech.com> References: <9F5E1E62-2E47-4CAE-87BD-71B250A1F132@mythostech.com> Message-ID: Didja plug it into 208V? We had a customer that blew up two before realizing that those (inexplicably) are 120V-only, unlike anything else modern on the planet. On 5/27/17 1:49 AM, James Laszko wrote: > Hi everyone- > > Had a new Adtran TA908e going into service tonight for a customer move and something went wrong and it physically blew up on us. Customer going live Tuesday morning, located in San Diego. Anyone have a compatible unit we can rent or buy until we get a replacement? Only really need 1 PRI with 23 SIP trunk capability. > > I appreciate any help that may be available and Happy Memorial Day! > > > Thanks, > > > James Laszko > Mythos Technology Inc > jamesl at mythostech.com > > > > Sent from my iPhone > From nanog at radu-adrian.feurdean.net Sun May 28 12:16:16 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sun, 28 May 2017 14:16:16 +0200 Subject: Cisco NCS5501 as a P Router In-Reply-To: <000d01d2d71d$6cb2b440$46181cc0$@gvtc.com> References: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> <1495877441.2205042.990222424.4D07C5D7@webmail.messagingengine.com> <000d01d2d71d$6cb2b440$46181cc0$@gvtc.com> Message-ID: <1495973776.2991581.990880288.37F773E5@webmail.messagingengine.com> Hi, We didn't test any of those features. My understandig was that they all require extra licenses that would bring them "out of scope" ($$$-wise).... and our need was for pure "P-routers"... actually being technically unable to perform as PE was kind of hidden requirement :) On Sat, May 27, 2017, at 21:14, Aaron Gould wrote: > Hi Radu-Adrian, have you done any MPLS PE functions on the NCS5001 ? > ...like MPLS/VPLS L2VPN, or L3VPN ? > > I'm asking because I tried a NCS5001 in my lab about a year or 2 ago and > it was pretty bad. At which point I was told to only try it as a P box > from a Cisco engineer....at which point it dropped from my consideration > since I needed to replace lots of Cisco ME3600's with mpls edge > functions, and I ended up settling on the Juniper ACX5048. > > I'm wondering if Cisco improved that NCS5001 in more recent versions of > XR to included functional MPLS L2 and L3 vpn's. > > -Aaron > > > From benc at overthewire.com.au Mon May 29 00:44:53 2017 From: benc at overthewire.com.au (Ben Cornish) Date: Mon, 29 May 2017 10:44:53 +1000 Subject: Cisco NCS5501 as a P Router In-Reply-To: References: <495D0934DA46854A9CA758393724D5907551BBF7@NI-MAIL02.nii.ads> <1495877441.2205042.990222424.4D07C5D7@webmail.messagingengine.com> Message-ID: <0c4a23d9b6d88ad91e00e1b8a2374ef9@mail.gmail.com> We are currently looking at the 5501 as a BGP'less super Core / P router configuration - as a replacement for the troubled 6840 platform. Curious who is running these with Brocade LSP's running through them ? I'm not overly convinced these are the right platform yet and happy to take direct feedback. We followed Cisco Recommendation on installing 6840's into our Core as P routers / BGP'less Super Core and had nothing but issues with them. Wrong forwarding labels / stuck LSP's. / heaps of Optics problems. Only to be told later that MPLS-TE Auto-Tunnel won't be coming to the platform either. We?ve been pretty unhappy with that platform. Seems the Cisco code can't handle new LSP mid-point creations with the same LSP ID. We currently have an issue around Brocade wanting to recalc and LSP path(midpoint failure), but wanting to use the same LSP id to create it- Cisco's want it to expire out first. Cisco sees this particular issue as Brocade not understanding the RFC - yet Brocade say the same thing ... Curious of anyone out there today using NCS5501's with Brocade LSP's transiting them ? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gustav Ulander Sent: Sunday, 28 May 2017 12:43 AM To: Radu-Adrian Feurdean ; nanog at nanog.org Subject: SV: Cisco NCS5501 as a P Router Hello. We are running 5001 also and we have the same issue with it programming the wrong entry into the hardware. Interesting to hear that the issue is still in 6.1.2 since we were thinking about upgrading to that one to see if it fixes the issue but I think we will give it a pass. Seems the BU cant find why its happening only that it indeed is happening. They don?t seem to be able to duplicate it in the lab either last we heard. /Gustav -----Ursprungligt meddelande----- Fr?n: NANOG [mailto:nanog-bounces at nanog.org] F?r Radu-Adrian Feurdean Skickat: den 27 maj 2017 11:31 Till: nanog at nanog.org ?mne: Re: Cisco NCS5501 as a P Router On Thu, May 18, 2017, at 15:21, Erik Sundberg wrote: > We're at the growing point where we need a dedicated P router for a > core device. We are taking a serious look at the NCS5501. Is there > anyone else using a NCS5501 as P Router or just general feedback on > the NCS5501 if you are using it? Hi, While we're not using the NCS5501, we do use the "previous version", NCS5001. We're not yet at a point to care about the minuscule buffers. Set-up : initially P-router in a very small BGP-free core (ISIS + LDP), then added route-reflector functionality too. As a P-router they usually behave correctly, except for the some cases where they start routing incorrectly (according to Cisco, the wrong label is programmed into hardware). That should have been fixed with 6.1.2, which we have deployed, until we recently had the same issue on 6.1.2, on the exact same box. We expect having some fun with the TAC about that. > The big downside is it's only has a single processor Yes, but: - it's powerful enough (we ended-up using them as RR too, and ~1.2M routes in RIB pose no problem) - ours being about half the price of a 5501, we have 2 of them on every site. If you can afford the same (2 / site) do it; If you don't - review the copy so that you can (Brocade SLX 9540 looks like a good alternative). From robt at cymru.com Mon May 29 17:25:57 2017 From: robt at cymru.com (Rabbi Rob Thomas) Date: Mon, 29 May 2017 13:25:57 -0400 Subject: BCP38/84 and DDoS ACLs In-Reply-To: References: <82C0CE81789FE64D8F4D15263191829715CD0841@MSG6.westman.int> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear team, > Your bogon list has a few non-bogons, and is missing a few current > bogon. > > Team Cymru keep a good resource for this: http://www.team-cymru. > org/bogon-dotted-decimal.html Thank you, Dave! The full list of formats and styles can be found here: Be well, Rob. - -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree." - Leo McKern -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZLFmkAAoJEEPoYWL6hfKNJTUP/2KWdB1nwUx/R6tReKNkKkSx L71nOaLMy/MIxOgw1OgI2xMPPpJtsGhTje37gpc8jV0jrx7P7VJ1/omp4gS8MFfd ij2XSgSmix8neTYoqpfpj15Ra+1fTxcqxO68mza5IG5zYDR7Z96/jOzHoGe1NgJk pPpS1cNv55ToeCG6ETcJ6k1LFC4uzNDdu5bVbLJMqeTbnHu0GCV/hx5xIHpWHOSM dODifv8fadqjJNx548smGim2aFApFv1ALHNrxLm8jWokNLhDSEJBQl9pnnByifrs huiRcCRVCzgJXCaig6ykS7RHtqCnMnIEllMqeJqCVzA2+l/FS7NFJmnXttXT5SyK HoL+pbQ7PeUO5CgMheBfSkguECIjRJb3L/mnMCGKuueBoYikH2u7WFUowBEYlezH I/BmooPVoKKrdSX9Y/UU8Pt/mW06M5rVo/hs2mB2uZ44SDqu9IZGcef+9Qb1Jq25 IxUHlRVXg5aC8k0VOQm0JCMD2JGeRO5OSnu/pnsuaywrK6wEvns/mgFaPTNOsTR1 AbUvrBl+MJ3sFbxJUDioIojXPn9H+LdC4x79+NpdVu9vY8EZ9aCY8YWJLd56hjIH HfA7Y+M5JGVfdXBp6iJftR6U1cBumWasQ5Evz48VCnzEt75qXitHijjdmvfeyRuV unmPsF25BuVfX3DAYYPu =57M1 -----END PGP SIGNATURE----- From nick at flhsi.com Tue May 30 15:22:46 2017 From: nick at flhsi.com (Nick Olsen) Date: Tue, 30 May 2017 11:22:46 -0400 Subject: RFC2544 Testing Equipment Message-ID: Greetings all, Looking for a good test set. Primary use will be testing L2 circuits (It'll technically be VPLS, But the test set will just see L2). Being able to test routed L3 would also be useful. Most of the sets I've seen are two sided, A "reflector" at the remote side, And the test set in hand run by the technician. Looking to test up to 1Gb/s at various packet sizes, Measure Packet loss, Jitter..etc. Primarily Copper, But if it had some form of optical port, I wouldn't complain. Outputting a report that we can provide to the customer would be useful, But isn't mandatory. Doesn't need anything fancy, Like MPLS awareness, VLAN ID's..etc. Nick Olsen Sr. Network Engineer Florida High Speed Internet (321) 205-1100 x106 From James at arenalgroup.co Tue May 30 15:26:21 2017 From: James at arenalgroup.co (James Breeden) Date: Tue, 30 May 2017 15:26:21 +0000 Subject: RFC2544 Testing Equipment In-Reply-To: References: Message-ID: When we had to do this once in a blue moon, we just bought a pair of old Agilent Framescopes off ebay. They worked great but we had issues getting reporting out of them. They had RJ45 and SFP on them. -----Original Message----- From: NANOG [mailto:nanog-bounces+james=arenalgroup.co at nanog.org] On Behalf Of Nick Olsen Sent: Tuesday, May 30, 2017 10:23 AM To: nanog at nanog.org Subject: RFC2544 Testing Equipment Greetings all, Looking for a good test set. Primary use will be testing L2 circuits (It'll technically be VPLS, But the test set will just see L2). Being able to test routed L3 would also be useful. Most of the sets I've seen are two sided, A "reflector" at the remote side, And the test set in hand run by the technician. Looking to test up to 1Gb/s at various packet sizes, Measure Packet loss, Jitter..etc. Primarily Copper, But if it had some form of optical port, I wouldn't complain. Outputting a report that we can provide to the customer would be useful, But isn't mandatory. Doesn't need anything fancy, Like MPLS awareness, VLAN ID's..etc. Nick Olsen Sr. Network Engineer Florida High Speed Internet (321) 205-1100 x106 From jhaustin at gmail.com Tue May 30 15:29:03 2017 From: jhaustin at gmail.com (Jeremy Austin) Date: Tue, 30 May 2017 15:29:03 +0000 Subject: RFC2544 Testing Equipment In-Reply-To: References: Message-ID: JW, have you moved on to EtherSAM? That's what I'd be looking for myself. On Tue, May 30, 2017 at 7:28 AM James Breeden wrote: > When we had to do this once in a blue moon, we just bought a pair of old > Agilent Framescopes off ebay. They worked great but we had issues getting > reporting out of them. They had RJ45 and SFP on them. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+james=arenalgroup.co at nanog.org] On > Behalf Of Nick Olsen > Sent: Tuesday, May 30, 2017 10:23 AM > To: nanog at nanog.org > Subject: RFC2544 Testing Equipment > > Greetings all, > > Looking for a good test set. Primary use will be testing L2 circuits > (It'll technically be VPLS, But the test set will just see L2). Being able > to test routed L3 would also be useful. Most of the sets I've seen are two > sided, A "reflector" at the remote side, And the test set in hand run by > the technician. > > Looking to test up to 1Gb/s at various packet sizes, Measure Packet loss, > Jitter..etc. Primarily Copper, But if it had some form of optical port, I > wouldn't complain. Outputting a report that we can provide to the customer > would be useful, But isn't mandatory. Doesn't need anything fancy, Like > MPLS awareness, VLAN ID's..etc. > > > Nick Olsen > Sr. Network Engineer > Florida High Speed Internet > (321) 205-1100 x106 > > > > > > > > From shawnl at up.net Tue May 30 16:02:10 2017 From: shawnl at up.net (Shawn L) Date: Tue, 30 May 2017 12:02:10 -0400 (EDT) Subject: RFC2544 Testing Equipment In-Reply-To: References: Message-ID: <1496160130.795830624@upnet.mymailsrvr.com> JDSU make some nice ones that we use to qualify cell tower back haul. Not cheap though -----Original Message----- From: "Jeremy Austin" Sent: Tuesday, May 30, 2017 11:29am To: "James Breeden" , "nick at flhsi.com" , "nanog at nanog.org" Subject: Re: RFC2544 Testing Equipment JW, have you moved on to EtherSAM? That's what I'd be looking for myself. On Tue, May 30, 2017 at 7:28 AM James Breeden wrote: > When we had to do this once in a blue moon, we just bought a pair of old > Agilent Framescopes off ebay. They worked great but we had issues getting > reporting out of them. They had RJ45 and SFP on them. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+james=arenalgroup.co at nanog.org] On > Behalf Of Nick Olsen > Sent: Tuesday, May 30, 2017 10:23 AM > To: nanog at nanog.org > Subject: RFC2544 Testing Equipment > > Greetings all, > > Looking for a good test set. Primary use will be testing L2 circuits > (It'll technically be VPLS, But the test set will just see L2). Being able > to test routed L3 would also be useful. Most of the sets I've seen are two > sided, A "reflector" at the remote side, And the test set in hand run by > the technician. > > Looking to test up to 1Gb/s at various packet sizes, Measure Packet loss, > Jitter..etc. Primarily Copper, But if it had some form of optical port, I > wouldn't complain. Outputting a report that we can provide to the customer > would be useful, But isn't mandatory. Doesn't need anything fancy, Like > MPLS awareness, VLAN ID's..etc. > > > Nick Olsen > Sr. Network Engineer > Florida High Speed Internet > (321) 205-1100 x106 > > > > > > > > From jwbensley at gmail.com Wed May 31 10:36:48 2017 From: jwbensley at gmail.com (James Bensley) Date: Wed, 31 May 2017 11:36:48 +0100 Subject: RFC2544 Testing Equipment In-Reply-To: References: Message-ID: On 30 May 2017 at 16:22, Nick Olsen wrote: > Greetings all, > > Looking for a good test set. Primary use will be testing L2 circuits > (It'll technically be VPLS, But the test set will just see L2). Being able > to test routed L3 would also be useful. Most of the sets I've seen are two > sided, A "reflector" at the remote side, And the test set in hand run by > the technician. > > Looking to test up to 1Gb/s at various packet sizes, Measure Packet loss, > Jitter..etc. Primarily Copper, But if it had some form of optical port, I > wouldn't complain. Outputting a report that we can provide to the customer > would be useful, But isn't mandatory. Doesn't need anything fancy, Like > MPLS awareness, VLAN ID's..etc. > > > Nick Olsen > Sr. Network Engineer > Florida High Speed Internet > (321) 205-1100 x106 If you are just testing the forwarding at layer 2 and have no budget you can use free software and a laptop (for your copper requirement). I've been writing this (https://github.com/jwbensley/Etherate) and we use that as well as hardware testers. Cheers, James. From saku at ytti.fi Wed May 31 10:56:47 2017 From: saku at ytti.fi (Saku Ytti) Date: Wed, 31 May 2017 13:56:47 +0300 Subject: RFC2544 Testing Equipment In-Reply-To: References: Message-ID: Cool. Seems you're using AF_PACKET, which makes it actually unique. iperf/netperf etc use UDP or TCP socket, so UDP performance is just abysmal, you can't saturate 1GE link with any reliability. So measuring for example packet loss is not possible at all. I've been meaning to write AF_PACKET based UDP sender/receiver and have gotten pretty far with friend of mine on rust version, we can congest 1GE (on minimum size frames) on Linux reliably and actually tell if you're lossy. It has server/client design, where client requests via JSON based messages through control-channel server to receive or send, and what exactly. Alas, we're only 80% there, and seem to struggle to find time to polish it for initial release. We definitely need tool like iperf, which performs at least to 1GE, and AF_PACKET can do that, UDP socket cannot. Alas 10GE is still pipe dream for anything as portable as iperf, as you'd need to use DPDK, netmap or equivalent which will remove the NIC from userland, there are quite few options for that use-case, but no good option for use-case when you want at least 1GE but you cannot remove NIC from userland. On 31 May 2017 at 13:36, James Bensley wrote: > On 30 May 2017 at 16:22, Nick Olsen wrote: >> Greetings all, >> >> Looking for a good test set. Primary use will be testing L2 circuits >> (It'll technically be VPLS, But the test set will just see L2). Being able >> to test routed L3 would also be useful. Most of the sets I've seen are two >> sided, A "reflector" at the remote side, And the test set in hand run by >> the technician. >> >> Looking to test up to 1Gb/s at various packet sizes, Measure Packet loss, >> Jitter..etc. Primarily Copper, But if it had some form of optical port, I >> wouldn't complain. Outputting a report that we can provide to the customer >> would be useful, But isn't mandatory. Doesn't need anything fancy, Like >> MPLS awareness, VLAN ID's..etc. >> >> >> Nick Olsen >> Sr. Network Engineer >> Florida High Speed Internet >> (321) 205-1100 x106 > > > If you are just testing the forwarding at layer 2 and have no budget > you can use free software and a laptop (for your copper requirement). > I've been writing this (https://github.com/jwbensley/Etherate) and we > use that as well as hardware testers. > > Cheers, > James. -- ++ytti From jwbensley at gmail.com Wed May 31 11:23:46 2017 From: jwbensley at gmail.com (James Bensley) Date: Wed, 31 May 2017 12:23:46 +0100 Subject: RFC2544 Testing Equipment In-Reply-To: References: Message-ID: On 31 May 2017 at 11:56, Saku Ytti wrote: > Cool. Seems you're using AF_PACKET, which makes it actually unique. > iperf/netperf etc use UDP or TCP socket, so UDP performance is just > abysmal, you can't saturate 1GE link with any reliability. So > measuring for example packet loss is not possible at all. > > I've been meaning to write AF_PACKET based UDP sender/receiver and > have gotten pretty far with friend of mine on rust version, we can > congest 1GE (on minimum size frames) on Linux reliably and actually > tell if you're lossy. It has server/client design, where client > requests via JSON based messages through control-channel server to > receive or send, and what exactly. > Alas, we're only 80% there, and seem to struggle to find time to > polish it for initial release. > > We definitely need tool like iperf, which performs at least to 1GE, > and AF_PACKET can do that, UDP socket cannot. Alas 10GE is still pipe > dream for anything as portable as iperf, as you'd need to use DPDK, > netmap or equivalent which will remove the NIC from userland, there > are quite few options for that use-case, but no good option for > use-case when you want at least 1GE but you cannot remove NIC from > userland. Hi Saku, Yeah AF_PACKET sockets are used and you really need to be on a 4.x Kernel for better performance (update your NIC firmware etc). The problem with Etherate is that is uses Ethernet for the test data and control data and since Ethernet is loss-less is does some strange (read: lame) things like send some control or data frames three times to try and ensure the other side receives it when there is frame loss. Yeah 1G with large frames is do-able. 10G with large frames is also do-able with a fast CPU. Etherate is single threaded though so you?ll not get anywhere near 10G with 64 byte frames in Etherate. I have started writing a multi-threaded version which will use TCP sockets to exchange control data but still use AF_PACKET sockets for data plane traffic. 10G with 64 byte packets should be achievable (still writing it so not 100% confirmed yet) when using the PACKET_MMAP Tx/Rx rings in AF_PACKET which is what the new aptly named EtherateMT (multi-threaded) uses. One can then use multiple threads (each on a difference CPU core) and each with its own Tx or Rx ring buffer to push packets to the NIC and we can use RSS on the NIC and assign each NIC Tx queue to a separate core also for processing NET_TX and NET_RX IRQs. So it might take 12 or 16 cores but it should be do-able in EtherateMT still with the iperf like portability, whereas DPDK can do this on a single core (pkt-gen and moon-gen etc). However EtherateMT would ideally use only Kernel native features (no 3rd party libraries required or custom Kernel complication to enable an optional modules). Yeah Rust seems cool, it's on my "to-learn" list along with Go and seven thousand over things so writing in C for now. Cheers, James. From dougm at nist.gov Wed May 31 15:55:44 2017 From: dougm at nist.gov (Montgomery, Douglas (Fed)) Date: Wed, 31 May 2017 15:55:44 +0000 Subject: NCCoE Secure Inter-Domain Routing Project - request for industry input. Message-ID: The National Cybersecurity Center of Excellence (NCCoE) requests community input on a proposed project entitled: Secure Inter-Domain Routing, Part 1: Route-Hijacks. https://nccoe.nist.gov/projects/building-blocks/secure-inter-domain-routing The objective of the project is to examine and demonstrate the state of the RPKI and BGP Origin Validation technologies in realistic scenarios and to address identified concerns with their deployment and use (e.g., security, robustness, management / monitoring, multi-vendor inter-operation). This request is for industry input on the the proposed project plan. In particular we seek input from both network operators and enterprises on practical issues and barriers to adoption and suggestions for how these could be addressed in the project. Please see the link above for instructions for submitting comments and how you can join a community of interest for the project. *The intention is not to have the discussion here on the NANOG list.* Thanks dougm ? Doug Montgomery, Mgr Internet & Scalable Systems Research at NIST/ITL/ANTD From kevinkarch at vackinc.com Wed May 24 19:14:56 2017 From: kevinkarch at vackinc.com (Kevin L. Karch) Date: Wed, 24 May 2017 14:14:56 -0500 Subject: Lille, France In-Reply-To: References: Message-ID: <9E4AEFC7-5CD9-47A5-A379-D817AF8BEA56@vackinc.com> Rod, We have carriers in France. Can you provide end point addresses and phone numbers along with desired services? Thank you, On May 24, 2017 2:03:19 PM CDT, Rod Beck wrote: >Hi, > > >I am looking for insight into which carriers have metropolitan or last >mile networks in this city. Preferably connected to Paris. > > >Roderick Beck > >Director of Global Sales > >United Cable Company > >www.unitedcablecompany.com > >85 Kir?ly utca, 1077 Budapest > >rod.beck at unitedcablecompany.com > >36-30-859-5144 > > >[1467221477350_image005.png] Kevin L. Karch Network Specialist VACK Inc. Direct: 847-833-8810 FAX: 847-985-5550 Email: kevinkarch at vackinc.com Web: www.vackinc.com The Optical, Wireless and Data Center Specialists? From seth at kjtechnology.com Thu May 25 17:38:52 2017 From: seth at kjtechnology.com (Seth Bekritsky) Date: Thu, 25 May 2017 17:38:52 +0000 Subject: RR > L3 > RCN Message-ID: <15723811941CF54B988377FD31EF949FCB755410@KJEXCH01.kjtechnology.com> Is there someone at Level 3 that can assist us? I am not a Level 3 customer, but our ISP (Spectrum/RoadRunner) hands off to Level 3. When traversing from our CA office (RoadRunner) to our NY office (RCN), we see packet loss between these two Level 3 Devices. The packet loss is causing issues for us. Hop 6 4.68.111.101 0 msec 10 msec 10 msec Hop 7 4.69.138.227 110 msec 70 msec 70 msec Our ISP wont help. Level 3 Support wont help. Anyone at Level 3 on here I can speak with about getting this fixed? Thanks, Seth [cid:image003.png at 01D2D55C.4078C5D0] Seth Bekritsky vCIO Direct: 646.556.6506 Main: 646.556.6500 Fax: 212.202.5013 seth at kjtechnology.com 247 West 36th Street, 5th Floor, New York, NY 10018 Transparency * Candor * Curiosity * Purposeful From s at xopher.net Fri May 26 09:42:01 2017 From: s at xopher.net (Scott Christopher) Date: Fri, 26 May 2017 12:42:01 +0300 Subject: Lille, France In-Reply-To: References: Message-ID: <1495791721.2910018.989274112.6BC43DB2@webmail.messagingengine.com> Rod Beck wrote: > Altice is in the States and going public soon. They have been producing > superior financial results. Appears to know how to run these cable > networks better than the standard American management. They don't actually lay any cable though, nor do they build their own network. They have been acquiring other telecoms at a brisk pace for 15 years as the industry consolidates. (They are debt heavy, especially for a European company, and this upcoming IPO is a 20% sale to grab more capital, riding the wave of recent market bullishness for U.S. telecoms.) Not sure if any of us network engineers will like them in 2 - 4 years - but you're a business consultant seeing this from a different perspective. ;) -- Regards, S.C. From secadmin at netsecdesign.com Fri May 26 16:44:52 2017 From: secadmin at netsecdesign.com (Security Admin (NetSec)) Date: Fri, 26 May 2017 16:44:52 +0000 Subject: Leasing /22 blocks Message-ID: <55deed029ae041c29937a30dd4dbc554@exchange2013a.mmicmanhomenet.local> Recently had someone offer to lease some IPv4 address space from me. Have never done that before. I thought I would ask the group what a reasonable monthly rate for a /22 in the United States might be. Thanks in advance! Ed(ward) Ray From mjl at caida.org Sat May 27 20:31:21 2017 From: mjl at caida.org (Matthew Luckie) Date: Sun, 28 May 2017 08:31:21 +1200 Subject: BCP38/84 and DDoS ACLs Message-ID: <20170527203121.GA99242@spandex.luckie.org.nz> > This doesn't seem quite like it is BCP38 and more like this is > BCP84, but it only talks about use of ACLs in section 2.1 without > providing any examples. Given that it is also 13 years old I thought > there might be fresher information out there. section 2.1 is about permitting packets from specific address ranges. If you want to assess the dynamism or size of ACL required for a given AS, place the AS into this URL: https://spoofer.caida.org/prefixes.php?asn=1909 Matthew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From james at talkunafraid.co.uk Tue May 30 15:41:42 2017 From: james at talkunafraid.co.uk (James Harrison) Date: Tue, 30 May 2017 16:41:42 +0100 Subject: RFC2544 Testing Equipment In-Reply-To: References: Message-ID: <829bff2b-8054-104a-5042-7deb9aac2568@talkunafraid.co.uk> On 30/05/17 16:22, Nick Olsen wrote: > Looking to test up to 1Gb/s at various packet sizes, Measure Packet loss, > Jitter..etc. Primarily Copper, But if it had some form of optical port, I > wouldn't complain. Outputting a report that we can provide to the customer > would be useful, But isn't mandatory. Doesn't need anything fancy, Like > MPLS awareness, VLAN ID's..etc. Viavi, VeEX and EXFO all do products in this space; Viavi/JDSU and VeEX do quite low cost handhelds with a limited feature set (with reporting to USB sticks et al), EXFO's handheld is a bit chunkier but a bit more capable. I quite liked the VeEX MX100e+ and Viavi Smartclass Ethernet units, they'll both do RFC2544. Having said that, you probably want to be testing Y.1564 (which those boxes will both do) if you're doing turn-up testing. Viavi and EXFO all have their own "flavours" which make things cleverer/easier if you have a basic environment, but I've found myself using the standards-based versions most of the time really. Lots of options for reflectors - all the vendors have them in various guises, if you have a VPLS setup then probably you'd go from a 1U box next to your VPLS box through the VPLS pipe through to the endpoint. We ended up buying a pair of EXFO FTB-1s but we're doing RFC2544 etc at 10G, so a slightly different kettle of fish. James From pawel.slesicki at thomsonreuters.com Tue May 30 16:39:47 2017 From: pawel.slesicki at thomsonreuters.com (pawel.slesicki at thomsonreuters.com) Date: Tue, 30 May 2017 16:39:47 +0000 Subject: [SPF] RFC2544 Testing Equipment In-Reply-To: References: Message-ID: <11A3863E86F12D439049175C5EF6387511A9417C@C111WZZLMBX05.ERF.thomson.com> I could recommend Accedian Metro NID for that purpose. Copper + SFP. L2 and L3 testing. Pawel > -----Original Message----- > From: NANOG [mailto:nanog- > bounces+pawel.slesicki=thomsonreuters.com at nanog.org] On Behalf Of Nick > Olsen > Sent: Tuesday, 30 May 2017 17:23 > To: nanog at nanog.org > Subject: [SPF] RFC2544 Testing Equipment > > Greetings all, > > Looking for a good test set. Primary use will be testing L2 circuits > (It'll technically be VPLS, But the test set will just see L2). Being > able to test routed L3 would also be useful. Most of the sets I've seen > are two sided, A "reflector" at the remote side, And the test set in > hand run by the technician. > > Looking to test up to 1Gb/s at various packet sizes, Measure Packet > loss, Jitter..etc. Primarily Copper, But if it had some form of optical > port, I wouldn't complain. Outputting a report that we can provide to > the customer would be useful, But isn't mandatory. Doesn't need anything > fancy, Like MPLS awareness, VLAN ID's..etc. > > > Nick Olsen > Sr. Network Engineer > Florida High Speed Internet > (321) 205-1100 x106 > > > > > > From vaibhav.bajpai at tum.de Wed May 31 13:36:18 2017 From: vaibhav.bajpai at tum.de (Bajpai, Vaibhav) Date: Wed, 31 May 2017 13:36:18 +0000 Subject: youtube redirector mapping Message-ID: <42ef6ee5-beaa-4106-8156-405b8c277587@BADWLRZ-SWMBX10.ads.mwn.de> Hello, Does anybody know what is reported in the ?debug_info? portion of the YT redirector mapping webpage: http://redirector.c.youtube.com/report_mapping Is this documented somewhere? Thanks. -- Vaibhav -------------------------- Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Researcher TU Munich, Germany -------------------------- From rishimusingh at gmail.com Wed May 31 14:40:29 2017 From: rishimusingh at gmail.com (Rishi Singh) Date: Wed, 31 May 2017 10:40:29 -0400 Subject: Internet connectivity in Ghana Message-ID: Has anyone dealt with getting internet connectivity in Ghana? I've been doing a lot of research and saw some peering plans with Nigeria but nothing solid there yet. Currently a financial client of mine is paying quite a bit every quarter on satellite up link fees. Do any of the major carriers have any direct connectivity into Ghana? Thank you,