Comparing RF Power

We’ve briefly mentioned a few RF basics in past articles. When discussing RF spectrum bands we were were speaking of frequency which is how often the wave occurs within a given timeframe (cycle) and is often measured in Hertz. Wavelength is closely related in that it is the physical distance that a wave travels over in a complete cycle. What we are going to dive into next is amplitude, or the height of the waveform (top peak to bottom peak). This strength of an RF signal is commonly measured by its power in Watts.

When power is measured in Watts, we call this absolute power. It is the actual amount of energy which exists in the RF signal. Sometimes though we need to compare two power signals. Either comparing two transmitters or comparing power before and after a potential change. Now this is where things get a little complicated because we normally take this next part for granted. Lets take an unrelated example, car speeds. If we have one car, a Mustang, traveling at 50mph and we have a second car, a Corvette, traveling at 100mph how do we compare their speeds? We could say that the Corvette is traveling 50mph faster, or we could say that it is traveling twice as fast as the Mustang. We never think about it, but how we describe the speed comparison depends on the mathematical method that we used to compare them. Did we subtract their speeds to get the difference ( 100mph – 50mph = 50mph difference)? Or did we divide their speeds (100mph / 50 mph = 2)? This may not seem like a big deal at first but when we start talking about transmit power, the absolute power values can differ greatly. Think about comparing your running speed to the speed of a bullet fired from a gun. It is not a linear range, but they grow exponentially. To help us deal with this, we use a logarithmic function called the decibel (dB). When each absolute power value (in W) have been converted to decibel (dB) then we can more easily compare the two values.

The decibel (dB) is an actual mathematical function. However this is not a math blog. What we need to know are just a few dB Laws so that we can do mental math. These laws are needed to be able to quickly compare power values in wireless certification exams. These laws include the Law of Zero, the Law of 3s, and the Law of 10s. A dB value of 0 means that the two absolute power values are equal. A dB value of 3 means that the absolute value being compared is double, and a dB value of 10 means the absolute value being compared is 10 times larger.

Power Change dB Value
= 0 dB
x 2 +3 dB
/ 2 -3 dB
x 10 + 10 dB
/ 10 -10 dB


To put this in practice let’s look at two quick examples. First, we have one transmitter at 5mW and another at 10mW. To get from 5 to 10, we have to multiply by two (5 x 2 = 10). Therefore according to the Law of 3s, the second transmitter is +3 dB greater.

A more complicated example would be comparing one transmitter at 5mW and another transmitter at 100mW. To get from 5 to 100 using our laws we have to make a few jumps:
5 x 2 = 10
10 x 10 = 100
So if we look at the changes we made, first we multiplied by two (x2 = +3 dB) and then we multiplied by 10 (x10 = +10 dB). So if we combine those operations (+3 dB) + (+ 10 dB) then we can say that the second transmitter is +13dB greater.

Why don’t you try a few more and leave a comment with your answers:

  1. 3mW vs 12mW
  2. 5mW vs 50mW
  3. 5mW vs 200mW
  4. 60mW vs 3mW
  5. 500mW vs 5mW



RF Channels and Bandwidth

In my previous post I outlined the frequency bands used for wireless LANs and briefly touched on the channels within those bands. I’m going to delve into those channels a little more in this post.

We’ve already established that a frequency band is a range of frequencies which are further divided into specific channels. Those channels are defined by standards bodies such as the FCC in the USA or the ITU internationally.

Channels within a band are defined based on a center frequency. Since real life is messy, we can’t limit an RF signal to just the center frequency. It spills over on each side of the center frequency to some degree, we call this sideband. The range of the spillage above and below the center frequency is what we call the signal bandwidth. Technically the bandwidth is the difference between the upper and lower cutoff frequencies. Another way to say it is that the signal bandwidth is the full range required to transmit on a specific RF frequency. These are defined in the 802.11 standards as the channel width.

As we said earlier, life is messy; but we do our best to clean it up. One of the tools we use to clean up a channel is a spectral mask. Spectral masks are overlays of what the channel should look like. Anything frequencies outside of the spectral mask are attenuated to help limit channel interference.

The problem that we sometimes run into and especially with the 2.4 GHz band is that the RF channel increments were defined prior to its adoption for communication use. In the 2.4 GHz (ISM) band the channels, or the center frequency, increment every 5 MHz. However in the 802.11 standards we have defined 11 MHz on each side of the center frequency which combined give the channel width of 22 MHz. Cramming something 22 MHz wide into something spaced out every 5 MHz quite obviously leads to channel overlap.

Hopefully this gives you some visualization on RF signal bandwidth and helps explain the discrepancy between the total number of channels in the 2.4 GHz band vs number of usable channels.

All images are my own and were crudely made using MS Visio.

Frequency Spectrums

The Bands

Way back in 1947, the International Telecommunication Union (ITU) reserved a band of frequencies for what are commonly referred to as Industrial, Scientific, and Medical (ISM) uses besides telecommunications. Those devices include things like microwaves which can create interference for radio based telecommunications. Basically these types of devices were so noisy that the ITU gave them their own frequency band. Since in the ISM band must tolerate interference from ISM devices, it was an easy spot of spectrum to be used for unlicensed use. Originally proposed in 1980 and finally authorized in 1985, the FCC began to allow the use of the unlicensed ISM bands for communications purposes.

Two of the ranges in the ISM band commonly used for wireless networks include 2.400 – 2.500 GHz and 5.725 – 5.875 GHz. In addition to the ISM bands there are also the UNII bands in America. The FCC refers to the 5 GHz band as the Unlicensed National Information Infrastructure (U-NII) band. The UNII bands are further broken down into 4 ranges:
UNII-1 from 5.150 GHz to 5.250 GHz, aka Lower Band
UNII-2 from 5.250 GHz to 5.35 GHz, aka Middle Band
UNII-2 Extended from 5.470 GHz to 5.725 GHz, aka H Band
UNII-3 from 5.725 GHz to 5.825 GHz, aka Upper Band

The Channels

In the US, the 2.4 GHz ISM band is broken down into 22 MHz wide channels separated by 5 MHz. With those requirements we get 11 available channels in the US, however a majority of those are overlapping. To avoid interference we should stick to the non-overlapping channels. This allows the use of channels 1, 6, and 11 in the US.

That seems kind of strange doesn’t it? With so many channels available why are we “limited” to only 3? If two access points use different channels which are too close together they will get overlapping channel interference. Basically what happens when devices are on the same channel they will know how long each other are transmitting for and will remain silent during that time to limit collisions. When devices are only separated by say 2 or 3 channels then they can still have collisions, but they will not hear the messages stating how long the other devices are transmitting. Therefore, this overlapping or adjacent channel interference is much worse than the co-channel interference because we can better handle the co-channel interference.

The 5 GHz spectrum is broken down into different bands listed earlier. The channels are spaced out 30 MHz wide in the lower band, and 20 MHz wide in the other bands. These channels are considered non-interfering though there is some slight overlap in the RF spectrum. This gives us a default of 25 channels available which makes the 5 GHz much more attractive for wireless networks.


This article was meant to be a brief introduction to the frequencies, bands, and channels which are used in 802.11 wireless networks. I will dig into some of these topics in greater detail, possibly touching on encoding mechanisms and the various 802.11 standards. If you found any of this information useful, please drop me a comment!

Getting nfacctd to InfluxDB via Curl

I wanted to highlight the process I used to get Netflow data gathered from nfacctd imported into InfluxDB. I found very little of this information online so I’m sharing it for my notes and if someone else needs it that’s great also.

The first step in my process was to get some temporary data coming in from nfacctd. To do this I setup a config file to write to the memory plugin with debug mode enabled and daemonize disabled. My nfacctd-test.conf file looks like:

debug: true
daemonize: false
plugins: memory
aggregate: src_host, dst_host, timestamp_start, timestamp_end, src_port, dst_port, proto, tos, tcpflags
nfacctd_port: 2100

From there I opened another SSH session and used the pmacct client to see what my traffic would look like:

robert@debian-netflow:~$ pmacct -s -e
SRC_IP           DST_IP           SRC_PORT  DST_PORT  TCP_FLAGS  PROTOCOL    TOS    TIMESTAMP_START                TIMESTAMP_END                  PACKETS               BYTES    52579     443       26         tcp         0      2016-11-21 06:24:31.0          2016-11-22 04:23:25.0          6                     400

For a total of: 1 entries

That line may be a little to wide to appear in the browser but it helped me to visualize what I was working with as I setup my awk statements later. I also made sure to use the -e flag with the pmacct client so I wouldn’t import records multiple time into InfluxDB.

The first thing I did was use sed to remove the first and last lines, and then awk to print a test with some values:

pmacct -s -e | \
sed '1d;$d' | \
awk '{print "SRC_IP value="$1" DST_IP value="$2" BYTES value="$13}'

Which gave me a result of:

SRC_IP value= DST_IP value= BYTES value=90
SRC_IP value= DST_IP value= BYTES value=

So I added another iteration of sed to remove the blank line that was previously before the last line:

pmacct -s -e | \
sed '1d;$d' | \
sed '/^\s*$/d' | \
awk '{print "SRC_IP value="$1" DST_IP value="$2" BYTES value="$13}'

The next thing I wanted to do was pass my Netflow timestamp to InfluxDB. To do this I had to reformat the timestamp value using gsub and then convert that string into a Unix timestamp with the mktime() function of gawk. (I had to install gawk to make this work on my Debian machine).

pmacct -s -e | \
sed '1d;$d' | \
sed '/^\s*$/d' | \
awk '{gsub(/[-:]/, FS); print "traffic,src_ip="$1",dst_ip="$2" value="$21" "mktime($14" "$15" "$16" "$17" "$18" "$19)}'

The final step was to pass this again to curl to write to the InfluxDB HTTP API. I also went ahead and added the variables for the rest of the Netflow tags I’m capturing in nfacctd.
When I first attempted this I noticed my timestamps were not taking correctly. After a little researched I discovered the mktime() function was creating a timestamp with seconds precision and InfluxDB was expecting a timestamp with nanosecond precision. So far I’ve just adjusted the curl statement to specify a precision of seconds:

pmacct -s -e | \
sed '1d;$d' | \
sed '/^\s*$/d' | \
awk '{gsub(/[-:]/, FS); print "traffic,src_ip="$1",dst_ip="$2",src_port="$3",dst_port="$4",tcp_flags="$5",proto="$6",tos="$7" value="$21" "mktime($14" "$15" "$16" "$17" "$18" "$19)}' | \
curl -i -XPOST '' --data-binary @-

So for now I’m going to pause with this setup to get some Grafana charts setup. I’ll also some back to tweak my nfacctd script to run as a daemon and get the curl script running on a regular schedule. That’s for another day.

Netflow via nfacctd

I’ve been experimenting with with some network management systems at home and one piece that I keep getting hung up on is Netflow. I think there is great value in being able to see what type of traffic is leaving (or entering) your network, even at a macro scale. To test these systems I’ve been using my home Juniper SRX100 and various Open Source solutions to try to grab this netflow data and do something useful. I’ve discovered that grabbing the data isn’t particulary difficult, but making it useful has been extremely difficult.

I’m currently using nfacctd, from the pmacct project. Within the pmacct project there is pmacctd which can grab traffic via libpcap and then aggregate it to make it useful for analysis. There is also nfacctd, which is the daemon that can listen for and process netflow/sFlow/IPFIX data. As far as my research has found the pmacct project is the most actively supported/developed open source project.

It is quite simple to setup nfacctd however there are no front-ends for this data. There are a plethora of plugins available to export the data, everything from an in-memory database to MySQL, Kafka, or AMQP. I’ve tried setting some custom charts written in PHP for the MySQL data, but I’m not a developer and this turns out to be an inefficient use of my time. My latest attempt though has been to get the data into InfluxDB which I can then graph on using Grafana. So far this appears to be the most promising solution.

As I complete stages in this project I plan on building documentation and sharing it via my Projects page. So far I’ve done the base Debian install and the simple InfluxDB install. My next step is to create a bash script that will use the pmacct client and curl to send the data to the InfluxDB HTTP API.

Installing Cisco VIRL using ESXi Host Client

author: admin
comments: true
date: 2015-12-18 17:18:28+00:00
layout: post
slug: installing-cisco-virl-using-esxi-host-client
title: Installing Cisco VIRL using ESXi Host Client
wordpress_id: 1276
– Networking
– Cisco
– esxi
– esxi host client
– host client
– install
– setup

– virl

I recently gave away my last Windows PC and vowed never to return. As a result I’m left with a MacBook Air for our general home use. I’ve wanted to get a VIRL lab setup since I heard about it, I even purchased some modest hardware to use as a host. However I was hesitant to proceed with VIRL because I was concerned with being able to manage my lone ESXi host without a Windows PC to install the vSphere client. I recently learned about a great new tool to manage standalone ESXi servers, the ESXi Embedded Host Client.

The host client is a VIB that you install directly on your ESXi host which offers a web interface to manage the host. You’re able to configure most items on the host, access VM consoles, and some limited performance monitoring. It really is a great tool, however it doesn’t have the full functionality that the vSphere client does. It is also only a Fling with VMware Labs, so its future is not certain. With this new tool I decided to plow along and get my VIRL lab up and running.

The first first issue I ran into was getting the ESXi .iso file onto a boot-able USB drive since my host hardware did not have an optical drive (neither does my MBA). The DiskUtility on OSX was recently changed with El Capitan so most of the how-to articles I found didn’t apply or wouldn’t fully function. I finally found a working solution from the Mac Repairs London blog. I summarized it here for posterity.

To get started I first installed ESXi (I used version 6 Update1). After the installation was completed I configured a static IP and enabled SSH. I then proceeded to install the ESXi Host Client VIB. The instructions are on the Host Client website. I used the SCP + SSH options to copy the file over and then execute the esxcli commands to install it. Now I’m able to view a web interface for the host.

The next step was to proceed with the VIRL installation. When purchasing my license I selected the VM option. The VIRL website has instructions for importing the OVA file using either the vSphere Client or the vSphere Web Client. I was able to follow the instructions for the vSphere client with only a few slight modifications:

Using the ESXi Host Client I was able to build the required port-groups (Flat, Flat1, SNAT, INT), however I had no options to enable promiscuous mode. I dug around the esxcli documentation and found out how to set this via ssh. I used SSH to connect to the host and issued the following commands (after creating the port-groups in the Host Client).

<code>esxcli network vswitch standard portgroup policy security set -o true -p Flat
esxcli network vswitch standard portgroup policy security set -o true -p Flat1
esxcli network vswitch standard portgroup policy security set -o true -p SNAT
esxcli network vswitch standard portgroup policy security set -o true -p INT</code>

After doing so command esxcli network vswitch standard portgroup policy security get -p Flat or the Host Client will display the new, correct settings.

I then proceeded to import the .ova file per the VIRL instructions. However, after a few failed attempts I finally noticed a message on the Host Client stating that if you’re attempting to import an .OVA over 1gb, you should extract and import the individual .ovf and .vmdk files. So on my OSX terminal I issued the command tar -zxvf virl.ova and then repeated the process but instead of selecting the .ova file I selected the individually extracted files and the import job successfully completed.

Now I’ve got an ESXi host and a VIRL lab all of which I can manage from my MBA!

Redistribute Connected

I’ve been building a lab scenario out for my next Pluralsight course and I discovered some interesting (or at least new to me) behavior with Cisco OSPF. I’ve already known about the different OSPF router types (ABR, ASBR), but it never really clicked for me until I saw it in real life.

The lab setup is very simple, a Juniper EX4200 connected to two Cisco 1721s running OSPF. Since I’m doing the labs on the Juniper EX4200, I was going to preconfigure the Cisco routers to already have OSPF configured. I configured the L3 interfaces and a network statement for the physical and the RID loopback. I also configured a loopback interface so I could generate some extra routes to the Juniper. I thought I would keep things simple so I just added the ‘redistribute connected’ command under the OSPF configuration without adding additional network statements. (This is me being lazy.)

When I logged into the EX4200 to verify the routes were working I noticed that one of the loopback routes I configured was showing up as an OSPF external route [OSPF/150]:
` *[OSPF/150] 00:00:17, metric 20, tag 0

to via ge-0/0/0.0 *[OSPF/150] 00:00:12, metric 20, tag 0
to via ge-0/0/23.0

So I started digging into the Cisco router to see why it was displaying the RID loopback, which had a network statement as an OSPF internal route, and the one being redistributed was showing up as external. A quick show ip ospf command and I had my lightbulb moment:
Cisco-RTR#sh ip ospf 1
Routing Process "ospf 1" with ID
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
** It is an autonomous system boundary router
Redistributing External Routes from,
Initial SPF schedule delay 5000 msecs

That’s when it hit me that the redistributed routes were automatically advertised as external. Which when I started thinking it made perfect sense. If we think about what the OSPF ‘network’ statement is actually doing; which is enabling OSPF and adding the interface(s) to the topology. Then it makes sense that my redistributed loopback interface wasn’t actually part of the OSPF topology, it was just a network being advertised into the topology. I guess I was just thinking that since it was still a local interface on a router running OSPF that it wouldn’t be considered ‘external’. That’s what I get for thinking. The ASBR function is to redistribute routes from other protocols, even if that protocol is directly connected.

When I was doing research into this behavior I found this Cisco link. So, I added a network statement to cover my additional loopback interface. This corrected the route preference on the Juniper EX4200, but I noticed that the Cisco router still considered itself an ASBR. So even if you have network statements covering all of the interfaces on the router, if ‘redistribute connected’ is still configured then the router will act as an ASBR.

This might be a ‘duh’ moment for most other engineers, and when I look back, it is. But it was a lightbulb moment for me to really understand the Type 5 LSA and the function of the ASBR in OSPF.