5 GHz Channel Widths

20 MHz, 40 MHz, 80 MHz, or 160 MHz channel widths?

More is not always better. 802.11n and 802.11ac can provide increased throughput by bonding channels together. However, bonding channels can come at a cost.

When you move from 20 MHz to 40 MHz you are basically halving the number of non-overlapping 5 GHz channels. A 80 MHz channel width results in quartering the number of available non-overlapping channels. Fewer non-overlapping channels result in more interference and increased channel utilization which can lead to performance issues. The figure below depicts the available non-overlapping channels per channel width.



While using 80 MHz or 160 MHz channel widths seems like a good idea to increase throughput, they are not practical in high density environments. Using 40 MHz channels is recommended in most enterprise environments, and 20 MHz for high-density deployments.

In addition, high-density environments often include a mix of device types (laptops, tablets, smartphones, etc.) with varying wireless capabilities. For example, some clients may only support 20 MHz, some with support for 40 MHz, and so on. Therefore, it would be better to select a channel width that is the least , providing clients equal access to the wireless network. It’s better to have 4 clients using 20 MHz with 4 access points, instead of 4 clients with mixed capabilities communicating with 1 access point at 80 MHz. With wireless being a shared medium, the slowest clients can impede on clients with higher channel widths.

It’s important to keep this in mind when designing wireless networks. It is best practice to incorporate a  proper channel plan in your wireless surveys to provide sufficient coverage without causing too much interference or over channel utilization.


Cisco Nexus 5000 – Change Port Type

The Cisco Nexus 5000 series switch supports Ethernet, Fiber Channel, and Fiber Channel over Ethernet (FCoE) using Unified Ports.

By default, all ports are set to type Ethernet. In order to support native Fiber Channel the ports must be set to type FC.

When converting built-in ports (or fixed) ports from one type to the other a reload of the switch is required. However, when converting ports that belong to an expansion module, you can reload the expansion module itself to complete the change without reloading the entire switch.

Example: Nexus 5596 built-in (fixed) Port(s) Type Change

N5K(config)#slot 1
N5K(config-port)#port 41-48 type fc
N5K(config-port)#copy running-config startup-config

Important: You must reload the entire switch when changing the port types of the built-in (fixed) ports.

Example: Nexus 5596 Expansion Module Port(s) Type Change

N5K(config)#slot 3
N5K(config-port)#port 1-16 type fc
N5K(config-port)#copy running-config startup-config
N5K(config-port)#poweroff module 3
N5K(config-port)#no poweroff module 3

Note:It is NOT necessary to reload the entire switch when changing the port types of ports on an expansion module.

The expansion module used in this example is a N55-M16UP(=) 16-Port Unified Port Expansion Module.

Testing MTUs Across a Network with Cisco IOS

Normally, packets are fragmented into smaller packets if the original length exceeds the MTU (maximum transmission unit) size of a link. For example, if there is a 6000-byte packet traversing a network and it encounters a link with a 1500 byte MTU, it is segmented into chunks that are sized at 1500 bytes or smaller.

It may be useful to test the MTU size across a network. There is a DF (don’t fragment) bit included in an IP header which if set to one, states that the packet should not be fragmented.

When a router receives a packet with the DF set to one, it knows that it should not fragment it and in turn drops the packet if it is larger than the set MTU size. You can test MTUs across a network by utilizing the Cisco IOS extended ping command with the DF options.

For example, the output of the extended ping command with the options shown below indicates that the MTU set on this link is set at 1500-bytes. You can see that MTUs byte sizes 500, 1000, and 1500 were successful, but an MTU of 2000-bytes failed (timed out).

Protocol [ip]:
Target IP address:
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]: y
Sweep min size [76]: 500
Sweep max size [18024]: 2000
Sweep interval [1]: 500
Type escape sequence to abort.
Sending 4, [500..2000]-byte ICMP Echos to, timeout is 2 seconds:
Packet sent with the DF bit set Packet has IP options: Total option bytes= 39, padded length=40
Reply to request 0 (1 ms) (size 500).
Received packet has options Total option bytes= 40, padded length=40
Reply to request 1 (1 ms) (size 1000).
Received packet has options: Total option bytes= 40, padded length=40
Reply to request 2 (4 ms) (size 1500).
Received packet has options Total option bytes= 40, padded length=40
Request 3 timed out (size 2000)
Success rate is 75 percent (3/4), round-trip min/avg/max = 1/2/4 ms