Friday, August 24, 2007

Getting a Network Lab on the Cheap

A network lab is useful for all sorts of things. Unfortunately really good labs can be expensive to put together. Over the years I've developed some alternatives that have worked well for many situations. This is still in informal draft format but I don't know when I'll next get a chance to clean it up. I think some folks may find it useful as is so I'm going ahead and posting it now.

Here are my strategies:

  • Emulators
    • There are Cisco hardware emulators that allow you to run IOS and PIX/ASA images. This has also been known to be possible with other vendors from time to time, sometimes officially offered by the vendor and sometimes not. I suggest a Google search for something like "vendor emulator".
      • Dynamips (Cisco hardware emulator that runs your provided IOS images for the 3800, 7200 and other platforms).
      • PEMU (Cisco 525 PIX hardware emulator that runs your provided PIX OS image)
      • Versions for Linux and Windows of the above
    • These emulators often run in their own VMs so, for example, it's possible to set up an entire lab of Cisco devices on a single laptop or desktop and have the emulated devices all "connected" to each other purely in software. e.g.
      • 2 x Cisco PIX 525 + 2 x 7200 NPE-400
      • ....on a 1.4Ghz Celeron laptop
    • Don't expect to do performance testing with emulators but they are often fully functional (the Cisco emulators run actual IOS and PIX images, whatever ones you provide) since you can build testbeds that closely resemble your actual network, including testing actual config changes, etc.
  • Vendor and reseller online accessible demo environments
    • These are nice for poking around and following along as you read through their manuals. Sometimes you can't change things but you can usually get as far as saving your changes -- which is good enough for many situations.
    • Can also be useful to see what newer versions of firmware look like, before you upgrade, since vendors usually keep their demo units up to date
    • Do Google searches for "myvendor demo", "myvendor demonstration", etc. e.g.
  • Quasi-Public looking glasses
    • Telnet reachable looking glasses / route servers / traceroute servers
    • Web-based
    • usually Cisco, Juniper, and some Zebra-based Linux/BSD boxes
    • Not as useful as other methods but sometimes can view live info you might not be able to simulate elsewhere such as large BGP tables
  • Rack rentals -- rented remote network lab racks (most often rented in 4-6 hour chunks, designed for folks studying for certifications such as CCIE)
    • as cheap as $10 for a 4 hour block (!!!)
    • check eBay for low cost rentals
    • check Google for others -- there are many so prices are pretty competitive
    • search for "CCIE rental" for Cisco rentals. Similar ones exist for Juniper and other vendors with certification programs.
    • since folks studying for higher end certifications, such as the CCIE, require pretty elaborate labs these "rack rentals" give you access to some incredibly large and higher-end equipment
  • Quasi-public environments (left open by accident? Sometimes folks leave their mgmt interfaces open intentionally, accidentally, or, hopefully, just the read-only modes)
    • When evaluating Axis cameras a while back, I did some Google searches and turned up a bunch of cameras left open to the public.
    • Hint: For web-based GUIs, figure out a unique portion of the text string that is usually in the HTML title and search for it using Google's "intitle:" command.
  • Try and Buy promotions
    • Many vendors, especially the smaller and more aggressive ones, are pretty open about letting folks try their products out for a month or so. Many times you can even talk 'em into holding onto them a little longer if you keep in touch with them, let them know you are evaluating for future purchase, etc.
    • Helps to have a business entity, be a "consultant" (state outright that you regularly recommend equipment to clients, if that's the case, since that peaks the interest of most sales folks). Even better is a tax reseller ID I suppose (I don't resell hardware so haven't taken advantage of this last bit before but I've been asked by sales folks when evaluating hardware who I imagine like to encourage new potential sales channels).
  • Purchasing standby spares
    • Spares bought to have for on-site swap-ins in the event of hardware failures can be used (carefully!) for lab work. Just be careful not to break, lose, or otherwise leave your spares in a state that hurts their real function.
  • Purchasing, borrowing, decommissioning lower-end but current enough models
    • Older models, that may or may not be end of sales status by the vendor, may be available cheaply. It's all about eBay.
    • Upgrading production devices and retaining the older models that get pulled for the lab (previously sunk cost, easier to justify over spending more $$$ on lab equipment)
    • A maintenance window for a non-critical office/PoP or during a time window (e.g., after 5pm, or 2am-6am or whatever) that is acceptable in your environment. Then temporarily doing the testing/evaluation/learning with this equipment before returning it back to production state. This isn't ideal but works better than "learning" on a more important part of your network at the same time you are intending to go live with the changes.
  • Out of date models that people are giving away
    • for some needs, "free" equipment can meet certain needs, especially when first learning about a new device when just getting the basic look and feel of the command line or GUI is the focus. Spend money only when you get a bit farther along -- after all many times projects get delayed mid-stream anyhow so why buy new lab equipment only to have it sit and collect dust for the next few months until you get around to working with it (and probably frustrating your boss who you convinced to spend money on it now rather than later).
  • Borrow from a colleague
    • Call your colleagues at other organizations. Often they've got some extra hardware sitting around that they are willing to lend.
    • If you break anything make sure you tell them upfront and replace it (been there done that, with an awful hardware problem in a modular router that, best as we could tell, took out one of the test chassis in addition to the problematic one due to some weird short on a removable module we pulled from the busted chassis to test in the known good chassis).
  • Borrowing under vendor hardware replacement and support contracts
    • If you have a current hardware replacement or support contract with your vendor, you can explain your particular situation and sometimes have them do you the favor of lending you equipment temporarily.
    • In a near-emergency, if you have an advanced hardware replacement contract, you can consider having a "failure" then sending the advanced sent hardware back when you're done with it. Don't abuse too much Might be acceptable under some circumstances. Make your own judgment.
  • Hosted x86 Virtual Machines
    • usually VMWare or Xen based (not that it matters much to the end-user)
    • can boot up various OSes on-demand, cheaply
    • some hosting companies will let you rent on short-term basis (e.g. Amazon EC2 Xen-based VMs charge by the hour and don't charge you while your VM is "shutdown/turned off")
    • Good for adding hosts to your test lab (nobody ever said a useful lab had to be physical)
    • Combined with network device emulators, discussed previously, makes it possible to do some crazy stuff
      • Want to simulate a 50 router nationwide network of Cisco 7200 class routers? Get a usage-based VM hosting account and install Dynamips.... It'll cost you something like $20 to get access to 50 VMs for four running hours via Amazon EC2
    • If you've got some real equipment you want combined with your virtualized equipment, remotely hosted x86 VMs, etc than build a VPN overlay to connect things up the way you want. The VPN can be an invisible transport layer for your lab network if you want or it can be part of the lab network itself.

No comments: