Showing posts with label IT. Show all posts
Showing posts with label IT. Show all posts

Wednesday, June 11, 2008

Minneapolis high school students take e-field trip to the operating room

About a year ago I observed that 64% of the schools in this region have connectivity at 100 Mbit/s or greater to the K12HSN -- and in turn the Internet and Internet2. I shared a few thoughts on how this might be used to do some nifty things.



Today I came across a news item from the Internet2 web site, covering a high school in Minneapolis that, using an Internet2 connection, participated in a live knee surgery.

As the surgery progressed before them, the 30 juniors and seniors in John Redelsheimer's class reacted to crystal-clear images of sliced flesh and bone with predictable groans and urrrghs. They asked questions of the surgical staff, such as how long the implant might last, and how a full and partial knee replacement differ.

Students in the Robbinsdale Armstrong High School anatomy and physiology class observed Wednesday as a surgeon in Columbus, Ohio, performed total knee-replacement surgery on an 85-year-old woman. And they didn't even board a bus.

Students in the Robbinsdale district are among a select group for whom technological expertise and resources have aligned to allow them to take an e-field trip -- in this case, to Dr. Joel Politi's operating room. Other classes have been to the International Wolf Center in Ely, Minn., a classroom in Egypt and a village in Mozambique.

The session was sponsored by COSI, a science center in Columbus, Ohio. It was made possible by Web-driven video-conferencing technology via Internet2, a superfast network linking universities, industry and government. The basic technology -- the cameras and microphones -- isn't new, but schools haven't been able to use it fully until recently because most lack that fast, powerful connection.

Link to full article is here.



This is what I am talking about!

Thursday, June 5, 2008

IPv6 Hyperbole & Opportunities

A oft touted phrase for IPv6 is something to the effect of "an address for every grain of sand"[1]. I have a problem with this statement. It's one of those statements that is technically true but, in fact, untrue -- when used as the answer to the question which it is implied to be answering.

If IP addresses were simply assigned to devices and backbone routers were made aware of every single one it might be true. It's not. It's important to view IPv6 address space size in the right light because otherwise we can end up in some of the same troubles as the current IPv4 Internet. These troubles include not only overall available IP addresses but also routing of these IP addresses across network operator boundaries. After all, what's an IP address without global reach ability? :-)

The way that IP addressing works, there is a hierarchy. This hierarchy is used to group individual IP addresses into larger IP address blocks (known as "prefixes" and sometimes "subnets"). In the early days of IPv4 that was the Class A, B, and C system. While it was replaced with CIDR, the new system still maintained a hierarchy based on network size -- it was simply less rigid. This is still necessary in an IPv6 world.

The size of the protocol's address space -- and how it is broken up -- is of the utmost importance to routing. One of the greatest ironies of IPv4 address consumption is that multi-homing -- the connection to more than one upstream Internet provider for performance, cost, and reliability reasons -- requires an IP block of a particular size. Anything smaller than that accepted by the community (through rough consensus and subject to stragglers, mavericks, and router capacity improvements) and you can't multi-home.

In the IPv4 world this has resulted in waste of IP addresses -- which are never actually assigned to end-user devices -- so that someone can multi-home. It's also made it more difficult for smaller networks that want redundancy. Even if they end up with sufficient IP space, it is likely from one of their ISPs and not portable. If they were truly bigger (as in, if they actually were going to use all of those IP addresses) they'd be able to bypass their ISPs, getting IP space from one of the geographically appropriate pseudo-NGOs that allocate IP address space to larger IP address consumers.

Why all the fuss? Why not just allow anyone and everyone to inject any size block into the Internet routing tables? Because routers have finite resources. The larger the routing tables the more memory and CPU used for every packet pushed through the router. At some point a line is drawn where it is no longer generally accepted to be economically viable. This is where the generally accepted "smallest prefix we'll accept into our routing tables" policies come from. (generally the smallest acceptable block is an /24 in the present IPv4 world, approximately 254 assignable IP addresses for end-user devices).

One of the still active debates in IPv6 is how multi-homing will be performed in the long run. Will the current IPv4 model work? Or does the current model artificially restrict how many folks would actually multi-home if they could? Does the current system encourage too much address waste -- and is that even still a concern? How rapidly would the routing tables grow if a different approach were taken? How will we handle the additional resource burden of the continued co-existence of both IPv4 _and_ IPv6 routing tables for quite some time? etc

IP address portability is (indirectly) addressed in IPv6. That remains to be seen though. Under this model, smaller sites still won't necessarily have their own permanent globally routable IP address blocks. They'll have plenty of real global IP addresses assigned by their ISP now -- without any fuss -- but those IPs will still be controlled by their ISP (i.e. if they opt to change ISPs they will have to return 'em and get new ones from their new ISP). Switching IP address blocks is made (supposedly) easier though. The idea is that deeper auto-configuration is adopted with something akin to current DHCP on steroids used pretty much across the board along with very tight integration with DNS -- and somehow overcoming DNS caching.

I am not advocating against IPv6. On the contrary, for its successful widespread adoption I think that expectations must be set appropriately. And, any open for debate areas -- which don't have to hold back its adoption necessarily -- need to continue to be widely discussed. The more awareness the less that a new adopter is blindsided -- and thus the happier they'll be with the outcome after they proceed with their adoption efforts. And, more importantly, the faster that some more definite solutions / best practices can be better understood and disseminated.

As always, I welcome comments, including contesting any of my conclusions and assumptions above. Discussion and debate is how nearly all progress is made, whether it is with ones self or with others. :-)

[1] “One of the major advantages of the new Internet protocol (IPv6) is that it overcomes the growth problems of the Internet caused by the current limitations in the number of IP addresses needed for every computer or other device in order to access the Internet. The new protocol allows for a virtually unlimited number of (2^128) addresses – enough to assign an address to every grain of sand on all the world’s beaches.”

--“European Commission hosts inaugural event to celebrate the launch of the world's first all IPv6 research network,” Brussels, 14th January 2004

Friday, March 14, 2008

Druid: Open Source Unified Communications Based on Asterisk

A group called Voiceroute just pushed out a product called Druid (actually two products, an open source version and a commercial version) that looks very intriguing. It is based on Asterisk at the core but they've done a lot of work on top of it -- besides just sticking on a useful GUI. This is what I love about the telephony space today -- continuous improvement as folks figure out what they really want. There's a decent little preview/review here. A more thorough explanation of features here. Some ideas for applications here.

So many forms of communications (voice, voicemail, email, IM, mobile, fax), so many ways to leverage it. Now a single IP communications platform based on open source and open standards.

What is Druid? Druid is the premier unified communications platform for enterprises. It allows companies to deploy easily and affordable high endIP communications services using off the shelve commodity hardware and IP phones. Druid covers your enterprise communication needs from IP voice, voicemail, IM all the way to the mobile space.
I love Asterisk and the various things which can be be built with it. But, at its core, (stock) Asterisk excels most at being an engine at the center of a telephony/communications platform. To maximize adoption, the barrier to use must be lowered through improved management interfaces and turnkey features out of the box that reflect what end-users want. There's lots of room for improvement for specific problem domains. That's why Asterisk's flexibility is so powerful and having a lively eco-system around it makes it more and more accessible to a broader base of users. That doesn't mean that Asterisk based solutions aren't ready for prime time today -- they most definitely are. Thankfully, Asterisk's eco-system is strong with solutions such as Fonality, FreePBX, Digium's AsteriskNOW/ABE/AA50, and many others. Oh, and now we have Voiceroute's Druid.

Definitely will be taking a look Druid soon.

Wednesday, February 20, 2008

Understanding MPLS VPNs

If you are an enterprise user of carrier WAN offerings, it is likely you've been offered MPLS as a solution. Most carriers are encouraging customers to consider MPLS based services over traditional Frame Relay, ATM and even Point-to-Point transport.

One misconception is that consumers of MPLS carrier services must "run MPLS" within their own networks or at least on the edge device(s) connected to the carrier's MPLS service. This is not the case (unless you are doing something pretty unusual). Standard routers -- and even bridges -- are used on the customer-side. The configurations may be a bit different than you're used to but they're still relatively straightforward (and cookie cutter once you do one).

Your layer 1 and layer 2 skills will still come in handy. The underlying transport is still going to be TDM (DS1, OC-3c, etc). You may end up running a dynamic routing protocol (BGP, OSPF) with the carrier's network. If that's new territory, don't worry. This BGP configuration is far less elaborate than that needed to (prudently) bring up BGP for Internet multi-homing.

So even though the MPLS component will be outsourced to your carrier, to be an informed buyer and troubleshooter when shit-hits-the-fan, you'll want to understand the different ways that MPLS can be delivered and used by carriers to provide your service. When the carrier asks you to make some choices or you're evaluating a prospective solution, you're more likely to get what you need (and hopefully less of what you don't).

Jeff Doyle, the author of Routing TCP/IP Volume I and II (both 900+ pages each), has two quick articles about MPLS. In Part I, he covers the basics relevant to any MPLS user as to the different types of MPLS network options and in Part II he covers some of the nitty gritty relevant to service providers and those with an interest in what goes on behind the scenes.

P.S. I have some experience with WANs. Feel free to ask me questions. You can post a comment here or drop me an e-mail.


-jr

Sunday, February 17, 2008

Improvements at Digium? ....and New AA50 Firmware

Yesterday I noted that Digium pushed out a new firmware release for their small business targeted hardware appliance (the AA50) and it looks like a good sized update. It is dated the 4th in the release notes but the 14th elsewhere so I think one or the other is a typo.

They appear to be syncing it up with their other code bases (Asterisk Business Edition, AsteriskNOW). From what I've seen in the public commits and hints on mailing lists from staff, they've been hitting pretty hard on both of those in the QA department of late.

Digium is clearly working on changing how they manage their code bases and the mixture of their commercial and open source releases, to address different customer/user segments and some of the problems that have come up. There was even a note about a split release change they are going to with AsteriskNOW for the GPL purists. Glad to see some serious re-thinking about releases, meeting the desires of different customers, quality control enhancements, and the public evidence of the aforementioned outside of press releases.

I imagine things will continue to trickle down and we'll see more improvements coming together. I'm sure some will turn out to be good ideas while others head back to the drawing board but that's how most progress works, eh? :)

The additional leverage should improve things across the board no matter where you fall in the Asterisk eco-system. Even if you don't use an Asterisk based telephony solution, their moves impact the others in the marketplace (and visa-versa).

Back to the new AA50 firmware release: It would appear to address IVR and ring group related bugs I encountering early on in the GUI, that I ended up bypassing the GUI to workaround. I haven't tried it yet on the AA50 I have access to. I'll probably give it another couple o' weeks in the wild first since it's a .0.1 rev. That client has some other problems and improvements they want me to attack first anyhow. Below are change log excerpts:

Version 1.1.0.1 - February 4, 2008
* Enable Internationalization settings in the GUI
* Provide the ability to select between kewlstart and loopstart
* g722 codec is available
* WAN Side Provisioning of Polycom phones is enabled
* AA50 has been synchronized to ABE C.1 branch source code
* Ring groups number of seconds field has been added
* Ring group bug using ivr option has been fixed.
* Polycom bug concering use of standard timezone has been fixed
* Blackfin math for meetme conferencing has been implemented
* Adjustable flash hook duration is now available in teh GUI
* Calling rule editing and deleting bug has been fixed.
* Bug concerning setting incoming rule to choose voicemail is fixed.
* DTMF twist settings for Brazil have been added to tone generation
* Call forwarding loops have been prevented so that they do not crash the AA50
* Voicemail attachments are set to WAV format.
* Network setting tabs no longer disappear.
* Added an optional full-wave mode DAA ring detect in the sx00i driver

Wednesday, February 6, 2008

Underwater Telecommunications Industry Geeks

For those who are interested in the inner workings -- both technical and business -- of the submarine fiber optic cable industry, take a look at SubOptic. Particularly recommended are the presentations from their last conference which are available to freely peruse all you like here.

Thursday, December 20, 2007

Asterisk Mashes Up Politics

I ran across this application today, called CommitteeCaller.com, which makes it easier for (U.S.) folks to contact their representatives. It's a nifty example of the type of applications that become possible when some imagination gets combined with lowered barriers to entry. This is what mashups are all about. Taking information that is out there on the Internet and combining it in ways that make it more useful, accessible, relevant, visible, etc.

This particular one uses Asterisk for the telephony, a database built from information on the Internet, and a custom AGI to interact with the user input, look up things in the database, make the calls, and get post-call rating feedback. AGIs are the equivalent of HTTP world CGIs (yes, the Asterisk world is progressing quite fast but the Web did get a big head start on it so it's still a little behind; CGIs, or AGIs, are pretty 1997 but you have to start somewhere).

Just wait until all the old school web developers that are used to coding in PHP, Ruby (Adhearsion), C, Perl (Asterisk::AGI), etc. discover they can write Asterisk telephony applications just as easily and in the same languages. (The Adhearsion page, even if you're not a Ruby programmer, has a good overview and example applications if you're curious).

CommitteeCaller.com is a site that allows one person to target an entire congressional committee over the phone. The web application utilizes the open source Asterisk PBX system to connect you to every senator or house member on a particular committee. No more digging around the 'net entering zip-codes to retrieve phone numbers of representatives. CommitteeCaller.com automates the tedium of finding and dialing your favorite politicians.

Select a committee, enter in your phone number and click "Put me in touch with democracy!" and you'll be called by our system and sequentially patched through to the front office of each member on that committee. You can even rate how each call went; information that will enable us to rank representatives on how accountable and responsive they are to their constituents.
[...]
Once connected Committee Caller will tell you which representive you are calling, who their legislative director or chief of staff is, and what district they represent. At any point you can use the * to hang up the call and move on to the next one. Remember not to hang up after each call as you will have the opportunity to rate how your call went.

-jr

Monday, December 10, 2007

Cordless VOIP Phones, Well, Stink

Michael Graves, over at the VOIP Users Conference, has a nice summary of the common frustrations he's had with cordless VOIP (SIP) phones. Michael plays with a lot of hardware, is a real user, and isn't selling anything related. His opinions are worth a read.

-jr

Friday, December 7, 2007

My New Home Asterisk PBX Embedded Box





[ The first two are photos of the actual unit, pulled from the eBay auction. The last two photos are not mine but stolen from a friendly Flickr source. Hoping Santa will bring the family a new camera.. ;-) ]

On Friday my HP Thin Client arrived. Only I'm not going to use it as a thin client. Instead I'm going to install Linux (or FreeBSD, see below) along with Asterisk, the open source telephony platform, onto it. This particular unit is an HP T5700.

It cost me <$100 on eBay. Low power <20w, class="blsp-spelling-error" id="SPELLING_ERROR_1">Ghz (Transmeta Crusoe) based with 256MB RAM, and 256MB Flash. I may add a 2.5 laptop drive (has IDE and USB too).

The lack of noise and the tiny form factor is a huge driver since this is going into our apartment and the low power is for our savings accounts and the environment. :) The flexibility and ease of use gained by keeping it x86 based is a big plus for saving time (no cross compiling, no searching out funky code patches for less mainstream architectures) and maintaining compatibility with the maximum amount of things I may want to do with it.

I nearly bought an IP04, or one the variations based on it like uCpbx. These are Blackfin based embedded systems designed to run Asterisk, specifically the Astin distro. These are very cost effective looking solutions for SMB type environments. They are also very very similar to Digium's Asterisk Appliance 50 (AA50), which is also Blackfin based. In fact, they are nearly the same thing if you don't count formal Digium backing and support. (I recently got some experience in with an AA50, in an installation for a client with Snom 320 phones and intend to post some about that at a future date).

I'm looking forward to getting this box on-line as our full-time home phone system. If all goes well I'll probably pick up another one (or several) for lab use. This should free up some space in the apartment and not require me to keep shutting my dev box down to eliminate ambient noise and power consumption. Now if only the power supply would get here quick. :)

Typically I install Debian or Ubuntu then plop in Asterisk. This time, this is meant to be more of a true "appliance" than a server. So I'm going to evaluate some other options before I settle on anything. This will give me the opportunity to get experience with and thus cross out some items on my "To Evaluate/Learn" list.

I'm going to try out Askozia which looks promising. It'll be a new one for me and it's actually FreeBSD, rather then Linux based (it's based on m0n0wall). Askozia also has a built-in web GUI which I'm looking forward to contrasting with Digium's own GUI (which is in AsteriskNOW). AstLinux is another option I'll check out. Unfortunately out-of-the-box it's Asterisk 1.2.x not 1.4.x based (though there's a dev version that is 1.4.x).

I do miss having a lot of tools anytime I've worked with embedded distros. And I like having extensive logging available -- even if the device is supposedly an "appliance" that just sits there. Tough to troubleshoot an appliance when there ain't no logs. :-)

Ultimately I may roll my own stripped down something or other. Or, grab a more generic already stripped down distro and put Asterisk plus the Digium Asterisk GUI on top. Having the option to add a laptop drive gives me comfort I can go with this route, even as far as installing Debian or Ubuntu stock if need be, while remaining low-power.

I also intend to experiment with the various Bluetooth integration options for Asterisk. Namely chan_mobile for headset and cell phone integration.

We'll see what else. :) The nice thing is that, besides really enjoying Asterisk, I can justify more than one solution, since whatever I don't actually use as the house system will still be rewarding in the lab for self-education and evaluating the options out there for my clients.

-jr

Wednesday, November 28, 2007

Improving the Snom IP Phone Retrieve Button Functionality

(Otherwise entitled "Getting the Snom Retrieve Button To Work Even When There Are Only Old Messages to Retrieve")

If you use Snom IP phones, you may have discovered, as I recently did, that the Retrieve button doesn't work, at least by default, unless there are new messages in the mailbox. If the user wants to listen to a saved voicemail, they are out of luck and have to dial the special voicemail extension directly. The Retrieve button just sits there and does nada.

This created some confusion in a recent installation since folks learned to use the Retrieve button to access voicemail and then later, after a day or so of use, wanted to listen to voicemails they had saved. :-) Sure, I had set-up an extension to dial the voicemail system directly (intended for when people were out of the office) but it was pretty silly to have two different ways for users to get used to accessing their voicemail, depending only on whether they had new messages or not.

I poked around a bit and the fix was very simple.... In the web management interface go to Setup->Identity X-->Mailbox and set it to your internal mailbox extension.

(As an aside: I am overall pretty happy with the Snom 320 IP phones. Be careful what firmware revisions you are running -- stay away from 7.x unless you know what you are doing and keep things consistent across your installation).

Sunday, November 11, 2007

VOIP Troubleshooting With (the free) Wireshark Packet Analyzer



Wireshark is a network protocol analyzer. Some may recognize it by its former name, Ethereal. It's free (and open source), runs on multiple platforms (including Windows and Linux), and actively developed. For those doing VOIP installations or troubleshooting existing installations, the latest release has some very handy VOIP specific support.

It will create visuals representing captured SIP and associated RTP connections. You can drill down by clicking on specific spots on the graph to pull up the associated packet(s). You can generate reports (as well as graph) jitter, bandwidth usage, etc. Various ways of displaying the data to get a better idea of what's really going on.

The screen captures at the beginning of this post are from Wireshark. They show a graph of a VOIP (SIP) call (and a half) between two Snom SIP phones attached to an Asterisk-based PBX (the green/blue/purple image). And an analysis of the associated RTP session (including packet loss, jitter, delay). WS can even playback captured VOIP calls (at least if using PCM/G.711/ulaw).

-jr

Wednesday, October 17, 2007

Sanitize All Possible Inputs

If you write applications, well, it's not just public web form input that needs to be sanitized...


:-)

-jr

Tuesday, October 9, 2007

California and SLO County School Connectivity (and Ideas!)

According to this data posted by K12HSN, 17% of schools state-wide are connected to the Internet (and, in turn, Internet2) at 100 Mbit/s or higher. What I found nifty is, upon zooming into the local schools here in San Luis Obispo County, that number jumps to 67% (fifty seven out of eighty four). You can see other data for SLO here. (You can zoom in on other areas of California there as well). With this foundation, some intriguing possibilities now exist.

Quick background: K12HSN is a state program funded by the California Department of Education, providing Network/Internet connectivity and related services to K-12. Through K12HSN, schools get access to CENIC/CalREN and, as a result, Internet2 as well as, of course, the Internet. CalREN, the California Research and Education Network, is specially designed to meet the unique requirements of these communities, and the majority of the state's K-20 educational institutions are connected to it. CENIC oversees CalREN and coordinates other related services for California public educational institutions. Internet2 is an R&D platform, for various research institutions both public and private (and, if you're under the impression that Internet2 is just about high speed connectivity, a bunch of network geeks, and some talk about tele-medicine, look here as well as as some of the following links to see how it's being used in the performing arts).

With this as a backdrop, interesting possibilities have emerged for local K-12 students. Here are some ideas:

  • The SLO County Office of Education could host an Internet2 Day where research projects and applications are demonstrated to promote awareness and spur ideas in the minds of researchers (read: students, teachers). Projects/applications discussed and demo'd might include collaboration, health sciences, arts & humanities, and science & engineering. It would reach across all disciplines.
  • The "economies of scale" necessary to have live expert guest lecturers teaching students statewide via video conferencing (and here). I'm talking about having the top professors, researchers, artists, politicians, etc. speak live to students across the state and have the capacity to take real-time Q&A from students. Sure beats watching a passive recorded video on television! And it's sure to intrigue students who might easily overlook great thinkers sitting still on a textbook page in front of them. You get the benefits of serendipity, live action, interaction, and young minds all rolled into one. This same infrastructure could be used to publicize to the larger student body things like state-wide competitions, which, at least traditionally, only the local and regional winners of contests have been able to visit when they head off to compete at the higher level. Why not spread the inspiration around?
  • Got more ideas? Post 'em!
How about it?

Monday, October 8, 2007

Can Technology Geeks Be (Good) Managers?

If you are a technology geek currently serving as a manager, you better figure out how to become a business manager, if you intend to lead a successful IT department, group, team, or project. You owe it to yourself, your direct reports, whomever you report to, your colleagues in other departments, and your company. You will get a bigger budget, better compensation, more respect from all of your constituents and stakeholders, greater cooperation for your projects to help them be more successful, and greater satisfaction from your career.

It's not all bad for the technology geek turned manager though. If you can grasp the business side, by taking a bit of initiative to learn it, and combine that with technology savvy (even if you let your direct reports worry about the deep down details) you can have the best of both worlds. The last thing technology geeks want are clueless managers. It doesn't matter whether they are clueless about business or about technology -- they are still going to make things more difficult, albeit unintentionally, for their employees.

IT managers should know how to write business plans, prepare budgets, use financial concepts competently such as: the difference between cash flow and profit as well as grasping present and future value calculations, tie projects to business objectives, communicate and be held accountable in business terms, systematically assess and explain risk and uncertainty in ways that relate to the overall business, and communicate with non-technology management in regards to strategy.

This doesn't mean you need an MBA. If you don't understand all of these concepts there are options:

  • Take a basic accounting course (or two) at your local community college
  • Sit down with your CFO, controller, or accountant and ask for some tutorial sessions
  • Buy some books. Ask your CFO, controller, or account for some recommendations (and get them to promise to answer your questions if you take the initiative by reading the books they suggest).
  • Ask your CEO if you can peak at the organization's overall business plan. Afterwards consider and discuss how your department, group, or project fits into the bigger picture. Ask if there are ways you might better consider and communicate your group's vision, goals, successes (and, yes, failures too) as part of the bigger picture.
  • I'll also try to highlight, in a future post, some specific resources that have helped me out.
-jr

Wednesday, October 3, 2007

Digium (Asterisk) Is Sending Busy Signals

Digium, the commercial company behind the open-source Asterisk IP PBX, has been ultra busy of late. They came out with a self-contained hardware based Asterisk appliance targeted at developers, telephony carriers, etc. to build custom IP PBXes for their customer bases. They followed this with a full blown out-of-the-box installable hardware IP PBX appliance (the AA50) intended for the mass market. They bought SwitchVox, a leading IP PBX appliance vendor with some nice innovative user interface and functionality features, then announced a deal with 3Com who will be OEM'ing their appliance as the foundation of their IP PBX offering.

Digium, has been selling components, such as as cards to interface between the traditional phone network, development and support services for Asterisk, and commercial licenses for vendors OEM'ing Asterisk code into their own PBXes and other telephony applications for several years now. Now, it's time to get serious I guess.

Further Notable Links:

Tuesday, October 2, 2007

A Promising New Book: The Pragmatic CSO (Chief Security Officer)

Last week I ran across a book I had not seen before. From the looks of things it reasonably could have been entitled "The Pragmatic CIO/CTO/IT Director/IT Engineer/IT Consultant". It is actually called The Pragmatic CSO. CSO stands for Chief Security Officer. Even if your organization doesn't actually have a CSO, there is a de facto one -- whomever is in charge of IT.

Since anyone within the IT group involved in spec'ing solutions needs to have a connection to the underlying business drivers in order to get buy-in from management for their project to proceed, this book ought to be useful to IT manager and geek alike. At least those that want to see their budget requests approved. :-)

This appears to be a promising resource with some good food for thought and practical approaches all collected together in one place. And, to boot, the approaches that look to be discussed should be readily applicable beyond IT security, to any IT project. No IT project proposal will get very far without a business case.

The book's web site is http://www.pragmaticcso.com. It is available as a regular book or electronically. You can get a sample section e-mailed to you from the web site. Or you can d/l the introduction chapter directly here:

http://www.pragmaticcso.com/Pragmatic-CSO_introduction.pdf

I have only read through the Table of Contents and Introduction and poked around at a few reviews at security blogs I monitor. If anyone else gets a copy and reads through more of it before me, please share your comments.

-jr

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.

Wednesday, August 22, 2007

Routers, Switches, and Firewalls: Marketing Benchmark Numbers versus Reality

A consistent problem when reading datasheets for networking devices (routers, switches, firewalls) is that the throughput numbers offered by the vendor are not useful without context and are coming from a bias source. Today I happen to be reading through a SonicWALL firewall datasheet and I notice a reference to RFC 2544 in the fine print:

**Testing Methodologies: Maximum performance based on RFC 2544 (for firewall). Actual performance may vary depending on network conditions and activated services
***VPN throughput measured using UDP traffic at 1280 byte packet size adhering to RFC 2544
****Throughput measured using HTTP throughput test
Well, RFC 2544 has apparently been around since 1999. It suggests a framework for a standardized methodology for benchmarking networking devices. I'm not sure why I've never come across it before. (Note: I haven't read through it yet so I'm not endorsing it).