Re: Recommendation on NTP appliances/devices
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. 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 -- ++ytti
Re: Cisco warranty
On 04/04/2014 01:51, Jimmy Hess wrote: On Thu, Apr 3, 2014 at 1:46 PM, Brandon Ewing nicot...@warningg.com 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
RE: BGPMON Alert Questions
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
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: Recommendation on NTP appliances/devices
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: Recommendation on NTP appliances/devices
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
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: BGPMON Alert Questions
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
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: Starting a greenfield carrier backbone network that can scale to national and international service. What would you do?
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 daniel.cromp...@gmail.com http://specialbrands.net/ http://specialbrands.net/ http://specialbrands.net/ http://twitter.com/webhat http://www.facebook.com/webhathttp://plancast.com/webhathttp://www.linkedin.com/in/redhat On 4 April 2014 03:50, Brandon Ross br...@pobox.com 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 one create numerous tier2 regional carriers, and they would feed into an over arching tier1? I'm thinking something like a 501c8
Re: Recommendation on NTP appliances/devices
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: Recommendation on NTP appliances/devices
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: Starting a greenfield carrier backbone network that can scale to national and international service. What would you do?
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: Starting a greenfield carrier backbone network that can scale to national and international service. What would you do?
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: BGPMON Alert Questions
On Fri, Apr 4, 2014 at 1:15 AM, Mark Tinka mark.ti...@seacom.mu 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: BGPMON Alert Questions
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
On Fri, Apr 4, 2014 at 11:17 AM, Sharon Goldberg gol...@cs.bu.edu 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: Recommendation on NTP appliances/devices
Quoting Julien Goodwin na...@studio442.com.au: 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).
Weekly Routing Table Report
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 pfsi...@gmail.com. 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
The 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
BGP Update 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. CommunicationsInternet 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.2%
165 Halsey and Perimeter Security
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
Anternet
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)
