09 January 2015

Workflow: git-Gerrit to bzr-Launchpad

I'm coming from a world of git and Gerrit to one of Bazaar (bzr) and Launchpad. Both sets of tools will, no doubt, do the job, and I hope to be able to translate my workflow from one to the other.

git and Gerrit

Here's a rough outline of what I would do with git and Gerrit:

# get a local repo down from gerrit
git clone ${UPSTREAM}/${REPO}
cd $REPO
git review -s

# work on a feature branch
git checkout -b $FEATURE
    hack and test...
git diff
git commit -a -m "Added $FEATURE"
    hack and test...
git commit --amend -a -m "Added $FEATURE"

# merge any changes in master to our feature
git checkout master
git pull
git checkout $FEATURE
git rebase master  # let's assume no conflicts

# push our new feature for review
git review
    In the Gerrit web app, others probably need to review and merge the change.

# update our local master with newly merged feature from Gerrit
git checkout master
git pull

# tidy up
git branch -D $FEATURE


bzr and Launchpad

Bazaar uses some similar concepts and commands, but is different enough to confuse, on first attempt.

  • Where git branches are cheap and easy references to specific commits within a repository, in Bazaar they seem to be analogous to a git repository itself, as the stand alone, fundamental unit
  • Where a developer in a Gerrit-based team may have multiple local git feature branches, each with a review waiting on the Gerrit server, Launchpad users may have several local bzr feature branches, but seem to limit themselves to a single personal branch in Launchpad, from which they make merge proposals (analogous to Gerrit reviews) against the team branch


Now the bzr and Launchpad equivalent of the workflow above:

# get a local branch down from lp:~teamname/projectname/branchname
bzr branch ${UPSTREAM}/{$BRANCH}

# work on a feature branch
bzr branch $BRANCH ${BRANCH}-${FEATURE}
cd ${BRANCH}-${FEATURE}
    hack and test...
bzr diff
bzr commit -m "Added $FEATURE"

# merge any changes in trunk to our feature
cd ../${BRANCH}
bzr pull
cd ../${BRANCH}-${FEATURE}
bzr merge ../${BRANCH}
bzr conflicts  # let's assume none
bzr commit -m "Merge from upstream $BRANCH"

# push our new feature for review to our personal branch
lp:~username/projectname/branchname
bzr push ${PERSONAL}/${BRANCH}
    In the Launchpad web app, raise a merge proposal to have this personal branch merged into the team trunk branch. Others then need to review and approve the MP.

# reviewer should probably do this
# update our local trunk with the feature
cd ../${BRANCH}
bzr merge ${PERSONAL}/${BRANCH}
bzr commit -m "Merged branch for $FEATURE"

# push up to remote trunk
bzr push

# tidy up
rm -rf ../${BRANCH}-${FEATURE}


Further Reading and References


  • https://wiki.openstack.org/wiki/Gerrit_Workflow
  • http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html
  • http://doc.bazaar.canonical.com/latest/en/tutorials/using_bazaar_with_launchpad.html


05 June 2014

Multi-node OpenStack Icehouse with Neutron

https://github.com/macgreagoir/gobstack

In the course of my work for one of the big corporate OpenStack public cloud providers and contributors, I've written a couple of OpenStack installation systems for my own testing and learning, and to provide development environments internally.

gobstack is one such project. It uses Vagrant and Virtualbox to provision multiple nodes, similar to what one might see in a production environment. The 'private cloud' runs successfully on my Debian laptop with 8GB RAM, and is able to boot an instance on each compute node.

Keystone, Glance, Nova, Swift, Cinder and Neutron are all installed across the various nodes, and the 29 April 2014 commit brings the project up to Icehouse.

The installer scripts themselves will work on real hardware too.

02 May 2013

mickgregg.com

Not being on LinkedIn anymore, I thought I should post some kind of online CV, so here it is: mickgregg.com

05 February 2013

Install Oracle Java 6 on Debian Wheezy with update-alternatives

Why Would I Want to do That!

I should open this with a statement about why I generally dislike Java as a web technology, in the hope that the sites forcing me to install this software stop using it. I should then make an apology for using the Oracle implementation of Java over some more open project. I'll do neither.

Because there's a well founded scare around the use of Java plugins in web browsers, and because some sites I must use consequently force the use of the most recent Oracle Java, I've installed jdk-6u39-linux-i586.bin from Oracle in a virtual machine, itself using Debian Wheezy.

Quick Procedure


  1. Get the binary installer from Oracle. I'll not link here; it'll probably change anyway
  2. $ chmod 0750 /place/where/downloaded/file/is/jdk-6u39-linux-i586.bin
  3. Get root
  4. # cd /usr/lib/jvm
  5. # /place/where/downloaded/file/is/jdk-6u39-linux-i586.bin
  6. # for j in java javac javaws javadoc javah javap; do update-alternatives --install "/usr/bin/$j" "$j" "/usr/lib/jvm/jdk1.6.0_39/bin/$j" 1066; done
  7. # update-alternatives --config java
  8. # update-alternatives --config javac
  9. # update-alternatives --config javaws
  10. # update-alternatives --install "/usr/lib/mozilla/plugins/libjavaplugin.so" "mozilla-javaplugin.so" "/usr/lib/jvm/jdk1.6.0_39/jre/lib/i386/libnpjp2.so" 1066
  11. # update-alternatives --config mozilla-javaplugin.so


Quick Explanation


  1. Download and install Oracle's JDK to /usr/lib/jvm/jdk1.6.0_39
  2. Let your system know about the new Java alternatives it can use, using `update-alternatives --install`
    1. I've used priority 1066 to set it higher than the OpenJDK packages I already had installed
  3. Set your system to use the new alternatives, including the Java web browser plugin, using `update-alternatives --configure`
    1. `update-alternatives --config java` prompts for which alternative you'd like to use. Pick the number for the Oracle version, if it's not already selected
    2. I've shown java, javac, and javaws above, but I also set javadoc, javah and javap

Test

  • $ java -version
  • Open your browser and check that it has the new Java plugin loaded
    • about:plugins in Iceweasel, for example
  • Go to an offending web site and be happy that it now works, as you curse them for using Java in the first place


11 June 2007

Book Critique: In the Beginning was the Command Line.

BCIS301-07A Book Critique

In the Beginning was the Command Line
Neal Stephenson (1999)

Critique by Mick Gregg
For Trevor Nesbit, Christchurch Polytechnic Institute of Technology

24 May 2007

Introduction
The story goes that Neal Stephenson originally started to write In the Beginning was the Command Line as an article (1) on slashdot (http://slashdot.org), but that it bloomed into a full manifesto of how he saw the then state of computing for the masses. 'Then' was 1999 when the desktop world was divided between Windows9x/NT and the pre-UNIX Mac OS, BeOS was alive and the age of Linux was still in single digits. What Stephenson wanted to tell the world was that since the days when he learned programming on a teletype across a modem to a mainframe, the power and workings of computers have been abstracted away from users for the sake of expediency and commercialisation, in the form of the Graphical User Interface (GUI). We are told that this disconnection allowed the businesses involved in operating systems and computer hardware - namely Microsoft and Apple - to dictate the terms of our relationship with technology, and for a few experts in the field to become dangerously powerful in a world where users are educated to expect only the most simple of choices.

While In the Beginning focusses on the importance of computing, Stephenson is happy to cite examples of the ills he perceives from the world outside as well, hinting that the Land of Operating Systems is really a microcosm of the Developed World. Stephenson sees a world pacified by "moral relativism" and a "global monoculture" that has "done away with the ability to make judgements". He concludes that, "It simply is the case that we are way too busy, nowadays, to comprehend everything in detail. And it's better to comprehend it dimly, through an interface, than not at all." For the computer specialist and the casual user alike, this may be an epiphany revealing why philosophies within the IT world, not just trends and prices, need to be firmly in the minds of decision makers.

Summary
The relatively recent history of electronic computing means that many formative protagonists are alive and well, many commentators have been involved since what they perceive to be day zero, and opinions haven't yet been muted and dulled by the parity-of-blame technique that makes academic historical study appear to be unbiased. Stephenson is one of these commentators and In the Beginning was the Command Line is all about having an opinion and taking a side, opening with a brief history of computing from his driver's seat. He begins as a schoolboy on a teletype and explains how he was using an interface that had existed for a century before to send commands to a distant mainframe, the move from paper output to a glass monitor, and the shift from batch processing to a real-time command line. For him, the GUI came about in 1984 when he began what he calls his "personal love affair with the Macintosh", and he acknowledges that providing a simplified interface to the computer through the GUI opened a newly created market to a new kind of computer user. He defines the end of the GUI debate as the point when Microsoft eventually adopted one as well, albeit as a layer on top of MS-DOS, and goes on to explain the "interface culture" that requires so many things to have a simplified GUI, abstracting technicalities below, so that users never have to properly learn and instead leave the hard stuff to an adept minority.

Stephenson draws parallels from the world outside computing to demonstrate that this hands-off culture is endemic in America, with the abandonment of command line interaction presented as both a symptom and cause of an apathetic and disengaged psyche of life through controlled voyeurism. More than extrapolating the fraudulence of GUI-based interaction to prove the cynicism of the industrial elite, Stephenson sees the GUI as an example of the consumer's general desire to ignore anything not filtered to him, through a medium designed and controlled by an entity that he may have erroneously placed his trust in, to avoid the need to personally judge and decide.

By now Stephenson has already described the OS choices of 1999 with car metaphors, so we know that Macs are stylish sedans with sealed bonnets, Windows is an over-priced, but hugely popular family station wagon, BeOS a Batmobile and Linux a free tank. It's no surprise then that he introduces the latter two with enthusiasm as he documents his move back to the command line after losing faith in his GUI-only Mac. He wanted to pop the bonnet again, and revels in the open source culture of hands-on computing, open bug-tracking and technical freedom. This may well be the point at which Stephenson suddenly looked back and saw the years of encroaching abstraction and consequently declining user abilities and waning understanding.

That the least technically sound OS options have become the most expensive and most popular is explained as a result of the historical business decisions of Apple and Microsoft to become hardware and software manufacturers respectively, and their need to swaddle their products, obfuscating their workings to create something salable. However, Stephenson surmises that Apple, as a hardware company, will lose out to the open architecture hardware that MS Windows runs on, and that Microsoft will lose out to Linux because operating systems are naturally required to be free (as in freedom). With optimism that a new age is beginning, where users demand openness and embrace the available power of Batmobiles and free tanks, Stephenson closes with a succinct summary of his position, that "if you don't like having choices made for you, you should start making your own."

Critique
It needs to be understood from the outset that Neal Stephenson isn't presenting In the Beginning as a history of modern computing, a technical guide to Linux or even an expostulation for the use of open source software. Instead it's a very personal account of his own experience of computing and how he sees this discipline going wrong. As such he makes, and is required to make, no effort to prove his case by citation and instead relies on the reader's trust in his authority and understanding of his logic to be persuaded. For example, he makes no mention of the invention of the GUI paradigm at Xerox PARC. This doesn't alter his argument, and he doesn't explicitly and incorrectly credit Apple with the first GUI, he simply mentions the Macintosh as his first encounter with it.

His anecdotal sampling of readily identifiable examples from the non-computing world illustrates his belief in the systematic decline of modern consumers' ability to think for themselves. The popularity of fake Disney-style worlds in preference to adventure travel, and factory souvenirs over genuine African art is used as an argument to prove a craving for "mediated experiences", which Stephenson likens to the desire to be coddled by a GUI. He also introduces HG Wells' Morlocks and Eloi to explain the relationship between technical workhorses and aloof users, highlighting the perversity that the latter are in the majority in contrast to the original Wellsian world. Then there's the Hole Hawg, a monster power drill that makes all others pale by comparison, used to represent UNIX. Like a populist politician, Stephenson isn't trying to complicate his arguments with exhaustive research or endless historical examples, he simply uses an easily imagined occurrence to illustrate what he's sure is a general point.

The Interface Culture chapter is particularly beautiful; a poignantly personal article in its own right during which Stephenson reveals the nucleus of his distaste for the effete and facile society he sees evolving. He gives himself room to explain the failings as he sees them, before logically tying the development of "feckless human being[s]" to the GUI-driven world where Morlocks present Eloi with only the most simple of choices. It's in this chapter that Stephenson's need for command line interaction is indelibly linked to the world at large, but he lightens what could degenerate into a diatribe by clearly conceding the misery associated with the Platonic rule of intellectuals.

Stephenson also spends a full, and relatively long, chapter looking into the contrasting ways in which the commercial marketing machines and open communities deal with bugs. This should be essential reading for every Microsoft software user, not because great hordes of Eloi will want to read technical documentation about the shortcomings of their tools, or to shock them with the abundant faults in the kit they've so expensively licensed. This chapter should be read to force users to accept that a company that wants to sell them something is going to lie to them about its product's quality, while a community that wants help to build something needs an honest exchange of findings. Again, Stephenson doesn't see a need to cite published evidence of his position, he gives us some examples from his personal experience and asserts that, "Joint stock corporations ... are good at many things. Admitting failure is not one of them."

It's probably fair to say that Stephenson has no great love of MS Windows and wouldn't encourage its use by Eloi or Morlock, but he is no stereotypical Microsoft-basher either. He seems to like the behemoth's application software and predicts, or at least hopes for, the day when this becomes its focus, leaving operating systems to those who make them truly open. As with his care not to deride corporations in general, this might be an attempt to appear balanced, but is more likely a piece of genuine praise, since Stephenson doesn't seem generally concerned to court favour from anyone, the reader included. His prediction that Apple's attempt to create a hardware monopoly and Microsoft's reliance on selling operating systems as its core business would eventually be their undoing has logic, and some of us live in hope, but to date these companies are still succeeding without changing these strategies.

In the Beginning is great reading for the anti-capitalist, Linux-using Morlock, and is probably as good for those who score two out of those three, but Stephenson isn't just trying to preach to the converted. Constantly stepping outside the computing world and directly using metaphors like the already mentioned OS-as-car, combined with Stephenson's personal narrative, makes the philosophy that he expounds not only understandable to non-technicals but also applicable to the modern consumer world in general. He acknowledges that he could be seen as a "snotty intellectual throwing a tantrum", but at the same time explains the need, as he sees it, for his personal world-view to be understood before the cultural aspect of Microsoft and Apple domination can be made sense of. He's not a political revolutionary and isn't calling for the overthrow of the world as we know it, but attempts in this book to open the eyes of the docile majority to the need he sees for hands on interaction in place of passive compliance.

In keeping with the informality and evangelism of the essay, the complete text is offered online to be freely downloaded (2). It comes in this form as an ASCII text file, archived in both Windows and Mac OS formats, leaving no excuse for the online community to ignore it.

Conclusion
In the Beginning was the Command Line is a manifesto. It's a line in the sand that Neal Stephenson drew in 1999, asking his readers to join him in as a Morlock or condemn themselves to sheepish Eloism. His position is simply that as consumers, modern westerners have become accustomed to, and even demand, that their interactions with the world be filtered through some kind of interface that reduces the need for them to think or judge or experience life for themselves, and that their decisions are increasingly made for them in advance by detached technocrats. Stephenson sees an escape from this by a move back to the command line; literally in the OS world and as a metaphor for direct interaction.

Linux and BeOS are discussed as the panacea to the commercially controlled and cynically protected operating system industry of 1999. The user's return to the command line will begin his journey to real involvement and understanding, and exemplify the failure of Microsoft and Apple to cage what should naturally be free and simplify what is intrinsically complex.

The circumstances have only slightly changed since then, with Apple embracing UNIX and once more endearing itself to Stephenson (3), as well as reviving its fortunes with the iPod portable music player. Just as Apple repackaged the Xerox GUI and sold it as its own, it now has a whole new market of consumers that thinks it invented the Walkman. The hardware company hasn't yet met its demise, neither has MS Windows yet lost its mass appeal, and BeOS is dead - though its fans may enjoy Haiku (http://haiku-os.org). The age of open source operating systems naturally replacing the incumbent closed ones hasn't dawned, but Linux has steadily increased in popularity, with even Michael Dell in its user base (4) and Dell itself about to launch a range of PCs with Ubuntu Linux pre-installed (5). Apple came to the command line party late and shunned Linux for a UNIX variant that it could still hide the code for, but it exploits plenty of open source projects - including Apache, OpenLDAP, Samba and Postfix - that allow users to dirty their hands beneath the GUI.

One day readers might regard In the Beginning as an historic document from a time before users wised-up to the need to educate themselves about the technologies that were running their lives, when point-and-click technicians called themselves Systems Engineers, and when the need for a company in Seattle to generate some cash for shareholders pushed worthless face-lifts onto any business that needed to buy a new PC, but the only alternative they could think of was an expensive, pretty toy for 'creatives'. That day hasn't come, but it still might and this gives continuing value to Neal Stephenson's 1999 commentary. Government policy makers and university strategists (assuming that these groups are independent of commerce) should read it so that business leaders, who don't care anyway, might one day at least be influenced by it by proxy. Stephenson's Eloi should read it and take time to assess who is directing their lives, and his Morlocks and would-be Morlocks should read it to grasp the importance of philosophy and policy in technology. What Stephenson reminds us is that as a society swamped in a culture of marketing-driven pseudo expertise and half-understood buzzwords, where brand familiarity replaces true comprehension and homogeneous thought is the profiteer's nirvana, it's up to those who call themselves experts and professionals to truly be such, and to provide real leadership in their domains. Exclusively learning the methodology and product range of one entity, no matter its market dominance, is, far from education, nothing more than a branch of consumerism.

Neal Stephenson paints a sobering picture of a user booting a machine to see a single button labelled 'LIVE' as the ultimate expression of a culture of deference. We're nearly there, but there is still time to pull back from the brink.


References
1. I haven't found the alleged original slashdot article. Though it is often referenced in forums about this book, it may be a piece of 'Net mythology.

2. Neal Stephenson (1999). In the beginning was the command line. Retrieved on 27 March 2007 from http://www.cryptonomicon.com/beginning.html

3. Neal Stephenson responds with wit and humour (20 October 2004). Retrieved on 27 March 2007 from http://interviews.slashdot.org/article.pl?sid=04/10/20/1518217

4. Michael's computers (2007). Retrieved on 17 May 2007 from http://www1.ap.dell.com/content/topics/global.aspx/corp/biographies/en/msd_computers

5. Dell to offer Ubuntu 7.04 (1 May 2007). Retrieved on 17 May 2007 from http://direct2dell.com/one2one/archive/2007/05/01/13147.aspx

03 May 2007

Is there a F/LOSS alternative to Cisco network routers?

Is there a F/LOSS alternative to Cisco network routers?

Mick Gregg, 2007-05-03

Contents
Terms of Reference
Executive Summary
Introduction
Hardware
Software
Configuration
Conclusion
End Notes

Terms of Reference
This report makes up the final assessment for my CPIT BCCS391 course, Contemporary Issues in ICT. It has been prepared for Dr Mike Lance at CPIT, being due 3 May 2007. The research I've done has been to answer the question of whether Free/Libre Open Source Software (F/LOSS) provides products that are able to equally compete with Cisco, the network device software and hardware manufacturer and market leader in network routers. The scope has been limited to a particular New Zealand market segment occupied by what I deem to be SME central LAN routers. I have not tried to prove that Cisco or F/LOSS offerings in this segment are good or bad, but have tried to assess whether and how they are comparable, working from the assumption that competition is good for innovation and price, and provides IT decision makers with choice. Part of the comparison is in the relative difficulty of configuration for administrators and of learning administrative skills on the different systems.

Executive Summary
By comparing the Cisco 2821, Vyatta F/LOSS-based appliance and Quagga project, and how they could be used as a central router in a New Zealand SME LAN, I attempted to answer whether there exists today a real F/LOSS alternative to Cisco in the network router market. After reviewing the abilities of the three options, interviewing experts and analysing third-party reports, I suggest that the Vyatta appliance is a directly comparable router appliance, and deserves to be assessed against, the Cisco 2821. Further, I believe that the open source routing projects I looked into provide readily available and free tools to learn network routing skills with, and that skills learned on either Cisco IOS, Vyatta OFR or Quagga are largely transferable to each other.

Introduction

One of the most important threads of 21st Century computing has been the rise of Free/Libre Open Source Software (F/LOSS) - described by the GNU General Public License1 from the Free Software Foundation, for example - which provides for the freedom of end users and programmers to dissect, alter and redistribute software according to their own needs and interests. The condition of this freedom is that they must in turn release their own modifications to GPL software under the GPL if they want to redistribute it.

With major commercial backing from companies like IBM and HP, F/LOSS lead by Linux provides strong and real competition to UNIX and Windows. While still a comparatively small player in the enterprise LAN server market, Linux does compete well with Windows and provides a much needed alternative in a sphere dominated by a single commercial entity. IT decision makers have a real option to consider and good IT departments should be able to use this to their advantage.

This is all well and good for servers, but a major expense in many company networks, and across the Internet as a whole, is in the high quality routers that make large LANs, WANs and inter-networking possible. Cisco (http://cisco.com ) got in very early in this market, became the best known name as a result and probably enjoys some sales that, as with any market leader, come from the buyer's comfort in choosing a leading brand. Also in line with common commercial practices, Cisco, having such a well known name, uses its name to add a premium to its prices. The question is, does the product that attracts such a brand loyalty have the quality that its price implies?

I have a real, personal interest in this question. I've successfully replaced many Windows file and print servers with Samba, setup VPNs with Openswan, and developed and hosted enterprise web applications in PHP and PostgreSQL, all on Linux-based operating systems. Despite this, I've never had the courage to go past a Cisco router in the middle of my LAN, simply because I've never been sure what the comparative quality of the F/LOSS alternatives are, and have instead trusted the blackbox of a Cisco router. As far as I've been aware, the Cisco router is good at its job, has the WAN interfaces I've wanted and has been recommended to me by the experts, so I've consequently released large chunks of my IT budget for my own peace of mind. Now, in glorious hindsight, I'll find out whether I was a wise purchaser or paid dollars, Euros and Pounds for my ignorance.

Because of this personal interest, and because I necessarily needed to limit the scope of my research into what is a very broad product range, I chose to focus on what I consider to be a typical requirement for a New Zealand SME; the central, main router in its LAN. Somewhere in my typical Kiwi SME's infrastructure, locked away in an air-conditioned server room or sweating in a dusty cupboard, sits this busy wee routing device, segmenting the LAN, connecting to the outside world and working to send network traffic to where it should be going. Many small LANs don't need more than a server with multiple Ethernet cards and a routing daemon that speaks RIP2 to do this job, or even just an ADSL firewall/router to connect to the Internet. I'm going to ignore these very simple scenarios and focus on a larger LAN where there's a need for more sophistication (like a possible requirement for OSPF and VRRP routing protocols), because this is where performance and cost start to become more important, and the comfort of having a Cisco router begins to look attractive to network architects.

Hardware
For this reason I've chosen a Cisco 2821 Integrated Services Router2 as my baseline. The 2821 setup that we want for our Kiwi SME LAN includes,
- 256MB RAM upgraded to 512MB
- 2 x integrated 10/100/1000 Ethernet port
- an additional 1 x FastEthernet 10/100 port

Cisco doesn't make this too easy to price online, but it does point us to CDW (http://www.cdw.com ) where we can, if we know what we want, configure and buy our Cisco 2821 router. The base hardware plus the RAM upgrade and additional LAN port comes in at around US$5300, including the standard software and 64MB of Flash memory. Aindriú Ó hEithir, a networking contractor from Dublin and qualified Cisco engineer, tells me (personal communication, 22 March 2007) that the 2821 is not "price competitive" compared with other commercial routers, but believes that Cisco's "legendary" reliability is the reason why SMEs will opt for it. He also cites the availability and relatively cheap cost of Cisco-literate administrators as a factor in Cisco's favour.

Cisco itself didn't reply to my request for comment, but a commercial F/LOSS competitor did. I approached Vyatta (http://vyatta.com) for an interview about its router appliance, which it directly pitches against Cisco in the corporate LAN. As an open source contributor, Vyatta develops and releases its router software under the GPL and BSD licenses3, and as part of its commercial operation pre-installs its Debian-based distro on a Dell PowerEdge server, selling this bundle as a commercially supported router. Dave Roberts, the Vice-President, Strategy and Marketing for Vyatta Incorporated, was very happy to have his appliance compared to the Cisco 2821 and told me (personal communication, 7 March 2007) to expect, in some cases, double the performance at half the price. To buy a Vyatta appliance to match the 2821 hardware specification above (from the Vyatta online store) comes in at US$2500, so he seems right about the price, at least.

According to Roberts, a server using a PCI Express chipset is required to better 400 Mbit/s. This is the reason for the Dell PowerEdge, with the bottom-of-the-line one being all that's required. I'm not going to join x86 architecture debate (the one where even Apple has joined Intel), but Vyatta contends that sticking within the x86 "ecosystem" brings all the advantages of choice in using commodity hardware.

Cisco's hardware catalogue is nothing if not exhaustive. It can be difficult to find a person to explain exactly what each offering from Cisco does and which of the many Cisco routers is right for a job. Using the Cisco website to find what you need is even less likely to help you choose. Aindriú Ó hEithir describes it as "incredibly hard to find the right product" (Ó hEithir, 2007). My own experience is that a trusted Cisco reseller's salesman comes up with some model numbers that a Cisco-qualified installation engineer double checks, and we all hope that a better or cheaper configuration wasn't available as the purchase order is signed. The only thing we can be sure of is that at some point we'll find a new feature that's only available to be retrofitted to a different, more expensive, chassis. Opinions vary as to whether the breadth of Cisco's hardware range is a purely commercial attempt to sell new boxes - the expansion card and chassis combinations are "rigidly segment[ed]", to quote Dave Roberts (Roberts, 2007) - a form of lock-in, where the great need to intimately learn a product range breeds brand loyalty, or if this relatively old company has failed to rationalise its product line to the point where now even the experts are confused.

I should be very careful here not to criticise Cisco in isolation. It's hardly the only IT company to baffle buyers with bombast. How many editions of Windows Vista are there and which of Dell's dozen or so notebooks (with three of four sub-varieties each) would run it to perfection, when they all sound so good? Indeed, Vyatta's single choice of a base appliance will surely increase many times as it targets different levels of the router market. Whether anyone else ever reaches the Cisco extent of product range without loosing customers to confusion will be an interesting point to monitor.

My immediate interest lies in the Cisco 2821 and the Vyatta PE860 appliance, so the baffling array of Cisco options can be mostly ignored for the moment. In both cases the buyer gets a computer with a CPU, RAM and interface cards, but in the case of Cisco, he really pays for it. A 1GB RAM upgrade for US$5000 seems very hard to justify, no matter what the quality, and hundreds more again over the Vyatta offering for Ethernet and E3 interfaces seems to be another strangely high cost for the same thing. The 2821 has room to add a 24-port switch module to its chassis (turning it into a switch as well as a router), which is something that Vyatta's appliance simply can't do. It's also something that our typical Kiwi SME probably doesn't want to do, when an external 48-port switch is cheap and the cost and relative advantage in my comparison would weigh heavily against Cisco.

By a stroke of luck, a recent report by the Tolly Group4 (the date of which, 9 March 2007, is hopefully enough to confirm the coincidence of me researching this paper) compares performances of the two. Though the report was commissioned by Vyatta, the Tolly Group is a commonly-used third party tester and my intention here is to determine whether the F/LOSS options are viable enough to be considered, not to determine exact performance qualities. Cisco's website publishes the results of a test it commissioned from Current Labs5 in 2004 in which the 2821 throughput is rated as similar to the Tolly Group's results for the Vyatta PE860 (but better than the Tolly Group results for the 2821). In the absence of any other performance data, and without the resources to commission or carry out my own testing, I used the results of the Tolly Group report as a guide, tempered by the Current Labs good results for the 2821. What it shows is that Vyatta's appliance is certainly comparable to Cisco's 2821 and probably superior in performance, for a substantially lower purchase price.

Performance is always going to be dependent on both software and hardware. Sluggish software may be fine on exceptional hardware and a slow processor may be enough for very a clean and lean operating system. Despite this, it seems unlikely that the Cisco IOS software (discussed below) is so inferior to the Vyatta Linux distribution, and the Cisco hardware so superior to the Dell server hardware, that the performance results between the two balance. If we assume that performance is at least equal and that software has a roughly equal affect between the two contenders, then Cisco hardware doesn't seem to be any faster than the entry-level Dell server. In fact, if the Tolly Group report is taken at face value, the Vyatta appliance, routing 64 bit frames, is nearly twice as good as the Cisco 2821, as Dave Roberts predicted. This paints an even more average picture of Cisco hardware, especially considering its price difference.

What appears here is a picture of Cisco selling commodity-quality hardware, but with an extensive array of network interfaces. Though the range of products is large enough to be confusing, and not all pieces work together in a single device, you can build a Cisco router that has exactly the hardware you need. This contrasts strongly with the Vyatta appliance, where hardware is manufactured by partner companies or purchased off the shelf and, for full commercial support at least, is limited to the most usual Ethernet, T1/E1 and T3/E3 interfaces. For our typical Kiwi SME, this limitation may not be an issue, in that we are probably connecting via Ethernet to an ISP-managed router or cheap ADSL modem and don't need any other type of interface. While Yvatta tells me that it will be adding to the interface range over time, today Cisco has a real head start and a F/LOSS option may not exist in the case of an exceptional hardware requirement.

If the hardware interfaces available for Linux servers meet your requirements, there is no comparative hardware quality argument to support the favour that Cisco has. It's time to look at the software to see if this is where Cisco has an edge.

Software
Cisco IOS is at the core of the company's product range. William Yeagar's multi-protocol router software was licensed by Cisco in 1987 to form the basis of its new Internetwork Operating System. At that time, before the world standardised on TCP/IP, Cisco used its new OS to cement its name in the router market as an enabler that could join together networks of disparate protocols. 20 years later, it's a fair debate as to whether Cisco IOS is a mature and stable system or an aged relic in need of retirement. Its popularity should temper any calls for deprecation, but Cisco's move to a modular replacement (IOS-XR)6 from a new code-base on its higher end routers provides some evidence that the shared memory and lack of pre-emptive multitasking of its monolithic architecture are of concern. A single badly behaved process in IOS can down the device, and the contrasting claims of lack of Cisco reliability from the F/LOSS community show at least some theoretical foundation here. Also, an update in IOS means a full system update, not just a bug-fix for a single module, so, again, a bad one is system-wide.

While the Linux kernel may be monolithic, the GNU/Linux operating system that Vyatta uses can hardly be described as dated or unstable. XORP, with its professed aims of extensibility and use by equipment vendors and application writers7, was chosen as the basis of the Vyatta OFR routing software. If the OFR process, or some other process on the Linux system gets out of control, it's usually able to be stabilised again without taking down the whole machine. XORP, and therefore OFR, share some syntax commonality with Juniper's JunOS and could be considered part of this superset, so when you login to the Vyatta terminal, instead of the bash shell that Linux distros commonly use, you'll see the xorpsh shell, accepting its JunOS-like commands.

Vyatta also offers a software-only commercial subscription service and an unsupported, free-to-download version of its Debian-based distro. Using these, it's possible to build your own router using the (x86) hardware of your choice. It's appropriate to consider such a non-commercial, custom appliance, and to broaden the research, I also introduced another player in the F/LOSS routing software community. Zebra (http://www.zebra.org ) has been around since the late 1990s as a competitor to Cisco IOS. In recent times it was forked as Quagga (http://quagga.net ), which is currently a more active development project. Its hardware considerations are going to be the same as Vyatta's and the quality and cost of hardware can be decided based on the performance required. Where the non-commercial option will be cheaper than a Vyatta subscription is when no support contract is bought.

Linux is one of a collection of *nix OS options to host Quagga, so fans of Solaris or the BSDs can choose them to build their routers. Quagga itself is modular, with each routing protocol being delivered by a separate daemon and these being abstracted from the kernel by a core Zebra daemon8. Modules of the suite can be individually upgraded, limiting the effects of a bad upgrade. If its syntax seems to mimic Cisco IOS, its separation of routing protocols into their own daemons and flexibility of base operating system make it a unique offering.

At this level of router there are some expected features. Cisco's 2821 supports the RIP, OSPF and BGP routing protocols, VRRP for high availability, and Ethernet, ATM and PPP encapsulation. It can also act as a DHCP server or relay, a VPN server and a NATed firewall. Vyatta includes all of this in its distro as does the combination of Quagga and whichever Linux distro you choose to run it on. Cisco doesn't make it easy to confirm exactly which of these features are included in the base IOS that comes bundled with the hardware from CDW, so we may or may not need to allow another US$700-US$1200 for feature packs and upgrades. Really, the costs have become irrelevant when the Cisco 2821 is quite clearly at least twice the price of the nearest F/LOSS alternative, but it's important to note that there is no software feature in this set that Cisco offers above the competition. Indeed it's debatable how much our Kiwi SME cares about OSPF, BGP, VRRP or ATM, and whether it would use the central router as a DHCP server.

Extensibility is always touted as an advantage of F/LOSS and Vyatta proved this advantage by adding VPN functionality to OFR, beyond the capability of XORP. Users wanting to extend Cisco IOS can only look back to Cisco to add a feature at the company's discretion. Linux routers can also easily make use of other software in the F/LOSS world and commonly employ tcpdump (http://www.tcpdump.org ) or Ethereal/Wireshark (http://www.wireshark.org ) for network monitoring. Vyatta also specifically integrates with the Asterisk Voice over IP server, which compares with Cisco offering the (expensive, of course) addition of CallManager software and its own IP hardware phones.

Another open source concept is that having many eyes on the code helps to identify and fix software bugs, and F/LOSS advocates sing the praises of their software's consequent stability and security. Cisco fans may also believe in the stability and security of IOS, but this may be debated by Michael Lynn, formally of Internet Security System (ISS) (http://iss.net ). Lynn discovered a major security flaw in IOS and, against orders from his management, made it public. Cisco's reaction was to take Lynn to court9, leading to a settlement that gags the researcher. In the F/LOSS world, testing and debugging are welcomed.

Configuration
A common complaint, even from Aindriú Ó hEithir, our de facto Cisco spokesman, is that Cisco IOS GUI tools are underdeveloped and limited. Aindriú actually describes the IOS GUI as "infantile" (Ó hEithir, 2007), saying that, "It is very easy to create a configuration using the CLI that the GUI will interpret as invalid." For this reason, and to acknowledge the command line snobbery that many network administrators might be accused of, I focussed on the CLI tools that the various routing software options offer. If nothing else, this allowed a like-like comparison.

Of course, as with so many systems, expertise in router administration comes mostly from a firm understanding of the theory. Speaking IOS or JunOS or OFR is worthless if I don't know what a router is meant to do and a cookbook administrator may only create a successful configuration by luck or mimicry. Here network administrators may be better equipped than server sysadmins. Vyatta's Dave Roberts does believe that Cisco veers from the standards that the Internet is built on, but doesn't believe that this deviation is enough to be a real problem. Maybe operating at the bottom three layers of the OSI model requires more interoperability, or maybe Cisco doesn't have just enough dominance to shut out the opposition, as other market giants have been accused of, but either way, TCP/IP networking theory can be equally applied across these systems and knowing this theory is a major requirement of configuring them.

I've already uttered the taboo that some of these systems are deferring to a de facto standard and I could even hint that JunOS, and by extension XORP and OFR, though certainly differing in their syntax, aren't a million miles away from Cisco IOS in administrative commands. The simple fact seems to be that Cisco, using Wiiliam Yeagar's multi-protocol router as its starting position, popularised a style of syntax that others have since stayed within reach of. This shouldn't necessarily be criticised. The GNU tools that make up a large chunk of the GNU/Linux operating systems started life as conscious open source rewrites of the tools that UNIX users required in their daily work, and the Linux kernel itself was an attempt to run UNIX at home. As Linux is UNIX-like, in the administrative interface at least, Quagga is IOS-like, OFR is JunOS-like and really JunOS itself is IOS-like. Whether they're siblings, cousins or bastard children isn't an issue, but that the skills applicable to one are transferable to the other is, and it belies any notion that non-Cisco skills would be too hard to introduce to a previously homogeneous environment.

By way a simple demonstration, let's look at how we would login to a Cisco router and set the IP address of its first Ethernet interface to 192.168.0.1/24.

Password: secrectpassword
cisco> enable
Password: supersecretpassword
cisco# config
cisco#(config) interface ethernet 0/0
cisco#(config-if) ip address 192.168.0.1 255.255.255.0

Now for the Vyatta OFR way.

vyatta login: vyattauser
Password: secrectpassword
vyattauser@vyatta> configure
vyattauser@vyatta# edit interfaces ethernet eth0
[edit interfaces ethernet eth0]
vyattauser@vyatta# set address 192.168.0.1 prefix-length 24

You can see that the syntax is different, but you can also see the similarities. Note the enable/configure mode, the > and # prompts to show which mode we're in and the (config)/[edit] hints to tell us what we're configuring. Knowing what an Ethernet interface is and how it should be configured for TCP/IP is the real knowledge required here.

For the sake of it, let's also look at the Quagga way to see how closely its syntax resembles IOS.

Password: secrectpassword
quagga> enable
Password: supersecretpassword
quagga# configure terminal
quagga#(config) interface eth0
quagga#(config-if) ip address 192.168.0.1/24

This minor piece of configuration should not be seen to argue that administrators of one system will immediately be able to configure another, but it does highlight that, once a new system is learned, there's no reason to expect initial configurations or regular maintenance to be any more arduous in one system than another. A quick Google search will deliver hordes of interested parties publishing configuration guides and even conversion tables to explain the syntax differences.10 11 12 13

All three options allow ASCII text configuration files to be exported for backup or to use on another system. With Cisco, it's tftp to another machine and with the Linux boxes, whatever system you would normally use for backup. The Linux options offer some real advantages here. Not only is transfer of the configuration between devices very simple, but a lower quality commodity computer using a matching configuration could be made available as a swap-out router for very little expense.

Conclusion
It seems obvious to me that while Cisco does produce a quality device in the 2821 Integrated Services Router, it does so at an expense that is hard to justify when it's compared to the commercially-supported Vyatta PE860 appliance, or a stock *nix server using Quagga. The arguments for using Cisco in this scenario seem to be non-technical requirements for the comfort of the status quo. Aindriú Ó hEithir talks about a need for a revolution to challenge the dominance of Cisco (not that he advocates such a change) but this revolution seems to be needed in the minds of network administrators and architects more than in the technology available.

My own question is answered: I probably have wasted IT budget on Cisco routers. I've had requirements for WAN interfaces outside the Vyatta-supported range - SDSL, for example - but a small amount of time and money testing the unsupported alternatives may have solved those needs, as could outboard modems or alternative WAN connections. Any of these alternatives would have fallen well within the cost of simply buying the Cisco router with its expansion cards and software updates.

I also discovered that I need to do some work improving my own technical skills in router administration. This won't require me to buy a Cisco router or even a Cisco simulator. I think I'll install a couple of new Linux virtual servers, one with Vyatta's free distro and the other using Quagga. It won't cost me a penny and I'll improve with a couple of syntax variations that will be useful even back in the Cisco world. Come the revolution, I'll be ready.

End Notes
1. GNU General Public License (2 May 2005). Retrieved 8 March 2007 from <http://www.fsf.org/licensing/licenses/gpl.html >

2. Cisco 2821 Integrated Services Router. Retrieved 8 March 2007 from <http://www.cisco.com/en/US/products/ps5880/index.html >

3. Robert Bays (16 January 2007). OFR License. Retrieved on 1 May 2007 from <http://vyatta.com/twiki/bin/view/Community/OfrLicense >

4. Vyatta 1.1.2, Competitive Gigabit Ethernet LAN Routing Throughput Evaluation versus Cisco 2821 Integrated Services Router (8 March 2007). Retrieved 9 March 2007 from <http://www.tolly.com/DocDetail.aspx?DocNumber=207190 >

5. Current Analysis Lab Challenge: Cisco 2821 Integrated Services Router (2004). Retrieved 29 March 2007 from <http://www.cisco.com/application/pdf/en/us/guest/products/ps5880/c1031/cdccont_0900aecd80425258.pdf >

6. Cisco IOS XR Software Release 3.0. Retrieved 29 March 2007 from <http://www.cisco.com/en/US/products/ps5845/products_data_sheet09186a008022d5f4.html >

7. The XORP Vision (16 October 2006). Retrieved 11 April 2007 from <http://xorp.org/xorp_vision.html >

8. System Architecture. Retrieved on March 29 2007 from <http://www.zebra.org/zebra/System-Architecture.html >

9. Cisco Systems Inc. and Internet Security Systems Inc. v Michael Lynn and Black Hat Inc., 03-CV-03043 (N.D. California, July 27, 2005).
Explanation: Cisco and Internet Security Systems (ISS) filed against Black Hat and Michael Lynn, alleging copyright infringement, trade secret misappropriation and breach of contract. Lynn, an ISS employee at the time, had shown a presentation at the Black Hat conference in Las Vegas that demonstrated how to exploit an IPv6 flaw in Cisco IOS to gain control of a Cisco router. The Plaintiffs were granted an injunction and all parties came to an out of court settlement.

10. Vyatta & Cisco Commands (24 April 2007). Retrieved on 27 April 2007 from <http://www.openmaniak.com/vyatta_compare.php >

11. Cisco/Juniper Commands (26 October 2003). Retrieved on 27 April 2007 from <http://networking.ringofsaturn.com/Cisco/ciscojuniper.php >

12. Peter Lunqvist, Peter Moyer, and Annette Kay Donnell (2001). Translations between JUNOS Internet Software and IOS. Retrieved 0n 27 April 2007 from <http://www.juniper.net/solutions/literature/app_note/350005.pdf >

13. Dominique Cimafranca and Rex Young, IBM developerWorks (8 October 2003). Build a network router on Linux. Retrieved on 27 April 2007 from <http://www-128.ibm.com/developerworks/linux/library/l-emu/ >