blah » technology

Jeb’s Jobs – Technical Support

bangky — Sun, 23 Aug 2009 07:41:36 +0000

For those geeky enough to remember the BOFH, here’s a modern-day (or Web 2.0 if that’s what you want to call it) variation on the same theme of dispensing evil, catastrophe-inducing advice to mind-numbingly stupid support requests.

Tech Support in the Middle Ages

Youtube before Google

bangky — Mon, 10 Aug 2009 03:53:29 +0000

For all that’s been said about Youtube’s massive content delivery infrastructure (in it’s post Google acquisition days), here’s a light-hearted look at what they were, or might have been like prior to that. From the days of yore when Youtube was still a (relatively) smallish start-up, Serverbeach bids a fond farewell to one of their biggest accounts.

An Identity Crisis at Facebook

bangky — Thu, 09 Apr 2009 03:30:21 +0000

For those of us who are (still) on Facebook, almost all of us that is, the not-so-recent changes in the structure of it’s homepage have probably changed the way we use and think of Facebook, whether we realize it or not.

On the previous change, I got used to it. It was intuitive enough and it served it’s purpose. With the latest makeover a few weeks ago, things have once again changed considerably – for the worse. It’s not about being an old lumbering dinosaur, averse to change and all that. But Facebook appears to have lost it’s core purpose. It’s no longer a bilateral (or multilateral) communication platform, but an up-to-the-minute broadcast platform.

Worse still, what it broadcasts is noise. In engineering speak, the signal-to-noise ratio is hopeless. More often than not, what the home page calls the “News Feed” is filled with updates on who has taken what quiz and what kind of person/animal/car/song the quiz determines the user to be. The quiz application engine is probably a natural evolution of the copy-and-paste quizzes that were once popular a few months back. But what it has evolved into is more of an irritant, akin to a buzzing pesky fly than anything else.

I don’t f**king care! I’m not interested in knowing what kind of car you will drive, what kind of animal suits your personality best, or how and when you’re going to die; at least not when it’s determined by a presumably unintelligent application engine. What I want out of Facebook is a way to catch up with friends whom I don’t get to see often, not the mindless brain-rotting junk that is beginning to resemble what we get on over-the-air television or radio broadcasts.

So let’s get our front row seats while they’re still available and watch Facebook go the way of the Friendster and all other fads that have come and gone before it. Resistance is, and always has been, futile.

29 March 2009

bangky — Sun, 29 Mar 2009 12:17:14 +0000

I was cleaning up and reorganizing some of my things today. So I took the chance to take a few photos of the “after” part of the cleanup. The “before” part is kind of messy so I didn’t bother to take photos.

My Linux Box
Only the top-most box is in use.
It’s an old P4 desktop converted for use as my home file-print-proxy-mail server.
Nothing fancy, it just works.

Do Not Enter
The sign says it all. Don’t attempt to touch my box, open it, or root it.

Cisco 2611
Previously used for NAT, tunnel termination and firewalling, but unable to keep up with my broadband provider’s constant upgrades. Now used for testing and experimental purposes.

The Whole Setup

Received-only Paths in the BGP RIB

bangky — Wed, 11 Mar 2009 04:43:13 +0000

Look at the example output for the show ip bgp command below.

 7606 9837 9837 9837 18250, (Received from a RR-client), (received & used)
   198.32.212.61 (metric 20) from 203.17.96.105 (203.17.101.40)
     Origin IGP, metric 0, localpref 90, valid, internal, best
     Community: 4854:6002
     Originator: 203.17.101.24, Cluster list: 203.17.101.40, 203.17.101.22

 1221 2764 9837 18250, (received-only)
   203.62.252.39 from 203.62.252.39 (203.62.252.39)
     Origin IGP, localpref 100, valid, external

Why has a path with a lower localpref of 90 been installed in the FIB, rather than another path that has a higher localpref of 100. Also, why is the path with a higher localpref marked as “received-only”?

Referring to this, the path in question has been denied by routing policy, but still remains in the RIB due to the enabling of soft-reconfiguration inbound on the router. Due to this setting, routes that have been denied by routing policy will still be stored on the router so as to minimize the impact of disruptions that may occur when the BGP session is cleared or reset. And tada, that’s all there is to this question.

AS 47868 Goes Wild with AS-Prepending

bangky — Sun, 22 Feb 2009 15:26:26 +0000

Early this week a small Czech ISP, SuproNet (AS 47868) started announcing its prefix via a backup transit provider with an extraordinarily large number of AS (autonomous system) prepends, 252 to be exact.

Aside from sounding alarms all over the world with routers logging errors related to maximum AS-path limits, it also ended up triggering a previously unknown bug, crashing routers running a certain firmware from a certain vendor *hint hint*.

So how did this happen? One usually doesn’t go prepending an AS number 252 times.

In IOS configuration, a 4-time AS-path prepend would be configured as such.

     neighbor xx.xx.xx.xx route-map longerisbetter out
     route-map longerisbetter permit 10
       set as-path prepend 47868 47868 47868 47868

So then, a manual 252-time AS-path prepend with the above config would involve a grotesquely long command like this.

       set as-path prepend 47868 47868 47868 47868 47868 47868 47868 47868 47868
       47868 47868 47868 47868 47868 47868 47868 47868 47868.................

Assuming that AS 47868 is run by a group of rational individuals, it doesn’t make sense to configure a 252-time AS-path prepend in such a manner (assuming that they use IOS routers in the first place, which isn’t the case as we’ll see below).

Remember, this is a world where other router vendors, both big and small exist. In this case, AS 47868 was using a router from MicroTik which has a radically different way of configuring AS-path prepends.

On a MicroTik router, AS-path prepending is configured with the command

     bgp-prepend

This takes an integer value between 1 and 16 (i.e. how many times the AS-path should be prepended). Unfortunately, a missing input limit check likely resulted in the router accepting the following command which might have been mistaken by the router operator to mean a single prepend for AS 47868.

     bgp-prepend 47868

Assuming a 8-bit integer is reserved for storing the input value for the bgp-prepend command, the value 47868 might have been stored as 252 (think 47868 mod 256). Does the number 252 sound familiar then?

Yes! It’s precisely the number of AS-path prepends on the prefix originated by AS 47868!

But case closed? Not quite. This incident opens a can of worms which includes questions such as – why did routers from a particular vendor crash upon receiving an extraordinarily long AS-path, what constitutes a operationally reasonable number of AS-path prepends, and what sort of precautions (think maximum AS-path limits) can be applied to prevent future incidents of a similar nature?

Once again, there are few definite answers to these questions. But for now, the Internet moves on.

This post was inspired by this – http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml

Meanwhile

bangky — Wed, 11 Feb 2009 16:28:31 +0000

I’ve been in China for awhile. The past 12 days to be exact.
I’m still pondering on what to write about next, as well as greater questions of where do I go from here.

Meanwhile, I just upgraded to Wordpress 2.7.1 with the automated upgrade tool. It works surprisingly well! Simply enter the FTP parameters (hostname, username, pw) and it upgrades itself nicely. Cool!

Tech Support in the Middle Ages

bangky — Wed, 14 Jan 2009 03:23:31 +0000

In a world where frustrations with technology have become a way of life for many who are unacquainted with the nuances and intricacies (or mundane stupidities) of electronic devices, it’s interesting to imagine how things that we take for granted today might have been viewed very differently several centuries ago.

Welcome to the world of Scroll 2.0.

p.s. I hear that this is much funnier if you understand the Norwegian dialogue.

IPv6 – Failure is an Option?

bangky — Wed, 26 Nov 2008 14:01:54 +0000

Here’s a presentation I stumbled upon yesterday.

Failure is an Option – Geoff Huston at the Australian IPv6 Summit

Aside from the usual presentation (or nagging) on how IPv6 adoption hasn’t taken off as it was planned 10 years ago (the usual diagrams). This presentation discussed something a little different.

What if IPv6 really fails to take off?

Such a hypothesis isn’t necessarily unreasonable as the IPv4 address pool *may* run out by the end of next year – a plausible, though pretty aggressive estimate if there turns out to be a stockpiling frenzy of IPv4 address space. This leaves us with about 300+ days to upgrade the entire Internet to support IPv6 (not including the phasing-out of IPv4).

With so many organizations (not to mention individuals) who have been taught to believe that NAT is a necessary component of any network, it becomes a slightly daunting task to think about how these networks will grasp the notion of globally routable addressing on end-user systems.

Now, what happens then if we manage to deplete the IPv4 address pool before IPv6 can be adopted on a large enough scale?

He mentions the possibility of NAT at the carrier level, which is something that has been mentioned before. With “carrier-grade NAT”, each customer is then limited to a set of port numbers rather than a globally routable IPv4 address. Will this work? Possibly. After all, many technologies today were developed in an era of non-existent end to end connectivity (think of SSL-VPNs, HTTP tunneling, Web 2.0 applications, etc). So it is likely that the “Internet” will continue to work for most people.

*But*, what happens if we adopt such a solution in the long run?

I haven’t been around long enough to have experienced the transition from globally routable host addressing to NAT (yes, I grew up in the era of NAT).

But having grown to appreciate the idea of end-to-end connectivity, I shudder to think about the possible outcomes that will result from the adoption of NAT at the carrier level. If you thought that port-forwarding on your Linksys/Dlink/ router was troublesome enough, think about what would happen when it is your ISP that controls your ability to port-forward.

Yes. The cold, hard, truth is that the short-term marginal benefit of IPv6 does not exceed the cost of upgrading a network to run IPv6. It’s true it would be far easier for an ISP to implement carrier-grade NAT. In fact, that’s what a number of mobile operators are doing to provide IP services over their cellular infrastructure.

But think about it. The long term implications of permanent non-existent end-to-end connectivity are pretty dire. From a home user’s perspective, think about no longer being able to run your favorite file-sharing applications. From an institutional perspective, think about the possibility of being unable to deploy new services without the intervention of your service provider. The list just goes on and on. And it gets scary.

As always, what lies ahead is unknown to us. We can only hope then, that the Internet continues to thrive. Hopefully, there will be a day when we can take end-to-end connectivity over IPv6 for granted, and look back at the past, thinking about how silly it was for us to even think of NAT as a long term solution.

Community DNS

bangky — Sat, 25 Oct 2008 04:37:45 +0000

Here’s an interesting project that makes use of a community of BGP-speaking DNS slave servers to do anycast DNS.

http://www.communitydns.eu

Instead of having to run their own geographically distributed servers and deal with administrative matters like colocation and hardware maintenance, Community DNS relies on its members to run slave servers that run on a customized Linux bootable CD.

Upon setup, these slave servers speak BGP with the hosting member’s routers to announce the anycast prefix. Theoretically, this improves the performance of the DNS service by routing queries to the closest DNS server and also providing plenty of redundancy against Distributed Denial of Service (DDoS) attacks.

For now though, the quantity and location of servers appear to be rather sparse, with most servers clustered around Western Europe and the usual peering points in the US.

http://www.communitydns.eu/map

Like peer-to-peer networks, this will only work if there are sufficient well-distributed nodes on the Internet. Given that they don’t seem to have been around for very long, there’s probably still a long way to go (and grow). Till then, let’s see how this works out.