Wednesday, March 2, 2011

Six Questions to Determine if You're Ready to Analyze 10GbE Traffic

While the cost for 10GbE is coming down and adoption is rapidly rising, there remain challenges in analyzing 10GbE traffic, most notably because the industry has yet to achieve real-time analysis at 10GbE line rates. However, 10GbE analysis is available and does not have to be limiting in terms of results. Below are six questions that will help determine if your organization is fully optimized for analyzing 10GbE traffic.

1. Are you being specific enough?
It's important to know exactly what you want to capture and what information is going to be most beneficial for your analysis. Your requirements will likely vary between each network segment and odds are you are going to have to capture data at several locations. An excellent way to analyze 10GbE traffic, especially when utilization is high, is to use post-capture analysis and only save the data to a disk in real-time. Trying to capture and analyze simultaneously, in real-time, on highly utilized network segments puts much more strain on the system than if you just save data to a disk for post-capture analysis. 

2. Do you REALLY know your network?
Knowing how you expect the network to be performing is all the more critical when trying to analyze highly utilized 10GbE segments. If you're already embroiled in a complex network analysis firefight it's too late to realize that your ability to assess "normal" conditions on the network may be lacking. To get a sense of "normal" conditions before trouble arises, you should perform and archive baseline measurements across specific network traffic like HTTP and key business applications over typical cycles - like an hour, a day, and a week, for the network as a whole. Other metrics to consider include understanding packets size distribution as well as protocol and node usage over time, uncovering cycles in these metrics, which provide a "fingerprint" of your utilization. That way you will always have a clear view of the network for comparison when trouble arises. Only after convincing yourself that the basic data is in place and being collected and analyzed should you embark on detailed analysis and drill-down of packet-level data.

3.  Are you sticking to the essentials?
The temptation is to try to capture and analyze everything, especially when the source of the problem is not immediately known. But quite often certain conditions can be immediately ruled out, and using these clues to limit the collection and analysis to only what is necessary dramatically improves network analysis performance. You always have the option to customize analysis by turning off modules that are not important to the current exercise. Modules such as wireless network performance can be turned off, especially in 10GbE analysis, because odds are they are not relevant to the problem being investigated. The key is to customize your usage and take advantage of it. 

4. Do you know your limits?
Even after analysis has been streamlined to only essential areas of the network, data capture for network analysis on 10GbE networks generates a great deal of data quickly, and managing the data becomes a significant challenge. Regardless of the system used, the data is typically stored for subsequent retrieval and post-capture analysis. The two most common formats are standard packet files and databases. In either case, two metrics to manage closely are file size and frequency of disk writes. Though intuition may lead you to think that the larger the file size the better, this is often not the case as very large files require very large memory footprints to open. If the files are too large they will be unworkable on the computer being used for analysis. Smaller files, however, typically lead to more frequent disk writes, and this can rob the system of precious resources for performing the actual packet capture. Optimum performance is achieved with a balance of these two demands, and this is different depending on the hardware resources available. One rule of thumb to keep in mind is that if files are being created every 30 seconds or less, it's going to increase strain on achieving the maximum packet capture rate significantly. Starting with reasonable sized buffers and files makes all the difference. We recommend that you start with 256MB buffer for packet capture and 128MB for files to be created. After a few captures you'll quickly determine if either of these parameters can be better optimized for your system. Also, try to use the lowest number of simultaneous captures as possible. In several systems, you're allowed to create as many captures as you want, but you need to remember that for each capture you open more memory is reserved for buffering and less is available for data processing. 

5. Are you filtering and slicing?
Filtering is a way of limiting the overall number of packets captured and stored based upon user-specified criteria. Slicing captures and stores all of the packets, but it truncates the packets after a certain length, typically allowing you to store the header information but slice off the payloads. In both cases the same result is achieved, the overall amount of data to store is significantly reduced, freeing up more processing power for capture and analysis and more disk space for storing the data that's truly important to the current analysis task. 

6. Are you being reasonable?
Most network analysis systems allow multiple users to connect to the hardware performing critical network data capture and analysis tasks. Put a limit on users. Nominate an owner for each system that will monitor filters and captures. Make sure it's understood who has the authority to go kill a capture. Too many users with too many options is a recipe for disaster. You can always scale with additional systems if needed.

VoFi Analysis: Get Started with our Guide to VoFi Monitoring, Analysis, and Troubleshooting

Online mobile VoIP (or VoFi) is coming. In-Stat anticipates 171.3 million users by 2013, with annual revenues projected at $10.8 billion ("Mobile VoIP - Transforming the Future of Wireless Voice; In-Stat In-Depth Analysis," Frank Dickson, Sept. 2009). Previously on our blog we've talked about why VoFi and why now, specifically the benefits of VoFi. Now we'll focus on VoFi monitoring, analysis, and troubleshooting.
Before you panic, take a deep breath. Analyzing VoFi traffic is basically the same as analyzing VoIP traffic. Remember though that wireless exacerbates factors such as jitter, latency, and packet loss that affect VoIP. Watch Using VoIP Metrics to Identify Network Problems for the specifics.
Begin at the Beginning: Your End User's Call
When problems arise with VoIP or VoFi applications, you start in the same place. Your first step - before you begin to worry about statistics or packets - is to take the time to listen to representative calls. You want to hear what your end users are experiencing. Your ear will reveal telltale signs of latency, jitter, and packet loss. Be sure your VoIP analysis application supports playback of call audio, specifically the playback of individual RTP streams as well as the playback of the complete call. Without the audio, you can spend hours tracking down problems that aren't due to either the application or the network - for example, clicking due to a damaged handset.
Take Your Network's Pulse
Once you have listened to the call, you'll want to take a look at what's going on in your network.
Figure 1: Overview of Network Health
Immediately you see what you heard - the call quality was poor. The Mean Opinion Score graph gives an average over all calls occurring on your network. In this example there's just one call, so you see the average for the duration of that call.
Dig Deeper
With Expert Events you're able to verify what your ear told you.
Figure 2: Event Summary
With this call, you can see that there are a lot of physical errors: late packet arrival, retries, out of sequence packets, packet loss, excessive jitter, and more. With the cause identified, you can quickly begin to fix the problem. Looking at the call in its entirety, you'll notice the call is closed, it had a successful ending - meaning the call wasn't truncated - what CODEC was used, how long it was, and what the Mean Opinion Score was.
Figure 3: Call Statistics
In this example, the mean opinion score of 2.5 lets you know that the quality of the call was pretty poor. In the media view, you can drill down into each segment leg to determine why the quality was poor.
Figure 4: Call Details - R Factor, Mean Opinion Score, Packet Loss Percentage, One Way Delay, Etc.
Understand the Differences between Wired VoIP and VoFi Calls
The next two figures show both a Wired VoIP call and a VoFi call packet-by-packet. (For an in-depth discussion of these calls, watch Anatomy of a VoFi Call: Packet-by-Packet.) You'll notice that they're pretty similar. The protocols used are different and with VoFi there's the additional step of authentication.
Figure 5: The Anatomy of a Wired VoIP Call
The differences involve: wireless segments instead of wired segments; signal interference; and wireless roaming.
Figure 6: The Anatomy of a Mobile VoIP (VoFi) Call
Learn More
Last week in Toronto, Joe Habib, Director of Global Services, presented "QoS of IP Telephony: Slaying the Three-Headed Beast of Jitter, Latency, and Packet Loss" at IT360. His presentation (PDF) is now available online. If you're interested in ensuring QoS for your current (or future) VoFi deployment, you should definitely check it out.
In the presentation, you will learn:
  • What six factors contribute to poor voice quality
  •  How to establish metrics for evaluating VoIP call quality
  • How to balance high-speed, bursty data requirements with requirements of high quality voice calls
  • How to capture data for VoFi Analysis and use VoIP metrics to identify developing problems
  • How to analyze a VoFi call packet-by-packet and verify voice quality with call playback

Wireless Roaming and its Effect on Quality

Roaming occurs when a handset moves out of the range of one access point into the range of another. It gives users the mobility to move around within a local coverage area and still be connected to the network. However, roaming is one of the primary reasons why users experience problems on wireless networks. Excessive roaming times lead to poor quality for voice and video over wireless and can lead to dropped calls or data connections.
Roaming usually involves a channel change, but that depends on the type of technology deployed. If it's a multi-channel architecture, which is most likely the case, a channel change is required. When roaming occurs, the client needs to be re-authenticated and re-associated with the new access point, which takes longer than 150 milliseconds in most instances, especially when advanced features like WPA2 and WMM are in use. Most organization's wireless networks are outfitted with multiple access points (APs) and users can experience poor signal strength and performance despite proper coverage in the area if the client is connected to the "wrong" AP. Even in the most modern, centrally managed systems, the wireless client is the one who decides when to switch from one AP to another. This decision is typically determined based on the current signal strength and is executed by the underlying software controlling the wireless client radio (the "supplicant"). This software is different from manufacturer to manufacturer and from device to device, so the way the decision to roam is made varies widely. In most cases, the wireless client will wait too long and as a result the available signal strength lowers, before the client switches to an AP with greater signal strength.
New and improved standards are available that specify the conditions for "fast roaming," enabling transitions that take as little as 5 - 10 milliseconds. These specifications include:
  • 802.11i - with opportunistic key caching so there is no re-authentication step
  • 802.11r - fast BSS transition, which optimizes the hand-off as clients move from one access point to another
  • 802.11k - radio resource management of WLANs allows re- authentication to be maintained between multiple APs and has predictive capabilities
These new standards (802.11i isn't new, but it's still part of an improving situation for roaming) allow APs greater control in determining when roaming should occur and the APs are more in tune with the current performance of, and demands on, the wireless network. However, this situation is even better when the overall wireless network is under the control of a centralized manager. The issue is that adoption of 11k and 11r has been very slow, especially in wireless clients, and until adoption increases significantly users will continue to suffer slow AP transitions when roaming, leading to poor voice and video over IP performance.
In the meantime, the best approach is to carefully monitor and analyze the roaming activity on your network. Obtaining a complete and accurate view requires real-time aggregation of data from multiple channels and APs, with integrated analysis that leads to detailed reporting - who is roaming, how long each event is taking and what does the average look like for each AP. The end result is simple, yet the process is complex, demonstrating why proper network analysis tools are key to staying productive.

Has World Cup Fever Spread to the Network?

It's called World Cup fever for a reason. With millions of people watching and reading related news online, it undoubtedly increased Internet traffic. In fact, people apparently care more about soccer than they do the presidential election. The very first day of the tournament, traffic exceeded the previous record of 8.5 million views per minute (vpm), which occurred when Barack Obama was elected. According to measurements by Akamai, traffic for news sites on June 11 started to climb steadily at 6 am ET and peaked six hours later, reaching nearly 12.1 vpm.  And the fact that June 11 was a workday didn't stop people from watching. People turned to their office computers to follow the action. Being able to identify high talkers and effectively manage traffic is a must for organizations that want to stay productive and successful.

Below are some considerations for enterprises in regards to their networks during times of high traffic: 

Understand how your network performs normally

The only way a company can improve network performance is to know where they stand in terms of network demands. Then they can measure success against those baselines. By looking at Internet connections, WAN links, WLAN environments and the data center, enterprises can get a sense of how their network normally acts. A network analyzer can also help organize this information into a report that can be used to not only solve issues that currently exist, but also to allow organizations to go back in time to validate performance and bandwidth utilization as necessary.

Prune and clean WLAN traffic

Remove unnecessary traffic. Devices like printers, support stacks and protocols that aren't in use in the environment can be eliminated. Sometimes, protocols that help manage the network, like routing protocols and SNMP can be found, hogging valuable bandwidth without any purpose.

Know your options

Consider a Web surfing policy. The 2010 FIFA World Cup lasts from June 11 through July 11, 2010 and will likely suck up a lot of bandwidth. Having a set policy in place will help keep traffic down and is an option to be explored. However, getting employees to abide by regulations it's often more of challenge than it's worth.

The fact is, it is important to see new trends approaching and make changes to the network to account for an enterprise's behavior. Popular events can erode profitability and corporate security, as employees not only watch but also participate in social media discussions and gamble online. Review network analysis measures and policies now, so when 2014 rolls around, networks stay healthy and humming.

Why Deep Packet Inspection Isn't Just for Network Engineers

Network troubleshooting using deep packet inspection is a tried and true approach for network engineers - no one would ever doubt this approach when a difficult problem is plaguing the network. But suggest the use of deep packet inspection for troubleshooting slow applications and you'll likely get some blank stares. Deep packet inspection is the domain of network engineers, not application engineers, right?

Not necessarily. Analyzing decoded packet headers is definitely more suited to a network engineer, but what about the payload data from all the packets? Most network engineers find little value in the payloads, often times they filter them out to conserve analysis resources. But payloads can be of high interest to application engineers investigating application problems, including slow response time.

Consider the example of a help desk application used by a large online retailer. Support professionals, who access the help desk application for each customer call they receive, begin to experience slow response times from the application and of course the initial report is that the network is the problem. A network engineer begins his investigation and after a short time, calls in the application designer stating the problem is the application, not the network. "How do you know that," asks the application engineer? "Simple", says the network engineer. "Your application is generating the following messages. Your server command was deadlocked with another process and has been chosen as a deadlock victim. Re-run your command. And The rollback transaction request has no corresponding BEGIN TRANSACTION". Flabbergasted, the application engineer exclaims, "Where did you get that information?" "From the packet payloads involved in the slow response time transactions on the network, using deep packet inspection network analysis troubleshooting. You should try it sometime."

Deep packet inspection can provide greater value than simple network troubleshooting. Application engineers can certainly benefit, both in troubleshooting application problems and analyzing the overall behavior of an application before trouble is reported. The following four steps should be done to quickly isolate and analyze specific application data:

1.  Capture data at the appropriate location
For application analysis and tuning, it's best to locate a distributed network analysis software probe or appliance in the data center in line with the application and database servers. This will capture the data for all application users, whether local or remote
2. Save packet data to disk
By saving packets to disk and employing post-capture analysis, you can take your time in doing your analysis, without worrying about missing key data.

3. Filter stored packet data for the application of interest
Some solutions make this easier than others, but this step is crucial in creating a data set that is manageable and applicable to the application you wish to analyze. This can often be done by filtering out all traffic except traffic that has the source or destination IP of your application server or servers. If it's a troubleshooting exercise and the problem is isolated to a particular client, you can even further refine the filter to just the IP to IP conversation between the client and the server. 

4. Use built-in analysis features to look for common faults
Before diving in and looking for complex, one-off faults, use the built-in fault detection and analysis capabilities of your analysis software (again, these features can vary wildly between competing solutions) to look for common issues, like one-way traffic, database client errors, slow server response time, failed login, resource errors, etc.
Overall, even though you may get some awkward stares for suggesting deep packet inspection  to troubleshoot slow applications, in the end it's worth it because, you'll not only keep the network healthy but employees happy and productive.

Prowling the Network for a Rogue Wireless Access Point

Prowling the Network for a Rogue Wireless Access Point
By way of review, a wireless access point (WAP) is a device that allows wired communication devices to connect to a wireless network using Wi-Fi or Bluetooth. The WAP usually connects to a router and can relay data between wireless devices, such as computers or printers and wired devices on the network. Prior to wireless networks, setting up a computer network required running tons of cables through walls and ceilings in order to deliver access to all the devices in the building. With a WAP, network users can add devices that access the network with fewer cables.

Wireless access is convenient and increases flexibility but at the same time security becomes a larger issue. Wired networks usually base the security on physical access control, but if wireless access points are connected to the network, anyone close by could connect. In fact, major data thefts have been initiated by attackers who have gained wireless access to organizations by connecting wirelessly to access points inside the organization.

Most often, the hardest part is convincing IT that there is an actual wireless network security breach. Fortunately, solutions like Wildpackets OmniPeek Network Analyzer make looking for wireless signals easy.

When I suspected a breach on a customer's network, I immediately turned to OmniPeek and produced a quick demo. My first step was to check the peer map for unencrypted connctions (see illustration below).

The IT guy said that there was no problem. After I reviewed the header of an email that he had just sent, I asked him if he was sure. There was an address on this plot, which was really close to the IP address of his mail server. After a bit of head scratching, he agreed.
Looking closer at the suspect IP address, it indicated that it was coming from a D-Link wireless router. But the company didn't have any of those, so they assumed it "wasn't a problem". After offering a further explanation of rogue access points, they began to slowly agree.
In the end, OmniPeek convinced the IT department that there was a problem to be investigated - an unauthorized access point on a critical server. With tools like OmniPeek, it's easy to prowl through complex networks and identify security issues, but a well-rounded explanation of the problem is truly the key to keeping networks healthy.

Troubleshooting Your Ethernet? Look for Physical Frame Corruption!

When troubleshooting your Ethernet network, the first thing to look for is physical frame corruption. Provided an organization is using coaxial Ethernet, below are four possible causes of physical frame corruption in an Ethernet network, each one different in the way it corrupts the frame and therefore recognizable (Note: Twisted-pair Ethernet implementations will not manifest these types of corruption patterns).

1) Collisions
Generally when a collision occurs, several bytes of the preamble of the colliding frame will be read into your analyzer's buffer before the signal is completely destroyed. You will see these bytes in the hexadecimal decode of the packet as either several bytes of AA's or several bytes of 55's at the very end of the frame (remember, AAh=1010b, 55h=0101b. Depending on where the collision occurred, the preamble could be perceived as either of these). If you see more than 8 bytes of AA or 55, then the corruption was not caused by a collision and more investigation is necessary.

2) Signal Reflections
One cause of signal reflection is an un-terminated cable. Electrons travel down the wire until they reach the cable's end, where, with no resistor to absorb the voltage potential, they reflect back from the open end of the cable. Another cause of signal reflections is mixing cables with different impedances. Impedance can be thought of as the "rate of flow" of the wire. When electrons from the higher impedance wire attempt to travel through the lower impedance wire, some of them can't make it and are reflected back, destroying the signal. The final cause of signal reflections is exceeding the maximum allowable bend radius of the cable. The copper media is deformed, causing reflections.

3) Electrical Noise
Physical frame corruption caused by electrical noise is similar in appearance to corruption caused by reflections in that there is no preamble in the frame -- the frame just seems to stop short, but is different in that the frames are generally cut off at random lengths.

4) Malfunctioning Hardware
Frame corruption caused by hardware malfunctions is potentially the hardest to diagnose because of the large number of ways that hardware can malfunction. Generally, hardware malfunctions will occur either randomly or constantly, but not regularly. The type of frame corruption is impossible to predict, generally manifesting as random "garbage" in the frame, but some common signs are: 
      •  A stream of ones or zeros. A transceiver has malfunctioned and is "jabbering" on the wire. Most transceivers have jabber detection circuitry that prevents the adapter from transmitting for longer than a certain preset time.
      • Gigantic frames (greater than 1500 bytes). Same as above. 
With these four main causes dissected above, troubleshooting an Ethernet network doesn't have to be confusing. While these tips are universal, specific analyzer's behavior might differ and an organization should determine what's best in terms of troubleshooting its own specific network.

How to Play By the Rules of Fast Ethernet

With today's bandwidth-intensive multimedia applications that number is barely adequate. For example, full motion video for video conferencing can require up to 25 Mbps. That means that classic Ethernet, at 10 Mbps, can only deliver poor quality real-time video for a single session. Fast Ethernet, which runs at 100 Mbps, allows for watching a broadcast presentation in one window while running a conference with three people in three other windows, while still leaving enough margin for network-based application usage.

Below are two primary areas to think about, if you want to play by the rules, when it comes to upgrading your network from 10Mbps to 100Mbps:

1. Cabling
A common problem with Fast Ethernet is the different cabling specifications. In Fast Ethernet, twisted pair cabling either needs to be category 5 or category 3 with proper twist on all four pairs. In classic Ethernet, it was easy to distinguish  between 10Base-2 for 10Base-5. With Fast Ethernet, special care must be taken to verify that the entire connection between station and concentrator either supports TX's 31.25MHz signal or maintains T4's four pairs with proper twist. There are a number of good cable testers and pair scanners available to help in determining this for your network.

2. Hubs
The problem with hubs is the number allowed in a single collision domain. Classic Ethernet allows hubs to be cascaded up to four deep between any two stations. In Fast Ethernet, the number of hubs allowed in a collision domain is drastically reduced to only a single hub. Sometimes it may be possible to have more than one hub in a collision domain, but it will probably be easier over the long term to design a Fast Ethernet network assuming that only one hub is allowed.

What the IEEE 802.3 spec does not explicitly state is that this limitation only applies to shared 100BASE-T, not switched 100BASE-T. Because switches act like bridges in defining a separate collision domain, installing Fast Ethernet switches will allow you to work around the single-hub problem. Even if it is not necessary to deliver dedicated switched Fast Ethernet to each desktop, Fast Ethernet hubs can be connected to switches. Connecting a number of repeaters to a switch will provide shared Fast Ethernet and allow you to maintain the size of your network.

The increase in speed and quality is well worth the transition to Fast Ethernet, however the number of hubs, along with the length and the type of cabling, need to be considered when upgrading your network to make sure it's an easy switch and has an overall positive impact on your organization.

"Installing Webmin on CentOs 5"

I just installed the latest version of webmin on my CentOs 5 server. I have not used webmin in about 2 years, I can not believe how much the interface has improved. Webmin is a GUI control panel that lets you administer a Linux box.

Here is all you need to do to get it installed:

This will install some dependencies.
yum -y install perl-Net-SSLeay
Install the system:
cd /usr/src
rpm -i webmin-1.510-1.noarch.rpm
Once you log in, you will see screens like this, click the image for a larger view:

Congrats to the Webmin team for keeping the product fresh!

Network Troubleshooting Commands

Troubleshooting computer network is one of the most important job description for network administrators, system administrators, network technicians and IT consultants. A computer network may have different types of problems as being infected with viruses and spyware, hacker attacks, can access by unauthorized users and may Connectivity problems due to failure of the faulty network devices or configurations face. The following is a list of basic network troubleshooting commands that are built into the Windows-based operating systems and UNIX etc. The right use of these commands can troubleshooting helps a lot in the diagnosis and solution of problems with your computer network.
Ping is the most important troubleshooting command and checks the connectivity with other computers. For example, your system’s IP address is and your network server’s IP address is and you can check the connection to the server by using the ping command in the following format.
At DOS command prompt, type ping and press Enter
When you receive the response from the server then the connectivity is ok and if you get the error message like this means to get “Request time out” so that there is a problem in connecting to the server.
IPconfig is another important command in Windows. It shows the IP address of the computer and it shows the DNS, DHCP, Gateway addresses the network and subnet mask.
At DOS prompt type ipconfig and press Enter to see the IP address of your computer.
inconfig In DOS prompt / all and press Enter to display the detailed information.
NSLOOKUP is a TCP / IP-based command and checks domain name aliases, DNS records, information on the operating system by query the Internet domain name server. You can correct the error with the DNS server on your network
Hostname command shows you the name of the computer.
At DOS prompt hostname and press Enter
NETSTAT utility shows a statistical protocols and the current established TCP / IP connections to the computer.
NBTSTAT helps to resolve the NetBIOS name resolution problems.
ARP displays and modifies IP Physical address translation table that is used by the ARP protocols.
Finger command is used to retrieve information about a user on a network.
Tracert command is used to determine the path of the remote system. This tool also provides the number of hops and the IP address of each hop. For example, if you see how many hops (routers) are involved to achieve,, and what the IP address of each hop is then to use the following command.
At the command prompt, type tracert you a list of all the hops and their IP addresses to see.
Traceroute is a very useful network debugging command and it is in the search for the server slows down the transmission on the Internet and it also shows the distance between the two systems are used.
Route command, you can manually make entries in the routing table.
Hopefully, the above commands will help you diagnose the troubleshooting computer networking problems.

Use Mac's Network Utility to troubleshoot networks

Prepackaged commands

Quick quiz: name the eight operations the Network Utility performs. Many Mac admins won’t even remember that the utility can perform that many functions, much less the actual operations. The actual network tasks and commands that the utility performs are:
  • Info (customizable by specific network interface)
  • Netstat
  • Ping
  • Lookup
  • Traceroute
  • Whois
  • Finger
  • Port Scan
The Info window returns detailed configuration information for a specific network interface. In addition to listing IP address, hardware (MAC) address, link speed and link status, the Info page also lists transfer statistics. The best part, like all the Network Utility tabs, all information is displayed within an easily read GUI.
The Netstat tab displays results from canned Netstat operations, including routing tables, comprehensive network statistics for protocols, multicast information and socket state status. The Netstat data proves helpful when troubleshooting routing issues and network failures by offering route, destination and socket data.
Ping, which tests connectivity and latency, offers just two options: address and number of pings. Techs simply enter the address (either a numeric IP or friendly web address) to test and specify either an unlimited number of pings or a specific limit.

Lookup simplifies testing DNS resolution. Techs enter a numeric or Web address in the provided field, specify the type of information to look up and click the provided button. The command then runs. Among the lookup options are Internet addresses, canonical names, MX records, name servers, and host names, among others.

Traceroute helps identify failures along a route. By tracing the path packets follow to a destination, enterprise administrators can learn where a breakdown is occurring. I’ve solved maddening routing issues with Traceroute’s assistance. I’ve had clients whose attempts to connect to cloud-based servers in Minnesota from Kentucky failed due to bad handoffs by the ISP in Utah. Copying and forwarding the Traceroute screens are what convinced the ISP’s technical staff that the problem was with their network.

Whois assists administrators in determining the owner of registered Web addresses. Besides returning registrar information, Whois searches also display domain expiration dates, name server settings and related information. Multiple Whois databases can be searched, including those maintained by Internic, Network Solutions ,and APNIC.
Finger enables supplying a user account and node address to learn more information about a user account, such as office location, telephone number, or other data. In the Internet’s early days, seeking and obtaining such information was commonly accepted, but latter-day security concerns typically result in finger traffic being blocked by many networks.
The Port Scan tab allows an enterprise administrator to list a specific IP address or site and perform a scan of open ports. To speed results, administrators can also test ports within specific ranges or just a single port using the supplied checkbox option. Such Port Scans can assist staff in ensuring only appropriate ports are enabled, thereby tightening a network’s security configuration.

Quick work of complex commands

The Mac’s Network Utility makes quick work of common, often complex commands. The addition of an easily read GUI makes the Network Utility, and the information it returns, that much more user friendly. Reached from /Applications/Utilities, the Network tool assists engineers in diagnosing common network problems and obtaining critical information needed to speed repair.

command for cisco initial configuration

I found the following handy Cisco commands are very useful for initial configuration of Cisco devices.
I always use these commands to configure Cisco devices from fresh configuration.
router> enable
router> configure terminal
router (config)# no ip domain-lookup

The no ip domain-lookup is very useful, what this command does is tell the Cisco device not to do a domain lookup when you mistype something in the CLI. For example if you do this without the no ip domain-lookup:
router# pign
Translating "pign"... domain server (
%unknown command or computer name, or unable to find computer address

The Cisco device will try to find the computer name of pign, it doesn't know that you mistyped ping. This process could take a very long time.
If you apply the no ip domain-lookup, the Cisco device won't try to do the domain lookup.
The second command is the alias command. This command makes an alias of a command that you use frequently.
For example you often use the command show ip interface brief, you can make an alias of it to be "ship".

router (config)# alias exec ship show ip interface brief

You configure it by entering alias first, followed by which mode the command resides in - in this example the show command resides in the exec mode - type in the alias for the command, then you enter the full commands that you want to make alias.
Now you just have to type in ship instead of the long show ip interface brief command.

Next command is useful when you connect to the Cisco devices and you need a very long time to configure it.
The Cisco devices have a default time of how long you're allowed to get connected to them. Sometimes you don't want to reconnect again all the time, but mind you that the time limitation is set because of security concern.

router (config)# line vty 0 4
router (config-line)# no exec-timeout

The above commands tell the router to give you all the time that you need when configuring the router from the telnet session, it won't cut your connection. You can also configure it for the console connection.
Last one is my favorite one, you know when you're configuring a Cisco device sometimes you'd get some notifications from the device which is great, it tells you things going on in it.
But it gets annoying when you're trying to configure it and the notifications just cut down your halfway written command.
The following command tells the router to write back the command you entered before the notifications cut it:

router (config)# line vty 0 4
router (config-line)# logging synchronous   

Configure Cisco Aironet in Lab 2

Now it's time to configure Cisco Aironet Wireless Access Point for Cisco home lab.

What I'm going to do first is to configure the connectivity between the Cisco Aironet 1240AG wireless access point to the Cisco 2950 switch.

Here's the closer look of the network diagram of the wireless access point and the switch:

The network will be using VLAN 5 ( network) as the native VLAN and the rest of the VLANs will be used for the SSIDs.

There's an interface called BVI or Bridge-group Virtual Interface, what this interface does is bridge all of the interfaces in the access point - the wired and wireless interfaces - so you can use the interface BVI IP address to manage all of those interfaces.

In Cisco Aironet 1240AG wireless access points, you have 1 interface fast ethernet port, 1 console port, 1 dot11radio 0 for the 802.11G, and 1 dot11radio 1 for 802.11A.

In this configuration I only going to configure the dot11radio 0 for the 802.11G wireless network since I only have the antennas for the 802.11G.
You can configure both 802.11A and 802.11G if you want.

First we configure the interface BVI 1 IP address:

1240AG> enable
1240AG# configure terminal
1240AG (config)# interface bvi 1
1240AG (config-if)# ip address
1240AG (config-if)# no shutdown

Now set the native VLAN (VLAN 5) to the wireless access point, we have to configure the native VLAN on both of the fastethernet sub interface and the dot11radio 0 sub interface:
1240AG (config)# interface fastethernet 0.5
1240AG (config-if)# encapsulation dot1q 5 native
1240AG (config-if)# interface dot11radio 0.5
1240AG (config-if)# encapsulation dot1q 5 native

Next is to set up the SSID starting from SSID for admin and associate it with VLAN 30.
We need to configure the SSID on the dot11radio 0 interface first then configure the VLAN on the dot11radio 0.30 sub interface and fast ethernet 0.30 sub interface.
Also I set up the SSID for open authentication first.

1240AG (config)# interface dot11radio 0
1240AG (config-if)# ssid ADMIN
1240AG (config-if-ssid)# vlan 30
1240AG (config-if-ssid)# authentication open
1240AG (config-if-ssid)# end
1240AG (config)# interface fastethernet 0.30
1240AG (config-subif)# encapsulation dot1q 30
1240AG (config-subif)# bridge-group 30
1240AG (config-subif)# interface dot11radio 0.30
1240AG (config-subif)# encapsulation dot1q 30
1240AG (config-subif)# bridge-group 30

The bridge-group command allows you to group interfaces and bridge nonrouted traffic among the interfaces.
In this example traffic from dot11radio 0.30 sub interface to fastethernet 0.30 sub interface and vice versa.
Note: If you configure the SSID on the global configuration mode, the SSID will be both in the dot11radio 0 and 1.
Do the same with the SSID for guest and associate it with VLAN 40:

1240AG (config)# interface dot11radio 0
1240AG (config-if)# ssid GUEST
1240AG (config-if-ssid)# vlan 40
1240AG (config-if-ssid)# authentication open
1240AG (config-if-ssid)# end
1240AG (config)# interface fastethernet 0.40
1240AG (config-subif)# encapsulation dot1q 40
1240AG (config-subif)# bridge-group 40
1240AG (config-subif)# interface dot11radio 0.40
1240AG (config-subif)# encapsulation dot1q 40
1240AG (config-subif)# bridge-group 40

Next step is to configure the switch port connected to the wireless access point as a trunk port with native VLAN 5.
I already posted about how to do this on the last post.
Also if you are going to use dynamic IP address, make sure you have configured router as DHCP server that serving clients for VLAN 30 and 40.
Right now if you have no problem pinging the switch and router from the wireless access point, your access point is broadcasting SSID and giving IP address from router for any client joining the SSID.
The SSIDs are not secure since they use open authentication, next time I'll configure it with stronger authentication.

Configure Cisco Aironet in Lab 1

I've configured my Cisco home lab with a router that connects to cable internet and a switch with VLANs.
Now it's time to add a new device to the Cisco home lab, a Cisco Aironet 1240AG wireless access point for wireless connection.

And by the way, the image on the left is not an official logo from Cisco or anything, I just made that up.

I won't configure anything fancy this time, only give basic administration configuration and set up an open SSIDs also associate the SSIDs to VLANs.

Since I want to configure two SSIDs - one is free for all SSID with no authentication and the other one with authentication - for the wireless network, I need to configure additional VLAN on the switch.

I have already the VLAN 30 for the wireless network and want to add VLAN 40, so in total there would be 5 VLANs in my Cisco home network lab.

I made a network diagram with Cisco Aironet 1240AG wireless access point added in the picture below:

So lets start the configuration on the next post, there are some steps to complete this Cisco home lab network diagram if you haven't done so.

Starting from the wireless access point I'm going to configure the basic administration configuration such as the access point's management IP address, SSIDs and associate them to VLANs, optionally configure the authentication security options for the SSIDs, and establish trunk connection to the switch.

For the switch I'll configure VLANs and the trunk connection to the access point and the router.

Wireless home Network

At the last post I talked briefly about the wireless site survey in networking projects.

Now I want to share my view in things that I personally consider in building wireless home network.
The following points are just my considerations, most home or SOHO users just plug their wireless access points, configure them and they just work fine.

Which Standard to Use

Currently there are four common standards for wireless networking, the 802.11a, 802.11b, 802.11g, and the latest one is 802.11n. These standards use unlicensed frequencies meaning they're all free for all to use.

You can use the frequencies for your wireless networks and you can't complain if your neighbors used up all of the frequencies available and interfere with your wireless signal.
Later on this when I talk about the wireless channels in a moment.

802.11a uses the 5GHz operational frequency and has a data rate transfer of 54Mbps. This standard is not too popular anymore because it has a higher frequency meaning it has higher data rates but with shorter range.
The higher the frequency also makes it more easily absorbed by solid objects around it.

802.11b and 802.11g use 2.4GHz operational frequency. Most wireless access points support both the b and g standards since they both use the same frequency they're both interoperable.
The difference is that the 802.11b has data rate transfer of 11Mbps while the 802.11g has 54Mbps.

The latest one is 802.11n, it uses 5GHz and/or 2.4GHz frequencies and in terms of data rate and wireless range, it has biggest data rate the widest range, some vendors claim their 802.11n access points can have data rates up to 114Mbps.

I don't know the truth about that since I don't have any 802.11n devices yet.
For me I just love the sleek looking design of 802.11n wireless router from Linksys.
Cool, gotta have that someday.

Wireless Access Points Locations
Place the access points in locations that you think can reach all the clients in the network. Consider the interferences from microwave oven or cordless phones.
Also keep in mind about objects that can block, absorb or reflect the signals from the access points such as thick wall or metal surfaces.

The further you get from the access points and the more objects standing between you and the access point, the lower data rate you'd get.

Channels to Use

If one wireless access point is enough to cover your clients, check on the wireless channels that are used by access points installed near your network.
If your access point uses the same channel as your neighbor's, they will interfere the wireless signals.
If you're using more than one access points, set them to use different channels.
In 802.11b and g standards, the common channels or the clean channels that you can use are channel 1, 6, and 11. Use one for each of your access point, do not use the same channel if the signals.
What I mean by clean channels is that these channels are not overlapping each other.
The following is the graphical representation of 802.11b and g wireless channels:

The 802.11a offers more clean channels for you to choose. You can see the wireless channels that you can use for 802.11a:

Service Set Identifier or SSID is like an ID for your wireless network. I'm sure you already know this, to join wireless network you need to know the SSID or you can scan for the SSID and join it.
You can use many available wireless network sniffers to scan the SSID and the wireless channels used by the wireless networks. Some of them you can find at the list here.
Once again not every sniffer works with your wireless network card, check on it before downloading.

You can use any SSID for your wireless network, your name, company name, etc. The reason I brought this up because if you're using the upper end wireless access points like from Cisco, you can have multiple SSID broadcasted from a single wireless access point.
Maybe you need a free for all SSID for your guests, another SSID for your home users or employees, and another one just for you as the admin.
In Cisco, you can tie these SSIDs to VLANs, this can give you flexibility in deciding different security for each SSID, different access list for them, etc.

Wireless Security

Now this is the most important part of all, the wireless security or the encryption method you want to associate with your SSID.
There are some types of wireless network authentication for security from the open authentication that you can apply for guests on your WLAN to the WPA version 2.
There are also WEP that is not so secure nowadays since people can tap on your signals and decrypt them.
Best to say that WPA or WPA2 are more secure to use in your WLAN, you can also use 802.1x security.

Remember that not all hardware or wireless NIC support all authentication, most of them support the WPA authentication so it's more common to use nowadays.