Helpful commands for anyone sitting the CCIE lab

no  whoops, I meant just -> logging synchronous
Router(config)# line con 0
Router(config-line)# logging synchronous

This command allows all of the logging output to show up on a separate line from the configuration commands you're typing at the console.  Meaning you can keep typing your commands w/o getting interrupted by a message you want to see, but don't want to be wedged in the middle of what you were trying to type. (thanks to SebaPast for being the first to set me straight!)

no ip domain-lookup

This command disables the DNS to IP domain lookup feature.  This "feature" keeps you waiting at the CLI while the AP/switch/router attempts to lookup the IP address of the invalid command you entered.

setup NTP on the location appliance

(just a link to the paragraphs and paragraphs of 'how-to' for this task)

config time ntp server 

This command works on controllers & on WCS when it is running on Linux.

When WCS is running on Windows or Linux, it checks the OS time clock every 24 hours for a time update.  If you make a change to the time - you need to stop/start the WCS service for the time change to take effect.

sntp server A.B.C.D

This command on a Cisco 1242 will point the AP to an NTP time source.

While googling SNTP I came across an article by @ioshints (wouldn't you know!) explaining SNTP Will Not Work if You've Configured NTP.  This I did not know.

I also found a great post by Adam about SNTP time sync on Cisco Aironet 1242

service timestamps debug datetime localtime show-timezone msec

service timestamps log datetime localtime show-timezone msec

logging on

logging A.B.C.D [ip address of syslog server]

logging console level

logging monitor level

logging facility facility-type

--> This command is used to specify the facility level used by the syslog messages and the default is local7

logging trap level

--> default is informational and lower

• Error messages about software or hardware malfunctions, displayed at the errors level.
• Interface up/down transitions and system restart messages, displayed at the notification level.
• Reload requests and low-process stack messages, displayed at the informational level.
• Output from the debug commands, displayed at the debugging level.

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.