Disabling useless Logs on an ASA

While reviewing the ASA logs in relation to a large wireless metering project in WA, i came across a number of log entries that were just there (hundreds of thousands of them), so here’s how to disable them:

%ASA-6-302013: Built inbound TCP connection……
%ASA-6-302013: Built inbound TCP connection…..
%ASA-6-302015: Built outbound UDP connection…..
%ASA-6-302014: Teardown TCP connection…….
%ASA-6-302013: Built inbound TCP connection ………
%ASA-6-302020: Built outbound ICMP connection………
%ASA-6-302013: Built inbound TCP connection……

To exclude these types of log messages from being recorded. Simply login to the CLI and type the following:

ASA#config t
ASA(config)#no logging message 302016

Each log message has a syslog-id which is the 6 digit number. If there are additional types of logs you want to block, simply repeat the command above for each syslog-id. Link to the massive list of syslog-id messages and their descriptions:

And the command reference:

AVC Deployment Guide


AVC provides application-aware control on a wireless network and enhances manageability and productivity. AVC is already supported on ASR and ISR G2 platforms. The support of AVC embedded within the WLAN infrastructure extends as this as an end-to-end solution, which gives a complete visibility of applications in the network and allows the administrator to take some action on the same.

Rouge Management in a Unified Wireless Network

A useful read around Cisco APs and Rouge Management.

Wireless networks extend wired networks and increase worker productivity and access to information. However, an unauthorized wireless network presents an additional layer of security concern. Less thought is put into port security on wired networks, and wireless networks are an easy extension to wired networks.

Click to access 112045-handling-rogue-cuwn-00.pdf

Wireless – Controller Discovery Process

In a CAPWAP environment, a lightweight access point discovers a controller by using CAPWAP discovery mechanisms and then sends it a CAPWAP join request. The controller sends the access point a CAPWAP join response allowing the access point to join the controller. When the access point joins
the controller, the controller manages its configuration, firmware, control transactions, and data transactions.

Lightweight access points must be discovered by a controller before they can become an active part of the network. The lightweight access points support the following controller discovery processes:

• Layer 3 CAPWAP or LWAPP discovery — Can occur on different subnets from the access point and uses IP addresses and UDP packets rather than the MAC addresses used by Layer 2 discovery.

• Over-the-air provisioning (OTAP)—This feature is supported by Cisco 4400 series controllers. If this feature is enabled on the controller (in the controller General page), all associated access points transmit wireless CAPWAP or LWAPP neighbor messages, and new access points receive the controller IP address from these messages. This feature is disabled by default and should remain disabled when all access points are installed.

• Locally stored controller IP address discovery—If the access point was previously associated to a controller, the IP addresses of the primary, secondary, and tertiary controllers are stored in the non-volatile memory of an access point. This process of storing controller IP addresses on access points for later deployment is called priming the access point.

• DHCP server discovery—This feature uses DHCP option 43 to provide controller IP addresses to the access points. Cisco switches support a DHCP server option that is typically used for this capability.

• DNS discovery—The access point can discover controllers through your domain name server (DNS). For the access point to do so, you must configure your DNS to return controller IP addresses in response to CISCO-CAPWAP-CONTROLLER.localdomain or CISCO-LWAPP-CONTROLLER.localdomain, where localdomain is the access point domain name.
When an access point receives an IP address and DNS information from a DHCP server, it contacts the DNS to resolve CISCO-CAPWAP-CONTROLLER.localdomain or CISCO-LWAPP-CONTROLLER.localdomain. When the DNS sends a list of controller IP addresses, the access point sends discovery requests to the controllers.

iSCSI Configuration

I recently worked at a client site and found it difficult to explain the various configuations for iSCSI so i have detialed them here:

Dedicated hardware for the Storage and Server connected devices keeping normal Network traffic separate from Storage network traffic due to their differing characteristics.
Segmentation – iSCSI should reside in its own vlan, and shutdown vlan1
Spanning Tree Protocol: RSTP/MST has superior port states and topology exchange mechanisms, compared to classic STP (802.1D).
Jumbo Frames– enable MTU 9216 on the switch and MTU 9000 on ESXi.
Flow Control – to be enabled on all ports, end to end, using ‘flowcontrol mode desire’ allowing the far end negotiation.
Storm Control – disabled for unicast, enabled for Multicast/Broadcast
Trunks – by default the switch will transport all vlans across the link. Only add vlans that are required. Because Cisco maintains per vlan instances of STP. More vlans means more complexity and heavier processing on the switch.
Dot1q – Explicitly set to dot1q and nonegotiate. Prevents against waste of generating/processing for Dynamic Trunking Protocol frames over the link.
Latest firmware is a given.

%d bloggers like this: