Network Analysis Unplugged

802.11n Close to Final as TGn Draft 3.0 Approved

The IEEE P802.11 Task Group N (TGn), the overseeers of the 802.11n project, approved TGn Draft 3.0 in this week. According to the official status report fresh out of the Atlanta meetings, 240 out of 325 or 85% voted affirmative, surpassing the required 75% required to carry.  Several hundred comments, largely editorial and techical clarifications from working members since Draft 2.0, have been resolved.  A letter ballot will go out to approve TGn Draft 3.0 as an official 802.11n draft.

Further comments have already been generated by the vote on 3.0 which is typical.  According to the IEEE "Comment resolution will promptly continue in a series of authorized conference calls and a three day ad hoc session to precede the next interim meeting in Taipei."  FYI, the letter ballot on TGn Draft 2.0 that became an approved 802.11n Draft standard, generated approximlay 740 comments which eventually resulted in an approved TGn Draft 2.05.

It seems like an endless cycle but TGn is calling for a final 802.11n standard in October 2008.

The Route Less Traveled: Musings on Layer 3 Switching

According to Wikipedia, the only difference between layer 3 switching and routing is in the internal hardware implementation.  Layer 3 switching takes place in specialized hardware vs. general purpose microprocessors in traditional routers. Furthermore “Layer 3 switches can be placed anywhere in the network because they handle high-performance LAN traffic and can cost-effectively replace routers.”  Thus, the motivation behind layer 3 switching appears be a need for high performance routing in our LAN environments.

Traditionally we built our LAN (and WAN for that matter) infrastructure by dividing our IP address space into subnets, which required inter-subnet routing.  The escalation in LAN bandwidth per user and changing application performance requirements placed additional demand on routers.

But let’s not overlook one very important aspect that had a far greater impact:  Over the years we virtualized our LANs into VLANs.  The original motivation for doing this was to control broadcast domains as our layer 2 switching infrastructure grew.

Dividing our LANs up into VLANs led to new benefits in the areas of security, management, and user control to name a few.  We even dedicated VLANs to applications requiring different handling characteristics such as VoIP.  Some esoteric uses for VLANs included assigning multiple SSIDs to a wireless access point in order to map to VLANs on the wired side.  This allowed us to prioritize incoming wireless traffic, restricting uses to certain resources, or both (corporate vs. guests or faculty vs. students, for instance).  It seems that our imagination became the limit.

Unfortunately we were faced with a rather nasty problem - how to get traffic between these isolated broadcast domains?  After all, packets like ARP broadcasts were stopped cold in their tracks. The answer?  Associate a VLAN with a particular subnet and use a router behind a switch to handle VLAN-to-VLAN traffic.

How efficient!  Not.  Extra packet hops and traffic across LAN segments and significant additional load on the router ensued. This problem became affectionately known as "local routing" and all the expert systems in protocol analyzers detected it (well the good ones anyhow).  Two devices could be plugged in side-by-side in the same layer 2 switch but on different VLANs and subnets.  Instead of containing the traffic inside the switch with high-speed switching between ports, the packet was sent up to a router and back down again, wasting bandwidth and router resources.

So what came next?  We threw more backbone bandwidth and router CPU at it!  I'm only half serious here. But for a while it was the only way to solve the problem and some are still doing it this way today.  Layer 3 switching to the rescue.

By pushing layer 3 switching down to the device per port level and applying techniques similar to content addressable memory found on layer 2 switches, but for IP addresses instead of MAC addresses, we solved our little VLAN problem.  Not only that, but we can now have as many ports as we want dedicated to one VLAN/subnet to serve multiple devices.  No more restrictive one-to-one subnet-to-router port relationships.  Slick.

One thing I really like about layer 3 switches when it comes to network analysis and troubleshooting is that they decrement the TTL in the IP header, just like a conventional router.  Thus allows you can see how many store and forward devices a packet has traversed, even if they were virtual hops within a single layer 3 switch.  Try that in conventional, transparently-switched layer 2 environments.  You have to resort to manually figuring out the switch route or using specialized analysis tools to follow the switch MAC address tables via SNMP. Fluke Networks specializes in this sort of thing, as a matter of fact.

As for layer 3 switching vs. routing in your environment, much of it boils down to how many localized VLANs you have and how much traffic passes between them.  This becomes an interesting exercise in analysis because some applications like VoIP will have a dedicated VLAN up to a certain point (think about scalability) and yet other applications and servers will have their own unique switching and routing requirements.
 
Another interesting question is at what point do you push layer 3 switching down to the workgroup?  I’ll leave that as an exercise for the student.

A Company is Born: Bitcricket

We interrupt this blog for an important announcement.

I’m proud to announce the birth of Bitcricket, my new company with an aim to make the network analysis experience personal again (with apologies to HP’s “The PC is Personal Again” campaign.)  You, my blog readers, are getting this exclusive before it hits the wire.

To celebrate, Bitcricket is giving away the brand new IP Subnet Calculator for IPv4 and IPv6.  With the Federal IPv6 mandate right around the corner in 2008, what better timing?  You can play with the various IPv6 addressing schemes, beginning with a choice of IPv6 addresses already configured in your workstation (the default for Vista and MacOS X).  Meanwhile, your favorite IPv4 mask, subnet, and CIDR features are there too.  The calculator has been designed to be cross-platform; it runs natively on Windows and MacOS X (both PPC and Intel architectures).

If you’d like, I can come on-site and teach real world protocol and network analysis with the tools you already own.  I am going to assume that you are already familiar with their basic operation via the owner’s manuals or introductory webinars from your vendors.   Likewise, I will gladly work side-by-side with you on troubleshooting and optimizing your most challenging application and/or network performance issues.

Happy troubleshooting!

Thank you and back to our regularly scheduled blog.

The Ups and Downs of Network Technology Stocks

I confess that I’m not a serious day trader although I do keep one eye on the market, especially the networking sector.  I’m always curious to see how the more focused companies like a NetScout or Cisco perform vs. umbrella technology companies like an IBM or HP.  So here’s my foolish attempt to write a financial blog. It’s  not quite what you’d expect from Motley, but you may find it interesting if you’re not exactly a market guru.

A great way to do a little stock trending analysis is via Google Finance.  Just type in a company name or ticker and a nifty history chart appears. It allows you to slide a window back and forth to select a period of time, move your mouse along the line chart to display the exact date, and see the trade volume bar chart at the bottom.  I think the coolest feature is the attachment of tags along the graph that reference financially related news at those exact dates.  If you’ve never tried it, give it a shot and type in NTCT for NetScout and follow along.  The figure below is the chart as of November 4th.

If you had put $2000 into NetScout back in May, it would be worth about $4000 today.  Not a bad return for less than 6 months time.  Sure beats my bank’s 4.872% (I made that up) CD for the same time period.  Just for fun, let’s follow the chart along with the recent news, as indicated by the letters.

Letter I, May 3 – Revenues are up but net income is below analysts’ estimates by a couple of pennies.  Oh rats, stock tanks shortly thereafter to $7.25.

Letter H, June 25 – The stock is now valued at $8.75 after a slow, upward climb of a buck and a half.  Fifty cents of that increase came the day NetScout announces a “Raised Q1 Guidance.”

Letter G, July 25 –A mere month later a similar Q2 Guidance (that was a rather short quarter, no?) is issued adding another million to the revenue projection and the stock knee jerks to ten bucks before settling down into the low nines the remainder of the summer.

Letters C-F, September 20 – The Network General  acquisition announcement generates some positive interest, kicking the stock up another buck or so.

Since then, it seems we’ve had lots of time to noodle the situation.  The most recent news last week is that the acquisition is officially complete.  My sources tell me that we’ll have to wait for the first round of real integration until April 1st of next year.  Meanwhile, it’s status quo.
A number of people I’ve spoken to thought the deal  was steal for NetScout at only $50m in real money, i.e. cash.  Since then, the stock has see-sawed upward, peaking at nearly $15.50 on Halloween.  Downright scary.

As an exercise to the student, try the same for Cisco and note how you could have doubled your investment albeit over a slightly longer period, one year.  Still beats that CD.

Meanwhile, those that bought NetScout in the weeks prior to the announcement are laughing all the way to the bank.  I wish I was one of them.