CCIE or Null!

My journey to CCIE!

Archive for January 2011

Understanding a Wi-Fi connection.

with 6 comments

Just some more details on how drastically different wireless networks differ from the traditional wired network is understanding the client connection. Surely we all understand how the wired connection works, we plug in a cable two of the four pairs carry data then speed and duplex setting are auto-negotatiated. However when you look at a wireless client you see an antenna, signal strength, data rate, RSSI, power level, and SNR values definitely a little more to think about.

I’ll start with RSSI, which is the Received Signal Strength Indicator this value is typically shown as a negative dBm value (dB and watt values are a topic for another post). RSSI is the measurement of power in an RF signal, the more power in an RF signal the better the connection quality is. So the closer this value is to 0 the stronger the signal is. So a value of -61 is stronger then a value of -74. Now different vendors do have different scales some vendors will have a max value of -100 while others go higher or lower, of course signals that weak should be avoided (and probably won’t work anyway). So it’s best to get some documentation from the vendor of your client WLAN cards to see the RSSI value range. The value of the RSSI will also play a role in the connection speed, and once again vendor documentation will provide the RSSI value to link speed ratio (and do keep in mind many other factors play a role in the connection speed as well).

SNR is the Signal to Noise ratio, this is how much stronger the wireless signal is compared to the noise floor surrounding the WLAN client. This is shown in a positive dB value. Too much RF noise around the WLAN client will cause collisions resulting in frames being retransmitted thus lowering the throughput of the connection. Try connecting a cordless phone that works in the 2.4 GHz range right next to a b/g access point, the phone can generate enough RF noise to cancel out the wireless signal completely. It’s typically best practice to have the SNR value 20 to 25 dB’s away from the RSSI value. So to go back to our previous example if our RSSI is -61 we would want our SNR value to be around -86, or if our RSSI is -74 we would want the SNR to be -99.

The data rate can be one of many values depending on which wireless standard you are connecting with. Be aware though that wireless is a shared medium so it’s half duplex it can not transmit and receive at the same time. So your actual throughput will be about half of what your client is connecting at. A WLAN device showing a connection of 54 Mbps will really have throughput of maybe 30 Mbps. Throughput can be tested using nice little utility called iperf which is available on both Windows and Linux platforms for free.

The power level is measured in mW and depicts how much power a WLAN device is using to maintain the connection. Its typically best practice to design your WLAN infrastructure so your devices operate at half their max output power. This way if an AP goes down neighboring AP’s can double their output power and maintain the availability of the WLAN.

So the overall signal strength/quality registered by client will be a mixture of all those variables.

Below is a screen shot from the Cisco Aironet Site Survey Utility

Here you will see the RSSI at -50 dBm and noise level of -96 dBm, resulting in an SNR value of 46 dB. This utility will also provide you with the BSSID (MAC Address) of the AP you are connecting to along with the RF Channel, 64 in this case utilizing 802.11a.

Written by Stephen J. Occhiogrosso

January 24, 2011 at 9:38 PM

Who’s congesting my network?

with 6 comments

I figured I would write a post concerning some features built-in to most Cisco routers nowadays that can be lifesavers in identifying network congestion and who/what is causing it.

The first feature I want to mention is NetFlow, this nifty little feature will identify network traffic by the protocol as well as determine how much throughput each protocol is using giving you a clear view of the traffic traveling your network. You configre it on a per interface basis, specify the address you want the Netflow information sent to, and also the port you want it sent out on. 2055 is the default port used by the SolarWinds Netflow Analyzer in this case (Free Tool)

You can issue the sh ip cache flow command to see the output. While this output can be duanting at first it is actually fairly simply to understand once you realize what each column signifies. A nice shortcut for analyzing netflow is to find a free tool that will do it for you.

Their is more information displayed but from this point it looks almost identical to the sh ip flow top-talkers command shown below, the important thing here is the breakdown of the major protocols.

The next really cool feature is called top talkers after you configure this you can quickly see which end devces on your network are taking up the most bandwidth.

The configuration is as follows:

A fairly straight forward configuration, first you enable top top talkers and then configure the parameters you want. You can set top-talkers to sort by the amount of bytes from each end device or by the amount of packets. You can also configure the amount of devices you want to see, anything from 1 device to 200 device I usually prefer to simply see the top 10 devices (well 8 in this case)

You view the top talkers with the sh ip flow top-talkers command:

As you can see the output is placed nicely in a few columns, identifying the source interface and IP address, the destination interface and IP address,  the protocol number (Pr column), the source and destination ports (keep in mind these are in hex format and need to be converted to decimal), and lastly the amount of bytes transferred in this case.

So whether someone has introduced a new program, or a users decides to try and download the entire internet you should be able to easily identify it. Those two built-in features alone can help you troubleshoot any network congestion your network experiences with your Cisco devices.

Written by Stephen J. Occhiogrosso

January 13, 2011 at 1:13 PM