Re: Hijacking machine: ASAS201640 / AS200002

2014-10-31 Thread Rob Mosher 
While it's not a thorough list of all announcements, here are nightly 
snapshots courtesy of http://bgp.he.net


AS201640: http://pastebin.com/nvuVbnpn
AS22: http://pastebin.com/1JZnWadD

--
Rob Mosher
Senior Network and Software Engineer
Hurricane Electric / AS6939

On 10/31/2014 11:57 PM, Ronald F. Guilmette wrote:

In message <54542174.30...@ghostnet.de>,
Armin Kneip  wrote:


http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=201640
http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=22

or

http://www.cidr-report.org/cgi-bin/as-report?as=AS201640&view=2.0
http://www.cidr-report.org/cgi-bin/as-report?as=AS22&view=2.0


Thank you.

Unfortunately, the former pair of links only seems to provide data
going back about one week, while the latter pair of links only seems
to provide current data as of today.

I am hoping to be able to find a list of all route announcements
made by ASAS201640 going all the way back to its creation, which
appears to possibly have occured on or about 2014-08-27.


Regards,
rfg

Route Issue Level3 to GTT - Packet loss & Latency

2014-10-31 Thread Dean Perrine 
Hit a strange route issue earlier transiting Level3 network to GTT - Packet
Loss & High Latency - caused some interruptions in critical traffic flow.

Between Level3 hop 4.68.63.158 and GTT 144.136.105.226 - had a 20ms latency
increase and packet loss. After about 1+ hours the route had shifted and
latency dropped back down. Does anyone have details on this by any chance?

Details below (If readable):

*GOOD*
*BAD*
*route*
*latency*
*route*
*latency*
xe-11-1-2.bar2.houston1.level3.net [4.59.126.105]
53
xe-11-1-2.bar2.Houston1.Level3.net (4.59.126.105)
57.3
ae-2-3514.edge2.atlanta4.level3.net [4.69.150.165]
65
ae-2-3514.edge2.Atlanta4.Level3.net (4.69.63.158)
70.3
gtt-level3.atlanta4.level3.net [4.68.63.158]
*65*
gtt-level3.Atlanta4.level3.net (4.68.63.158)
*70.3*
xe-0-3-1.dal33.ip4.gtt.net [141.136.107.69]
*70*
xe-11-3-3.dal33.ip4.gtt.net (144.136.105.226)
*98.3*
gtt-gw.ip4.gtt.net [173.241.130.138]
70
gtt-gw.ip4.gtt.net (173.241.130.138)
97.1
66.171.224.26
70
66.171.224.34
97.8

Thanks,
Dean

Re: Is it unusual to remove defunct rr objects?

2014-10-31 Thread Randy Bush 
> So who do we ask about making IRRs expire defunct objects 

you might start with a rigorous definition of defunct

randy

Re: Hijacking machine: ASAS201640 / AS200002

2014-10-31 Thread Ronald F. Guilmette 

In message <54542174.30...@ghostnet.de>, 
Armin Kneip  wrote:

>http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=201640
>http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=22
>
>or
>
>http://www.cidr-report.org/cgi-bin/as-report?as=AS201640&view=2.0
>http://www.cidr-report.org/cgi-bin/as-report?as=AS22&view=2.0


Thank you.

Unfortunately, the former pair of links only seems to provide data
going back about one week, while the latter pair of links only seems
to provide current data as of today.

I am hoping to be able to find a list of all route announcements
made by ASAS201640 going all the way back to its creation, which
appears to possibly have occured on or about 2014-08-27.


Regards,
rfg

Re: Hijacking machine: ASAS201640 / AS200002

2014-10-31 Thread Jima 

On 2014-10-31 17:20, Ronald F. Guilmette wrote:

P.S.  If anybody is able to look up _all_ of the route announcements
that have been made by AS201640 over the past few months, I for one would
definitely like to see those.


 Hello again, Ronald.

 I don't know for certain that it's all-inclusive, but I would look at 
https://stat.ripe.net/widget/routing-history#w.resource=AS201640 .


 Unlike last time, I don't have any contacts at the relevant ISPs.  Shame.

 Jima

Hijacking machine: ASAS201640 / AS200002

2014-10-31 Thread Ronald F. Guilmette 

I don't routinely follow this list, so I'm not sure how much of this is
common knowledge already, but...

  http://blogs.cisco.com/security/talos/help-my-ip-address-has-been-hijacked/

Current route announcements for AS201640:

36.0.56.0/21  probable hijack - China
41.92.206.0/23probable hijack - Cameroon
41.198.80.0/20probable hijack - South Africa
41.198.224.0/20   probable hijack - South Africa
61.242.128.0/19   probable hijack - China
119.227.224.0/19  probable hijack - India
123.29.96.0/19probable hijack - Vietnam
177.22.117.0/24   probable hijack - Brazil
187.189.158.0/23  probable hijack - Mexico
202.39.112.0/20   probable hijack - Taiwan Network Information Center
210.57.0.0/19 probable hijack - Telstra/Japan

It would appear that AS201640 may possibly exist at the present time
only for the purpose of providing illicitly obtained IP space for
spammers, including but not limited to the ""Mike Prescott" mentioned
in the Cisco blog entry cited above.

The spammer, "Mike Prescott"... not his real last name... has also been
spotted spewing from IP space routed by AS22, which is AS201640's
only connection to the rest of the world.

Coincidence?  You be the judge.


Regards,
rfg


P.S.  If anybody is able to look up _all_ of the route announcements
that have been made by AS201640 over the past few months, I for one would
definitely like to see those.  Please e-mail them to me off list.  I
already know that "Mike Prescott" has been spewing from at least one
of the above current announcements (202.39.112.0/20) and probably all
of the others too.  But there are additional route announcements that
have already been withdrawn, and I'd like to check those for "Mike
Prescott" footprints also.

P.P.S.  To the real "Mike P."... on the off chance that he might see
this... You can run, but you don't hide very well.  You should have
gotten out of the game in 1998 when you had the chance.  Maybe the
Powers That Be will lock you up this time.

BGP Update Report

2014-10-31 Thread cidr-report 
BGP Update Report
Interval: 23-Oct-14 -to- 30-Oct-14 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS23752  201970  4.6%1655.5 -- NPTELECOM-NP-AS Nepal 
Telecommunications Corporation, Internet Services,NP
 2 - AS14287  177579  4.1%   25368.4 -- TRIAD-TELECOM - Triad Telecom, 
Inc.,US
 3 - AS9829   112487  2.6%  67.6 -- BSNL-NIB National Internet 
Backbone,IN
 4 - AS56116  109395  2.5% 935.0 -- HWXD Beijing Hongweixinda  
Sci-Tech Development Co. Ltd.,CN
 5 - AS12696   79634  1.8%6125.7 -- AXA-TECH GIE AXA Technology 
Services France,FR
 6 - AS45786   77866  1.8%1112.4 -- HTSNET-AS-ID HTSNET - ISP,ID
 7 - AS45899   68836  1.6% 110.8 -- VNPT-AS-VN VNPT Corp,VN
 8 - AS538460794  1.4% 364.0 -- EMIRATES-INTERNET Emirates 
Telecommunications Corporation,AE
 9 - AS13682   45436  1.0%7572.7 -- TELEFONICA MOVILES GUATEMALA 
S.A.,GT
10 - AS51964   34162  0.8% 146.0 -- 
ORANGE-BUSINESS-SERVICES-IPSN-ASN Equant Inc.,FR
11 - AS28573   28709  0.7%  18.2 -- NET Serviços de Comunicação 
S.A.,BR
12 - AS764328624  0.7%  83.0 -- VNPT-AS-VN Vietnam Posts and 
Telecommunications (VNPT),VN
13 - AS331327721  0.6%   13860.5 -- INET-AS BT Italia S.p.A.,IT
14 - AS48159   24149  0.6%  88.5 -- TIC-AS Telecommunication 
Infrastructure Company,IR
15 - AS478723487  0.5%  81.6 -- ASN-CBN Internet Service 
Provider,ID
16 - AS840223066  0.5%  75.9 -- CORBINA-AS OJSC "Vimpelcom",RU
17 - AS23342   22188  0.5% 568.9 -- UNITEDLAYER - Unitedlayer, 
Inc.,US
18 - AS60725   20431  0.5%5107.8 -- O3B-AS O3b Limited,JE
19 - AS25003   19969  0.5% 587.3 -- INTERNET_BINAT Internet Binat 
Ltd,IL
20 - AS958318692  0.4%  16.3 -- SIFY-AS-IN Sify Limited,IN


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS14287  177579  4.1%   25368.4 -- TRIAD-TELECOM - Triad Telecom, 
Inc.,US
 2 - AS61039   16125  0.4%   16125.0 -- ZMZ OAO ZMZ,RU
 3 - AS331327721  0.6%   13860.5 -- INET-AS BT Italia S.p.A.,IT
 4 - AS18135   10293  0.2%   10293.0 -- BTV BTV Cable television,JP
 5 - AS13682   45436  1.0%7572.7 -- TELEFONICA MOVILES GUATEMALA 
S.A.,GT
 6 - AS12696   79634  1.8%6125.7 -- AXA-TECH GIE AXA Technology 
Services France,FR
 7 - AS662910751  0.2%5375.5 -- NOAA-AS - NOAA,US
 8 - AS25983   15641  0.4%5213.7 -- SHAW-ENVISION - Enmax Envision 
Inc.,CA
 9 - AS60725   20431  0.5%5107.8 -- O3B-AS O3b Limited,JE
10 - AS621744929  0.1%4929.0 -- INTERPAN-AS INTERPAN LTD.,BG
11 - AS566362878  0.1%2878.0 -- ASVEDARU VEDA Ltd.,RU
12 - AS577342271  0.1%2271.0 -- FRANCEIX France IX Services 
SASU,FR
13 - AS350934371  0.1%2185.5 -- RO-HTPASSPORT High Tech 
Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO
14 - AS527293685  0.1%1842.5 -- BrNet Informatica,BR
15 - AS572011833  0.0%1833.0 -- EDF-AS Estonian Defence 
Forces,EE
16 - AS309441716  0.0%1716.0 -- DKD-AS Bendra Lietuvos, JAV ir 
Rusijos imone uzdaroji akcine bendrove "DKD",LT
17 - AS340231659  0.0%1659.0 -- CITYLINE-AS PE Shattah Zia 
G.Naman,UA
18 - AS31659  0.0%2975.0 -- MIT-GATEWAYS - Massachusetts 
Institute of Technology,US
19 - AS23752  201970  4.6%1655.5 -- NPTELECOM-NP-AS Nepal 
Telecommunications Corporation, Internet Services,NP
20 - AS31647  0.0%5517.0 -- MIT-GATEWAYS - Massachusetts 
Institute of Technology,US


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 202.70.64.0/21   101161  2.2%   AS23752 -- NPTELECOM-NP-AS Nepal 
Telecommunications Corporation, Internet Services,NP
 2 - 202.70.88.0/2198790  2.1%   AS23752 -- NPTELECOM-NP-AS Nepal 
Telecommunications Corporation, Internet Services,NP
 3 - 202.61.101.0/24   77294  1.7%   AS45786 -- HTSNET-AS-ID HTSNET - ISP,ID
 AS65001 -- -Private Use AS-,ZZ
 4 - 208.78.116.0/22   35518  0.8%   AS14287 -- TRIAD-TELECOM - Triad Telecom, 
Inc.,US
 5 - 208.88.232.0/22   35514  0.8%   AS14287 -- TRIAD-TELECOM - Triad Telecom, 
Inc.,US
 6 - 208.73.244.0/22   35514  0.8%   AS14287 -- TRIAD-TELECOM - Triad Telecom, 
Inc.,US
 7 - 216.162.0.0/2035514  0.8%   AS14287 -- TRIAD-TELECOM - Triad Telecom, 
Inc.,US
 8 - 208.70.20.0/2235508  0.8%   AS14287 -- TRIAD-TELECOM - Triad Telecom, 
Inc.,US
 9 - 64.29.130.0/2422002  0.5%   AS23342 -- UNITEDLAYER - Unitedlayer, 
Inc.,US
10 - 192.115.44.0/22   19905  0.4%   AS25003 -- INTERNET_BINAT Internet Binat 
Ltd,IL
11 - 91.235.169.0/24   16125

The Cidr Report

2014-10-31 Thread cidr-report 
This report has been generated at Fri Oct 31 21:14:13 2014 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org/2.0 for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
24-10-14521614  289252
25-10-14522066  289302
26-10-14522320  289236
27-10-14521998  289212
28-10-14522002  289264
29-10-14522115  289231
30-10-14525540  288920
31-10-14525536  289245


AS Summary
 48695  Number of ASes in routing system
 19584  Number of ASes announcing only one prefix
  3035  Largest number of prefixes announced by an AS
AS10620: Telmex Colombia S.A.,CO
  120193024  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 31Oct14 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 527072   289246   23782645.1%   All ASes

AS13184 2928   21 290799.3%   HANSENET Telefonica Germany
   GmbH & Co.OHG,DE
AS6389  2894  108 278696.3%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.,US
AS17974 2824   83 274197.1%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia,ID
AS22773 2847  163 268494.3%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.,US
AS28573 2572  115 245795.5%   NET Serviços de Comunicação
   S.A.,BR
AS4766  2951 1334 161754.8%   KIXS-AS-KR Korea Telecom,KR
AS6147  1780  166 161490.7%   Telefonica del Peru S.A.A.,PE
AS7303  1769  290 147983.6%   Telecom Argentina S.A.,AR
AS9808  1475   53 142296.4%   CMNET-GD Guangdong Mobile
   Communication Co.Ltd.,CN
AS8402  1371   25 134698.2%   CORBINA-AS OJSC "Vimpelcom",RU
AS4755  1920  632 128867.1%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP,IN
AS7545  2444 1157 128752.7%   TPG-INTERNET-AP TPG Telecom
   Limited,AU
AS20115 1816  557 125969.3%   CHARTER-NET-HKY-NC - Charter
   Communications,US
AS4323  1643  410 123375.0%   TWTC - tw telecom holdings,
   inc.,US
AS10620 3035 1813 122240.3%   Telmex Colombia S.A.,CO
AS9498  1314  111 120391.6%   BBIL-AP BHARTI Airtel Ltd.,IN
AS18566 2044  869 117557.5%   MEGAPATH5-US - MegaPath
   Corporation,US
AS7552  1210   51 115995.8%   VIETEL-AS-AP Viettel
   Corporation,VN
AS6983  1542  400 114274.1%   ITCDELTA - Earthlink, Inc.,US
AS7029  2137 1112 102548.0%   WINDSTREAM - Windstream
   Communications Inc,US
AS22561 1321  298 102377.4%   AS22561 - CenturyTel Internet
   Holdings, Inc.,US
AS4812  1523  507 101666.7%   CHINANET-SH-AP China Telecom
   (Group),CN
AS7738   999   83  91691.7%   Telemar Norte Leste S.A.,BR
AS34984 1840  927  91349.6%   TELLCOM-AS TELLCOM ILETISIM
   HIZMETLERI A.S.,TR
AS56040  892   30  86296.6%   CMNET-GUANGDONG-AP China
   Mobile communications
   corporation,CN
AS38285  978  131  84786.6%   M2TELECOMMUNICATIONS-AU M2
   Telecommunications Group
   Ltd,AU
AS4788  1086  247  83977.3%   TMNET-AS-AP TM Net, Internet
   Service Provider,MY
AS24560 1179  349  83070.4%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services,IN
AS18881  860

Re: Comcast throttling?

2014-10-31 Thread Valdis . Kletnieks 
On Fri, 31 Oct 2014 15:41:43 -0400, Mark Price said:
> Similar to another thread on the list today, I'm troubleshooting a problem
> for a customer on Comcast business fiber.
>
> Downloading a file from one of our web servers is very slow (~15KByte/sec).

I recently hit a similar problem, tracked it down to a brain-dead firewall
owner that had configured the gear to change the TCP WSCALE header option to
NOPs.  Hilarity ensues when the sender thinks the window is 389 bytes rather
than 389<<10 bytes.

Yes, you *would* think that sort of tomfoolery went out with the last century,
but it's amazing how long people will re-invent bad ideas


pgprfQLuAILEN.pgp
Description: PGP signature

Re: Comcast throttling?

2014-10-31 Thread Justin M. Streiner 

On Fri, 31 Oct 2014, Mark Price wrote:


Similar to another thread on the list today, I'm troubleshooting a problem
for a customer on Comcast business fiber.

Downloading a file from one of our web servers is very slow (~15KByte/sec).
mtr looks clean in both directions.  I added an IP address on the same
server from a different class C on our network, and downloads form this new
IP are fast (2MByte/sec).

Tracerouting from server to client is the same using both source IPs.  But,
one IP consistently has the very slow speeds that the other does not.
Changing our outbound path between different upstreams does not make a
difference.

It certainly feels like Comcast is throttling one of our IP ranges.  Could
someone at Comcast please contact me off-list for details?


That's possible, but while a traceroute can help shed some light on 
certain performance problems, this doesn't seem like one where a 
traceroute will help very much.  The slow traceroute hops are more likely 
due to other factors (ICMP rate limiting / control plane policing / etc), 
rather than a direct indicator of Comcast shaping / throttling your 
traffic.


As others have indicated, doing a packet capture of a transfer session 
that shows the behavior you noted is likely to be a lot more telling than 
a traceroute.


jms

Re: Comcast throttling?

2014-10-31 Thread John Neiberger 
Replying off-list as requested.

John

On Fri, Oct 31, 2014 at 1:41 PM, Mark Price  wrote:

> Similar to another thread on the list today, I'm troubleshooting a problem
> for a customer on Comcast business fiber.
>
> Downloading a file from one of our web servers is very slow (~15KByte/sec).
>  mtr looks clean in both directions.  I added an IP address on the same
> server from a different class C on our network, and downloads form this new
> IP are fast (2MByte/sec).
>
> Tracerouting from server to client is the same using both source IPs.  But,
> one IP consistently has the very slow speeds that the other does not.
> Changing our outbound path between different upstreams does not make a
> difference.
>
> It certainly feels like Comcast is throttling one of our IP ranges.  Could
> someone at Comcast please contact me off-list for details?
>
>
> Thanks,
>
> Mark
>

Re: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom

2014-10-31 Thread Jared Mauch 
Recommendations:

1) Use iperf in TCP mode to test the performance
2) use iperf in UDP mode to test the performance

This is the best way to quickly triage the issue and determine if
it's actual bandwidth issue or something else.

It's quite common for various NAT/VPN devices to eat or meddle with
packets such that performance is limited, sometimes severely.  You need
to check the CPU/performance of these devices.

Do you have graphs showing the links as idle for each end while
doing the test?

Many people don't have this data or tools.  Consider setting up
a tool like observium to monitor the health and performance of the
devices.

Check other devices, such as switches, duplex settings, etc.  If
the device is 'unmanaged' and you can't tell if it negotiated 100-full
or 100-half, consider it may have done half-duplex.  I recall one customer case
where after much troubleshooting for performance they had a duplex issue
causing trouble.


Hope this helps,

- Jared


On Fri, Oct 31, 2014 at 03:29:56PM -0400, Zachary Frederick wrote:
> I apologize I should have said it starts out about 3 meg max and slows to 
> about 400kpbs for most of the transfer.
> 
> 
> 
> > On Oct 31, 2014, at 3:27 PM, John Neiberger  wrote:
> > 
> > With a max bandwidth of 25 Mbps and a 40ms RTT, the max is more like 14MB/s 
> > or 1.75 Mbps. 
> > 
> > https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=80&loss=1e-06&bw=25&rtt2=35&win=64&Calculate=Calculate
> >  
> > 
> > 
> > But that's only if either endpoint is stuck at a 64 KB receive window. A 
> > quick packet capture would be able to see what was happening.  Check the 
> > TCP setup and make sure that both ends are doing TCP window scaling 
> > properly.
> > 
> > John
> > 
> > On Fri, Oct 31, 2014 at 1:02 PM, Pedro Cavaca  > > wrote:
> > On 31 October 2014 18:32, Zachary Frederick  > > wrote:
> > 
> > > We have been having a problem receiving software releases from our
> > > developer. The releases are typically around 1G in size. The developer’s
> > > connection is a 100m metro fiber with TW Telecom,  our connection is a 25m
> > > Comcast Enterprise Fiber.
> > >
> > > Our traffic graphs show very little utilization of our connection.
> > > Typically on average we are at about 7 meg utilization of our 25.
> > >
> > > Every other partner that shares in our software development that receives
> > > the software releases can receive the updates 3-4 times faster than we 
> > > can.
> > >
> > > Typically we receive the releases at about 3mbps.
> > >
> > 
> > Are you using an application that uses TCP transport for the transfer?
> > 
> > https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=38&loss=1e-06&Calculate=Calculate&bw=100&rtt2=80&win=64
> >  
> > 
> > 
> > 3Mbps looks about right. Time for a tune up
> > 
> > 
> > > I have tried contacting Comcast Enterprise Tech support, however I’ve been
> > > told that if I run a speed test from my connection and the test runs at 
> > > the
> > > speed we are paying for, there is very little they are willing to look 
> > > into.
> > >
> > > Can anyone check on the Comcast Routers on the Tracert below, or is there
> > > anything that can be throttling this connection between the two 
> > > connections?
> > >
> > > Also, our firewall and connection is able to run at the full 25. We have
> > > no throttling or QOS set to prevent a good connection to our developer. 
> > > For
> > > example, we can run a multi-threaded upload, in the middle of the night, 
> > > to
> > > Amazon Glacier storage and completely saturate our connection when doing
> > > so. The firewall and connection is able to handle our full bandwidth
> > > capacity during that backup.
> > >
> > > If there is any other information I can provide to help track this problem
> > > down, please let me know.
> > >
> > > Thanks in advance, everyone!
> > >
> > >
> > > Trace Route below:
> > >
> > >
> > >
> > >
> > > 1  (172.16.150.1)  1.143 ms  1.132 ms  1.122 ms
> > >
> > >
> > > 2  (173.227.204.1)  1.585 ms  1.583 ms  1.574 ms
> > >
> > >
> > > 3  chi2-pr1-xe-0-3-0-0.us.twtelecom.net 
> > >  (66.192.245.166)  10.477 ms
> > > 10.485 ms 10.478 ms
> > >
> > >
> > > 4  x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net 
> > >  
> > > (75.149.230.141)
> > > 10.470 ms 10.465 ms  10.457 ms
> > >
> > >
> > > 5  he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net 
> > >  (68.86.86.37)  
> > > 10.733
>

Comcast throttling?

2014-10-31 Thread Mark Price 
Similar to another thread on the list today, I'm troubleshooting a problem
for a customer on Comcast business fiber.

Downloading a file from one of our web servers is very slow (~15KByte/sec).
 mtr looks clean in both directions.  I added an IP address on the same
server from a different class C on our network, and downloads form this new
IP are fast (2MByte/sec).

Tracerouting from server to client is the same using both source IPs.  But,
one IP consistently has the very slow speeds that the other does not.
Changing our outbound path between different upstreams does not make a
difference.

It certainly feels like Comcast is throttling one of our IP ranges.  Could
someone at Comcast please contact me off-list for details?


Thanks,

Mark

Re: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom

2014-10-31 Thread John Neiberger 
Sounds like a combination of packet loss and small TCP receive windows. If
you can, grab a packet capture and make sure to get the TCP setup. That
should show you what's happening under the hood.

Also, I should mention that I totally hosed the units in my first reply.
 :)  That's what I get for hurrying.

John

On Fri, Oct 31, 2014 at 1:29 PM, Zachary Frederick 
wrote:

> I apologize I should have said it starts out about 3 meg max and slows to
> about 400kpbs for most of the transfer.
>
>
>
> On Oct 31, 2014, at 3:27 PM, John Neiberger  wrote:
>
> With a max bandwidth of 25 Mbps and a 40ms RTT, the max is more like
> 14MB/s or 1.75 Mbps.
>
>
> https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=80&loss=1e-06&bw=25&rtt2=35&win=64&Calculate=Calculate
>
> But that's only if either endpoint is stuck at a 64 KB receive window. A
> quick packet capture would be able to see what was happening.  Check the
> TCP setup and make sure that both ends are doing TCP window scaling
> properly.
>
> John
>
> On Fri, Oct 31, 2014 at 1:02 PM, Pedro Cavaca 
> wrote:
>
>> On 31 October 2014 18:32, Zachary Frederick 
>> wrote:
>>
>> > We have been having a problem receiving software releases from our
>> > developer. The releases are typically around 1G in size. The developer’s
>> > connection is a 100m metro fiber with TW Telecom,  our connection is a
>> 25m
>> > Comcast Enterprise Fiber.
>> >
>> > Our traffic graphs show very little utilization of our connection.
>> > Typically on average we are at about 7 meg utilization of our 25.
>> >
>> > Every other partner that shares in our software development that
>> receives
>> > the software releases can receive the updates 3-4 times faster than we
>> can.
>> >
>> > Typically we receive the releases at about 3mbps.
>> >
>>
>> Are you using an application that uses TCP transport for the transfer?
>>
>>
>> https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=38&loss=1e-06&Calculate=Calculate&bw=100&rtt2=80&win=64
>>
>> 3Mbps looks about right. Time for a tune up
>>
>>
>> > I have tried contacting Comcast Enterprise Tech support, however I’ve
>> been
>> > told that if I run a speed test from my connection and the test runs at
>> the
>> > speed we are paying for, there is very little they are willing to look
>> into.
>> >
>> > Can anyone check on the Comcast Routers on the Tracert below, or is
>> there
>> > anything that can be throttling this connection between the two
>> connections?
>> >
>> > Also, our firewall and connection is able to run at the full 25. We have
>> > no throttling or QOS set to prevent a good connection to our developer.
>> For
>> > example, we can run a multi-threaded upload, in the middle of the
>> night, to
>> > Amazon Glacier storage and completely saturate our connection when doing
>> > so. The firewall and connection is able to handle our full bandwidth
>> > capacity during that backup.
>> >
>> > If there is any other information I can provide to help track this
>> problem
>> > down, please let me know.
>> >
>> > Thanks in advance, everyone!
>> >
>> >
>> > Trace Route below:
>> >
>> >
>> >
>> >
>> > 1  (172.16.150.1)  1.143 ms  1.132 ms  1.122 ms
>> >
>> >
>> > 2  (173.227.204.1)  1.585 ms  1.583 ms  1.574 ms
>> >
>> >
>> > 3  chi2-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.245.166)  10.477 ms
>> > 10.485 ms 10.478 ms
>> >
>> >
>> > 4  x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net (75.149.230.141)
>> > 10.470 ms 10.465 ms  10.457 ms
>> >
>> >
>> > 5  he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.37)
>> 10.733
>> > ms  10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net
>> > (68.86.86.33)  12.146 ms
>> >
>> >
>> > 6  be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225)  33.202 ms
>> > 32.144 ms  32.127 ms
>> >
>> >
>> > 7  68.86.91.30 (68.86.91.30)  41.508 ms  41.322 ms  41.599 ms
>> >
>> >
>> > 8  te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net (69.139.168.26)
>> > 38.196 ms te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net
>> > (162.151.21.82)  44.644 ms
>> te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net
>> > (69.139.195.18)  38.266 ms
>> >
>> >
>> > 9  (107.1.72.98)  39.781 ms  39.785 ms  39.912 ms
>>
>
>
>

Re: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom

2014-10-31 Thread Zachary Frederick 
I apologize I should have said it starts out about 3 meg max and slows to about 
400kpbs for most of the transfer.



> On Oct 31, 2014, at 3:27 PM, John Neiberger  wrote:
> 
> With a max bandwidth of 25 Mbps and a 40ms RTT, the max is more like 14MB/s 
> or 1.75 Mbps. 
> 
> https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=80&loss=1e-06&bw=25&rtt2=35&win=64&Calculate=Calculate
>  
> 
> 
> But that's only if either endpoint is stuck at a 64 KB receive window. A 
> quick packet capture would be able to see what was happening.  Check the TCP 
> setup and make sure that both ends are doing TCP window scaling properly.
> 
> John
> 
> On Fri, Oct 31, 2014 at 1:02 PM, Pedro Cavaca  > wrote:
> On 31 October 2014 18:32, Zachary Frederick  > wrote:
> 
> > We have been having a problem receiving software releases from our
> > developer. The releases are typically around 1G in size. The developer’s
> > connection is a 100m metro fiber with TW Telecom,  our connection is a 25m
> > Comcast Enterprise Fiber.
> >
> > Our traffic graphs show very little utilization of our connection.
> > Typically on average we are at about 7 meg utilization of our 25.
> >
> > Every other partner that shares in our software development that receives
> > the software releases can receive the updates 3-4 times faster than we can.
> >
> > Typically we receive the releases at about 3mbps.
> >
> 
> Are you using an application that uses TCP transport for the transfer?
> 
> https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=38&loss=1e-06&Calculate=Calculate&bw=100&rtt2=80&win=64
>  
> 
> 
> 3Mbps looks about right. Time for a tune up
> 
> 
> > I have tried contacting Comcast Enterprise Tech support, however I’ve been
> > told that if I run a speed test from my connection and the test runs at the
> > speed we are paying for, there is very little they are willing to look into.
> >
> > Can anyone check on the Comcast Routers on the Tracert below, or is there
> > anything that can be throttling this connection between the two connections?
> >
> > Also, our firewall and connection is able to run at the full 25. We have
> > no throttling or QOS set to prevent a good connection to our developer. For
> > example, we can run a multi-threaded upload, in the middle of the night, to
> > Amazon Glacier storage and completely saturate our connection when doing
> > so. The firewall and connection is able to handle our full bandwidth
> > capacity during that backup.
> >
> > If there is any other information I can provide to help track this problem
> > down, please let me know.
> >
> > Thanks in advance, everyone!
> >
> >
> > Trace Route below:
> >
> >
> >
> >
> > 1  (172.16.150.1)  1.143 ms  1.132 ms  1.122 ms
> >
> >
> > 2  (173.227.204.1)  1.585 ms  1.583 ms  1.574 ms
> >
> >
> > 3  chi2-pr1-xe-0-3-0-0.us.twtelecom.net 
> >  (66.192.245.166)  10.477 ms
> > 10.485 ms 10.478 ms
> >
> >
> > 4  x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net 
> >  (75.149.230.141)
> > 10.470 ms 10.465 ms  10.457 ms
> >
> >
> > 5  he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net 
> >  (68.86.86.37)  
> > 10.733
> > ms  10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net 
> > 
> > (68.86.86.33)  12.146 ms
> >
> >
> > 6  be-10206-cr01.newyork.ny.ibone.comcast.net 
> >  (68.86.86.225)  33.202 
> > ms
> > 32.144 ms  32.127 ms
> >
> >
> > 7  68.86.91.30 (68.86.91.30)  41.508 ms  41.322 ms  41.599 ms
> >
> >
> > 8  te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net 
> >  (69.139.168.26)
> > 38.196 ms te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net 
> > 
> > (162.151.21.82)  44.644 ms te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net 
> > 
> > (69.139.195.18)  38.266 ms
> >
> >
> > 9  (107.1.72.98)  39.781 ms  39.785 ms  39.912 ms
>

Re: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom

2014-10-31 Thread John Neiberger 
With a max bandwidth of 25 Mbps and a 40ms RTT, the max is more like 14MB/s
or 1.75 Mbps.

https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=80&loss=1e-06&bw=25&rtt2=35&win=64&Calculate=Calculate

But that's only if either endpoint is stuck at a 64 KB receive window. A
quick packet capture would be able to see what was happening.  Check the
TCP setup and make sure that both ends are doing TCP window scaling
properly.

John

On Fri, Oct 31, 2014 at 1:02 PM, Pedro Cavaca  wrote:

> On 31 October 2014 18:32, Zachary Frederick  wrote:
>
> > We have been having a problem receiving software releases from our
> > developer. The releases are typically around 1G in size. The developer’s
> > connection is a 100m metro fiber with TW Telecom,  our connection is a
> 25m
> > Comcast Enterprise Fiber.
> >
> > Our traffic graphs show very little utilization of our connection.
> > Typically on average we are at about 7 meg utilization of our 25.
> >
> > Every other partner that shares in our software development that receives
> > the software releases can receive the updates 3-4 times faster than we
> can.
> >
> > Typically we receive the releases at about 3mbps.
> >
>
> Are you using an application that uses TCP transport for the transfer?
>
>
> https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=38&loss=1e-06&Calculate=Calculate&bw=100&rtt2=80&win=64
>
> 3Mbps looks about right. Time for a tune up
>
>
> > I have tried contacting Comcast Enterprise Tech support, however I’ve
> been
> > told that if I run a speed test from my connection and the test runs at
> the
> > speed we are paying for, there is very little they are willing to look
> into.
> >
> > Can anyone check on the Comcast Routers on the Tracert below, or is there
> > anything that can be throttling this connection between the two
> connections?
> >
> > Also, our firewall and connection is able to run at the full 25. We have
> > no throttling or QOS set to prevent a good connection to our developer.
> For
> > example, we can run a multi-threaded upload, in the middle of the night,
> to
> > Amazon Glacier storage and completely saturate our connection when doing
> > so. The firewall and connection is able to handle our full bandwidth
> > capacity during that backup.
> >
> > If there is any other information I can provide to help track this
> problem
> > down, please let me know.
> >
> > Thanks in advance, everyone!
> >
> >
> > Trace Route below:
> >
> >
> >
> >
> > 1  (172.16.150.1)  1.143 ms  1.132 ms  1.122 ms
> >
> >
> > 2  (173.227.204.1)  1.585 ms  1.583 ms  1.574 ms
> >
> >
> > 3  chi2-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.245.166)  10.477 ms
> > 10.485 ms 10.478 ms
> >
> >
> > 4  x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net (75.149.230.141)
> > 10.470 ms 10.465 ms  10.457 ms
> >
> >
> > 5  he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.37)  10.733
> > ms  10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net
> > (68.86.86.33)  12.146 ms
> >
> >
> > 6  be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225)  33.202 ms
> > 32.144 ms  32.127 ms
> >
> >
> > 7  68.86.91.30 (68.86.91.30)  41.508 ms  41.322 ms  41.599 ms
> >
> >
> > 8  te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net (69.139.168.26)
> > 38.196 ms te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net
> > (162.151.21.82)  44.644 ms
> te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net
> > (69.139.195.18)  38.266 ms
> >
> >
> > 9  (107.1.72.98)  39.781 ms  39.785 ms  39.912 ms
>

Re: Industry standard bandwidth guarantee?

2014-10-31 Thread Carlos Alcantar 
+1 on this exactly what we do, keeps the calls down.


Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / car...@race.com / http://www.race.com





On 10/31/14, 9:56 AM, "Laszlo Hanyecz"  wrote:

>If you're selling to end users, under promise and over deliver.  Tell them
>20Mbit but provision for 25.  That way when they run their speedtest,
>they're delighted that they're getting more, instead of being disappointed
>and feeling screwed.  In practice they will leave it idle most of the time
>anyway.
>This isn't a technical problem, it's just a matter of setting expectations
>and satisfying them.  Some of the customers might be completely clueless,
>but if your goal is to make them happy, then explaining protocol overhead
>is
>probably not the right way.
>
>-Laszlo
>
>
>
>
>

RE: Industry standard bandwidth guarantee?

2014-10-31 Thread Frank Bulk 
We get this with wireless carriers -- they ask for quote for a 100 Mbps
Ethernet circuit, and then tell us afterwards that it's 100 Mbps of goodput,
so we have to size it to 125 Mbps to cover all their one MPLS and two 802.1Q
tags and to past the RFC 2544 test at 64-byte frames.

Frank

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Bacon, Ricky (RJ)
Sent: Friday, October 31, 2014 11:50 AM
To: David Hofstee; nanog@nanog.org
Subject: RE: Industry standard bandwidth guarantee?



>That *is* a silly example.
>
>A more proper analogy would be that you buy 12 gallons of gas, but the 
>station only deposits 11 gallons in your tank because the pumps are
operated by gasoline engines and they feel it is fine to count the number of
gallons pulled out of their tank instead of the amount given to the
customer.

So if you tell a customer you are giving them 10 g of space for their email,
you shouldn't charge them for the storage taken up by each individual
email's headers.  Is that how it works though? Not so much I think. As long
as the pricing policy is consistent across the industry, and it is, then you
are not being ripped off.  Creating, implementing and maintaining a deep
dive billing systems to figure out how much of your traffic is packet header
and protocol and how much is your data would just add to operating expense
which would eventually be passed on to the customer. 

If you want a pipe that will let you transmit 10G of raw data, I can have
than implemented.  Just tell me where to connect the two ends.  If you want
to connect one end to our router or switch, we'll do that too, but it won't
get you much.  If you want to participate on the internet with a 10Gig link,
you are going to have to use protocols, and the data will have to be in
layer 3 packets, and they can be any kind you choose.  But you are
originating the request packets and receiving the reply packets and those
will include overhead.  We just transport them to and from the internet.  

In TCP protocol RxWinSize/RTT*8 is your theoretical protocol download
limitation in bits per second.  You will not exceed that unless you run
multiple sessions, and even then it will always be less than link speed,
which is your physical limit, how many bits you can receive in a second,
protocol or otherwise.

Re: Comcast Enterprise Fiber Slow Connection Problem from TW Telecom

2014-10-31 Thread Pedro Cavaca 
On 31 October 2014 18:32, Zachary Frederick  wrote:

> We have been having a problem receiving software releases from our
> developer. The releases are typically around 1G in size. The developer’s
> connection is a 100m metro fiber with TW Telecom,  our connection is a 25m
> Comcast Enterprise Fiber.
>
> Our traffic graphs show very little utilization of our connection.
> Typically on average we are at about 7 meg utilization of our 25.
>
> Every other partner that shares in our software development that receives
> the software releases can receive the updates 3-4 times faster than we can.
>
> Typically we receive the releases at about 3mbps.
>

Are you using an application that uses TCP transport for the transfer?

https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460&rtt=38&loss=1e-06&Calculate=Calculate&bw=100&rtt2=80&win=64

3Mbps looks about right. Time for a tune up


> I have tried contacting Comcast Enterprise Tech support, however I’ve been
> told that if I run a speed test from my connection and the test runs at the
> speed we are paying for, there is very little they are willing to look into.
>
> Can anyone check on the Comcast Routers on the Tracert below, or is there
> anything that can be throttling this connection between the two connections?
>
> Also, our firewall and connection is able to run at the full 25. We have
> no throttling or QOS set to prevent a good connection to our developer. For
> example, we can run a multi-threaded upload, in the middle of the night, to
> Amazon Glacier storage and completely saturate our connection when doing
> so. The firewall and connection is able to handle our full bandwidth
> capacity during that backup.
>
> If there is any other information I can provide to help track this problem
> down, please let me know.
>
> Thanks in advance, everyone!
>
>
> Trace Route below:
>
>
>
>
> 1  (172.16.150.1)  1.143 ms  1.132 ms  1.122 ms
>
>
> 2  (173.227.204.1)  1.585 ms  1.583 ms  1.574 ms
>
>
> 3  chi2-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.245.166)  10.477 ms
> 10.485 ms 10.478 ms
>
>
> 4  x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net (75.149.230.141)
> 10.470 ms 10.465 ms  10.457 ms
>
>
> 5  he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.37)  10.733
> ms  10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net
> (68.86.86.33)  12.146 ms
>
>
> 6  be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225)  33.202 ms
> 32.144 ms  32.127 ms
>
>
> 7  68.86.91.30 (68.86.91.30)  41.508 ms  41.322 ms  41.599 ms
>
>
> 8  te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net (69.139.168.26)
> 38.196 ms te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net
> (162.151.21.82)  44.644 ms te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net
> (69.139.195.18)  38.266 ms
>
>
> 9  (107.1.72.98)  39.781 ms  39.785 ms  39.912 ms

Re: Is it unusual to remove defunct rr objects?

2014-10-31 Thread Jimmy Hess 
On Fri, Oct 31, 2014 at 12:39 PM, Jared Mauch  wrote:
[snip]
> People tend to treat things like IRR (eg: RADB, etc) as a
> garbage pit you toss things into and never remove from.

So who do we ask about making IRRs  expire  defunct objects and/or
changing their system design to  ensure that the legitimate resource holder
can remove references to their prefix  from ASes  they no longer
authorize to carry them,

without requiring all sorts of assistance, cooperation, and
willingness from the AS maintainer?  :)


>>   Is this a non-issue that I shouldn't worry about?  Doesn't the
>> quality of this data effect Origin Validation efforts?
>
> Yes it does.  This has a fairly severe impact for those that build
> off the IRR data for filters.  We have seen customers end up including
> AS7018 in their AS-SET or as you noticed have other legacy routes appear.
>


--
-JH

Comcast Enterprise Fiber Slow Connection Problem from TW Telecom

2014-10-31 Thread Zachary Frederick 
We have been having a problem receiving software releases from our developer. 
The releases are typically around 1G in size. The developer’s connection is a 
100m metro fiber with TW Telecom,  our connection is a 25m Comcast Enterprise 
Fiber.

Our traffic graphs show very little utilization of our connection. Typically on 
average we are at about 7 meg utilization of our 25.

Every other partner that shares in our software development that receives the 
software releases can receive the updates 3-4 times faster than we can.

Typically we receive the releases at about 3mbps.

I have tried contacting Comcast Enterprise Tech support, however I’ve been told 
that if I run a speed test from my connection and the test runs at the speed we 
are paying for, there is very little they are willing to look into.

Can anyone check on the Comcast Routers on the Tracert below, or is there 
anything that can be throttling this connection between the two connections?

Also, our firewall and connection is able to run at the full 25. We have no 
throttling or QOS set to prevent a good connection to our developer. For 
example, we can run a multi-threaded upload, in the middle of the night, to 
Amazon Glacier storage and completely saturate our connection when doing so. 
The firewall and connection is able to handle our full bandwidth capacity 
during that backup.

If there is any other information I can provide to help track this problem 
down, please let me know.

Thanks in advance, everyone!


Trace Route below:




1  (172.16.150.1)  1.143 ms  1.132 ms  1.122 ms   


2  (173.227.204.1)  1.585 ms  1.583 ms  1.574 ms 


3  chi2-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.245.166)  10.477 ms  10.485 ms 
10.478 ms  


4  x-eth-0-0-4-pe05.350ecermak.il.ibone.comcast.net (75.149.230.141)  10.470 ms 
10.465 ms  10.457 ms  


5  he-2-1-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.37)  10.733 ms  
10.731 ms he-2-0-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.86.33)  12.146 
ms


6  be-10206-cr01.newyork.ny.ibone.comcast.net (68.86.86.225)  33.202 ms  32.144 
ms  32.127 ms  


7  68.86.91.30 (68.86.91.30)  41.508 ms  41.322 ms  41.599 ms  


8  te-0-0-0-1-sur01.greensburg.pa.pitt.comcast.net (69.139.168.26)  38.196 ms 
te-0-0-0-3-sur01.greensburg.pa.pitt.comcast.net (162.151.21.82)  44.644 ms 
te-0-0-0-0-sur01.greensburg.pa.pitt.comcast.net (69.139.195.18)  38.266 ms  
  


9  (107.1.72.98)  39.781 ms  39.785 ms  39.912 ms

Re: Industry standard bandwidth guarantee?

2014-10-31 Thread Rafael Possamai 
I have a feeling this issue only occurs with residential customers, and
perhaps small businesses. It is most likely cheaper to over deliver in this
case then to maintain a larger call center and support team to attempt to
explain end users how TCP has limitations. No two large communication
businesses (ISP in this case) with properly educated technical people (i.e.
network engineers or similar) on both ends should start an argument on who
gets to cover transmission overhead (or for simplicity, the packaging on
the cake).



On Fri, Oct 31, 2014 at 11:56 AM, Laszlo Hanyecz 
wrote:

> If you're selling to end users, under promise and over deliver.  Tell them
> 20Mbit but provision for 25.  That way when they run their speedtest,
> they're delighted that they're getting more, instead of being disappointed
> and feeling screwed.  In practice they will leave it idle most of the time
> anyway.
> This isn't a technical problem, it's just a matter of setting expectations
> and satisfying them.  Some of the customers might be completely clueless,
> but if your goal is to make them happy, then explaining protocol overhead
> is
> probably not the right way.
>
> -Laszlo
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jeff Sorrels
> Sent: Friday, October 31, 2014 16:14
> To: nanog@nanog.org
> Subject: Re: Industry standard bandwidth guarantee?
>
> And if you look at it from the provider's prospective, they have lots of
> customers who want 12 gallons of gas worth of driving time, but only
> want to pay for 11 gallons (or worse, went to "gasspeedtest.net" and it
> showed their purchased gas only gave them 10 gallons worth of driving
> time).
>
> Consider a better analogy from the provider side:  A customer bakes a
> nice beautiful fruit cake for their Aunt Eddie in wilds of
> Saskatchewan.   The cake is 10 kg - but they want to make sure it gets
> to Eddie properly, so they wrap it in foil, then bubble wrap, then put
> it in a box.  They have this 10kg cake and 1kg of packaging to get it to
> up north.  They then go to the ISP store to get it delivered - and are
> surprised, that to get it there, they have to pay to ship 11kg.  But the
> cake is only 10kg!  If they pay to ship 11kg for a 10kg cake, obviously
> the ISP is trying to screw them. The ISP should deliver the 10kg cake at
> the 10kg rate and eat the cost of the rest - no matter how many kg the
> packaging is or how much space they actually have on the delivery truck.
>
> And then the customer goes to the Internet to decry the nerve of the ISP
> for not explaining the concept of "packaging" up front and in big
> letters.  "Why they should tell you - to ship 10kg, buy 11kg up front!
> Or better yet, they shouldn't calculate the box when weighing for
> shipping! I should pay for the contents and the wrapping, no matter how
> much it is, shouldn't even be considered! It's plain robbery.  Harrumph".
>
> Jeff
>
> On 10/31/2014 6:02 AM, Joe Greco wrote:
> > That's fine as long as they're giving you a resource that can potentially
> > transfer the 20Mbps.
> >
> > That *is* a silly example.
> >
> > A more proper analogy would be that you buy 12 gallons of gas, but the
> > station only deposits 11 gallons in your tank because the pumps are
> > operated by gasoline engines and they feel it is fine to count the
> > number of gallons pulled out of their tank instead of the amount given
> > to the customer.
> >
> >
> > Finding new ways to give the customer less while making it look like more
> > has a long, proud history, yes.
> >
> > ... JG
>
> --
> Jeff Sorrels
> Network Administrator
> KanREN, Inc
> jlsorr...@kanren.net
> 785-856-9820, #2
>
>
>

Weekly Routing Table Report

2014-10-31 Thread 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, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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 01 Nov, 2014

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

Analysis Summary


BGP routing table entries examined:  518662
Prefixes after maximum aggregation:  199550
Deaggregation factor:  2.60
Unique aggregates announced to Internet: 253190
Total ASes present in the Internet Routing Table: 48444
Prefixes per ASN: 10.71
Origin-only ASes present in the Internet Routing Table:   36294
Origin ASes announcing only one prefix:   16343
Transit ASes present in the Internet Routing Table:6178
Transit-only ASes present in the Internet Routing Table:169
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  93
Max AS path prepend of ASN ( 55644)  86
Prefixes from unregistered ASNs in the Routing Table:  1809
Unregistered ASNs in the Routing Table: 435
Number of 32-bit ASNs allocated by the RIRs:   7781
Number of 32-bit ASNs visible in the Routing Table:5972
Prefixes from 32-bit ASNs in the Routing Table:   21275
Number of bogon 32-bit ASNs visible in the Routing Table:16
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:351
Number of addresses announced to Internet:   2713052580
Equivalent to 161 /8s, 181 /16s and 229 /24s
Percentage of available address space announced:   73.3
Percentage of allocated address space announced:   73.3
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   96.9
Total number of prefixes smaller than registry allocations:  176879

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   128935
Total APNIC prefixes after maximum aggregation:   36851
APNIC Deaggregation factor:3.50
Prefixes being announced from the APNIC address blocks:  133024
Unique aggregates announced from the APNIC address blocks:53376
APNIC Region origin ASes present in the Internet Routing Table:4988
APNIC Prefixes per ASN:   26.67
APNIC Region origin ASes announcing only one prefix:   1199
APNIC Region transit ASes present in the Internet Routing Table:862
Average APNIC Region AS path length visible:4.7
Max APNIC Region AS path length visible: 93
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1153
Number of APNIC addresses announced to Internet:  736685408
Equivalent to 43 /8s, 232 /16s and 237 /24s
Percentage of available APNIC address space announced: 86.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:171887
Total ARIN prefixes after maximum aggregation:85320
ARIN Deaggregation factor: 2.01
Prefixes being announced from the ARIN address blocks:   173718
Unique aggregates announced from the ARIN address blocks: 81425
ARIN Region origin ASes present in the Internet Routing Table:16390
ARIN Prefixes per ASN:

Re: Is it unusual to remove defunct rr objects?

2014-10-31 Thread Jared Mauch 
On Fri, Oct 31, 2014 at 10:34:23AM -0700, Tim Howe wrote:
>   I've since found a disturbing number of defunct objects that
> relate to my customers (and me) in a similar way, and I have mostly
> had success in getting them cleared up.  If my relatively small
> customer base is any indication, there are more incorrect objects out
> there than correct ones.  I feel this is something I should have been
> looking into sooner.

People tend to treat things like IRR (eg: RADB, etc) as a
garbage pit you toss things into and never remove from.

>   Is this a non-issue that I shouldn't worry about?  Doesn't the
> quality of this data effect Origin Validation efforts?

Yes it does.  This has a fairly severe impact for those that build
off the IRR data for filters.  We have seen customers end up including
AS7018 in their AS-SET or as you noticed have other legacy routes appear.

> 
>   Sorry that this turned out so long; I wanted to give some
> context.

No worries.  I've got a transient routing leak detector
that does find/fuzz these issues which has been running for a few
years now.  I'm guessing you may see some of the related prefixes
there as a result.  It's in need of a U/I redesign (code welcome)
but is located here:

http://puck.nether.net/bgp/leakinfo.cgi

- Jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Is it unusual to remove defunct rr objects?

2014-10-31 Thread Tim Howe 
In the recent past, we've had another provider in our same market
erroneously advertising prefixes for some of our customers.

After we got it cleared up, I noticed that there were some old
route objects in RADB that were entered for that provider years ago by
360.  These route objects, in a sense, legitimized, the erroneous
advertisements by matching the prefixes to that providers ASN.  As that
provider no longer uses 360/Zayo, I asked Zayo if they could remove the
objects.  Once the request made it to someone who understood what I was
asking, they spent some time and effort over the next few weeks (much
appreciated by me, I might add) in hunting down the info they needed to
(I assume) manage the old 360 maintnr object.  They then removed the
offending objects (again, my thanks).

One of the Zayo support folks mentioned to me, somewhat
apologetically, that it took some time as nobody had ever made such a
request before.  So this got me wondering: is it really such a rare
thing to manage ones route objects such that old defunct data is
removed?  I'm not under the impression that the issue I had would have
been alleviated any by the related route objects having been removed
beforehand, but their existence wasn't helping me any either.

I've since found a disturbing number of defunct objects that
relate to my customers (and me) in a similar way, and I have mostly
had success in getting them cleared up.  If my relatively small
customer base is any indication, there are more incorrect objects out
there than correct ones.  I feel this is something I should have been
looking into sooner.

Is this a non-issue that I shouldn't worry about?  Doesn't the
quality of this data effect Origin Validation efforts?

Sorry that this turned out so long; I wanted to give some
context.

--TimH

RE: Industry standard bandwidth guarantee?

2014-10-31 Thread Laszlo Hanyecz 
If you're selling to end users, under promise and over deliver.  Tell them
20Mbit but provision for 25.  That way when they run their speedtest,
they're delighted that they're getting more, instead of being disappointed
and feeling screwed.  In practice they will leave it idle most of the time
anyway.
This isn't a technical problem, it's just a matter of setting expectations
and satisfying them.  Some of the customers might be completely clueless,
but if your goal is to make them happy, then explaining protocol overhead is
probably not the right way.

-Laszlo


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jeff Sorrels
Sent: Friday, October 31, 2014 16:14
To: nanog@nanog.org
Subject: Re: Industry standard bandwidth guarantee?

And if you look at it from the provider's prospective, they have lots of 
customers who want 12 gallons of gas worth of driving time, but only 
want to pay for 11 gallons (or worse, went to "gasspeedtest.net" and it 
showed their purchased gas only gave them 10 gallons worth of driving time).

Consider a better analogy from the provider side:  A customer bakes a 
nice beautiful fruit cake for their Aunt Eddie in wilds of 
Saskatchewan.   The cake is 10 kg - but they want to make sure it gets 
to Eddie properly, so they wrap it in foil, then bubble wrap, then put 
it in a box.  They have this 10kg cake and 1kg of packaging to get it to 
up north.  They then go to the ISP store to get it delivered - and are 
surprised, that to get it there, they have to pay to ship 11kg.  But the 
cake is only 10kg!  If they pay to ship 11kg for a 10kg cake, obviously 
the ISP is trying to screw them. The ISP should deliver the 10kg cake at 
the 10kg rate and eat the cost of the rest - no matter how many kg the 
packaging is or how much space they actually have on the delivery truck.

And then the customer goes to the Internet to decry the nerve of the ISP 
for not explaining the concept of "packaging" up front and in big 
letters.  "Why they should tell you - to ship 10kg, buy 11kg up front!  
Or better yet, they shouldn't calculate the box when weighing for 
shipping! I should pay for the contents and the wrapping, no matter how 
much it is, shouldn't even be considered! It's plain robbery.  Harrumph".

Jeff

On 10/31/2014 6:02 AM, Joe Greco wrote:
> That's fine as long as they're giving you a resource that can potentially
> transfer the 20Mbps.
>
> That *is* a silly example.
>
> A more proper analogy would be that you buy 12 gallons of gas, but the
> station only deposits 11 gallons in your tank because the pumps are
> operated by gasoline engines and they feel it is fine to count the
> number of gallons pulled out of their tank instead of the amount given
> to the customer.
>
>
> Finding new ways to give the customer less while making it look like more
> has a long, proud history, yes.
>
> ... JG

-- 
Jeff Sorrels
Network Administrator
KanREN, Inc
jlsorr...@kanren.net
785-856-9820, #2

RE: Industry standard bandwidth guarantee?

2014-10-31 Thread Bacon, Ricky (RJ) 


>That *is* a silly example.
>
>A more proper analogy would be that you buy 12 gallons of gas, but the 
>station only deposits 11 gallons in your tank because the pumps are operated 
>by gasoline engines and they feel it is fine to count the number of gallons 
>pulled out of their tank instead of the amount given to the customer.

So if you tell a customer you are giving them 10 g of space for their email, 
you shouldn't charge them for the storage taken up by each individual email's 
headers.  Is that how it works though? Not so much I think. As long as the 
pricing policy is consistent across the industry, and it is, then you are not 
being ripped off.  Creating, implementing and maintaining a deep dive billing 
systems to figure out how much of your traffic is packet header and protocol 
and how much is your data would just add to operating expense which would 
eventually be passed on to the customer. 

If you want a pipe that will let you transmit 10G of raw data, I can have than 
implemented.  Just tell me where to connect the two ends.  If you want to 
connect one end to our router or switch, we'll do that too, but it won't get 
you much.  If you want to participate on the internet with a 10Gig link, you 
are going to have to use protocols, and the data will have to be in layer 3 
packets, and they can be any kind you choose.  But you are originating the 
request packets and receiving the reply packets and those will include 
overhead.  We just transport them to and from the internet.  

In TCP protocol RxWinSize/RTT*8 is your theoretical protocol download 
limitation in bits per second.  You will not exceed that unless you run 
multiple sessions, and even then it will always be less than link speed, which 
is your physical limit, how many bits you can receive in a second, protocol or 
otherwise.

Re: Industry standard bandwidth guarantee?

2014-10-31 Thread Jeff Sorrels 
And if you look at it from the provider's prospective, they have lots of 
customers who want 12 gallons of gas worth of driving time, but only 
want to pay for 11 gallons (or worse, went to "gasspeedtest.net" and it 
showed their purchased gas only gave them 10 gallons worth of driving time).


Consider a better analogy from the provider side:  A customer bakes a 
nice beautiful fruit cake for their Aunt Eddie in wilds of 
Saskatchewan.   The cake is 10 kg - but they want to make sure it gets 
to Eddie properly, so they wrap it in foil, then bubble wrap, then put 
it in a box.  They have this 10kg cake and 1kg of packaging to get it to 
up north.  They then go to the ISP store to get it delivered - and are 
surprised, that to get it there, they have to pay to ship 11kg.  But the 
cake is only 10kg!  If they pay to ship 11kg for a 10kg cake, obviously 
the ISP is trying to screw them. The ISP should deliver the 10kg cake at 
the 10kg rate and eat the cost of the rest - no matter how many kg the 
packaging is or how much space they actually have on the delivery truck.


And then the customer goes to the Internet to decry the nerve of the ISP 
for not explaining the concept of "packaging" up front and in big 
letters.  "Why they should tell you - to ship 10kg, buy 11kg up front!  
Or better yet, they shouldn't calculate the box when weighing for 
shipping! I should pay for the contents and the wrapping, no matter how 
much it is, shouldn't even be considered! It's plain robbery.  Harrumph".


Jeff

On 10/31/2014 6:02 AM, Joe Greco wrote:

That's fine as long as they're giving you a resource that can potentially
transfer the 20Mbps.

That *is* a silly example.

A more proper analogy would be that you buy 12 gallons of gas, but the
station only deposits 11 gallons in your tank because the pumps are
operated by gasoline engines and they feel it is fine to count the
number of gallons pulled out of their tank instead of the amount given
to the customer.


Finding new ways to give the customer less while making it look like more
has a long, proud history, yes.

... JG


--
Jeff Sorrels
Network Administrator
KanREN, Inc
jlsorr...@kanren.net
785-856-9820, #2

looking for clueful mail administrator at Google

2014-10-31 Thread Eliot Lear 
Please contact me offline about a misbehaving filter.



signature.asc
Description: OpenPGP digital signature

RE: Industry standard bandwidth guarantee?

2014-10-31 Thread David Hofstee 
-Oorspronkelijk bericht-
Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Joe Greco
Verzonden: Friday, October 31, 2014 12:02 PM
Aan: Rafael Possamai
CC: keith tokash; nanog@nanog.org
Onderwerp: Re: Industry standard bandwidth guarantee?

...
>> A silly example would be this: you fill your gas tank with 12 gallons...
>> After driving until it's empty, your engine only used an average of 6 
>> gallons to actually move you from point A to point B. The other 6 were 
>> just wasted in form of heat. Do you ask for your money back at the gas 
>> station?
>> Or maybe you invest in a hybrid car?
>
>That *is* a silly example.
>
>A more proper analogy would be that you buy 12 gallons of gas, but the station 
>only deposits 11 gallons in your tank because the 
>pumps are operated by gasoline engines and they feel it is fine to count the 
>number of gallons pulled out of their tank instead of the amount given to the 
>customer.

And bits/s is exactly what you get. With your example: You don't get kilometers 
at the gas stations, you get quantities of gas (e.g. a liter). And depending on 
a lot of factors, you get a distance from that quantity. 





David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

Re: Industry standard bandwidth guarantee?

2014-10-31 Thread Joe Greco 
> Yes, and no.
> 
> If you are a given a limited resource (in this case, a physical port that
> can process no more than 1gbps for example) and your efficiency in
> transferring data over that port is not 100%, the provider itself is not to
> blame. Each and every protocol has limitations, and in this case we are
> talking about payload I guess. What the provider should say is: if you need
> "true" 20mbps, then instead you should contract 20mbps X
> 1+your-payload-process-loss.

That's fine as long as they're giving you a resource that can potentially
transfer the 20Mbps.

> A silly example would be this: you fill your gas tank with 12 gallons...
> After driving until it's empty, your engine only used an average of 6
> gallons to actually move you from point A to point B. The other 6 were just
> wasted in form of heat. Do you ask for your money back at the gas station?
> Or maybe you invest in a hybrid car?

That *is* a silly example.

A more proper analogy would be that you buy 12 gallons of gas, but the
station only deposits 11 gallons in your tank because the pumps are
operated by gasoline engines and they feel it is fine to count the
number of gallons pulled out of their tank instead of the amount given
to the customer.

> Like I mentioned before, this is not unique to networking, it's a broader
> concern in the design of any system or process.

Finding new ways to give the customer less while making it look like more
has a long, proud history, yes.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.