Taobao AS37963 (Alibaba) network abuse

[Tyler Applebaum via NANOG]

Has anyone ever had success in working with the abuse contact for Taobao? I 
e-mailed i...@cnnic.cn . We were seeing a flood of 
requests from 42.120.128.0/17. Went ahead and blocked that and a few others to 
prevent damage, but we're still seeing the ACL hits pile up.


Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender with a copy to complia...@ochin.org, delete 
this email and destroy all copies.

RE: Proving Gig Speed

[Tyler Applebaum]

I have this deployed for our customers, it works well. I have yet to hear any 
complaints of not being able to max out a connection.

https://github.com/adolfintel/speedtest

-Original Message-
From: NANOG  On Behalf Of Matt Erculiani
Sent: Monday, July 16, 2018 11:17 AM
To: Chris Gross 
Cc: North American Network Operators' Group 
Subject: Re: Proving Gig Speed

We use Iperf3 for customers that complain about throughput, it's relatively low 
overhead compared to the Ookla HTML5 client. Same scenario as you, we have the 
tech hook up their laptop to the customer's drop and perform testing. I suspect 
your antivirus may be attempting to perform real-time inspection on the http(s) 
traffic, which would crush the little laptop CPU for sure.

Message me off-list and I'll send you a private Iperf3 server IP to test with.

-Matt

On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross  
wrote:
> I'm curious what people here have found as a good standard for providing 
> solid speedtest results to customers. All our techs have Dell laptops of 
> various models, but we always hit 100% CPU when doing a Ookla speedtest for a 
> server we have on site. So then if you have a customer paying for 600M or 
> 1000M symmetric, they get mad and demand you prove it's full speed. At that 
> point we have to roll out different people with JDSU's to test and prove it's 
> functional where a Ookla result would substitute fine if we didn't have 
> crummy laptops possibly. Even though from what I can see on some google 
> results, we exceed the standards several providers call for.
>
> Most of these complaints come from the typical "power" internet user of 
> course that never actually uses more than 50M sustained paying for a 
> residential connection, so running a circuit test on each turn up is uncalled 
> for.
>
> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
> that can actually do symmetric gig, a rugged small inexpensive device we can 
> roll with instead to prove, or any other weird solution involving ritual 
> sacrifice that isn't too offensive to the eyes?
Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender with a copy to complia...@ochin.org, delete 
this email and destroy all copies.

RE: tracking TCP session hop by hop

[Tyler Applebaum]

Somebody needs to renew their Let's Encrypt SSL cert.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jennifer Rexford
Sent: Wednesday, November 29, 2017 8:08 AM
To: Yifeng Zhou 
Cc: nanog@nanog.org
Subject: Re: tracking TCP session hop by hop

https://paris-traceroute.net/ 

> On Nov 28, 2017, at 3:48 PM, Yifeng Zhou  wrote:
>
> Hi Experts,
>
> Is there any way that we can track TCP session hop by hop?
>
> Say we have 10 ECMP between A and Z point, what's the easiest way to
> track specific session is using which path? How we can check between
> servers(Linux/Unix) and between Routers(Cisco/Juniper etc)?
>
> Thanks
>
> -Yifeng

Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender with a copy to complia...@ochin.org, delete 
this email and destroy all copies.

T-Mobile Looking Glass

[Tyler Applebaum]

Hey all, just wondering if AS21928 has a looking glass.


-  Tyler

Need contact info for AS1798 - State of Oregon

[Tyler Applebaum]

If you could contact me off-list, I'd appreciate it.


-  Tyler

RE: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out.

[Tyler Applebaum]

Maybe they didn't pay their bill! (kidding...)

http://money.cnn.com/2016/05/02/investing/puerto-rico-default-may-1/

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Javier J
Sent: Wednesday, May 4, 2016 1:37 PM
To: nanog@nanog.org
Subject: ATT Mobile Outage San Juan, PR 8+ hours, 1 Million out.

Anyone know what is going on, nothing in the English speaking media (not
surprised)

but reports are that a million + people on ATT in the metro area are without 
service for 8+ hours now.


Only reports I have seen are on local media and social media.


Any information is appreciated.   If there is a better mailing list please
let me know.

- Javier
Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender with a copy to complia...@ochin.org, delete 
this email and destroy all copies.

RE: Microwave link capacity

[Tyler Applebaum]

DragonWave is one of the bigger players in the game offering 1gbps+ throughput.

http://www.dragonwaveinc.com/products/packet-microwave

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jean-Francois Mezei
Sent: Monday, April 4, 2016 10:29 AM
To: Nanog@nanog.org
Subject: Microwave link capacity


In a context of providing rural communities with modern broadband.

Reading some tells me that Microwave links can be raised to 1gbps. How common 
is that ?

I assume that cell phone towers have modern microwave links (when not directly 
on fibre). What sort of capacity would typically be provided ?

And in the case of a remote village/town served by microwave originally 
designed to handle just phone calls, how difficult/expensive is it to upgrade 
to 1gbps or higher capacity ? Just a change of radio ? or radio and antenna, 
keeping only the tower ?

(keeping spectrum acquisition out of discussion as that is a whole other ball 
game).
Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender with a copy to complia...@ochin.org, delete 
this email and destroy all copies.

RE: IP's with jitter/packet loss and very far away

[Tyler Applebaum]

Anything on Integra's network.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Dovid Bender
Sent: Friday, September 18, 2015 8:43 AM
To: NANOG 
Subject: IP's with jitter/packet loss and very far away

Hi,

I am working on a presentation and looking to create samples of what a trace 
should not look like? Anyone have IP's that I can trace from the US or UK that 
will show
1) jitter
2) packet loss
3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms

TIA.

Dovid
Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender, delete this email and destroy all copies.

RE: IP's with jitter/packet loss and very far away

[Tyler Applebaum]

I was just kidding anyway. This is a 10gig Voxel IP: 80.249.209.187

No loss or anything, but it is in the EU, ~ 155ms latency for me on US West 
coast.

From: Dovid Bender [mailto:do...@telecurve.com]
Sent: Friday, September 18, 2015 8:54 AM
To: Tyler Applebaum <appleba...@ochin.org>
Cc: NANOG <nanog@nanog.org>
Subject: Re: IP's with jitter/packet loss and very far away

Any specific IP? I don't want this to turn into an ISP bashing session..

On Fri, Sep 18, 2015 at 11:44 AM, Tyler Applebaum 
<appleba...@ochin.org<mailto:appleba...@ochin.org>> wrote:
Anything on Integra's network.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org<mailto:nanog-boun...@nanog.org>] On 
Behalf Of Dovid Bender
Sent: Friday, September 18, 2015 8:43 AM
To: NANOG <nanog@nanog.org<mailto:nanog@nanog.org>>
Subject: IP's with jitter/packet loss and very far away

Hi,

I am working on a presentation and looking to create samples of what a trace 
should not look like? Anyone have IP's that I can trace from the US or UK that 
will show
1) jitter
2) packet loss
3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms

TIA.

Dovid
Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender, delete this email and destroy all copies.

Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender, delete this email and destroy all copies.

RE: Dual stack IPv6 for IPv4 depletion

[Tyler Applebaum]

Do people actually use VLANs for security? It's nice to implement them for 
organizational purposes and to prevent broadcast propagation.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Naslund, Steve
Sent: Thursday, July 09, 2015 12:24 PM
To: nanog@nanog.org
Subject: RE: Dual stack IPv6 for IPv4 depletion

Seems to me that the problem might be thinking that the allocation toward the 
customer is a static thing.  I think it is limiting to think that was going 
forward.  Our industry created DHCP so we didn't have to deal with statically 
configured users who did not want to deal with IP addressing.  Seems to me that 
a natural progression is to hand a network block to the CPE (DHCP-PD) and let 
it deal with it.  No reason a CPE device cannot be created that will request 
more addresses when it needs them and dynamically receive a larger assignment.

When you think about it long term our network infrastructure is pretty archaic 
in that we have to do paperwork to get an block assignment from the regional 
numbering authority and then manually chop that up.  I would expect that model 
to die over time and become more of a hierarchy whereby addresses are 
dynamically assigned top to bottom.  Seems like the numbering authority could 
be a lot more effective if a network could tell them about its utilization and 
have additional addresses assignments happen automatically.  The converse would 
be true as well, a network could reconfigure to free underutilized blocks on 
its own.  If a customer CPE needs more addresses it will request them.  If you 
add a pop to your network it should automatically get an allocation from an 
upstream device.

The only reason why anyone cares what their address is results from the fact 
that our name to address mapping via DNS is so slow to update.  The end user 
does not care what addresses they get as long as everyone can reach what they 
need to.  Your customers would not care about renumbering pain if there wasn't 
any.  Today they could care less if it is V4 or V6 as long as everyone can see 
each other.  My dad gets V6 on his cell phone and he can't even spell IP.

Another inefficient legacy is the assignment of address space on a service 
provider basis when geographic assignment would allow for better summarization. 
 If that happened you could create a better model where less routers need to 
carry a full table view of the Internet.  As long as I know how to get around 
my area and to regional routers that can reach out globally, that is all we 
need.  Now you would not have the limitation that a wide variety of routers 
need to carry every route and the /64 routing limitation goes away.  Today our 
routing is very much all or nothing.  Either use defaults or get a whole table 
via are probably the two most common options (yeah, I know there are others but 
those are the main two).

The ideas on the reasons for building VLANs is pretty out of date too.  It 
drives me nuts when I see the usual books giving you the usual example that 
accounting and their server are on one VLAN and engineering and their server 
are on another VLAN and that this is for performance and security reasons.  
Some of the biggest vendors in the business use examples like this (yes, Cisco, 
I'm looking at you) and it just does not work that way in the real world.  Who 
gets to what server is most often decided by the server (AD membership or group 
policy of some type).  If the accounting and engineering department are both 
going to a cloud service VLAN separation is pretty moot.  In a world where my 
refrigerator wants to talk to the power company and send a shopping list to my 
car, VLAN based security is not really a solution.  In the Internet of things 
we keep hearing about, everything is talking to everything. Security is highly 
dependent in that world on a device defending itself and not relying on a VLAN 
boundary.  From what I am seeing out there today, there are usually far too 
many VLANs and too much layer three going on in most large networks.

In the future it would seem that systems would create their own little networks 
ad-hoc as needed for the best efficiency.  I know this is not all out there 
today but planning address allocation 10 years down the road might be an 
exercise in futility.  I would suggest plan for today and build it so you can 
easily change it when your prediction invariably prove wrong or short-sighted.

Steven Naslund
Chicago IL



 On Jul 9, 2015, at 09:16 , Matthew Huff mh...@ox.com wrote:

 When I see a car that needs a /56 subnet then I’ll take your use case 
 seriously. Otherwise, it’s just plain laughable. Yes, I could theorize a use 
 case for this, but then I could theorize that someday everyone will get to 
 work using jetpacks.

When I see a reason not to give out /48s, I might start taking your argument 
seriously.

 We have prefix delegation already via DHCP-PD, but some in the IPv6 world 
 don’t even want to 

RE: ATT/Telia issue

[Tyler Applebaum]

Still seeing this as of 7:40AM PST. Looks isolated to ATT and Telia in Seattle.

HOST: PC-002Loss%  Snt  LastAvg Best Wrst  StDev
  1.|-- 172.31.255.1   0.0%   10 00.803
0.9
  2.|-- 10.98.0.4  0.0%   10 11.514
1.1
  3.|-- 67.51.253.17   0.0%   10 62.826
1.2
  4.|-- 67.51.253.10.0%   10 21.412
0.5
  5.|-- 67.51.253.30.0%   10 21.312
0.5
  6.|-- v202.core1.pdx1.he.net 0.0%   10 12.014
1.2
  7.|-- 10ge12-4.core1.sea1.he.net 0.0%   10 9   10.99   13
1.0
  8.|-- sea-b1-link.telia.net 50.0%   1042   42.0   42   42
0.0
  9.|-- att-ic-153030-sea-b1.c.telia.net  50.0%   1046   44.8   43   46
1.3
 10.|-- cr84.st0wa.ip.att.net 40.0%   1071   73.8   71   76
1.8
 11.|-- cr2.st6wa.ip.att.net  40.0%   1074   73.7   72   75
1.2
 12.|-- 12.122.158.14670.0%   1074   73.7   73   74
0.6
 13.|-- 12.122.158.15750.0%   1071   71.0   71   71
0.0
 14.|-- 12.248.207.6  20.0%   1071   71.0   71   71
0.0
 15.|-- ancr-5-1-12-12.attalascom.net 30.0%   1071   71.0   71   71
0.0
 16.|-- 66-2-12-12.attalascom.net 30.0%   1085   85.3   85   86
0.5
 17.|-- KCHC-42-7-12-12.attalascom.net30.0%   1095   95.6   95   96
0.5

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tyler Applebaum
Sent: Tuesday, May 19, 2015 4:20 PM
To: nanog@nanog.org
Subject: ATT/Telia issue

Seeing this on AS7018 to AS1299. Anyone out there at either provider know 
anything about this?

HOST: PC-002  Loss%  Snt  LastAvg Best Wrst  StDev
  1.|-- 172.31.255.1 0.0%   10 10.7030.9
  2.|-- 10.98.0.30.0%   10 11.0110.0
  3.|-- 67.51.253.17 0.0%   10 22.5240.7
  4.|-- 67.51.253.3  0.0%   10 11.2120.4
  5.|-- v202.core1.pdx1.he.net   0.0%   10 7   10.57   121.9
  6.|-- 10ge12-4.core1.sea1.he.net   0.0%   10 55.0550.0
  7.|-- sea-b1-link.telia.net0.0%   10 55.85   122.2
  8.|-- den-b1-link.telia.net0.0%   10   108  107.3  106  1080.7
  9.|-- sjo-b21-link.telia.net  20.0%   10   137  134.9  134  1371.0
10.|-- 192.205.33.45   40.0%   10   136  136.2  135  1381.2
11.|-- cr1.sffca.ip.att.net10.0%   10   141  141.9  139  1451.9
12.|-- 12.122.2.77 20.0%   10   140  140.1  137  1422.0
13.|-- 12.122.160.149  10.0%   10   138  141.1  137  1648.6
14.|-- 12.117.131.214  30.0%   10   139  141.0  139  1451.9
15.|-- 199.103.47.230.0%   1051  128.0   51  142   34.0

HOST: PC-002  Loss%  Snt  LastAvg 
Best Wrst  StDev
  1.|-- 172.31.255.1 0.0%   20 11.1 
   030.6
  2.|-- 10.98.0.40.0%   20 11.3 
   140.7
  3.|-- 67.51.253.17 0.0%   20 34.9 
   2   48   10.2
  4.|-- 67.51.253.1  0.0%   20 21.1 
   120.3
  5.|-- 67.51.253.11 0.0%   20 11.4 
   120.5
  6.|-- v202.core1.pdx1.he.net   0.0%   20 69.1 
   1   123.2
  7.|-- 10ge12-4.core1.sea1.he.net   0.0%   20 56.5 
   5   111.7
  8.|-- sea-b1-link.telia.net0.0%   20 55.1 
   560.3
  9.|-- att-ic-153030-sea-b1.c.telia.net 0.0%   20 97.7 
   691.2
10.|-- cr83.st0wa.ip.att.net5.0%   20   118  119.7  
117  1231.5
11.|-- cr2.ptdor.ip.att.net 0.0%   20   119  120.1  
118  1221.4
12.|-- cr2.sffca.ip.att.net 0.0%   20   120  119.2  
117  1211.4
13.|-- cr2.sc1ca.ip.att.net 0.0%   20   119  121.1  
118  1496.6
14.|-- 12.122.151.129   0.0%   20   118  119.8  
117  1221.5
15.|-- ???100.0%   20 00.0  
  000.0
16.|-- 71.157.120.39   75.0%   20   119  118.6  
118  1190.5
17.|-- 108-248-29-59.lightspeed.renonv.sbcglobal.net5.0%   20   139  137.1  
135  1462.5
18.|-- 108-241-228-42.lightspeed.renonv.sbcglobal.net   5.0%   20   143  139.2  
135  1524.9
Attention: Information contained in this message

ATT/Telia issue

[Tyler Applebaum]

Seeing this on AS7018 to AS1299. Anyone out there at either provider know 
anything about this?

HOST: PC-002  Loss%  Snt  LastAvg Best Wrst  StDev
  1.|-- 172.31.255.1 0.0%   10 10.7030.9
  2.|-- 10.98.0.30.0%   10 11.0110.0
  3.|-- 67.51.253.17 0.0%   10 22.5240.7
  4.|-- 67.51.253.3  0.0%   10 11.2120.4
  5.|-- v202.core1.pdx1.he.net   0.0%   10 7   10.57   121.9
  6.|-- 10ge12-4.core1.sea1.he.net   0.0%   10 55.0550.0
  7.|-- sea-b1-link.telia.net0.0%   10 55.85   122.2
  8.|-- den-b1-link.telia.net0.0%   10   108  107.3  106  1080.7
  9.|-- sjo-b21-link.telia.net  20.0%   10   137  134.9  134  1371.0
10.|-- 192.205.33.45   40.0%   10   136  136.2  135  1381.2
11.|-- cr1.sffca.ip.att.net10.0%   10   141  141.9  139  1451.9
12.|-- 12.122.2.77 20.0%   10   140  140.1  137  1422.0
13.|-- 12.122.160.149  10.0%   10   138  141.1  137  1648.6
14.|-- 12.117.131.214  30.0%   10   139  141.0  139  1451.9
15.|-- 199.103.47.230.0%   1051  128.0   51  142   34.0

HOST: PC-002  Loss%  Snt  LastAvg 
Best Wrst  StDev
  1.|-- 172.31.255.1 0.0%   20 11.1 
   030.6
  2.|-- 10.98.0.40.0%   20 11.3 
   140.7
  3.|-- 67.51.253.17 0.0%   20 34.9 
   2   48   10.2
  4.|-- 67.51.253.1  0.0%   20 21.1 
   120.3
  5.|-- 67.51.253.11 0.0%   20 11.4 
   120.5
  6.|-- v202.core1.pdx1.he.net   0.0%   20 69.1 
   1   123.2
  7.|-- 10ge12-4.core1.sea1.he.net   0.0%   20 56.5 
   5   111.7
  8.|-- sea-b1-link.telia.net0.0%   20 55.1 
   560.3
  9.|-- att-ic-153030-sea-b1.c.telia.net 0.0%   20 97.7 
   691.2
10.|-- cr83.st0wa.ip.att.net5.0%   20   118  119.7  
117  1231.5
11.|-- cr2.ptdor.ip.att.net 0.0%   20   119  120.1  
118  1221.4
12.|-- cr2.sffca.ip.att.net 0.0%   20   120  119.2  
117  1211.4
13.|-- cr2.sc1ca.ip.att.net 0.0%   20   119  121.1  
118  1496.6
14.|-- 12.122.151.129   0.0%   20   118  119.8  
117  1221.5
15.|-- ???100.0%   20 00.0  
  000.0
16.|-- 71.157.120.39   75.0%   20   119  118.6  
118  1190.5
17.|-- 108-248-29-59.lightspeed.renonv.sbcglobal.net5.0%   20   139  137.1  
135  1462.5
18.|-- 108-241-228-42.lightspeed.renonv.sbcglobal.net   5.0%   20   143  139.2  
135  1524.9
Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender, delete this email and destroy all copies.