Archive

Archive for January, 2009

CCNA Virtual Lab

January 18th, 2009 No comments

Virtualization has been a hot topic in the IT would for a while now. From the datacenter to our home labs, virtualization is changing the way we work and play.

I recently made an addition to my lab that I think will allow me to add more complexity to lab simulations, at the same time it has saved me some money! A few months back you will recall that I purchased some additional hardware and made a virtualization server (using Windows 2008 Server and Hyper-V). Since that setup was not getting much use, I went a different route that should prove to be more useful.

There are three physical parts to my current lab setup. They are: 16U rack with physical network equipment, server running VMware Server, and my laptop. The rack consists of the following:

  • 1 x 2528 access server
  • 3 x 2525 routers
  • 1 x 3640 router (NM-2FE2W, NM-1E2W, NM-8A/S)
  • 1 x 2924 switch
  • 2 x 3550 switches (L3 support)

The server running VMware has a quad core Intel Xenon processor with 8GB of RAM and 5 x 500GB hard drives in a hot-swappable drive cage. This used to be a file server which is why it has so many hard drives and a hot-swap cage. Only one hard drive is being used to house both the operating system and all of the virtual machines. Finally, my laptop is my old reliable Compaq Presario V2000. With 1GB of RAM, a 1.8Ghz AMD Turion processor, and a 5400RPM hard drive this thing gets bogged down in a hurry when I start running anything more than a few routers in GNS3! It survived five years of college as many other laptops around me crumbled, so I can’t come to replace it just yet!

How do I connect all of this? It’s not overly complicated once you get everything straight in your head, however when putting something like this together for the first time I suggest some actual planning! The diagram below will help illustrate what I have done.

The two large boxes at the top (vmware-server and Laptop) are the two physical computers. The setup on my laptop is straightforward, since I only have GNS3 running there (no VMs). As you can see, I use the cloud feature in GNS3 to connect the wired network card on my laptop to my physical lab (The rack at the bottom of the diagram).

The VMware server is what complicates things. First you will notice that the server has two network cards. I have used this to my advantage to segment some things out. The first network card (eth0) is used for management of the VMware server through the web interface, as well as linking any VMs to the Internet (either directly via a bridged network or through some GNS3 routing). The second network card (eth1) is strictly used to tie the VM running GNS3 to my physical lab rack. There are two virtual network adaptors (vmnet0 and vmnet5) that are bridged directly to each of the physical network cards.

Inside of the VMware server there are four other virtual network adaptors (vmnet1 to vmnet4). These four devices are host-only network adaptors. This means that they are not tied in any way to either of the servers physical network cards. Notice that the GNS3 VM connects to each of these virtual network adaptors. I did this so that I can perform routing between each subnet. The GNS3 VM is also tied to each of the bridged network adaptors so that I can route traffic externally as well.

One thing not pictured in the diagram is the other VMs I use. These are simple setups, as each VM connects to one (and only one) of the host only network adaptors. These VMs act as endpoints/nodes to test connectivity between other nodes.

Hopefully this will provide other people with a jumping off point for adding virtualization to their lab. This can be accomplished for a small amount of money. A desktop with plenty of RAM will work just fine as a VMware server. Combine the price of memory now with the low, low price of free for Linux and VMware Server and you have an incredible deal!

Categories: Cisco Lab, Virtualization Tags:

Lab On The Go

January 12th, 2009 No comments

It seems like not too long ago that I had to jump through hoops just to be able to get some lab time in at work, or when I was otherwise away from my rack. My original routine for remote labbing was to leave the equipment I needed powered on with my laptop connected via console cable to my access server. I then setup port forwarding to my laptop so that I could RDP into it while I was at work.

This setup was inefficient for several reasons. The most obvious was the fact that I had to leave all of that equipment powered on for a full eight hours just so I might be able to get less than an hour of lab time. Another problem I ran into was that the connections between the equipment could not be reconfigured when I was not physically present.

My recent purchase of a Western Digital Passport external hard drive sent me on a quest for more portable apps to install onto it for remote use. It was then that I discovered GNS3 could be installed onto a flash drive or external hard drive (just about any removable media for that matter). The process was simple, during the installation of GNS3, you just set the installation directory of a folder on your removable media. The installation only requires about 40MB, so a minimal amount of space is required. From there you just copy the IOS images you need onto the flash drive and you are good to go!

It should be noted that GNS3 does WinPcap if you would like to bind some of your labs to the physical network card on the laptop. If you do not require this feature, then there are no other dependencies.

Links:

GNS3

GNS3 on a USB Key

Categories: CCNA Study Tags:

Network Jitter and VOIP

January 4th, 2009 No comments

Network jitter, or jitter, is the name given to a variation in the time delay between packet arrival. This concept is better explained using the illustration below.

In the above illustration, the gaps between each of the packets represent the time it takes for each packet to reach the destination. Jitter is shown by the uneven gaps between packets two and three, as well as three and four.

In a perfect world, every packet should arrive at a set amount of time after the preceding packet. In reality, there are many factors to take into consideration when jitter is experienced. Sometimes the cause of jitter is beyond your control, since issues may arise outside your network.

The effect Jitter has on network applications can vary. It is unlikely for a user surfing the internet to report a problem that is a result of jitter. Other real time services, such as VOIP, can experience serious problems related to jitter. Lucky for us, many vendors (including Cisco) build provisions into their routers that can compensate for jitter.

On Cisco routers, the playout delay buffer (PDB) is the mechanism that is used to compensate for jitter. The PDB stores the incoming packets and then sends them to the next destination as a steady stream. This buffering process is similar to that used with other real-time protocols such as those used for audio and video. The ultimate goal of the buffer is to negate any jitter by relaying the packets as a steady stream. An illustration of the packets before and after the playout delay buffer does its job is shown below.

The buffer can only compensate for packets that are delayed within a specified range. If packets start to arrive outside of the working range of the buffer, those packets are dropped. With VOIP a dropped packet can mean the loss of some of the audio, which can make part of a conversation seem choppy.

In a Cisco router, the playout delay buffer sends a steady stream of packets to the digital signal processors. The main job of the DSP is to convert the audio from digital to analog. A secondary function of the DSP is to compensate for missing packets. If a packet is missing, the DSP can make an educated guess as to the contents of the missing packet and insert that missing piece into the audio stream. The result is that the end user never hears a difference. The DSP can only compensate for a finite amount of dropped packets before the end users start to notice an effect on call quality.

Jitter can present some interesting problems, particularly when you are dealing with real-time services. Cisco has built some provisions into their routers to help counter some of the effects of jitter.

Categories: Voice (VOIP) Tags:

Documenting the Undocumentable

January 3rd, 2009 No comments

You just landed that new networking position after months of interviews and waiting! If you’re lucky, the hard part is over and you will slip into a position where the network paracticly manages itself. Meanwhile, back in the real work…

Network administrators are like software developers. That is documentation is usually an afterthought, and sometimes it is not a thought at all! We have all faced this problem. This is the situation that I walked into this past summer. The key here is not to look at the situation as a problem, but as a challenge.  Our largest building was our biggest challenge. The cabling was not done in a structured manner, and in some cases I was baffled how some of the “redundant links” did not cause network loops since STP was not activated.

The biggest challenge in this building was troubleshooting link problems between the switch closets. Dropping the link from one cabinet to another would cause half the building to go down in some cases. Without proper network documentation, we were left in the dark. With the way the cabling between the switches was laid out, it would be a copious amount of work document this by hand. Enter Solarwinds with their LANsurveyor product.

LANsurveyor can be used to create network maps with a minimal amount of information. In my case, I was able to create a network map for each of our seven buildings using nothing more then the IP address range for that building and our SNMP community strings. Even if your community strings are not standardized, changing them on your devices would be considerably less work than creating a manual network map.

This convenience does come at a price. The version I use sells for about $2000 and is a standalone piece of software. There is a $500 version that integrates with Visio, but I have not used that so I cannot comment. You do have the option of downloading a trial before you purchase the software. If $2000 is not in your personal budget, you may be able to sell the software to your boss if you calculate all of the man hours it would take to map your network by hand!

Below are some screen shots of LANsurveyor, one of which shows the chaotic network map for the building I mentioned above.

LANsurveyor network discovery settings:

Sample Network Map (I zoomed out so you can see how difficult this would have been to document by other means):

Note: This is not an advertisement for Solarwinds, and thus I am not profiting from this post! If you have used other software to solve a similar problem, please share your experiences in the comments section.

Categories: General Tags: