How do I read or interpret the WCCP logs on Cisco Web Security appliance?
Available Languages
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Question
How do I read or interpret the WCCP logs on Cisco Web Security appliance?
Environment
Cisco Web Security Appliance (WSA), all versions of AsyncOS
In AsyncOS version 7.1 and below: WCCP messages are logged in the Proxy Logs.
In AsynOS version 7.5 and above: WCCP messages is seen in WCCP logs along with the proxy logs.
Check your "Log Subscriptions" (under GUI > System Administration > Log Subscriptions) to make sure the proxy and/or WCCP logs are enabled.
In AsyncOS version 7.1 and below: The WCCP logging level can be changed by entering the following CLI command:
| wsa01> advancedproxyconfig []> wccp Enter values for the various "wccp" options: Enter the log level for debugging WCCP : [0]> 3 |
On AsyncOS version 7.5 and above: The logging level for WCCP logs and/or proxy logs can be changed in GUI under "System Administration > Log Subscriptions > <Corresponding-WCCP-Log-Name>"
The logging levels will show the following data:
| 7.1 log level (CLI) | 7.5 Log level (GUI) | Information seen in logs at the configured log level |
| 0 | Critical | Errors |
| 1 | Warning | Errors, CONFIG, |
| 2 | Information | Errors, CONFIG, INFO |
| 3 | Debug | Errors, CONFIG, INFO, STATE |
| 4 | Trace | Errors, CONFIG, INFO, STATE, CHANGE (state changes) |
The logs can be broken into a few different areas (separated by space indentation) after the CONFIG is printed:
### Timestamp ###
SVC : Service ID data
Nexus : Nexus data - For each service, for each router, there is one nexus (Can be thought as a virtual basket where data is kept)
Rtr : Router data
WC : Web cache data
The following below is an explanation of the possible values you can find in the WCCP trace logging level. The exact example below is from a real scenario.
wccp: CONFIG:SG:0: type 0
wccp: CONFIG:SG:0: 80
wccp: CONFIG:0:[raptor]
wccp: CONFIG:0: GRE & L2
wccp: CONFIG:0:ret GRE & L2
wccp: CONFIG:0:TCP
wccp: CONFIG:0: 172.28.15.33
wccp: CONFIG:SG:0: Security enable <- 1
wccp: CONFIG:SG:0: Hash enable <- 1
wccp: CONFIG:SG:0: Mask enable <- 1
wccp: CONFIG:SG:0: Service direction <- 0
wccp: CONFIG:SG:0: Hash/mask on client <- 0
wccp: INFO:WCCPv2: local IP is 10.251.0.73
wccp: INFO:Accepting WCCP messages on port 2048, FD 3 at 10.251.0.73.
wccp: INFO:Openning a socket set
WCCP Configuration Information
wccp: INFO:### Timestamp 100 ###
The timestamp always start at 100. This value increments in seconds.
Service (SVC) Data
SVC: Service @<<memory pointer - for developement debugging>>
[MH_UNDECIDED] Load balancing method is undetermined at this time (hashing vs. masking)
NeedRA: Need Redirect Assign (RA). If 1 = Something in this service view has changed. If we are the DWC, we need to send a RA.
ISY@: The timestamp of the last received "I See You (ISY)" for this service.
This period: In the last 10 seconds (standard tick), how many:
Ports: Ports to be redirected to the web cache (WC). When using web-cache the ports are left blank, but port 80 will be redirected. |
Nexus Data
Nexus: For each service, for each router, there is one nexus (Can be thought as a virtual basket where data is kept) Recvd_key: Address of the DWC that sent the RA, the keychg number the DWC sent (incremental)
Rtr_mention: Router last mentioned itself @ <timestamp>
These are flags for this nexus
Rstate: ?? |
Router Data
Rtr: Router information for this nexus - duplicated for nexii on the same router
Configaddr: IP address for the router that is configured ID_addr: Advertized router identifier address From_addr: Address where the packets really came from (source IP) |
Web cache data
<IP> mentioned: The IP of the referenced WC and the timestamp it was introduced into the service ID
[ME]: This WC is the WSA were running this daemon |
Below is a complete sample output and break down of a WCCP level 3 log. In this log, the WSA is joining a service ID that has 2 other WSAs already in it. The WSA will become the DWC (since it has the lowest IP in the service):
wccp: INFO:### Timestamp 100 ### |
Nothing has been sent out yet - all initialization data.
wccp: INFO:### Timestamp 101 ### |
We sent out the first HIA @ 101 and received back an ISY @101. Below is the update of the view now that we've received an ISY.
wccp: INFO:### Timestamp 101 ### |
We recognize the other 2 web caches and they are flagged ACTIVE. The current DWC is 172.17.0.10 per the rcvd_key in the nexus. Nexus status is NEG_PEND, ReceiveID=158.
wccp: INFO:### Timestamp 111 ### |
Since the service view has changed, needRA is flagged. Expecting an RA @117. Also note that the router change # is 23. You'll see that we sent out another HIA at 111 and received another ISY at 111.
wccp: INFO:### Timestamp 111 ### |
The view has changed again and the viewchg is incremented accordingly. The router also noticed a change and incremented its change #. You'll see that THIS WSA is now being reported and labeled ACTIVE. This means that all the routers on this service have mentioned the WC.
wccp: INFO:### Timestamp 117 ### |
It's 117 now, the time specified for needing to send an RA. Now that this WSA is ACTIVE, we've decided that we are the DWC, since we are the lowest IP among the WCs. The INFO states that we need to send an RA. The load balancing method we've negotiated is MASKING. The Masking table uses a round robin index and is displayed. The INFO at the bottom shows that we have sent an RA @ 117.
wccp: INFO:### Timestamp 121 ### |
The view is now valid and we've sent 1 redirect assign, as notifed by the sent_key. At this point everything should be up and running and good.
Revision History
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
10-Oct-2014 |
Initial Release |
Contributed by Cisco Engineers
- Josh Wolfer and Siddharth RajpathakCisco TAC Engineers.
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)