Multihoming and BGP

I’m looking into the possibility of multi-homed internet connectivity for a client and as usually happens in this sort of situation, I’m learning a whole bunch of new technology. Okay, this isn’t quite new, but it’s something I’ve never dealt with before, so a great learning experience.

There are several ways to multihome, separate from the actual protocols used to do so, amongst which the most important are:

Single Link, Multiple IP address (Spaces)

The host has multiple IP addresses (e.g. 2001:db8::1 and 2001:db8::2 in IPv6), but only one physical upstream link. When the single link fails, connectivity is down for all addresses.

Multiple Interfaces, Single IP address per interface

The host has multiple interfaces and each interface has one, or more, IP addresses. If one of the links fails, then its IP address becomes unreachable, but the other IP addresses will still work. Hosts that have multiple AAAA or A records enabled can then still be reachable at the penalty of having the client program time out and retry on the broken address. Existing connections can’t be taken over by the other interface, as TCP does not support this. To remedy this, one could use SCTP which does allow this situation. However SCTP is not used very much in practice.

Multiple Links, Single IP address (Space)

This is what in general is meant with Multihoming. With the use of a routing protocol, in most cases BGP, the end-site announces this address space to its upstream links. When one of the links fails, the protocol notices this on both sides and traffic is not sent over the failing link any more. Usually this method is used to multihome a site and not for single hosts.

Multiple Links, Multiple IP address (Spaces)

        This approach uses a specialized Link Load Balancer (or WAN Load Balancer) appliance between the firewall and the link routers. No special configuration is required in the ISP’s routers. It allows use of all links at the same time to increase the total available bandwidth and detects link saturation and failures in real time to redirect traffic. Algorithms allow traffic management. Incoming balancing is usually performed with a real time DNS resolution.

        (That’s from Wikipedia, which has a great description on BGP)

        And here a great article on Multihoming and BGP.

        Application Virtualisation

        I came across a great post on Adam Hall’s blog talking about aspects of application virtualisation. I’ve only come across this recently to tell you the truth, with the rollout of SoftGrid here at IOMG, and have been pretty impressed with what the package achieves.

        So what is application virtualisation you may ask? It’s a process by which applications are encapsulated and segregated away from the operating system they are running on. The main advantage of doing this is that it keeps applications and their OS requirements totally seperate and allows you to run applications that may previously have conflicted with one another, or the underlying OS. It also helps an enterprise desktop strategy in that applications are more mobile and a standard desktop is now a possibility. This, coupled with the fact that operating systems are now protected from the applications that run on them, is a pretty compelling story for anyone responsible for more than just a few machines.

        Anyway, back to Adam’s post, he raises some great questions that this strategy needs answering to guarantee the success of the implementation. I’m going to quote them here:

        Can the applications be virtualised. Some things just do not virtualise well. The answer to this will vary dependent on the solution. Softgrid bubbles cannot talk to each other directly, only through the OS. So multiple applications may need to be in the same bubble, which may well defeat the purpose of the Virtualisation in the first place.
        Where do the applications need to run from. On the LAN? Over the Internet? Running under Terminal Services? (Softgrid is as close as I have seen to being a silver bullet for applications under Terminal Services)
        What investment does the customer have in their application packaging and deployment solutions. What is the migration path and cost.

        Some great thoughts there Adam, keep ’em coming!

        Five things SOA vendors are missing

        Excellent post by David Linthicum on Infoworld today talking about 5 things that SOA vendors need to do to get in order to be more successful. If you’re in the SOA space you’ll be able to relate to these points; especially if you’re on the bleeding end of trying to implement a product suite that sounded amazing but is failing to deliver. Here’s his advice to SOA vendors:

        • Make sure your product works
        • Make sure you know what SOA is
        • Get wise about the approach to SOA
        • Don’t sell yourself as “One Stop SOA Shopping”
        • Consider the future

        Irrespective of whether you’re working in the financial markets, life insurance, government or any other organisation trying to implement a Service Oriented Architecture, I’m sure you’ll look at the points above and relate them to experiences you’ve had with vendors … Read the complete post here.

        (Addendum: Dave Rosenburg echos this on his post adding another tip: Get your product into user’s hands. So true: users are the real reason organisations buy these products)

        (also posted on my WorkConnexions blog)

        The Twitter Debate

        There are some interesting conversations on Techmeme at the moment discussing the merits and downfalls of Twitter. It seems to have been sparked off by Twitter falling over during the MacWorld keynote speech and made more public Dave Winer discussing whether Twitter would be more stable if it were decentralised, but there’s a very interesting post by Scott Carp arguing that the real value of Twitter is it’s centralised database that stores the social graph that makes Twitter so compelling. A decentralised service would be no different to the Blogosphere which he describes as “…a loose affiliation that no one owns”. Russell Beatie also adds that a P2P model might suit it better. Pretty healthy debate so far and one that’s quite interesting.

        I’ll be talking about a service soon that works on a decentralised model, but I can’t speak about it right now, so let’s leave it at that.

        Back to Twitter, I agree with Scott above that the real value (to me) of Twitter is the collection of people I follow and conversations I have with them. I didn’t catch on to Twitter straight away, but now, thanks to TwitterFox and other Twitter tools I have amassed, it’s become a pretty good way to keep in touch with news and people .. to an extent that has surpassed my use of RSS to keep up with news and blogs (which is really scary). It has also reduced my IM time to a certain extent, in that it helps me feel connected with people “around” me in a more, albeit in a more voyeristic sense.

        It’s also interesting to see people’s feelings about Twitter. Some people have just accepted it. some totally refuse to embrace it and some claim that it is too geeky. What about you? Do you Twitter? If you do, follow me here.

        It’s an interesting journey .. wonder where it will end up …

        BizTalk 2006 R2 Released

        After month of testing, it’s nice to see that Microsoft have finally pushed BizTalk 2006 R2 out to the world. Here’s the blurb:

        With the introduction of the fifth full version, BizTalk Server 2006 R2 builds upon the Business Process Management and SOA/ESB capabilities in prior releases to help organizations extend core process management technologies even further with new capabilities like native support for Electronic Data Interchange (EDI), AS2 and RFID and close alignment with the releases of 2007 Microsoft Office system and Windows Vista, including key .NET Framework technologies such as Windows Workflow Foundation and Windows Communication Foundation.

        There’s lots of great stuff in there; ever since BizTalk 2004, Microsoft have introduced a new wave of services and application helping to accelerate business development and agility. It’s nice to be working in this space, but it’s very easy to forget what a step-change it is for developers to make the leap from writing applications to delivering services.

        If you want to learn more about how you can leverage Microsoft technology to empower your business, check out, BizTalk for SOA and BizTalk for BPM

        Bringing the Publish-Subscribe to a webpage near you ..

        Google has opened up some new potential in their Gadgets API by allowing gadgets to communicate with one another. As you can imagine gadgets on a page can either be there or not, so communication has to be loosely coupled between the two. They achieve this using a Publish-Subscribe model (pub/sub). Designing gadget topology to use pub/sub implies that gadget don’t “expect” or “require” other gadget to be available on a page, but can function just as well if they are not. It also lends itself to scaling out quite elegantly, as there’s no overhead used for the components to synchronously talk to one another.

        Incidentally, pub/sub is the model that Microsoft BizTalk is built around. It was fairly new to me when BizTalk 2004 first came out, but it’s the first model I look to now. BizTalk operates by using a central MessageBox to store all incoming messaging, then having different endpoints subscribe to types of messages. Again, this makes the architecture highly scalable and robust (albeit not focusing directly on latency). Latency won’t be too much of an issue for Google Gadgets talking to one another though, as things will appear to be happening on screen while the gadgets establish communication with one another.

        Here’s a quick synopsis on how it works (thanks to Google Blogoscoped)

        For instance, you can create two gadgets, A and B, which you will “bind” to each other using the same name “test001”. Then, in the user preferences portion of the XML-based gadget, A contains the parameter publish="true”, making it a publisher gadget. And B will contain the parameter listen="true” and the event on_change="updateMessage”, making it a subscriber gadget.

        If you design Google Gadgets, check out the documentation here

        Fallacies of Distributed Computing

        I came across a Wikipedia page on the Fallacies of Distributed Computing. Read these and tell me if they ring any bells:

        1. The network is reliable.
        2. Latency is zero.
        3. Bandwidth is infinite.
        4. The network is secure.
        5. Topology doesn’t change.
        6. There is one administrator.
        7. Transport cost is zero.
        8. The network is homogeneous.

        Great aren’t they? If you’ve worked in IT for any measuable amount of time, you’re bound to has assumed, or seen someone assume, one of the fallacies above. But they will always come back and haunt you!

        Nigel, one of my colleagues, is a firm believer that things were better in the mainframe days. Things were simpler, more controlled and infintely more reliable. His favourite anecdote recounts a speaker at a conference who went up on stage bouncing a basketball. He compared this to a mainframe, easy to control. He then pulls out a bucket of ping pong balls, throws it into the audience and then asks them how then can control that. It think that comparison is a bit harsh, however, it does outline the non-linearity that distributed computing suffers from when it comes to issues of control, manageability and fault control.

        Personally, I think it’s a matter of market/technology granularity. Yes, a mainframe may seem more dependable, but that’s mainly because you’re dealing with one supplier who? gets called in when there’s an issue. The end-user never sees the individual components that make up a system, it’s a black-box that someone else manages, so yes, it’s surely going to look like an easier environment. Distributed apps are likely to be running on disperate hardware, across multiple operating systems, supplier and supported by different vendors, all with their own support procedures. And this is where non-linearity steps in. In mathematics, a nonlinear system is one whose behavior can’t be expressed as a sum of the behaviors of its parts (or of their multiples.) (more on Wikipedia). The challenge software/system/technical architects? today face is expressing this non-linearity in terms of risk so that the business can understand it. It still is a thorny issue though.

        Do you come across these problems in your day job?