Re: Anternet

[Christopher Morrow]

On Sat, Apr 5, 2014 at 2:32 AM, Andrew D Kirch  wrote:
> So, if there's more than 4 billion ants... what are they going to do?

there will never be more than 4 billion ants.

> On 4/5/2014 1:44 AM, Larry Sheldon wrote:
>>
>>
>> Offered for your amusement--no followup.
>>
>> http://kottke.org/14/04/the-anternet
>
>
>

Re: Anternet

[Andrew D Kirch]

So, if there's more than 4 billion ants... what are they going to do?

Andrew

On 4/5/2014 1:44 AM, Larry Sheldon wrote:


Offered for your amusement--no followup.

http://kottke.org/14/04/the-anternet

Anternet

[Larry Sheldon]

Offered for your amusement--no followup.

http://kottke.org/14/04/the-anternet
--
Requiescas in pace o email   Two identifying characteristics
of System Administrators:
Ex turpi causa non oritur actio  Infallibility, and the ability to
learn from their mistakes.
  (Adapted from Stephen Pinker)

165 Halsey and Perimeter Security

[Martin Hannigan]

Folks,

Anyone have a contact at Tishman that can help me with perimeter
security concerns at 165 Halsey? The situation in the neighborhood is
currently unsatisfactory (and unsafe) and I'd like to engage the
landlord directly. Currently a tenant of a colo provider, not the
landlord directly.

Ping me offline. Very much appreciated.

Best,

-M<

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 27-Mar-14 -to- 03-Apr-14 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS36998   69594  2.8%  42.5 -- SDN-MOBITEL,SD
 2 - AS982964062  2.6%  63.1 -- BSNL-NIB National Internet 
Backbone,IN
 3 - AS50710   44782  1.8% 199.0 -- EARTHLINK-AS EarthLink Ltd. 
Communications&Internet Services,IQ
 4 - AS29571   39069  1.6% 229.8 -- CITelecom-AS,CI
 5 - AS476129840  1.2%  18.7 -- INDOSAT-INP-AP INDOSAT Internet 
Network Provider,ID
 6 - AS840227088  1.1%  34.9 -- CORBINA-AS OJSC "Vimpelcom",RU
 7 - AS56115   25702  1.0% 428.4 -- NGGL-BD Road 27  House 13  
Block  C2,BD
 8 - AS13118   23248  0.9% 645.8 -- ASN-YARTELECOM OJSC 
Rostelecom,RU
 9 - AS45899   21807  0.9%  59.9 -- VNPT-AS-VN VNPT Corp,VN
10 - AS25184   20942  0.8% 163.6 -- AFRANET AFRANET Co. Tehran, 
Iran,IR
11 - AS41691   20534  0.8% 622.2 -- SUMTEL-AS-RIPE Summa Telecom 
LLC,RU
12 - AS17557   18014  0.7% 173.2 -- PKTELECOM-AS-PK Pakistan 
Telecommunication Company Limited,PK
13 - AS48159   15904  0.6%  88.4 -- TIC-AS Telecommunication 
Infrastructure Company,IR
14 - AS23893   15699  0.6% 402.5 -- BPL-BD House No:03, Road no: 
23/A,BD
15 - AS20450   15632  0.6%7816.0 -- THL16-ASN - Trojan Hosting, 
LLC.,US
16 - AS28573   14381  0.6%   6.1 -- NET Serviços de Comunicação 
S.A.,BR
17 - AS755214172  0.6%  13.3 -- VIETEL-AS-AP Viettel 
Corporation,VN
18 - AS22561   13077  0.5% 108.1 -- AS22561 - CenturyTel Internet 
Holdings, Inc.,US
19 - AS53062   12618  0.5% 332.1 -- G G NET - Telecomunicações LTDA 
EPP,BR
20 - AS58947   12073  0.5%4024.3 -- SOFTWARE-AS-AP Software Shop 
Limited,BD


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS662910353  0.4%   10353.0 -- NOAA-AS - NOAA,US
 2 - AS20450   15632  0.6%7816.0 -- THL16-ASN - Trojan Hosting, 
LLC.,US
 3 - AS181357519  0.3%7519.0 -- BTV BTV Cable television,JP
 4 - AS58947   12073  0.5%4024.3 -- SOFTWARE-AS-AP Software Shop 
Limited,BD
 5 - AS544658600  0.3%2866.7 -- QPM-AS-1 - QuickPlay Media 
Inc.,US
 6 - AS174942585  0.1%2585.0 -- BTTB-AS-AP Telecom Operator & 
Internet Service Provider as well,BD
 7 - AS234662430  0.1%2430.0 -- -Reserved AS-,ZZ
 8 - AS560422711  0.1%1355.5 -- CMNET-SHANXI-AP China Mobile 
communications corporation,CN
 9 - AS31311  0.1%1987.0 -- MIT-GATEWAYS - Massachusetts 
Institute of Technology,US
10 - AS165611977  0.1% 988.5 -- ARIBANETWORK - Ariba 
Technologies, Inc,US
11 - AS22688 896  0.0% 896.0 -- DOLGENCORP - Dollar General 
Corporation,US
12 - AS47714 847  0.0% 847.0 -- DRIESSEN-AS Driessen Aerospace 
Group NV,IT
13 - AS232951677  0.1% 838.5 -- EA-01 - Extend America,US
14 - AS37367 834  0.0% 834.0 -- CALLKEY,KE
15 - AS60345 823  0.0% 823.0 -- NBITI-AS Nahjol Balagheh 
International Research Institution,IR
16 - AS48068 807  0.0% 807.0 -- VISONIC Visonic Ltd,IL
17 - AS14436   11050  0.4% 789.3 -- INTUIT-QDC - Intuit Inc.,US
18 - AS3235 1542  0.1% 771.0 -- GOLDENISP-AS OJSC "Vimpelcom",RU
19 - AS53841 730  0.0% 730.0 -- RAMHOST - RAM Host,US
20 - AS322444269  0.2% 711.5 -- LIQUID-WEB-INC - Liquid Web, 
Inc.,US


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 109.161.64.0/20   22953  0.9%   AS13118 -- ASN-YARTELECOM OJSC 
Rostelecom,RU
 2 - 89.221.206.0/24   20402  0.8%   AS41691 -- SUMTEL-AS-RIPE Summa Telecom 
LLC,RU
 3 - 121.52.144.0/24   18023  0.7%   AS17557 -- PKTELECOM-AS-PK Pakistan 
Telecommunication Company Limited,PK
 AS45773 -- HECPERN-AS-PK PERN AS Content 
Servie Provider, Islamabad, Pakistan,PK
 4 - 192.58.232.0/24   10353  0.4%   AS6629  -- NOAA-AS - NOAA,US
 5 - 78.109.192.0/209893  0.4%   AS25184 -- AFRANET AFRANET Co. Tehran, 
Iran,IR
 6 - 66.210.60.0/24 8988  0.3%   AS20450 -- THL16-ASN - Trojan Hosting, 
LLC.,US
 7 - 206.152.15.0/248596  0.3%   AS54465 -- QPM-AS-1 - QuickPlay Media 
Inc.,US
 8 - 205.247.12.0/247574  0.3%   AS6459  -- TRANSBEAM - I-2000, Inc.,US
 9 - 42.83.48.0/20  7519  0.3%   AS18135 -- BTV BTV Cable television,JP
10 - 65.90.49.0/24  7151  0.3%   AS3356  -- LEVEL3 - Level 3 
Communications, Inc.,US
11 - 74.231.237.0/246644  0.2%   AS20450 -- THL16-ASN - Trojan Hosting, 
LLC.,US
12 - 103.26.138.0/246210  0.2%   AS58947 -- SOFTWARE-AS-AP Software Shop 
Limited,BD
13 - 199.187.118.0/24   6029  0

The Cidr Report

[cidr-report]

This report has been generated at Fri Apr  4 21:13:45 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
28-03-14492834  278076
29-03-14492942  278137
30-03-14493047  278044
31-03-14493219  278056
01-04-14493216  278233
02-04-14493055  278223
03-04-14493267  278669
04-04-14494011  279075


AS Summary
 46697  Number of ASes in routing system
 19082  Number of ASes announcing only one prefix
  3673  Largest number of prefixes announced by an AS
AS28573: NET Serviços de Comunicação S.A.,BR
  119829504  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').

 --- 04Apr14 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 494763   279040   21572343.6%   All ASes

AS28573 3673  360 331390.2%   NET Serviços de Comunicação
   S.A.,BR
AS6389  3004   56 294898.1%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.,US
AS17974 2781  235 254691.5%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia,ID
AS4766  2963  906 205769.4%   KIXS-AS-KR Korea Telecom,KR
AS18881 1923   35 188898.2%   Global Village Telecom,BR
AS1785  2188  473 171578.4%   AS-PAETEC-NET - PaeTec
   Communications, Inc.,US
AS18566 2047  565 148272.4%   MEGAPATH5-US - MegaPath
   Corporation,US
AS36998 1637  166 147189.9%   SDN-MOBITEL,SD
AS4323  2944 1522 142248.3%   TWTC - tw telecom holdings,
   inc.,US
AS10620 2817 1497 132046.9%   Telmex Colombia S.A.,CO
AS7303  1753  458 129573.9%   Telecom Argentina S.A.,AR
AS4755  1844  616 122866.6%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP,IN
AS7545  2231 1087 114451.3%   TPG-INTERNET-AP TPG Telecom
   Limited,AU
AS7552  1224  125 109989.8%   VIETEL-AS-AP Viettel
   Corporation,VN
AS22561 1304  241 106381.5%   AS22561 - CenturyTel Internet
   Holdings, Inc.,US
AS6983  1327  314 101376.3%   ITCDELTA - Earthlink, Inc.,US
AS22773 2413 1427  98640.9%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.,US
AS4808  1365  424  94168.9%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network,CN
AS9829  1618  708  91056.2%   BSNL-NIB National Internet
   Backbone,IN
AS24560 1123  297  82673.6%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services,IN
AS18101  920  165  75582.1%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI,IN
AS8151  1405  658  74753.2%   Uninet S.A. de C.V.,MX
AS7738   914  182  73280.1%   Telemar Norte Leste S.A.,BR
AS701   1482  753  72949.2%   UUNET - MCI Communications
   Services, Inc. d/b/a Verizon
   Business,US
AS855762   57  70592.5%   CANET-ASN-4 - Bell Aliant
   Regional Communications,
   Inc.,CA
AS4788  1014  315  69968.9%   TMNET-AS-AP TM Net, Internet
   Service Provider,MY
AS6147   782  113  66985.5%   Telefonica del Peru S.A.A.,PE
AS4780  1031  367  66464.4%   SEEDNET Digital United Inc.,TW
AS31148 1017

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, 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 05 Apr, 2014

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

Analysis Summary


BGP routing table entries examined:  491178
Prefixes after maximum aggregation:  192805
Deaggregation factor:  2.55
Unique aggregates announced to Internet: 242078
Total ASes present in the Internet Routing Table: 46547
Prefixes per ASN: 10.55
Origin-only ASes present in the Internet Routing Table:   35729
Origin ASes announcing only one prefix:   16379
Transit ASes present in the Internet Routing Table:6052
Transit-only ASes present in the Internet Routing Table:172
Average AS path length visible in the Internet Routing Table:   4.6
Max AS path length visible:  53
Max AS path prepend of ASN ( 50404)  51
Prefixes from unregistered ASNs in the Routing Table:  1892
Unregistered ASNs in the Routing Table: 474
Number of 32-bit ASNs allocated by the RIRs:   6323
Number of 32-bit ASNs visible in the Routing Table:4766
Prefixes from 32-bit ASNs in the Routing Table:   15525
Number of bogon 32-bit ASNs visible in the Routing Table:78
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:446
Number of addresses announced to Internet:   2665473028
Equivalent to 158 /8s, 223 /16s and 228 /24s
Percentage of available address space announced:   72.0
Percentage of allocated address space announced:   72.0
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   96.0
Total number of prefixes smaller than registry allocations:  171352

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   116725
Total APNIC prefixes after maximum aggregation:   34817
APNIC Deaggregation factor:3.35
Prefixes being announced from the APNIC address blocks:  119479
Unique aggregates announced from the APNIC address blocks:49894
APNIC Region origin ASes present in the Internet Routing Table:4915
APNIC Prefixes per ASN:   24.31
APNIC Region origin ASes announcing only one prefix:   1229
APNIC Region transit ASes present in the Internet Routing Table:850
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 25
Number of APNIC region 32-bit ASNs visible in the Routing Table:891
Number of APNIC addresses announced to Internet:  730414720
Equivalent to 43 /8s, 137 /16s and 62 /24s
Percentage of available APNIC address space announced: 85.4

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-63999, 131072-133631
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:167494
Total ARIN prefixes after maximum aggregation:83096
ARIN Deaggregation factor: 2.02
Prefixes being announced from the ARIN address blocks:   168900
Unique aggregates announced from the ARIN address blocks: 78489
ARIN Region origin ASes present in the Internet Routing Table:16209
ARIN Prefixes per ASN: 

Re: Recommendation on NTP appliances/devices

[Dan Drown]

Quoting Julien Goodwin :

Show my anything short of a classic SONET transmission system (or
perhaps sync-E) where you actually have something with jitter that  
low [tens of microseconds].


Since you asked, here you go: http://i.imgur.com/DvMJd5y.png

Two EndRun Unison GPS NTP servers, one in New York metro and one in  
London metro.  They're connected via 10G over dark fiber (along with a  
bunch of networking gear doing more than just measuring time).   
Measurements taken from ntp running on the New York server, the blue  
line is the offset between the two clocks (in ms, left labels) and the  
pink line is the rtt (in ms, right labels).


90th percentile of the offsets is 34 microseconds, and 10th percentile  
is 5 microseconds.


You can see a spike in one-way latency near sample "590".  Most likely  
culprit is of one of the firewalls being busy (there's two in this  
path).

Re: BGPMON Alert Questions

[Sharon Goldberg]

On Fri, Apr 4, 2014 at 11:17 AM, Sharon Goldberg  wrote>
>
>
> Actually, since this is NANOG, might as well ask:
>
> Do you all view filtering your downstream's downstreams as much more
> difficult than filtering only downstreams, or only stub ASes?   Do you have
> a sense for how many networks filter only their direct downstreams but no
> further, versus those that also filter downstreams downstreams?
>

I set up a quick anonymous survey (2 questions) to gather some info on
this.
If you have a minute, go here:

https://docs.google.com/forms/d/1x6Bbe7OYvuWeOzO8xpxbIZzW3N14wI1SVVbQer4FSa4/viewform

We will share our anonymized results on NANOG.

Thanks,
Sharon

Re: BGPMON Alert Questions

[Nick Hilliard]

On 04/04/2014 16:17, Sharon Goldberg wrote:
> we assumed that no one filters their downstreams downstreams.

plenty of organisations do this.  it can easily be done with irrdb AS sets.

Nick

Re: BGPMON Alert Questions

[Sharon Goldberg]

On Fri, Apr 4, 2014 at 1:15 AM, Mark Tinka  wrote:

> On Friday, April 04, 2014 05:06:22 AM Sharon Goldberg wrote:
>
> > We also looked at prefix filtering and found that it has
> > better partial deployment characteristics. Our analysis
> > assumed that ISPs only filter routes from their *stub*
> > customers. (We defined a stub an AS that does not have
> > its own customers.)
>
> Just curious; in your considerations, how would/did you
> treat cases where ISP's filter their downstreams, to include
> their downstream's downstreams?
>

Right, we didn't include that in our analysis because we didn't have a good
sense for how many ISPs actually do filter their downstream downstreams.
So we chose to give a conservative estimate of the impact of prefix
filtering in partial deployment: we assumed that no one filters their
downstreams downstreams.  I'm honestly not sure exactly what including this
assumption would do to our results, except to say that it would make them
better (ie. that more attacks would be stopped).  Might be a good
experiment for one of my summer interns.

Actually, since this is NANOG, might as well ask:

Do you all view filtering your downstream's downstreams as much more
difficult than filtering only downstreams, or only stub ASes?   Do you have
a sense for how many networks filter only their direct downstreams but no
further, versus those that also filter downstreams downstreams?

Sharon

-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe

Re: Starting a greenfield carrier backbone network that can scale to national and international service. What would you do?

[charles]

On 2014-04-04 09:08, Mark Radabaugh wrote:

On 4/3/14, 4:52 PM, char...@thefnf.org wrote:

Hello everyone,

It's been some time since I've been subscribed/replied/posted here (or 
on WISPA for that matter). I've been pretty busy running a non profit 
startup (protip: don't do that. It's really really terrible) :) I'm 
cofounder and CTO of the Free Networking Foundation. Our goal is to 
bring broadband (5 mbps symmetric to start) bandwidth to the 2/3 of 
Americans who currently can't get it (rural, urban core, undeserved, 
"$ILEC stops on otherside of street" etc).



Please feel free to visit us at https://www.thefnf.org for more 
information.



I'm equally confused.   Last mile is much more of a problem than
backbone.


Quite true. This is why we've started there, and it's been our primary 
focus. We have more work to do of course. However efforts are promising 
and ongoing.



 I run a (for a WISP) mid size end user network.  Raw

bandwidth cost is <8% of our expenses.


Nice. That's not horrible. You have an AS/ip space? Or buying blended?

  Last mile delivery and

transport around our own network is the expensive part.


Yes. It certainly is. Gear, end user support, truck rolls etc.



Nearly all of the action in new last mile networks is wireless or
small provider FTTx deployments.   I would look at what WISPA
(www.wispa.org) is doing,


Yes. I'm quite connected with the WISPA folks, especially the 
principals.




as well at the FTTH council

(www.ftthcouncil.com)


Wasn't familiar with them. Thanks!

 to see what is being done in last mile.   The

FCC and Agriculture departments is also heavily involved in rural and
last mile deployments and is (depending on your view) either funding
these deployments, distorting the markets by discouraging private
investment, or wasting lots of money.


Yeah. I've been keeping an eye on that. We've helped several network 
builds happen via grants. Usually from local economic development 
councils.

Re: Starting a greenfield carrier backbone network that can scale to national and international service. What would you do?

[Mark Radabaugh]

On 4/3/14, 4:52 PM, char...@thefnf.org wrote:

Hello everyone,

It's been some time since I've been subscribed/replied/posted here (or 
on WISPA for that matter). I've been pretty busy running a non profit 
startup (protip: don't do that. It's really really terrible) :) I'm 
cofounder and CTO of the Free Networking Foundation. Our goal is to 
bring broadband (5 mbps symmetric to start) bandwidth to the 2/3 of 
Americans who currently can't get it (rural, urban core, undeserved, 
"$ILEC stops on otherside of street" etc).



Please feel free to visit us at https://www.thefnf.org for more 
information.


I'm equally confused.   Last mile is much more of a problem than 
backbone.   I run a (for a WISP) mid size end user network.  Raw 
bandwidth cost is <8% of our expenses.  Last mile delivery and transport 
around our own network is the expensive part.


Nearly all of the action in new last mile networks is wireless or small 
provider FTTx deployments.   I would look at what WISPA (www.wispa.org) 
is doing, as well at the FTTH council (www.ftthcouncil.com) to see what 
is being done in last mile.   The FCC and Agriculture departments is 
also heavily involved in rural and last mile deployments and is 
(depending on your view) either funding these deployments, distorting 
the markets by discouraging private investment, or wasting lots of money.


Mark

--
Mark Radabaugh
Amplex

m...@amplex.net  419.837.5015 x 1021

Re: Recommendation on NTP appliances/devices

[Saku Ytti]

> So what, that sends IP packets, are you using to *measure* it. I can

Agilent if we need unidir. Normal run-of-the-mill 10GE SP router will give you
low single digit microsecond jitter when not congested. (You can run 99.99% no
problem, as long as you don't try >100% (i.e. >1 interface sending)).

We only do bidir for constant measurements of network, unidir is unfortunately
only for troubleshooting case-by-case.
It would be very nice to always have unidir view to the network, but
cost/benefit is not there if you have lot of pops.

-- 
  ++ytti

Re: Recommendation on NTP appliances/devices

[Julien Goodwin]

On 04/04/14 21:48, Saku Ytti wrote:
> On (2014-04-04 20:37 +1100), Julien Goodwin wrote:
> 
>>> Meinberg[0] pegs rubidium at ±8ms per year, if you need NTP to do say single
>>> direction backbone SLA measurement you want to have microsecond precision.
>>
>> Those two statements don't go together.
> 
> Point I was making is that free-running rubidium is not accurate enough for
> QoS measurements of IP core.

Free running oscillators are fine as long as you know what the actual
specs are (and have the unit measured to that).

>> Also outside the HFTers most of us don't care about a few milliseconds
>> (sure an extra 50ms can be a pain, but is trivial to measure).
> 
> Jitter in backbone is low tens of microseconds, if you want to measure how
> that changes over time, free-running rubidium is not going to cut it.

What you'd actually measure is a side affect of buffer depth at any point.

Show my anything short of a classic SONET transmission system (or
perhaps sync-E) where you actually have something with jitter that low.

So what, that sends IP packets, are you using to *measure* it. I can
imagine using an FPGA hard clocked to a reference oscillator (and even a
TCXO is good enough) doing it, but I'm not aware of any actual
implementation of this. Again, short of the HFT world I just can't
imagine how this could actually matter.

Re: Starting a greenfield carrier backbone network that can scale to national and international service. What would you do?

[Daniël W . Crompton]

I recently saw an interesting talk about this at 30c3, this is the way some
French ISPs are solving this:

http://media.ccc.de/browse/congress/2013/30C3_-_5391_-_en_-_saal_6_-_201312291130_-_y_u_no_isp_taking_back_the_net_-_taziden.html

D.


Oplerno is built upon empowering faculty and students

-- 
Daniël W. Crompton 




http://specialbrands.net/

   




On 4 April 2014 03:50, Brandon Ross  wrote:

> Let's start with your basic assumption here.  Why would you build a
> backbone at all if your goal is to solve last mile problems?
>
> It seems to me that the expense and distraction of building a large
> backbone network doesn't contribute to your goals at all, given that there
> are many high quality, nationwide backbone networks in North America today
> available at reasonable cost.
>
>
> On Thu, 3 Apr 2014, char...@thefnf.org wrote:
>
>  Hello everyone,
>>
>> It's been some time since I've been subscribed/replied/posted here (or on
>> WISPA for that matter). I've been pretty busy running a non profit startup
>> (protip: don't do that. It's really really terrible) :) I'm cofounder and
>> CTO of the Free Networking Foundation. Our goal is to bring broadband (5
>> mbps symmetric to start) bandwidth to the 2/3 of Americans who currently
>> can't get it (rural, urban core, undeserved, "$ILEC stops on otherside of
>> street" etc).
>>
>> Efforts so far primarily have consisted of WiFI last (square) mile
>> delivery using Ubiquiti hardware and the qmp.cat firmware (also meraki
>> access points that were donated, for some reason this seems to happen quite
>> a bit). We've helped numerous networks get started, grow and (soon we hope)
>> become self sustaining in Austin, Kansas City, Los Angeles, Detroit, New
>> York and a few other places throughout the US. The networks are in various
>> stages of maturity of course, but a number of them are fully operational
>> and passing real traffic. Especially the one in Kansas City (it spans both
>> states).
>>
>> These are (point to point, routed) access/distribution networks which
>> connect into colocation providers blended networks.
>>
>> So that's the background and current state of affairs. Not really NANOG
>> material.
>>
>> The next step is to secure our v6 space and AS number. Now that's not
>> horribly difficult or really worthy of NANOG (though I do greatly
>> appreciate folks on the list who helped me through the theory/practice of
>> that process sometime ago). It appears to be fairly straightforward if you
>> are not an LIR. Simply go through the paperwork (LOA, submit to ARIN, get
>> out the credit card, textbook BGP config and done). And if FNF was
>> operating the networks (we don't, we just help with
>> organizing/consulting/software guidance/hardware spend
>> optimization/logistics etc) and if there was just one POP (and associated
>> administrative body), then again it wouldn't be that interesting or worth
>> cluttering up NANOG.
>>
>> FNF goal is to serve as an LIR, SWIPing out /48 chunks to neighborhood
>> level operators. They would then peer with whatever upstream ISPs are
>> regionally close and announce out the space. This of course would be
>> associated with a training program, registration in an IPAM tool etc.
>>
>> Regarding the above?
>>
>> What do the operators on this list wish they could of been trained in
>> starting out? I mean obviously they should have good mastery and working
>> experience of CCNA level material, along with exposure to higher level
>> concepts of WAN networking. What are the tricks, the gotchas, the "man that
>> would of saved my company a million bucks in transit costs". Yes I realize
>> these sort of things are usually closely held. I also am striving to create
>> an entirely new breed of operators running BGP enabled sites with ipv6. The
>> more I can do to help ease those folks integration into the internet, the
>> better. In short, the often debated issue on this list of v6 endpoint
>> explosion is going to be very very very real.
>>
>> What IPAM tools out there can scale to a multi hundred million node,
>> distributed, "eventual consistency" national level? (I've been working
>> closely with guifi.net, and we are attempting to relaunch that as a very
>> slick Apple like experience with a libremap (couchdb based) system.
>>
>> I'd love to hear from folks across the spectrum of experience and network
>> size. From folks who have been dual homed for <~1 year at a single site, to
>> tier1 operators who were there when it all started.
>>
>> So what would you like to see done in a greenfield, open source, open
>> governance carrier backbone network? What would a dream TIER1 (and I use
>> that in the default free zone sense of the word) look like to you?
>>
>> Also how the heck would one get this bootstrapped at a sustainable pace?
>> Would o

Re: Recommendation on NTP appliances/devices

[Saku Ytti]

On (2014-04-04 20:37 +1100), Julien Goodwin wrote:

> > Meinberg[0] pegs rubidium at ±8ms per year, if you need NTP to do say single
> > direction backbone SLA measurement you want to have microsecond precision.
> 
> Those two statements don't go together.

Point I was making is that free-running rubidium is not accurate enough for
QoS measurements of IP core.

> Also outside the HFTers most of us don't care about a few milliseconds
> (sure an extra 50ms can be a pain, but is trivial to measure).

Jitter in backbone is low tens of microseconds, if you want to measure how
that changes over time, free-running rubidium is not going to cut it.

-- 
  ++ytti

Re: BGPMON Alert Questions

[Benno Overeinder]

On 04/04/2014 05:06 AM, Sharon Goldberg wrote:
> Finally, like Randy says, RPKI deploys quite different from BGPSEC. My
> intuition says that (1) once the RPKI is fully populated with ROAs for all
> originated prefixes, then (2) a partial deployment of origin validation at
> a few large ISPs should be fairly effective. But I would have to validate
> this with experiments before I can be sure, or say exactly how many ISPs,
> etc.

Indeed.  A MSc. project did a (limited) evaluation measuring the effects
of RPKI route origin validation of a Dutch ISP xs4all which prefixes
where incorrectly injected by another (larger according to CAIDA cone
ranking) European ISP.

With ROAs published and a small percentage (order of 5%) of the largest
ISPs doing route origin validation, this would filter the incorrect
announcement and result in about ~98% globally correct routes in the
35000 ASes (this work is done a couple years ago).  With no route origin
validation (or any other filtering) the percentage of correct routes at
the ASes would be ~25% globally.  Again, this was a specific scenario.

See for results and figures the slides at
http://www.caida.org/workshops/bgp-traceroute/slides/bgp-traceroute1108_rpki_deployment_study.pdf
(slide 18).

Best,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/

Re: Recommendation on NTP appliances/devices

[William F. Maton Sotomayor]

On Thu, 3 Apr 2014, David Hubbard wrote:


Anyone have recommendations on NTP appliances; i.e. make, model, gps vs
cell, etc.?  Roof/outdoor/window access not available.  Would ideally
need to be able to handle bursts of up to a few thousand simultaneous
queries.  Needs IPv6 support.


For some diversity you could try:

- WWVB/CHU radio with a good indoor antenna into an appliance
- CDMA, which yes is based on GPS, but tied with Rb oscillator can carry
  over any reception outages (CDMA or GPS)
- Of course just setup an NTP server that peers to pool.ntp.org
  (but perphaps the least desirable)

I've seen good results using the Endrun CDMA units as well as the
WWVB units, both appliances and IPv6-enabled.  Symmetricom does this too.

wfms

Re: Recommendation on NTP appliances/devices

[Julien Goodwin]

On 04/04/14 10:16, Majdi S. Abbas wrote:
> On Thu, Apr 03, 2014 at 06:55:02PM -0400, David Hubbard wrote:
>> Anyone have recommendations on NTP appliances; i.e. make, model, gps vs
>> cell, etc.?  Roof/outdoor/window access not available.  Would ideally
>> need to be able to handle bursts of up to a few thousand simultaneous
>> queries.  Needs IPv6 support.
> 
>   Without roof access I'd suggest CDMA instead of GPS:
> 
>   http://www.endruntechnologies.com/ntp-server.htm
> 
>   Appears to fit your requirements.
> 
>   --msa
> 

The downside of CDMA is it's going to live until Verizon & Sprint can
get enough of their customers migrated to LTE.

It really depends on how accurate you need to be.

If you only want <10ms accuracy but stable (It's trivial to get all
clients better than 1ms) then grab three to five old servers (or new
low-power ones), and just put ntpd on them, pointing at some nearby
upstreams.

If it *must* be an appliance the Symmetricom units are nice, and support
IPv6 (have done for years).

Re: Recommendation on NTP appliances/devices

[Julien Goodwin]

On 04/04/14 17:29, Saku Ytti wrote:
> On (2014-04-03 21:25 -0700), Will Orton wrote:
> 
>> There are commercially available NTP servers with GPS + Rb oscillators... 
>> for NTP 
>> use you could basically let it sync up a couple days, disconnect the GPS and 
>> let 
>> it freerun. You'd still be within a millisecond of GPS even after a couple 
>> years 
>> most likely. Reconnect it to GPS for a couple days every 1-2 years to resync 
>> it. 
>> More fun and cheaper to build your own I'd bet, if you had the time.
> 
> Meinberg[0] pegs rubidium at ±8ms per year, if you need NTP to do say single
> direction backbone SLA measurement you want to have microsecond precision.

Those two statements don't go together.

Also outside the HFTers most of us don't care about a few milliseconds
(sure an extra 50ms can be a pain, but is trivial to measure).

It's one thing to be a time-nut (I'm certainly one), but recognise that
straight NTP, well deployed, even syncing from the pool is sufficient
for nearly all use cases not needing sub-millisecond precision.

> I think most GPS chipsets today do Glonass also, maybe it's partly because
> Russia has import sanctions for those who don't do, or maybe simply because it
> gives better user experience as sync is found earlier.
> 
> But is there NTP product which you can configure to GPS-only mode or
> Glonass-only mode, which I think might be closer to Rob's idea of redundancy.
> As if you use both, 'poisoned' source would break all of your kit.
> But that is probably not easy to solve with two sources, if half is GPS and
> half is Glonass, and Glonass starts sending bad timing information, what do
> your NTP clients do, average to the middle?
> 
> [0] http://www.meinbergglobal.com/english/specs/gpsopt.htm
> 

Re: Cisco warranty

[Simon Lockhart]

On Fri Apr 04, 2014 at 09:42:29AM +0200, Laurent CARON wrote:
> My device is indeed supposedly covered by a lifetime warranty. Since I'm 
> still in the timeframe of less than 5 years after EOS...it should be 
> good...should.

The *Limited* Lifetime Warranty is only offered to the original purchaser of
the equipment from Cisco. If you're registered with Cisco as the purchaser,
there's no reason they wouldn't honour it. If you're not, because the person
you bought it off is registered as the original purchaser, then you'd need to
go through that person/company to get the warranty from Cisco.

Simon

RE: BGPMON Alert Questions

[Vitkovský Adam]

> That Upstream B is simply "accepting everything"
> their customer is sending to them without applying proper filters, or checking
> to confirm that what their customer needs to send them should come from
> them is absolutely and unacceptably shocking!

I wonder when (or if ever) we'll have such a discussion about data packets, 
i.e. finding that someone is not doing packet-filtering based on BGP updates is 
absolutely and unacceptably shocking! 

adam

Re: Cisco warranty

[Laurent CARON]

On 04/04/2014 01:51, Jimmy Hess wrote:

On Thu, Apr 3, 2014 at 1:46 PM, Brandon Ewing  wrote:


On Thu, Apr 03, 2014 at 01:26:58PM -0400, Michael Brown wrote:

Did you purchase SMARTnet when you bought the device? If you didn't,
you're probably SOL.

This is not true.  Cisco provides a limited lifetime warranty on hardware
purchased from them or an authorized reseller, with our without SmartNet.



On some:  not all their hardware, they offer limited lifetime warranty.
Lifetime is the exception to the rule: many of their components are 90 days
or 1 year.
The "limited" bit is also important --- they have restrictions in fine
print.

It's strongly recommended you buy their SmartNet, if you want their reps to
treat you reasonably and make efforts to fulfill your paper warranty.
Getting the manufacturer rep to actually honor the paper warranty and allow
you an RMA, when there is no paid support is another thing altogether.

May require a great deal of persistence on your part,
As in continuing to contact Cisco and refusing to take "NO" as an
acceptable answer to your RMA request.

Or it may just not happen


My device is indeed supposedly covered by a lifetime warranty. Since I'm 
still in the timeframe of less than 5 years after EOS...it should be 
good...should.


Never experienced such a bad service from Juniper or 3COM/H3C/HP