Re: BBC reports Kenya fiber break
A comment on the WSJ storyhttp://online.wsj.com/article/SB10001424052970203833004577249434081658686.htmlcontains a link to a great map. http://www.submarinecablemap.com/ -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: dns and software, was Re: Reliable Cloud host ?
In message CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=uwtlkywudua6...@mail.gmail.com, William Herrin writes: On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews ma...@isc.org wrote: DNS TTL works. =A0Applications that don't honour it arn't a indication th= at it doesn't work. Mark, If three people died and the building burned down then the sprinkler system didn't work. It may have sprayed water, but it didn't *work*. Not enough evidence to say if it worked or not. Sprinkler systems are designed to handle particular classes of fire, not every fire. It is also worth noting that many fire systems are not intended to put out the fire, but to provide warning and then provide an extended window for people to exit the affected building through use of sprinklers and other measures to slow the spread of the fire. As you suggest, most sprinkler systems are not actually designed to be able to completely extinguish fires - but that even applies to fires they are intended to be able to handle. This is a common misunderstanding of the technology. A 0 TTL means use this information for this transaction. We don't tear down TCP sessions on DNS TTL going to zero. If one really want to deprecate addresses we need something a lot more complicated than A and records in the DNS. We need stuff like use this address for new transactions, this address is going away soon, don't use it unless no other works. One also has to use multiple addresses at the same time. This has always been a weakness of the technology and documentation. The common usage scenario of static hosts and merely needing to be able to resolve a hostname to reach the traditional example of a departmental server or something like that is what most code and code examples are intended to tackle; very little of what developers are actually given (in real practical terms) even hints at needing to consider aspects such as TTL or periodically refreshing host-ip mappings, and most of the documentation I've seen fails to discuss the implications of overloading things like TTL for deliberate load-balancing or geo purposes. Shocking it's poorly understood by developers who just want their poor little program to connect over the Internet. It's funny how these two technologies are both often misunderstood. I would not have thought of comparing DNS to fire suppression. :-) ... 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.
Re: BBC reports Kenya fiber break
On Feb 29, 2012, at 3:31 AM, Joly MacFie j...@punkcast.com wrote: A comment on the WSJ storyhttp://online.wsj.com/article/SB10001424052970203833004577249434081658686.htmlcontains a link to a great map. http://www.submarinecablemap.com/ There's about 1/2 a dozen or so known private and government research facilities on Antarctica and I'm surprised to see no fiber end points on that continent? This can't be true. -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: BBC reports Kenya fiber break
Joly MacFie j...@punkcast.com wrote: A comment on the WSJ storyhttp://online.wsj.com/article/SB10001424052970203833004577249434081658686.htmlcontains a link to a great map. http://www.submarinecablemap.com/ I always liked this one, too: http://is.gd/DXcddb (Yes, flash. Still.) -Jan pgp4IKk8HiXGd.pgp Description: PGP signature
Re: BBC reports Kenya fiber break
On Wed, 29 Feb 2012 08:37:40 EST, Rodrick Brown said: There's about 1/2 a dozen or so known private and government research facilities on Antarctica and I'm surprised to see no fiber end points on that continent? This can't be true. Cost-benefit. A dozen sites, each with only 100-200 people, scattered across something a tad bigger than Europe. Even if you *land* a cable (which would be a technical challenge, as there's few places you can land it without having to contend with an ice shelf), the other 11 sites will *still* be so far away that dragging fiber to *there* will be cost-impractical. Especially the ones that are moving because they're actually on glaciers or ice shelves. But hey, if you think you can do it without going broke, go for it. ;) pgpDckbNclw7N.pgp Description: PGP signature
Re: BBC reports Kenya fiber break
On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner strei...@cluebyfour.org wrote: On Wed, 29 Feb 2012, Rodrick Brown wrote: There's about 1/2 a dozen or so known private and government research facilities on Antarctica and I'm surprised to see no fiber end points on that continent? This can't be true. Constantly shifting ice shelves and glaciers make a terrestrial cable landing very difficult to implement on Antarctica. Satellite connectivity is likely the only feasible option. There are very few places in Antarctica that are reliably ice-free enough of the time to make a viable terrestrial landing station. Getting connectivity from the landing station to other places on the continent is another matter altogether. Apparently at least one long fiber pull has been contemplated. http://news.bbc.co.uk/2/hi/sci/tech/2207259.stm (Note : the headline is incorrect - the Internet reached the South Pole in 1994, via satellite, of course : http://www.southpolestation.com/trivia/90s/ftp1.html ) As far as I can tell, this was never done, and the South Pole gets its Internet mostly via TDRSS. http://www.usap.gov/technology/contentHandler.cfm?id=1971 Regards Marshall jms
Re: BBC reports Kenya fiber break
Constantly shifting ice shelves and glaciers make a terrestrial cable landing very difficult to implement on Antarctica. Satellite connectivity is likely the only feasible option. There are very few places in Antarctica that are reliably ice-free enough of the time to make a viable terrestrial landing station. Getting connectivity from the landing station to other places on the continent is another matter altogether. The British Antarctic Survey certainly use (used) satellite: http://www.antarctica.ac.uk/bas_research/techniques/tech7.php They gave a good presentation about it a couple of years ago: http://webmedia.company.ja.net/content/documents/shared/networkshop300310/blake_theuseofnetworksinthepolarregions.pdf Cheers, Rob
Re: dns and software, was Re: Reliable Cloud host ?
On Feb 29, 2012, at 6:18 AM, William Herrin wrote: On Wed, Feb 29, 2012 at 7:57 AM, Joe Greco jgr...@ns.sol.net wrote: In message CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=uwtlkywudua6...@mail.gmail.com, William Herrin writes: On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews ma...@isc.org wrote: DNS TTL works. =A0Applications that don't honour it arn't a indication th= at it doesn't work. Mark, If three people died and the building burned down then the sprinkler system didn't work. It may have sprayed water, but it didn't *work*. Not enough evidence to say if it worked or not. Sprinkler systems are designed to handle particular classes of fire, not every fire. It is also worth noting that many fire systems are not intended to put out the fire, but to provide warning and then provide an extended window for people to exit the affected building through use of sprinklers and other measures to slow the spread of the fire. Hi Joe, The sprinkler system is designed to delay the fire long enough for everyone to safely escape. As a secondary objective, it reduces the fire damage that occurs while waiting for firefighters to arrive and extinguish the fire. If three people died then the system failed. Perhaps the design was inadequate. Perhaps some age-related issue prevented the sprinkler heads from melting. Perhaps someone stacked boxes to the ceiling and it blocked the water. Perhaps the water was shut off and nobody knew it. Perhaps an initial explosion damaged the sprinkler system so it could no longer work effectively. Whatever the exact details, that sprinkler system failed. Bill, you are blaming the sprinkler system for what could, in fact, be not a failure of the sprinkler system, but, of the 3 humans. If they were too intoxicated or stoned to react, for example, the sprinkler system is not to blame. If they were overcome by smoke before the sprinklers went off, that may be a failure of the smoke detectors, but, it is not a failure of the sprinklers. If they were killed or rendered unconsious and/or unresponsive in the preceding explosion you mentioned and did not die in the subsequent fire, then, that is not a failure in the sprinkler system. Whoever you want to blame, DNS TTL dysfunction at the application level is the same way. It's a failed system. With the TTL on an A record set to 60 seconds, you can't change the address attached to the A record and expect that 60 seconds later no one will continue to connect to the old address. Nor 600 seconds later nor 6000 seconds later. The system for renumbering a service of which the TTL setting is a part consistently fails to reliably function in that manner. Yes, the assumption by developers that gni/ghi is a fire-and-forget mechanism and that the data received is static is a failure. It is not a failure of DNS TTL. It is a failure of the application developers that code that way. Further analysis of the underlying causes of that failure to properly understand name resolution technology and the environment in which it operates is left as an exercise for the reader. The fact that people playing interesting games with DNS TTLs don't necessarily understand or well document the situation to raise awareness among application developers could also be argued to be a failure on the part of those people. It is not, in either case, a failure of the technology. One should always call gni/gai in close temporal (and ideally close in the code as well) proximity to calling connect(). Obviously one should call these resolver functions prior to calling connect(). Most example code is designed for short-lived non-recovering flows, so, it's designed along the lines of resolve-(iterate through results calling connect() for each result untill connect() succeeds)-process- close-exit. Examples for persistent connections and/or connections that recover or re-establish after a failure and/or browsers that stay running for a long time and connect to the same system again significantly later are few and far between. As a result, most code doing that ends up being poorly written. Further, DNS performance issues in the past have led developers of such applications to take matters into their own hands to try and improve the performance/behavior of their application in spite of DNS. This is one of the things that led to many of the TTL ignorant application-level DNS caches which you are complaining about. Again, not a failure of DNS technology, but, of the operators of that technology and the developers that tried to compensate for those failures. They introduced a cure that is often worse than the disease. Owen Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Programmers with network engineering skills
Is clearance the problem, or the ability to obtain clearance due to something in their background? If your work requires it, you should have some recourse for applicants to obtain the required clearance, no? My understanding is that while primary and subcontractor companies can put people in the sponsoring organization's clearance granting queue, it takes so long to get someone through the queue that for high-level positions they essentially make having the clearance already a prerequisite. Things have gotten a lot better than they used to be. My understanding is that these days a DoD collateral TS is routinely completed in 6 months. -r
RE: Cisco ME3400
You'll need to use a metroipaccess image on the me3400 if you want more than 2 NNI interfaces. We don't do any triple play or ETTH services so I can't speak on that but as a layer 2 customer prem device for Carrier Ethernet services it works well and it's hard to beat the price. Would have been great if it was MPLS capable at its current price point though! It's functional as a Layer 3 switch but I don't think it is very robust as a router. If you are not married to Cisco, the Brocade CES is worth looking in to. MPLS capable across all Ethernet ports. More expensive though. Andy S -Original Message- From: Ramanpreet Singh [mailto:sikandar.ra...@gmail.com] Sent: Tuesday, February 28, 2012 22:45 To: Holmes,David A Cc: North American Network Operators' Group Subject: Re: Cisco ME3400 Checkout me3600/me3800 ngn metro boxes which supports service level/efp configuration. Also commonly known as cisco's evc infrastructute currently supported on 7600 with es+ cards and asr 9k. I dont think there is any other box from cost prespective which supports most of the desired metro features as me3600/3800 does. On Feb 28, 2012 4:08 PM, Holmes,David A dhol...@mwdh2o.com wrote: Anyone with advice on the ME3400 which some telcos use for Metro Ethernet Forum (MEF) services? Specifically looking for layer2 vs layer 3. At Layer 2 NNI/UNI vs dot1q qinq vs private VLANs. At Layer 3 multiple VRF CE/PE support. Specifically which connectivity options have been found to be most reliable and scalable. This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: dns and software, was Re: Reliable Cloud host ?
On 2/29/2012 1:38 PM, Robert Hajime Lanning wrote: On 02/29/12 10:01, Owen DeLong wrote: Further, DNS performance issues in the past have led developers of such applications to take matters into their own hands to try and improve the performance/behavior of their application in spite of DNS. This is one of the things that led to many of the TTL ignorant application-level DNS caches which you are complaining about. I have found some carriers to run hacked nameservers. Several years ago I was moving a website and found that Cox was overriding the TTL for all www names. At least for their residential customers in Oklahoma. The TTL value our test subject was getting was larger than it had ever been set. Back in the day, the uu.net cache servers where set for 24 hours (can't remember if they claimed it was a performance issue or some other justification). Several other large ISPs of the day also did this, so you typically got the allow 24 hours for full propagation of DNS changes ... response when updating external DNS entries. Nominal best practice is to expect that and to run the service on old and new IPs for at least 24 hours then start doing redirection (where possible by protocol) or stop servicing the protocols on the old IP. I'm sure other providers are doing the same to slow down fast flux entries being used for spam site hosting today. -- --- James M Keller
Re: dns and software, was Re: Reliable Cloud host ?
On Wed, Feb 29, 2012 at 7:57 AM, Joe Greco jgr...@ns.sol.net wrote: In message CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=uwtlkywudua6...@mail.gmail.com, ?William Herrin writes: On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews ma...@isc.org wrote: DNS TTL works. =A0Applications that don't honour it arn't a indication th= at it doesn't work. Mark, If three people died and the building burned down then the sprinkler system didn't work. It may have sprayed water, but it didn't *work*. Not enough evidence to say if it worked or not. ?Sprinkler systems are designed to handle particular classes of fire, not every fire. It is also worth noting that many fire systems are not intended to put out the fire, but to provide warning and then provide an extended window for people to exit the affected building through use of sprinklers and other measures to slow the spread of the fire. Hi Joe, The sprinkler system is designed to delay the fire long enough for everyone to safely escape. Hi Bill, No, the sprinkler system is *intended* to delay the fire long enough for everyone to safely escape, however, in order to accomplish this, the designer chooses from some reasonable options to meet certain goals that are commonly accepted to allow that. For example, the suppression design applied to a multistory dwelling where people live, cook, and sleep is typically different from the single-story light office space. Neither design will be effective against all possible types of fire As a secondary objective, it reduces the fire damage that occurs while waiting for firefighters to arrive and extinguish the fire. If three people died then the system failed. That's silly. The system fails if the system *fails* or doesn't behave as designed. No system is capable of guaranteeing survival. Just yesterday, here in Milwaukee, we had a child killed at a railroad crossing. The crossing was well-marked, with signals and gates. Visibility of approaching trains for close to a mile in either direction. The crew on the train saw him crossing, blew their horn, laid on the emergency brakes. CP Rail inspected the gates and signals for any possible faults, but eyewitness accounts were that the gates and signals were working, and the train made every effort to make itself known. The 11 year old kid had his hood up and earbuds in, and apparently didn't see the signals or look up and down the track before crossing, and for whatever reason, didn't hear the train horn blaring at him. At a certain point, you just can't protect against every possible bad thing that can happen. I have a hard time seeing this as a failure of the railroad's fully functional railroad crossing and related safety mechanisms. The system doesn't guarantee survival. Whoever you want to blame, DNS TTL dysfunction at the application level is the same way. It's a failed system. With the TTL on an A record set to 60 seconds, you can't change the address attached to the A record and expect that 60 seconds later no one will continue to connect to the old address. Nor 600 seconds later nor 6000 seconds later. The system for renumbering a service of which the TTL setting is a part consistently fails to reliably function in that manner. It's a failure because people don't understand the intent of the system, and it is pretty safe to argue that it is a multifaceted failure, due to failures by client implementations, server implementations, sample code, attempts to use the system for things it wasn't meant for, etc. This is by no means limited to TTL; we've screwed up multiple addresses, IPv6 handling, negative caching, um, do I need to go on...? In the specific case of TTL, the problem is made much worse due to the way most client code has hidden this data from developers, so that many developers don't even have any idea that such a thing exists. I'm not sure how to see that a design failure of the TTL mechanism. I don't see developers ignoring DNS and hardcoding IP addresses into code as a failure of the DNS system. I see both as naive implementation errors. The difference with TTL is that the implementation errors are so widespread as to render any sane implementation relatively useless. ... 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.
Re: dns and software, was Re: Reliable Cloud host ?
On Wed, Feb 29, 2012 at 4:02 PM, Joe Greco jgr...@ns.sol.net wrote: In the specific case of TTL, the problem is made much worse due to the way most client code has hidden this data from developers, so that many developers don't even have any idea that such a thing exists. I'm not sure how to see that a design failure of the TTL mechanism. Hi Joe, You shouldn't see that as a design failure of the TTL mechanism. It isn't. It's a failure of the system of which DNS TTL is a component. The TTL component itself was reasonably designed. The failure is likened to installing a well designed sprinkler system (the DNS with a TTL) and then shutting off the water valve (gethostbyname/getaddrinfo). I don't see developers ignoring DNS and hardcoding IP addresses into code as a failure of the DNS system. It isn't. It's a failure of the sockets API design which calls on every application developer to (a) translate the name to a set of addresses with a mechanism that discards the TTL knowledge and (b) implement his own glue between name to address mapping and connect by address. It would be like telling an app developer: here's the ARP function and the SEND function. When you Send to an IP address, make sure you attach the right destination MAC. Of course the app developer gets it wrong most of the time. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Reliable Cloud host ?
HP has built an Openstack based cloud. I got a beta account and things are surprisingly stable. hpcloud dot com On Wed, Feb 29, 2012 at 1:12 PM, Tei oscar.vi...@gmail.com wrote: related to the topic: http://slashdot.org/story/12/02/29/153226/microsofts-azure-cloud-suffers-major-downtime -- -- ℱin del ℳensaje.
Re: WW: Colo Vending Machine
Hi Jon, On Tue, Feb 21, 2012 at 2:34 AM, Jon Lewis jle...@lewis.org wrote: Speaking of that sort of thing, I'd really LOVE if there were a device about the size of a netbook that could be hooked up to otherwise headless machines in colos that would give you keyboard, video mouse. i.e. a folding netbook shaped VGA monitor with USB keyboard and touchpad. I know there are folding rackmount versions of this (i.e. from Dell), but I want something far more portable. Twice in the past month, I'd had to drive 100+ miles to a remote colo and took a full size flat panel monitor and keyboard with me. Has anyone actually built this yet? What about something like this? http://www.comsol.com.au/SL-PCC-01 cheers, Dale
RE: WW: Colo Vending Machine
What about something like this? http://www.comsol.com.au/SL-PCC-01 cheers, Dale Neat. But, apparently comsol does not sell outside of the US.
Re: WW: Colo Vending Machine
G'day Nathan, On Thu, Mar 1, 2012 at 12:53 PM, Nathan Eisenberg nat...@atlasnetworks.us wrote: Neat. But, apparently comsol does not sell outside of the US. I didn't read the entire thread properly before posting my last message (w/ link to Comsol site). Someone else had already posted links to the same device on other sites so I'm sure you could track one down with a bit of digging. cheers, Dale
Re: BBC reports Kenya fiber break
On Feb 29, 2012, at 8:17 AM, Marshall Eubanks wrote: On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner strei...@cluebyfour.org wrote: On Wed, 29 Feb 2012, Rodrick Brown wrote: There's about 1/2 a dozen or so known private and government research facilities on Antarctica and I'm surprised to see no fiber end points on that continent? This can't be true. Constantly shifting ice shelves and glaciers make a terrestrial cable landing very difficult to implement on Antarctica. Satellite connectivity is likely the only feasible option. There are very few places in Antarctica that are reliably ice-free enough of the time to make a viable terrestrial landing station. Getting connectivity from the landing station to other places on the continent is another matter altogether. Apparently at least one long fiber pull has been contemplated. http://news.bbc.co.uk/2/hi/sci/tech/2207259.stm (Note : the headline is incorrect - the Internet reached the South Pole in 1994, via satellite, of course : http://www.southpolestation.com/trivia/90s/ftp1.html ) As far as I can tell, this was never done, and the South Pole gets its Internet mostly via TDRSS. http://www.usap.gov/technology/contentHandler.cfm?id=1971 hmm antartica. that's very interesting place to deploy internet services ;) Regards Marshall
Re: BBC reports Kenya fiber break
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner strei...@cluebyfour.org wrote: On Wed, 29 Feb 2012, Rodrick Brown wrote: There's about 1/2 a dozen or so known private and government research facilities on Antarctica and I'm surprised to see no fiber end points on that continent? This can't be true. Constantly shifting ice shelves and glaciers make a terrestrial cable landing very difficult to implement on Antarctica. Satellite connectivity is likely the only feasible option. There are very few places in Antarctica that are reliably ice-free enough of the time to make a viable terrestrial landing station. Getting connectivity from the landing station to other places on the continent is another matter altogether. There were INOC-DBA phones at several of the Antarctic stations, for quite a few years. We could see connectivity to them go up and down as the satellites rose above the horizon and set again. -Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPTwztAAoJEG+kcEsoi3+HpgwP/2wjrnyjCoBrLgQYC/rsjVYe uE8X9ZcnkAkBYI5Q3Aa3ZeVYNbUaX6OChgnsXlt+1v962Lja+V78QuthVDRCJ1Dp Z5T+XtiIQB4u11lhN55mx8cPXbAKubGCduyCzjBBi+QqE5ayqqCocBHAItxYOMd7 RRS5ijNUKVMtGIWWWHAdMFAdGuy3zOIt/9oWkq9jJo30RJkEVR6pi7b/sGmM7rjX XLVc1RPtCmtDkALohRyQOPrMJ2k7284fJ49t2P2Z/8yBbvJtGRmRBkTiUNis0wtx Ndxed96TaNwwF3snE/zAxu6xCZnjR5trzC586b3ULS2sGSSo2W63AjOqzpMtb8HG /hlK2GuaAe1vy9Qa+6XDwVJZqbkzPKzrNv7A3RjNvFkTapPGwk1FI7SBO46CUqHh y2xED78JrIcoKTbC927eWrrArFGRe4ujx+w2D5enlZJT/vGonDScsE/ISAxITbCx QHbtoAWIjVbraN1UZx+g9hvYOb3AT04zkTImQCj0Kj42COx729WvR7anrkwNNAJV uqQyLK2wyS9ItyG3U54tECeGVeK0nn9Gyuhp9wdIKI4Qs+JHxXb2eHFqzbn9OZHB O7PhbBTW3h+viNUkK2NnoiFbQP3E3ZzzNAKjTN9hWa15uGOKum5xUxSZFCD47BuD J2CjI8dx5PhmLTbcZS4C =M/np -END PGP SIGNATURE-
Re: BBC reports Kenya fiber break
we had an instance of B root there for a season. connectivity was a problem and we pulled the node in 2001. /bill On Wed, Feb 29, 2012 at 09:45:16PM -0800, Bill Woodcock wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner strei...@cluebyfour.org wrote: On Wed, 29 Feb 2012, Rodrick Brown wrote: There's about 1/2 a dozen or so known private and government research facilities on Antarctica and I'm surprised to see no fiber end points on that continent? This can't be true. Constantly shifting ice shelves and glaciers make a terrestrial cable landing very difficult to implement on Antarctica. Satellite connectivity is likely the only feasible option. There are very few places in Antarctica that are reliably ice-free enough of the time to make a viable terrestrial landing station. Getting connectivity from the landing station to other places on the continent is another matter altogether. There were INOC-DBA phones at several of the Antarctic stations, for quite a few years. We could see connectivity to them go up and down as the satellites rose above the horizon and set again. -Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPTwztAAoJEG+kcEsoi3+HpgwP/2wjrnyjCoBrLgQYC/rsjVYe uE8X9ZcnkAkBYI5Q3Aa3ZeVYNbUaX6OChgnsXlt+1v962Lja+V78QuthVDRCJ1Dp Z5T+XtiIQB4u11lhN55mx8cPXbAKubGCduyCzjBBi+QqE5ayqqCocBHAItxYOMd7 RRS5ijNUKVMtGIWWWHAdMFAdGuy3zOIt/9oWkq9jJo30RJkEVR6pi7b/sGmM7rjX XLVc1RPtCmtDkALohRyQOPrMJ2k7284fJ49t2P2Z/8yBbvJtGRmRBkTiUNis0wtx Ndxed96TaNwwF3snE/zAxu6xCZnjR5trzC586b3ULS2sGSSo2W63AjOqzpMtb8HG /hlK2GuaAe1vy9Qa+6XDwVJZqbkzPKzrNv7A3RjNvFkTapPGwk1FI7SBO46CUqHh y2xED78JrIcoKTbC927eWrrArFGRe4ujx+w2D5enlZJT/vGonDScsE/ISAxITbCx QHbtoAWIjVbraN1UZx+g9hvYOb3AT04zkTImQCj0Kj42COx729WvR7anrkwNNAJV uqQyLK2wyS9ItyG3U54tECeGVeK0nn9Gyuhp9wdIKI4Qs+JHxXb2eHFqzbn9OZHB O7PhbBTW3h+viNUkK2NnoiFbQP3E3ZzzNAKjTN9hWa15uGOKum5xUxSZFCD47BuD J2CjI8dx5PhmLTbcZS4C =M/np -END PGP SIGNATURE-
Re: dns and software, was Re: Reliable Cloud host ?
On Mon, Feb 27, 2012 at 10:57 PM, Matt Addison matt.addi...@lists.evilgeni.us wrote: gai/gni do not return TTL values on any platforms I'm aware of, the only way to get TTL currently is to use a non standard resolver (e.g. lwres). The issue is application developers not calling gai every time GAI/GNI do not return TTL values, but this should not be a problem. If they were to return anything, it should not be a TTL, but a time() value, after which the result may no longer be used. One way to achieve that would be for GAI to return an opaque structure that contained the IP and such a value, in a manner consumable by the sockets API, and adjust connect() to return an error if passed a structure containing a ' returned time + TTL' in the past. TTL values are a DNS resolver function; the application consuming the sockets API should not be concerned about details of the DNS protocol. All the application developer should need to know is that you invoke GAI/GNI and wait for a response. Once you have that response, it is permissible to use the value immediately, but you may not store or re-use that value for more than a few seconds. If you require that value again later, then you invoke GAI/GNI again; any caching details are the concern of the resolver library developer who has implemented GAI/GNI. -- -JH
Re: BBC reports Kenya fiber break
On Mar 1, 2012, at 10:12 AM, bmann...@vacation.karoshi.com wrote: we had an instance of B root there for a season. connectivity was a problem and we pulled the node in 2001. /bill You should install it on sattelite dima On Wed, Feb 29, 2012 at 09:45:16PM -0800, Bill Woodcock wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner strei...@cluebyfour.org wrote: On Wed, 29 Feb 2012, Rodrick Brown wrote: There's about 1/2 a dozen or so known private and government research facilities on Antarctica and I'm surprised to see no fiber end points on that continent? This can't be true. Constantly shifting ice shelves and glaciers make a terrestrial cable landing very difficult to implement on Antarctica. Satellite connectivity is likely the only feasible option. There are very few places in Antarctica that are reliably ice-free enough of the time to make a viable terrestrial landing station. Getting connectivity from the landing station to other places on the continent is another matter altogether. There were INOC-DBA phones at several of the Antarctic stations, for quite a few years. We could see connectivity to them go up and down as the satellites rose above the horizon and set again. -Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPTwztAAoJEG+kcEsoi3+HpgwP/2wjrnyjCoBrLgQYC/rsjVYe uE8X9ZcnkAkBYI5Q3Aa3ZeVYNbUaX6OChgnsXlt+1v962Lja+V78QuthVDRCJ1Dp Z5T+XtiIQB4u11lhN55mx8cPXbAKubGCduyCzjBBi+QqE5ayqqCocBHAItxYOMd7 RRS5ijNUKVMtGIWWWHAdMFAdGuy3zOIt/9oWkq9jJo30RJkEVR6pi7b/sGmM7rjX XLVc1RPtCmtDkALohRyQOPrMJ2k7284fJ49t2P2Z/8yBbvJtGRmRBkTiUNis0wtx Ndxed96TaNwwF3snE/zAxu6xCZnjR5trzC586b3ULS2sGSSo2W63AjOqzpMtb8HG /hlK2GuaAe1vy9Qa+6XDwVJZqbkzPKzrNv7A3RjNvFkTapPGwk1FI7SBO46CUqHh y2xED78JrIcoKTbC927eWrrArFGRe4ujx+w2D5enlZJT/vGonDScsE/ISAxITbCx QHbtoAWIjVbraN1UZx+g9hvYOb3AT04zkTImQCj0Kj42COx729WvR7anrkwNNAJV uqQyLK2wyS9ItyG3U54tECeGVeK0nn9Gyuhp9wdIKI4Qs+JHxXb2eHFqzbn9OZHB O7PhbBTW3h+viNUkK2NnoiFbQP3E3ZzzNAKjTN9hWa15uGOKum5xUxSZFCD47BuD J2CjI8dx5PhmLTbcZS4C =M/np -END PGP SIGNATURE-
Switch designed for mirroring tap ports
Hello All, We are looking for a switch or a device that we can use for mirroring tap ports. For example , take a mirror port off of a core router say a 6509, connect it to a port on said device, say port 1. I would like then to be able to mirror port 1 on said device to multiple ports, like port 2 , 3, 4. We have the need to analyze traffic from one port on multiple devices. Seems most switches are limited to mirroring to a max of 1 or 2 ports. Any suggestions would be great. Thanks, Ameen
Re: Reliable Cloud host ?
On Mon, Feb 27, 2012 at 7:03 PM, George Herbert george.herb...@gmail.com wrote: On Mon, Feb 27, 2012 at 3:45 PM, William Herrin b...@herrin.us wrote: universe does $30/mo per customer recover that cost during the useful life of the equipment? As I stated, one can either do it with SANs or with alternate storage. Should not assume Rackspace et. all provide any level of fault tolerance for extraordinary situations such as hardware failure beyond what they have promised or advertised. IaaS provided redundancy is not always necessary, and may be unwanted in various situations due to its cost; single redundancy means a minimum of twice the cost of non-redundant (plus the overhead of failover coordination). With various computing applications it may make a great deal of sense to handle in software -- should a node fail, the software can detect a node failed, eject it, reassign its unfinished work units later. Typical Enterprise level fault tolerant SAN manufacturer prices seen are ~ $12 to $15/GB usable storage, for ~50 IOPS/TB, data mostly at rest, and SAN equipment has a useful lifetime of 5-6 years; a typical 200gb server then exceeds $30/month in intrinsic FT SAN hardware cost. There IS a place for IaaS providers to sell such product, probably at four or five times the $/month for a typical server. Just like there is a place for Network service providers to sell transport and network access products that have redundancy built into the product, such as protected circuits, multiple-port,dual WAN , that can sustain any single router failure, etc. Those network products still can't reliably guarantee 100% uptime for the service. There is a place for IaaS providers to sell products where they do NOT promise a level of reliability/fault tolerance or performance guarantee that requires them to utilize an Enterprise FC SAN or similar solution. Just like there is a place for NSPs to sell transport and network access products that will fail if a single router, card, port fails, or if there is a single fiber break or erroneously unplugged cable. This way the end user can save on their network connectivity costs; a tradeoff based on the impact of the difference between their network with 1% downtime and their network with 0.001% downtime; VERSUS the impact of the cost difference between those two options. End users may also prefer to implement their redundancy through dual-homing via multiple providers. It is very important that the end user and the provider's sales/marketing know exactly which kind of product each offering is. Amazon hit those price points with a custom distributed filesystem that's more akin to the research distributed filesystems than anything Amazon is quite unique; developing a custom distributed filesystem is a rather extraordinary measure, that provides them an advantage when selling certain services. But even EC2 instance storage is not guaranteed.The instance storage is scratch space If your instance becomes degraded, and you need to restart it, what you get is a clean instance, matching the original image. EBS and S3 are another matter. The same provider that offers some 'unprotected' services, may also offer some more expensive storage services that have greater protections. -- -JH
