Verifying VTP information

Taken from "Troubleshooting VLAN Trunk Protocol (VTP)"

show vtp statistics

The general purpose of an MD5 value is to verify the integrity of a received packet and to detect any changes to the packet or corruption of the packet during transit. When a switch detects a new revision number that is different from the currently stored value, the switch sends a request message to the VTP server and requests the VTP subsets. A subset advertisement contains a list of VLAN information. The switch calculates the MD5 value for the subset advertisements and compares the value to the MD5 value of the VTP summary advertisement. If the two values are different, the switch increases the No of config digest errors counter.

A common reason for these digest errors is that the VTP password is not configured consistently on all VTP servers in the VTP domain. Troubleshoot these errors as a misconfiguration or data corruption issue.When you troubleshoot this problem, ensure that the error counter is not historical. The statistics menu counts errors since the most recent device reset or the VTP statistics reset.





Catalyst Switches Do Not Exchange VTP Information
VTP allows switches to advertise VLAN information between other members of the same VTP domain. VTP allows a consistent view of the switched network across all switches. There are several reasons why the VLAN information can fail to be exchanged.
Verify these items if switches that run VTP fail to exchange VLAN information:

VTP information only passes through a trunk port. Make sure that all ports that interconnect switches are configured as trunks and are actually trunking.

Make sure that if EtherChannels are created between two switches, only Layer 2 EtherChannels propagate VLAN information.
Make sure that the VLANs are active in all the devices.
One of the switches must be the VTP server in a VTP domain. All VLAN changes must be done on this switch in order to have them propagated to the VTP clients.
The VTP domain name must match and it is case sensitive. CISCO and cisco are two different domain names.
Make sure that no password is set between the server and client. If any password is set, make sure that the password is the same on both sides.
Every switch in the VTP domain must use the same VTP version. VTP V1 and VTP V2 are not compatible on switches in the same VTP domain. Do not enable VTP V2 unless every switch in the VTP domain supports V2.

Note: VTP V2 is disabled by default on VTP V2-capable switches. When you enable VTP V2 on a switch, every VTP V2-capable switch in the VTP domain enables V2. You can only configure the version on switches in VTP server or transparent mode.
Switches that operate in transparent mode drop VTP advertisements if they are not in the same VTP domain.
The extended-range VLANs are not propagated. Therefore, you must configure extended-range VLANs manually on each network device.

Note: In the future, the Catalyst 6500 Cisco IOS Software switches support VTP Version 3. This version is able to transmit extended-range VLANs. So far, VTP Version 3 is only supported on CatOS. Refer to the Understanding How VTP Version 3 Works section of Configuring VTP for more information on VTP Version 3.
The Security Association Identifier (SAID) values must be unique. SAID is a user-configurable, 4-byte VLAN identifier. The SAID identifies traffic that belongs to a particular VLAN. The SAID also determines to which VLAN each packet is switched. The SAID value is 100,000 plus the VLAN number. These are two examples:


The SAID for VLAN 8 is 100008.
The SAID for VLAN 4050 is 104050.


The updates from a VTP server do not get updated on a client if the client already has a higher VTP revision number. Also, the client does not allow these updates to flow to its downstream VTP clients if the client has a higher revision number than that which the VTP server sends.

spanning-tree portfast bpdufilter default

Problem - configure connections to not pass BPDUs without disabling STP on the port.

There is a good conversation on how to reduce the STP CPU utilization due to a high number of VLANs configured on a given switch on Cisco's NetPro forum.  The following links are referenced in the post (including those links here just for good measure).

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.1E/native/configuration/guide/stp_enha.html#wp1042489

 "STP PortFast causes a Layer 2 LAN interface configured as an access port to enter the forwarding state immediately, bypassing the listening and learning states"

 "When configured for PortFast, a port is still running the spanning tree protocol."

 http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.1E/native/configuration/guide/stp_enha.html#wp1033403

 "PortFast BPDU filtering can also be configured on a per-port basis. When PortFast BPDU filtering is explicitly configured on a port, it does not send any BPDUs and drops all BPDUs it receives."

The Catalyst 6500 configuration guide lists the following information about the command spanning-tree portfast bpdufilter default:

Be careful when enabling BPDU filtering. Functionality is different when enabling on a per-port basis or globally. When enabled globally, BPDU filtering is applied only on ports that are in an operational PortFast state. Ports still send a few BPDUs at linkup before they effectively filter outbound BPDUs. If a BPDU is received on an edge port, it immediately loses its operational PortFast status and BPDU filtering is disabled. 

When enabled locally on a port, BPDU filtering prevents the Catalyst 6500 series switch from receiving or sending BPDUs on this port.

Caution: Be careful when using this command. This command can cause bridging loops if not correctly used.

One of these days I'm gonna get organiz-ized!

I've been carrying my cables around in Ziploc® bags for far too long.  Now I am officially organiz-ized (at least when it comes to my cables).

I found some great, heavy-duty fabric (Made in USA) and commissioned my favorite Etsy seamstress Zigzagstitches to whip up some zippered cases for all the stuff I carry in my backpack.  I thought I'd share pictures of her handiwork in case anyone else needs help with organization. She's a whiz with a sewing machine!

(The first bag I had commissioned was the cool black & white circuit board bag.  I found the fabric online & shipped it to Zigzagstitches so she could make me a bag out of it.)

Each bag is lined in a heavy-duty canvas and will stand up to being kicked around inside my backpack much longer than a flimsy Ziploc®.

I also had some small zippered pencil case style bags made to hold all the little cables for my camera, itouch and Blackberry as well as one for my wireless tools/USB sticks.

Goodbye you ratty old Ziploc® bags, I can't say I'll miss you.  I'm glad to finally be able to pull out my kit of site survey tools and not have it crinkle and crackle like a brown bag lunch.

Personal Wi-Fi Hotspot devices VS Enterprise Deployed Guest networks

Last week I was performing a passive site survey of a currently deployed WLAN in several large hospital facilities in south Texas.  During the course of a week and entering countless patient rooms I validated an opinion I'd had for some time.

Out of the dozens of patient rooms I entered, at least 12 or so people understood what it was that I was doing and told me they were using the guest WLAN provided by the hospital.  This, in itself is unusual.  The majority of the hospital staff seemed unaware that a WLAN had been deployed or was in use.

What really struck me was the number of hospital patients and guests that were using their own personal wireless hot spots.  One patient told me he wasn't using the guest network because it didn't allow him to login to his Facebook page, so he was using his MiFi device instead.  Another visitor told me she was using her MiFi device because the guest network didn't let her play her favorite online Tetris game.  Whatever the reason, the presence of these personal wireless devices is detrimental to the overall reliability of the 2.4 GHz (802.11b/g) wireless infrastructure within the enterprise.  Seemingly, any attempts to restrict usage of the guest wireless network will only lead to more and more people choosing to use their own personal wireless hot spot devices for internet connectivity.

In short, I think we've reached the point where the timeline for abandoning  the 2.4 GHz wireless network for business uses in favor of moving mission-critical wireless connectivity over to the 5 GHz spectrum (802.11a) should be ramped up considerably.  There are simply too many sources of interference in the 2.4 GHz frequencies on top of the rapidly expanding number of personal Wi-Fi devices all competing for the same small segment of unlicensed 2.4 GHz spectrum.

Gestalt IT Wireless Field Day March 17-18 2011 SJC

So, you may or may not have heard that there is going to be a Wireless Field Day taking place in San Jose March 17-18th through a lot of hard work by the fine folks at Gestalt IT.  Stephen & Claire along with the help of the delegates are working to make the first Wireless Field Day simply stupendous.  There hasn't been anything like this put together before - and this is a first in many regards.

The current list of Wireless Field Day delegates is growing, and is sure to be a who's who of the wireless wizards of social media!  The up to date list of Wireless Field Day Delegates is here.  The information coming out of the Wireless Field Day will be shared via this page from GestaltIT.com

Delegate Steve Williams has already written up a great post about his excitement for the event, and I'm sure we'll see more and more of the delegates discussing their excitement for the event as the date draws closer.

H-Reap factoids as of 11/2010

Taken from the H-REAP deployment guide:


The CAPWAP, on which Cisco's Unified Wireless Network architecture is based, specifies two different primary modes of wireless access point operation:


Split-MAC—In Split-MAC mode, the system shares key functions of the 802.11 specification between the access point and the controller. In such a configuration, the controller is not only responsible for much of the processing of things such as 802.11 authentications and associations, it also acts as the single point of ingress and egress for all user traffic. Split-MAC access points tunnel all client traffic to the controller via an CAPWAP data tunnel (CAPWAP control also follows the same path.).


Local MAC—Local MAC, in implementing full 802.11 functionality at the access point, allows for the decoupling of the data plane from the control path by terminating all client traffic at the wired port of the access point. This allows not only for direct wireless access to resources local to the access point, but it provides link resiliency by allowing the CAPWAP control path (the link between AP and controller) to be down while wireless service persists. This functionality is particularly useful in small remote and branch offices across WAN links where only a handful of access points are needed and the cost of a local controller is not justified.


H REAP WAN Considerations
Because the H REAP has been designed specifically to operate across WAN links, it has been optimized for such installations. Though H REAP is flexible when it comes to these remote network design scenarios, there are still a few guidelines that need to be honored when architecting a network with H REAP functionality.


Hybrid REAP supports up to four fragmented packets or a minimum 500-byte maximum transmission unit (MTU) WAN link.


Roundtrip latency must not exceed 300 milliseconds (ms) for data and 100 ms for voice and data between the access point and the controller, and CAPWAP control packets must be prioritized over all other traffic.


The controller can send multicast packets in the form of unicast or multicast packets to the access point. In hybrid-REAP mode, the access point can receive multicast packets only in unicast form.


In order to use CCKM fast roaming with hybrid-REAP access points, you need to configure hybrid-REAP groups.


Hybrid-REAP access points support multiple SSIDs.


NAC out-of-band integration is supported only on WLANs configured for hybrid-REAP central switching. It is not supported for use on WLANs configured for hybrid-REAP local switching.


Note: During an upgrade, each AP needs to retrieve a 4 MB code update across the WAN link. Plan upgrades and change windows accordingly.


In order to ensure that support for this stated latency limitation is in place, it is strongly recommended that between the access point and controller, priority be configured in the intermediary infrastructure to elevate CAPWAP (UDP port 5246) to the highest priority queue available. Without priority placed on CAPWAP control, spikes in other network traffic can very likely cause H REAP access points to frequently shift from connected to Standalone modes as WAN link congestion prevents access point/controller messages (and keep-alives) from being delivered. It is highly recommended to Network designers, who plan to deploy HREAP AP over WAN links, to test all their applications.


Frequent H REAP flapping causes serious connectivity issues. Without proper network prioritization in place, it is prudent to place controllers at remote sites to ensure consistent and stable wireless access.


Note: Whether H REAP is configured to tunnel client traffic back to the controller or not, the CAPWAP data path is used to forward all 802.11 client probes and authentication/association requests, RRM neighbor messages, and EAP and web authentication requests back to the controller. As such, ensure that CAPWAP data (UDP port 5247) is not blocked anywhere between the access point and controller.


Hybrid REAP groups
In order to better organize and manage your hybrid REAP access points, you can create hybrid REAP groups and assign specific access points to them. All of the hybrid REAP access points in a group share the same CCKM, WLAN, and backup RADIUS server configuration information. This feature is helpful if you have multiple hybrid REAP access points in a remote office or on the floor of a building and you want to configure them all at once. For example, you can configure a backup RADIUS server for a hybrid REAP group rather than having to configure the same server on each access point. For each controller, you can configure up to 20 hybrid REAP groups with up to 25 access points per group.


To Trunk or not to Trunk
H REAP access points may be connected to 802.1Q trunk links or untagged access links. When connected to a trunk link, H REAP access points send their CAPWAP control and data traffic back to the controller via the native VLAN. Locally switched WLANs may then have their traffic dropped on any available VLANs (native, or otherwise). When set to operate on an access link (with no 802.1Q visibility), H REAP s forward all CAPWAP messages and locally switched user data out to the single, untagged subnet to which it is connected.


General guidelines for the selection of the switchport mode for H REAPs are as follows:
Use a trunk link if more than one WLAN is configured for local switching and if traffic on these SSIDs needs to be dropped on different subnets. Both the access point and the upstream switchport need to be configured for 802.1Q trunking. The configuration of H REAPs for 802.1Q trunking is the most common configuration and provides the most flexibility. Native VLAN also needs to be configured on the switchport that the H REAP is connected to as all CAPWAP communication between the AP and the WLC is on the native VLAN.


Use an access link when H REAPs either do not have more than a single locally switched WLAN or have multiple locally switched WLANs that do not require wired-side separation. Be aware that a trunk link can still be desirable under these conditions if separation between CAPWAP messaging and user data is desired. But, this is neither a configuration requirement, nor a security risk.


Note: H REAP access points default to operate on untagged, access link interfaces.


Radio Resource Management (RRM)
Transmit Power Control (TPC) algorithms in RRM are not triggered until four or more access points are within range of each other. So, some H REAP installations might never power their radios down. As such, without ever being able to power down their radios in the first place, H REAPs do not adjust transmit power upward to compensate in the event of a coverage hole detection.


In Standalone mode, RRM functions on H REAPs that require controller processing are not supported.


Note: H REAP was not designed to provide location services. Therefore Cisco cannot support stated location accuracy claims in H REAP deployments.


L2 and L3 Mobility
Roaming events between H REAPs on locally switched WLANs may take between 50 ms and 1500 ms, which depend on WAN latency, RF designs and environmental characteristics, as well as security types and client-specific roaming implementations.


Layer 3 roaming is not supported for locally switched WLANs but is supported for centrally switched WLANs.


Other H REAP Limitations
H REAPs do not support WGB.


If you have configured a locally switched WLAN, then Access Control Lists (ACLs) do not work and is not supported. On a centrally switched WLAN, ACLs is supported.


Any changes to a locally switched WLAN configuration on the Controller cause a temporary loss in connectivity as the new configuration is applied to the H REAP. As such any clients on these locally switched WLAN get temporarily disconnected. The WLAN is enabled right away and the clients re-associate back.


The controller can send multicast packets in the form of unicast or multicast packets to the access point. In hybrid-REAP mode, the access point can receive multicast packets only in unicast form.


Per @samuel_clements there is no limit to the number of H-REAP APs that are supported in newer versions of controller code.  Seconded by @revolutionwifi & link to a good discussion on H-REAP provided by @IndTechTalk

The H-REAP feature matrix document is also quite useful.

Comparing 802.1x Authentication Methods

I could have sworn I'd already linked to this image.  This is the chart I frequently refer to when I get asked 'What is the best security method for us'.  This chart will help you decide how secure a WLAN can be depending on the security mechanisms currently at your disposal (read: no additional spending required).  This chart is a bit old, and doesn't list new OSes like Windows 7, but you get the idea.