Re: google and amazon wierdness via HE right now

[Andree Toonk]

It appears HE and others accepted 'hijacked' routes from AS200759.
A quick initial investigation shows close to 2,000 prefixes were
affected including prefixes normally announced by networks such as
Facebook, Google, Amazon, Twitter, Apple, Akamai, Time Warner Cable and
more.

Also see more details on the bgpmon blog here:

http://www.bgpmon.net/large-hijack-affects-reachability-of-high-traffic-destinations/

Cheers
 Andree


My secret spy satellite informs me that Frank Bulk wrote On 2016-04-22,
10:31 AM:
> Being discussed on outages, too.
> 
> Our monitoring system saw access to www.amazon.com and www.cablelabs.com
> (over v6) down via HE ... amazon came back up for me via Zayo, but when
> www.cablelabs.com came back up, it was on HE.  So the same as you.
> 
> So I suspect HE had a hiccup.
> 
> Frank
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ken Chase
> Sent: Friday, April 22, 2016 12:22 PM
> To: NANOG 
> Subject: google and amazon wierdness via HE right now
> 
> 
> From toronto - something odd - mtr to google.com (google.com
> (172.217.3.142))
> 
>  5. v638.core1.tor1.he.net  
>  6. 100ge7-2.core1.nyc4.he.net  
>  7. 100ge11-1.core1.par2.he.net 
>  8. 10ge3-2.core1.zrh1.he.net   
>  9. ???
> 
> par is paris, zrh is zurich?
> 
> same base path for hitting my EC2 nodes... Cant imagine this is just
> affecting Toronto
> HE customers.
> 
> EC2 node is in 107.20/14 
> 
> /kc
> 
> 

Weekly Routing Table Report

[Routing Analysis Role Account]

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,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 23 Apr, 2016

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  592244
Prefixes after maximum aggregation (per Origin AS):  217479
Deaggregation factor:  2.72
Unique aggregates announced (without unneeded subnets):  289716
Total ASes present in the Internet Routing Table: 53506
Prefixes per ASN: 11.07
Origin-only ASes present in the Internet Routing Table:   36591
Origin ASes announcing only one prefix:   15706
Transit ASes present in the Internet Routing Table:6431
Transit-only ASes present in the Internet Routing Table:167
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  39
Max AS path prepend of ASN ( 40285)  34
Prefixes from unregistered ASNs in the Routing Table:  1000
Unregistered ASNs in the Routing Table: 361
Number of 32-bit ASNs allocated by the RIRs:  13578
Number of 32-bit ASNs visible in the Routing Table:   10484
Prefixes from 32-bit ASNs in the Routing Table:   41067
Number of bogon 32-bit ASNs visible in the Routing Table:18
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:387
Number of addresses announced to Internet:   2809388612
Equivalent to 167 /8s, 115 /16s and 222 /24s
Percentage of available address space announced:   75.9
Percentage of allocated address space announced:   75.9
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.1
Total number of prefixes smaller than registry allocations:  193331

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   151863
Total APNIC prefixes after maximum aggregation:   42146
APNIC Deaggregation factor:3.60
Prefixes being announced from the APNIC address blocks:  162423
Unique aggregates announced from the APNIC address blocks:66131
APNIC Region origin ASes present in the Internet Routing Table:5170
APNIC Prefixes per ASN:   31.42
APNIC Region origin ASes announcing only one prefix:   1185
APNIC Region transit ASes present in the Internet Routing Table:914
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 39
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2018
Number of APNIC addresses announced to Internet:  754038596
Equivalent to 44 /8s, 241 /16s and 183 /24s
Percentage of available APNIC address space announced: 88.1

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 131072-135580
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:180914
Total ARIN prefixes after maximum aggregation:89696
ARIN Deaggregation factor: 2.02
Prefixes being announced from the ARIN address blocks:   185979
Unique aggregates announced from the ARIN address blocks: 88323
ARIN Region origin ASes present in the Internet Routing Table:16385

Re: google and amazon wierdness via HE right now

[Ray Van Dolson]

On Fri, Apr 22, 2016 at 01:22:27PM -0400, Ken Chase wrote:
> and of course the second I post it all fixes itself. NANOG works! Thanks!
> 
> (was going on for about 10-15 min)
> 
> On Fri, Apr 22, 2016 at 01:21:47PM -0400, Ken Chase said:
>   >
>   >From toronto - something odd - mtr to google.com (google.com 
> (172.217.3.142))
>   >
>   > 5. v638.core1.tor1.he.net  
>   > 6. 100ge7-2.core1.nyc4.he.net  
>   > 7. 100ge11-1.core1.par2.he.net 
>   > 8. 10ge3-2.core1.zrh1.he.net   
>   > 9. ???
>   >
>   >par is paris, zrh is zurich?
>   >
>   >same base path for hitting my EC2 nodes... Cant imagine this is just 
> affecting Toronto
>   >HE customers.
>   >
>   >EC2 node is in 107.20/14 
>   >
>   >/kc
> 
> /kc

There's some chatter about Amazon issues on the Outages mailing list as
well.  Definitely seems like something blipped.

Ray

RE: google and amazon wierdness via HE right now

[Frank Bulk]

Being discussed on outages, too.

Our monitoring system saw access to www.amazon.com and www.cablelabs.com
(over v6) down via HE ... amazon came back up for me via Zayo, but when
www.cablelabs.com came back up, it was on HE.  So the same as you.

So I suspect HE had a hiccup.

Frank

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ken Chase
Sent: Friday, April 22, 2016 12:22 PM
To: NANOG 
Subject: google and amazon wierdness via HE right now


>From toronto - something odd - mtr to google.com (google.com
(172.217.3.142))

 5. v638.core1.tor1.he.net  
 6. 100ge7-2.core1.nyc4.he.net  
 7. 100ge11-1.core1.par2.he.net 
 8. 10ge3-2.core1.zrh1.he.net   
 9. ???

par is paris, zrh is zurich?

same base path for hitting my EC2 nodes... Cant imagine this is just
affecting Toronto
HE customers.

EC2 node is in 107.20/14 

/kc

Re: google and amazon wierdness via HE right now

[Ken Chase]

and of course the second I post it all fixes itself. NANOG works! Thanks!

(was going on for about 10-15 min)

On Fri, Apr 22, 2016 at 01:21:47PM -0400, Ken Chase said:
  >
  >From toronto - something odd - mtr to google.com (google.com (172.217.3.142))
  >
  > 5. v638.core1.tor1.he.net  
  > 6. 100ge7-2.core1.nyc4.he.net  
  > 7. 100ge11-1.core1.par2.he.net 
  > 8. 10ge3-2.core1.zrh1.he.net   
  > 9. ???
  >
  >par is paris, zrh is zurich?
  >
  >same base path for hitting my EC2 nodes... Cant imagine this is just 
affecting Toronto
  >HE customers.
  >
  >EC2 node is in 107.20/14 
  >
  >/kc

/kc

google and amazon wierdness via HE right now

[Ken Chase]

>From toronto - something odd - mtr to google.com (google.com (172.217.3.142))

 5. v638.core1.tor1.he.net  
 6. 100ge7-2.core1.nyc4.he.net  
 7. 100ge11-1.core1.par2.he.net 
 8. 10ge3-2.core1.zrh1.he.net   
 9. ???

par is paris, zrh is zurich?

same base path for hitting my EC2 nodes... Cant imagine this is just affecting 
Toronto
HE customers.

EC2 node is in 107.20/14 

/kc

Re: Major IX bandwidth sharing

[Dovid Bender]

I assume they are looking for some one that has a lot of upstream content.


On Thu, Apr 21, 2016 at 5:13 PM, Blake Dunlap  wrote:

> Not to mention the sharer's traffic will be impacted by said DoS...
>
> On Thu, Apr 21, 2016 at 1:43 PM, Max Tulyev  wrote:
> > They fight with DDoS, so it means every month 95% traffic will be full
> 100G.
> >
> > On 21.04.16 22:40, Pavel Odintsov wrote:
> >> If they could offer 95th percentile usage no more than commit they
> >> should pay only for it. But actually it depends on certain carrier and
> >> certain agreement conditions.
> >>
> >> On Thursday, 21 April 2016, Max Tulyev  >> > wrote:
> >>
> >> Hello,
> >>
> >> I'm sure in this case they will pay for 100G every month, not for
> >> 10-20G ;)
> >>
> >> On 21.04.16 20:25, Pavel Odintsov wrote:
> >> > Hello!
> >> >
> >> > If you want cheaper price just ask any TIER-1 provider for link
> >> with commit
> >> > 10ge and burst up to 100GE. It will be definitely cheaper and
> >> simpler than
> >> > your "magic" with IX cost reduction.
> >> >
> >> > On Thursday, 21 April 2016, Paras Jha  >> > wrote:
> >> >
> >> >> Interesting to see how the idea is gaining traction
> >> >>
> >> >> On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko
> >> 
> >> >> >
> >> >> wrote:
> >> >>
> >> >>> Hello Nanog-ers,
> >> >>>
> >> >>> We are looking for a company that has >=100G connectivity to
> >> major IX-es
> >> >>> (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing
> >> traffic,
> >> >>> willing to resell incoming fraction n*10G/1*100G IX-only IP
> transit.
> >> >>> Our company develops custom Anti-DDoS solution on PC platform (
> >> >>> http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we
> >> want to
> >> >>> collocate 1U scrubbing node.
> >> >>>
> >> >>> Please contact me off list for more details.
> >> >>>
> >> >>> Thank you.
> >> >>> --
> >> >>> Piotr Iwanejko
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Regards,
> >> >> Paras
> >> >>
> >> >> President
> >> >> ProTraf Solutions, LLC
> >> >> Enterprise DDoS Mitigation
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Sincerely yours, Pavel Odintsov
> >
>

Re: Major IX bandwidth sharing

[Pavel Odintsov]

Hello!

Nice addition. That's additional risks for company which want to share
capacity :)

On Fri, Apr 22, 2016 at 12:13 AM, Blake Dunlap  wrote:
> Not to mention the sharer's traffic will be impacted by said DoS...
>
> On Thu, Apr 21, 2016 at 1:43 PM, Max Tulyev  wrote:
>> They fight with DDoS, so it means every month 95% traffic will be full 100G.
>>
>> On 21.04.16 22:40, Pavel Odintsov wrote:
>>> If they could offer 95th percentile usage no more than commit they
>>> should pay only for it. But actually it depends on certain carrier and
>>> certain agreement conditions.
>>>
>>> On Thursday, 21 April 2016, Max Tulyev >> > wrote:
>>>
>>> Hello,
>>>
>>> I'm sure in this case they will pay for 100G every month, not for
>>> 10-20G ;)
>>>
>>> On 21.04.16 20:25, Pavel Odintsov wrote:
>>> > Hello!
>>> >
>>> > If you want cheaper price just ask any TIER-1 provider for link
>>> with commit
>>> > 10ge and burst up to 100GE. It will be definitely cheaper and
>>> simpler than
>>> > your "magic" with IX cost reduction.
>>> >
>>> > On Thursday, 21 April 2016, Paras Jha >> > wrote:
>>> >
>>> >> Interesting to see how the idea is gaining traction
>>> >>
>>> >> On Thu, Apr 21, 2016 at 8:52 AM, Piotr Iwanejko
>>> 
>>> >> >
>>> >> wrote:
>>> >>
>>> >>> Hello Nanog-ers,
>>> >>>
>>> >>> We are looking for a company that has >=100G connectivity to
>>> major IX-es
>>> >>> (AMS-IX, DE-CIX preferred) with traffic asymmetry/heavy outgoing
>>> traffic,
>>> >>> willing to resell incoming fraction n*10G/1*100G IX-only IP transit.
>>> >>> Our company develops custom Anti-DDoS solution on PC platform (
>>> >>> http://www.slideshare.net/atendesoftware/100-mpps-on-pc) and we
>>> want to
>>> >>> collocate 1U scrubbing node.
>>> >>>
>>> >>> Please contact me off list for more details.
>>> >>>
>>> >>> Thank you.
>>> >>> --
>>> >>> Piotr Iwanejko
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Regards,
>>> >> Paras
>>> >>
>>> >> President
>>> >> ProTraf Solutions, LLC
>>> >> Enterprise DDoS Mitigation
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Sincerely yours, Pavel Odintsov
>>



-- 
Sincerely yours, Pavel Odintsov

Re: Latency, TCP ACKs and upload needs

[Eygene Ryabinkin]

Wed, Apr 20, 2016 at 07:27:53AM -0700, Leo Bicknell wrote:
> 90%+ of the stacks deployed will be too small.  Modern Unix generally
> has "autotuning" TCP stacks, but I don't think Windows or OS X has
> those features yet

OS X since ~10.5 has autotuning, here are some hints from ESnet
  https://fasterdata.es.net/host-tuning/osx/
Personally never tried this on the sat-type RTT.  As explained,
scaling factor of 3 is a limiting one for high-performance transfers.
For sat links may limit the things too, since 64K * 2^3 / 0.9 ms RTT * 8 ~
4.5 Mbit/sec, but one's mileage may vary.  And, of course, packet loss
can turn down this BDP-derived speed drastically.
-- 
Eygene Ryabinkin, National Research Centre "Kurchatov Institute"

Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live.


signature.asc
Description: PGP signature