-
Cisco ACNS Software Command Reference, Release 5.5
-
Index
-
Preface
-
Command Line Interface Command Summary
-
Cisco ACNS Software Commands - aaa accounting to clear
-
Cisco ACNS Software Commands - clock to hostname
-
Cisco ACNS Software Commands - http to ldap
-
Cisco ACNS Software Commands - less to rtsp (global config)
-
Cisco ACNS Software Commands - rtsp to show hardware
-
Cisco ACNS Software Commands - show hosts to show statistics content-distribution-network
-
Cisco ACNS Software Commands - show statistics content-routing to show statistics tvout
-
Cisco ACNS Software Commands - show statistics udp to tacacs
-
Cisco ACNS Software Commands - tcp to wccp router-list
-
Cisco ACNS Software Commands - wccp rtsp to write
-
Appendix A: Acronyms
-
Appendix B: Standard Time Zones
-
Feedback
Table Of Contents
url-filter (global configuration)
2tcp
To configure Transmission Control Protocol (TCP) parameters, use the tcp global configuration command. To disable TCP parameters, use the no form of this command.
tcp client-mss maxsegsize
tcp client-receive-buffer kbytes
tcp client-rw-timeout seconds
tcp client-satellite
tcp client-send-buffer kbytes
tcp cwnd-base segments
tcp ecn enable
tcp increase-xmit-timer-value value
tcp init-ss-threshold value
tcp keepalive-probe-cnt count
tcp keepalive-probe-interval seconds
tcp keepalive-timeout seconds
tcp memory-limit {low-water-mark megabytes | high-water-mark-pressure megabytes | high-water-mark-absolute megabytes}
tcp server-mss maxsegsize
tcp server-receive-buffer kbytes
tcp server-rw-timeout seconds
tcp server-satellite
tcp server-send-buffer kbytes
tcp type-of-service enable
no tcp {client-mss | client-receive-buffer | client-rw-timeout | client-satellite | client-send-buffer | cwnd-base | ecn | increase-xmit-timer-value | init-ss-threshold | keepalive-probe-cnt | keepalive-probe-interval | keepalive-timeout | memory-limit | server-mss | server-receive-buffer | server-rw-timeout | server-satellite | server-send-buffer | type-of-service}
Syntax Description
Defaults
tcp server maximum segment size: 1460 bytes
tcp client maximum segment size: 1432 bytes
tcp server-receive-buffer: 32 KB
tcp client-receive-buffer: 8 KB
tcp server-rw-timeout: 120 seconds
tcp client-rw-timeout: 120 seconds
tcp server-send-buffer: 8 KB
tcp client-send-buffer: 32 KB
tcp keepalive-probe-cnt: 4
tcp keepalive-probe-interval: 75 seconds
tcp keepalive-timeout: 300 seconds
tcp server-satellite (RFC 1323): disabled
tcp client-satellite (RFC 1323): disabled
tcp type of service: disabled
tcp cwnd-base: 2 segments
tcp increase-xmit-timer-value: 1
tcp init-ss-threshold: 2 segments
Table 2-172 gives the default TCP memory limit settings.
Table 2-172 Default TCP Memory Limit Settings
1 GB, 2 GB, or 4 GB
360 MB
380 MB
400 MB
512 MB
180 MB
190 MB
200 MB
256 MB
25 MB
28MB
30 MB
Command Modes
global configuration
Usage Guidelines
Caches are typically deployed for any of the following reasons:
•
To save bandwidth
•
•
•
Queries sent between a server and a client and the replies generated are defined as transactions. For data transactions between client and servers, the size of windows and buffers is important.
The relevant TCP parameters to maximize cache performance and throughput include the ability to tune timeout periods, client and server receive and send buffer sizes, and TCP window scaling behavior.
Caution
Explicit Congestion Notification
TCP Explicit Congestion Notification (ECN) allows an intermediate router to notify the end hosts of impending network congestion. It also provides enhanced support for TCP sessions associated with applications that are sensitive to delay or packet loss, including Telnet, web browsing, and transfer of audio and video data. The major issue with ECN is the need to change the operation of both the routers and the TCP software stacks to accommodate the operation of ECN.
Congestion Windows
The congestion window (cwnd) is a TCP state variable that limits the amount of data that a TCP sender can transmit onto the network before receiving an acknowledgment (ACK) from the receiving side of the TCP transmission. The TCP cwnd variable is implemented by the TCP congestion avoidance algorithm. The goal of the congestion avoidance algorithm is to continually modify the sending rate so that the sender automatically senses any increase or decrease in available network capacity during the entire data flow. When congestion occurs (manifested as a packet loss), the sending rate is first lowered and then gradually increased as the sender continues to probe the network for additional capacity.
Retransmit Time Multiplier
The TCP sender uses a timer to measure the time that has elapsed between sending a data segment and receiving the corresponding ACK from the receiving side of the TCP transmission. When this retransmit timer expires, the sender (according to the RFC standards for TCP congestion control) must reduce its sending rate. However, because the sender is not reducing its sending rate in response to network congestion, the sender is not able to make any valid assumptions about the current state of the network. To avoid congesting the network with an inappropriately large burst of data, the sender implements the slow-start algorithm, which reduces the sending rate to one segment per transmission.
You can modify the sender's retransmit timer by using the tcp increase-xmit-timer-value global configuration command. The retransmit time multiplier modifies the length of the retransmit timer by one to three times the base value, as determined by the TCP algorithm that is being used for congestion control.
When making adjustments to the retransmit timer, be aware that they affect performance and efficiency. If the retransmit timer is triggered too early, the sender pushes duplicate data onto the network unnecessarily; if the timer is triggered too slowly, the sender remains idle for too long, unnecessarily slowing the data flow.
TCP Slow Start
Slow start is one of four congestion control algorithms used by TCP. The slow-start algorithm controls the amount of data being inserted into the network at the beginning of a TCP session when the capacity of the network is not known.
For example, if a TCP session began by inserting a large amount of data into the network, much of the initial burst of data would probably be lost. Instead, TCP initially transmits a modest amount of data that has a high probability of successful transmission. TCP then probes the network by sending increasing amounts of data as long as the network does not show signs of congestion.
The slow-start algorithm begins by sending packets at a rate that is determined by the congestion window or cwnd variable. The algorithm continues to increase the sending rate until it reaches the limit set by the slow-start threshold (ssthresh) variable. (Initially, the value of the ssthresh variable is adjusted to the receiver's maximum window size [RMSS]. However, when congestion occurs, the ssthresh variable is set to half the current value of the cwnd variable, marking the point of the onset of network congestion for future reference.)
The starting value of the cwnd variable is set to that of the sender maximum segment size (SMSS), which is the size of the largest segment that the sender can transmit. The sender sends a single data segment. Because the congestion window is equal to the size of one segment, the congestion window is now full. The sender then waits for the corresponding ACK from the receiving side of the transmission. When the ACK is received, the sender increases its congestion window size by increasing the value of the cwnd variable by the value of one SMSS. Now the sender can transmit two segments before the congestion window is again full and the sender is once more required to wait for the corresponding ACKs for these segments. The slow-start algorithm continues to increase the value of the cwnd variable and increase the size of the congestion window by one SMSS for every ACK received. If the value of the cwnd variable increases beyond the value of the ssthresh variable, then the TCP flow control algorithm changes from the slow-start algorithm to the congestion avoidance algorithm.
TCP-Over-Satellite Extensions
The Content Engine has the ability to turn on TCP-over-satellite extensions (as documented in RFC 1323) to maximize performance and end-to-end throughput over satellite-type connections.
The large number of satellites available to network infrastructures has increased the amount of bandwidth available in the air. Taking advantage of these connections through satellite-type connections has created the following new challenges in the use of TCP transactions and acknowledgments:
•
•
•
Use the tcp server-satellite and tcp client-satellite global configuration commands to set the TCP connection so that it complies with RFC 1323.
TCP Read-Write Timeout and Persistent Connections
The Content Engine keeps a connection persistent if persistence is allowed for the persistence idle timeout period (which is 600 seconds by default). If HTTP persistent connections are enabled, then no keepalive is needed and the Content Engine keeps the connection open until the idle timeout period is exceeded.
Note
Once a response or data is sent over the persistent connection, the idle period restarts. HTTP persistent connections can be configured for either the client or server or both.
The persistence does not start until an initial request is made (for example, a GET request) or until data starts to flow over the persistent connection. If there is no initial request or data sent over a persistent connection, the read-write (rw)-timeout setting takes effect. The rw-timeout setting also is used if the connection goes idle for some reason before it has finished sending or receiving the data. In this case, the connection is timed out for the period specified by the rw-timeout setting. The rw-timeout setting can be set for reading and writing data to either the server or the client through the tcp server-rw-timeout and tcp client-rw-timeout global configuration commands. By default, the rw-timeout for both the server and the client is set to 120 seconds.
Configuring Content Engines to Send out TCP Keepalives
By default, the Content Engine does not automatically send out keepalives. To configure a Content Engine to send out TCP keepalives on HTTP connections, you must enter the http tcp-keepalive enable global configuration command. After entering the http tcp-keepalive enable command, the Content Engine sends out a keepalive every 75 seconds on an HTTP connection. If a response is received, the Content Engine continues to send a keepalive every 75 seconds. If a response is not received, the Content Engine waits 90 seconds and logs a miss. After four misses, the Content Engine considers the HTTP connection is down and closes the connection.
Use the tcp keepalive-probe-cnt global configuration command to specify how many times the Content Engine should attempt to connect to the device before closing the connection. The count can be from 1 to 10; the default is 4 attempts.
Use the tcp keepalive-probe-interval global configuration command to specify how often the Content Engine is to send out a TCP keepalive. The interval can be from 1 to 120 seconds; the default is 75 seconds.
Use the tcp keepalive-timeout global configuration command to wait for a response (the device does not respond) before the Content Engine logs a miss. The timeout can be from 1 to 120 seconds; the default is 90 seconds.
Configuring TCP Memory Limits
In the ACNS 5.3.3 software and later releases, you can configure TCP memory limits. The TCP memory limit settings allow you to control the amount of memory that can be used by the TCP subsystem's send and receive buffers. Use the tcp memory-limit global configuration command to configure TCP memory limits.
Caution
Examples
The following example shows how to configure the TCP receiving buffer size in kilobytes for incoming TCP packets:
ContentEngine(config)# tcp client-receive-buffer 100The following example shows how to reset the TCP receiving buffer size in kilobytes for incoming TCP packets:
ContentEngine(config)# no tcp client-receive-buffer
Note
Related Commands
clear statistics tcp
show statistics tcp
show tcptcpdump
To dump the network traffic, use the tcpdump EXEC command.
tcpdump [LINE]
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Use the tcpdump command to gather a sniffer trace on the Content Engine, Content Router, or Content Distribution Manager for troubleshooting, when asked to gather the data by the Cisco TAC. See the "Obtaining Technical Assistance" section on page xvii for more information. This utility is very similar to the Linux or Unix tcpdump command.
The tcpdump command allows an administrator (must be an admin user) to capture packets from the Ethernet. On the Content Engine 500 series, the interface names are eth0 and eth1. On all ACNS platforms, we recommend that you specify a path/filename in the local1 directory.
You can do a straight packet header dump to the screen by entering the tcpdump command. Press Ctrl-C to stop the dump.
The tcpdump command has the following options:
•
•
•
•
The following example captures the first 1500 bytes of the next 10,000 packets from interface Ethernet 0 and puts the output in a file named dump.pcap in the local1 directory on the Content Engine:
ContentEngine# tcpdump -w /local1/dump.pcap -i eth0 -s 1500 -c 10000When you specify the -s option, it sets the packet snaplength. The default value captures only 64 bytes, and this default setting saves only packet headers into the capture file. For troubleshooting of redirected packets or higher level traffic (HTTP, authentication, and so on), you must copy the complete packets.
After the TCP dump has been collected, you need to move the file from the Content Engine to a PC so that the file can be viewed by a sniffer decoder.
ftp <ip address of the CE>!--- Log in using the admin username and password.cd local1binhashget <name of the file>!--- Using the above example, it would be dump.pcap.byeWe recommend that you use Ethereal as the software application for reading the TCP dump. With Ethereal, you can decode packets that are encapsulated into a GRE tunnel used by WCCP redirection. See the Ethereal website for further information.
Note
Examples
The following example shows how to dump the TCP network traffic:
CONTENTENGINE# tcpdumptcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes12:45:42.617677 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 3342832089:3342832201(112) ack 1248615673 win 1523212:45:42.618950 IP 172.19.226.63 > CONTENTENGINE.cisco.com: icmp 36: 172.19.226.63 udp port 2048 unreachable12:45:42.619327 IP CONTENTENGINE.cisco.com.10015 > dns-sj2.cisco.com.domain: 49828+[|domain]12:45:42.621158 IP dns-sj2.cisco.com.domain > CONTENTENGINE.cisco.com.10015: 49828 NXDomain*[|domain]12:45:42.621942 IP CONTENTENGINE.cisco.com.10015 > dns-sj2.cisco.com.domain: 49829+[|domain]12:45:42.623799 IP dns-sj2.cisco.com.domain > CONTENTENGINE.cisco.com.10015: 49829 NXDomain*[|domain]12:45:42.624240 IP CONTENTENGINE.cisco.com.10015 > dns-sj2.cisco.com.domain: 49830+[|domain]12:45:42.626164 IP dns-sj2.cisco.com.domain > CONTENTENGINE.cisco.com.10015: 49830*[|domain]12:45:42.702891 802.1d config TOP_CHANGE 8000.00:03:9f:f1:10:63.8042 root 8000.00:01:43:9a:c8:63 pathcost 26 age 3 max 20 hello 2 fdelay 1512:45:42.831404 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 112 win 6435112:45:42.831490 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: . 112:1444(1332) ack 1 win 1523212:45:42.831504 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 1444:1568(124) ack 1 win 1523212:45:42.831741 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 1568:1696(128) ack 1 win 1523212:45:43.046176 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 1568 win 6553512:45:43.046248 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 1696:2128(432) ack 1 win 1523212:45:43.046469 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 2128:2256(128) ack 1 win 1523212:45:43.046616 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 2256:2400(144) ack 1 win 1523212:45:43.107700 802.1d config TOP_CHANGE 8000.00:03:9f:f1:10:63.8042 root 8000.00:01:43:9a:c8:63 pathcost 26 age 3 max 20 hello 2 fdelay 1512:45:43.199710 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 1696 win 6540712:45:43.199784 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 2400:2864(464) ack 1 win 1523212:45:43.199998 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 2864:2992(128) ack 1 win 1523212:45:43.259968 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 2400 win 6470312:45:43.260064 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 2992:3280(288) ack 1 win 1523212:45:43.260335 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 3280:3408(128) ack 1 win 1523212:45:43.260482 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 3408:3552(144) ack 1 win 1523212:45:43.260621 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 3552:3696(144) ack 1 win 1523212:45:43.413320 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 2992 win 6553512:45:43.413389 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 3696:3984(288) ack 1 win 1523212:45:43.413597 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 3984:4112(128) ack 1 win 1523212:45:43.413741 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 4112:4256(144) ack 1 win 1523212:45:43.473601 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 3552 win 6497512:45:43.473659 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 4256:4544(288) ack 1 win 1523212:45:43.473853 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 4544:4672(128) ack 1 win 1523212:45:43.473994 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 4672:4816(144) ack 1 win 1523212:45:43.474132 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 4816:4960(144) ack 1 win 1523212:45:43.484117 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: P 1:81(80) ack 3696 win 6483112:45:43.484167 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 4960:5248(288) ack 81 win 1523212:45:43.484424 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 5248:5392(144) ack 81 win 1523212:45:43.627125 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 4112 win 6441512:45:43.627204 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 5392:5680(288) ack 81 win 1523212:45:43.627439 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 5680:5808(128) ack 81 win 1523212:45:43.627586 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 5808:5952(144) ack 81 win 1523212:45:43.688261 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 4544 win 6553512:45:43.688316 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 5952:6240(288) ack 81 win 1523212:45:43.688495 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 6240:6368(128) ack 81 win 1523212:45:43.688638 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 6368:6512(144) ack 81 win 1523212:45:43.689012 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 4960 win 6511912:45:43.689046 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 6512:6800(288) ack 81 win 1523212:45:43.689170 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 6800:6928(128) ack 81 win 1523212:45:43.689309 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 6928:7072(144) ack 81 win 1523212:45:43.689447 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 7072:7216(144) ack 81 win 1523212:45:43.698391 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 5392 win 6468712:45:43.698437 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 7216:7504(288) ack 81 win 1523212:45:43.698599 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 7504:7632(128) ack 81 win 1523212:45:43.698740 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 7632:7776(144) ack 81 win 1523212:45:43.840558 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 5808 win 6427112:45:43.840622 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 7776:8064(288) ack 81 win 1523212:45:43.840819 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 8064:8192(128) ack 81 win 1523212:45:43.840962 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 8192:8336(144) ack 81 win 1523212:45:43.901868 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 6368 win 6553512:45:43.901938 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 8336:8624(288) ack 81 win 1523212:45:43.901887 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 6928 win 6497512:45:43.901910 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 7216 win 6468712:45:43.902137 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 8624:8752(128) ack 81 win 1523212:45:43.902281 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 8752:8896(144) ack 81 win 1523212:45:43.902414 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 8896:9024(128) ack 81 win 1523212:45:43.902547 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 9024:9152(128) ack 81 win 1523212:45:43.902687 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 9152:9296(144) ack 81 win 1523212:45:43.902826 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 9296:9440(144) ack 81 win 1523212:45:43.902965 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 9440:9584(144) ack 81 win 1523212:45:43.903104 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 9584:9728(144) ack 81 win 1523212:45:43.922413 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 7632 win 6427112:45:43.922459 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 9728:10304(576) ack 81 win 1523212:45:43.922622 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 10304:10432(128) ack 81 win 1523212:45:43.922764 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 10432:10576(144) ack 81 win 1523212:45:44.053872 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 8192 win 6553512:45:44.053972 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 10576:10864(288) ack 81 win 1523212:45:44.054308 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 10864:11104(240) ack 81 win 1523212:45:44.054453 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 11104:11248(144) ack 81 win 1523212:45:44.054596 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 11248:11392(144) ack 81 win 1523212:45:44.111702 802.1d config TOP_CHANGE 8000.00:03:9f:f1:10:63.8042 root 8000.00:01:43:9a:c8:63 pathcost 26 age 3 max 20 hello 2 fdelay 1512:45:44.114626 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 8752 win 6497512:45:44.114712 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 11392:11712(320) ack 81 win 1523212:45:44.115219 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 11712:11952(240) ack 81 win 1523212:45:44.115381 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 11952:12096(144) ack 81 win 1523212:45:44.115426 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 9152 win 6457512:45:44.115617 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 12096:12336(240) ack 81 win 1523212:45:44.115760 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 12336:12480(144) ack 81 win 1523212:45:44.115904 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 12480:12624(144) ack 81 win 1523212:45:44.116045 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 12624:12768(144) ack 81 win 1523212:45:44.116094 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 9440 win 6428712:45:44.116114 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 9728 win 6553512:45:44.116332 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 12768:13088(320) ack 81 win 1523212:45:44.116473 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 13088:13232(144) ack 81 win 1523212:45:44.116614 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 13232:13376(144) ack 81 win 1523212:45:44.116755 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 13376:13520(144) ack 81 win 1523212:45:44.116895 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 13520:13664(144) ack 81 win 1523212:45:44.135947 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: . ack 10432 win 6483112:45:44.135996 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 13664:13808(144) ack 81 win 1523212:45:44.136223 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 13808:14048(240) ack 81 win 1523212:45:44.136366 IP CONTENTENGINE.cisco.com.ssh > 10.77.140.97.4314: P 14048:14192(144) ack 81 win 1523212:45:44.144104 IP 10.77.140.97.4314 > CONTENTENGINE.cisco.com.ssh: P 81:161(80) ack 10576 win 64687102 packets captured105 packets received by filter0 packets dropped by kernelThe following example shows how to dump the TCP network traffic and redirect it to a file named test:
CONTENTENGINE# tcpdump port 8080 -w testtcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes216 packets captured216 packets received by filter0 packets dropped by kerneltelnet
To log in to a network device using the Telnet client, use the telnet EXEC command.
telnet {hostname | ip-address} [portnum]
Syntax Description
hostname
Hostname of the network device.
ip-address
IP address of the network device.
portnum
(Optional) Port number (1-65535). Default port number is 23.
Defaults
The default port number is 23.
Command Modes
EXEC
Usage Guidelines
Some UNIX shell functions, such as escape and the suspend command, are not available in the Telnet client. In addition, multiple Telnet sessions are also not supported.
This Telnet client allows you to specify a destination port. By entering this command, you can test websites by attempting to open a Telnet session to the website from the Content Engine CLI.
Examples
The following example shows how to open a Telnet session to a network device using the hostname:
ContentEngine# telnet cisco-ceThe following example shows how to open a Telnet session to a network device using the IP address:
ContentEngine# telnet 172.16.155.224The following example shows how to open a Telnet session to a network device on port 8443 using the hostname:
ContentEngine# telnet cisco-ce 8443The following example shows how to open a Telnet session to a network device on port 80 using the hostname:
ContentEngine# telnet www.yahoo.com 80telnet enable
To enable Telnet, use the telnet enable global configuration command. To disable Telnet, use the no form of this command.
telnet enable
no telnet enable
Syntax Description
This command has no arguments or keywords.
Defaults
Enabled
Command Modes
global configuration
Usage Guidelines
Use this terminal emulation protocol for a remote terminal connection. The telnet enable command allows users to log in to other devices using a Telnet session.
Examples
The following example shows how to enable Telnet on the Content Engine:
ContentEngine(config)# telnet enableRelated Commands
show telnet
terminal
To set the number of lines displayed in the console window, or to display the current console debug command output, use the terminal EXEC command.
terminal {length length | monitor [disable]}
Syntax Description
Defaults
The default is 24 lines.
Command Modes
EXEC
Usage Guidelines
When 0 is entered as the length parameter, the output to the screen does not pause. For all nonzero values of length, the -More- prompt is displayed when the number of output lines matches the specified length number. The -More- prompt is considered a line of output. To view the next screen, press the Spacebar. To view one line at a time, press the Enter key.
The terminal monitor command allows a Telnet session to display the output of the debug commands that appear on the console. Monitoring continues until the Telnet session is terminated.
Examples
The following example sets the number of lines to display to 20:
ContentEngine# terminal length 20The following example configures the terminal for no pausing:
ContentEngine# terminal length 0Related Commands
All show commands
test-url
To test the accessibility of a URL, using FTP, HTTP, or HTTPS, use the test-url EXEC command.
test-url {ftp url [use-ftp-proxy proxy-url] | http url [custom-header header [head-only] [use-http-proxy proxy-url] | head-only [custom-header header] [use-http-proxy proxy-url] | use-http-proxy proxy-url [custom-header header] [head-only]] | https url [head-only]}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
In the ACNS 5.2 software and later releases, an HTTP CLI client is supported. This capability allows you to test connectivity and debug caching issues. The test-url EXEC command in the ACNS 5.2 software and later releases allows the users to test whether a URL is accessible over the FTP, HTTP, and HTTPS protocols. When you test the connectivity using the test-url command, the Content Engine sends a request using the protocol that you have specified to the server and fetches the requested contents. The actual content is dumped into the path /dev/null, and the server response with the header information is displayed to the user.
You can use the test-url ftp command to test the following for the specified URL:
•
•
•
•
You can use the test-url http command to test the following for the specified URL:
•
•
•
•
•
You can use the test-url https command to test whether the HTTPS URL is accessible and to test authentication to the web server. You can use the head-only option to request only the header information alone for the specified page.
Examples
The following example tests the accessibility to the URL http://192.168.171.22 using HTTP:
ContentEngine# test-url http http://ce1.server.com--02:27:20-- http://ce1.server.com/=> `/dev/null'Len - 22 , Restval - 0 , contlen - 0 , Res - 134728056Resolving ce1.server.com..done.Connecting to ce1.server.com[192.168.171.22]:80... connected.HTTP request sent, awaiting response...1 HTTP/1.1 200 OK2 Date: Mon, 26 Jul 2004 08:41:34 GMT3 Server: Apache/1.2b84 Last-Modified: Fri, 25 Apr 2003 12:23:04 GMT5 ETag: "1aee29-663-3ea928a8"6 Content-Length: 16357 Content-Type: text/html8 Via: 1.1 Application and Content Networking System Software 5.29 Connection: Keep-Alive(1635 to go)0% [ ] 0 --.--K/s ETA --:--Len - 0 ELen - 1635 Keepalive - 1100%[====================================>] 1,635 1.56M/s ETA 00:0002:27:20 (1.56 MB/s) - `/dev/null' saved [1635/1635]The following example tests the accessibility to the URL http://192.168.171.22 through the HTTP proxy 10.107.192.148:
ContentEngine# test-url http http://192.168.171.22 use-http-proxy 10.107.192.148:8090--15:22:51-- http://10.77.155.246/=> `/dev/null'Len - 1393 , Restval - 0 , contlen - 0 , Res - 134728344Connecting to 10.107.192.148:8090... connected.Proxy request sent, awaiting response...1 HTTP/1.1 401 Authorization Required2 Date: Mon, 27 Sep 2004 15:29:18 GMT3 Server: Apache/1.3.27 (Unix) tomcat/1.04 WWW-Authenticate: Basic realm="IP/TV Restricted Zone"5 Content-Type: text/html; charset=iso-8859-16 Via: 1.1 Application and Content Networking System Software 5.2.17 Connection: CloseLen - 0 , Restval - 0 , contlen - -1 , Res - -1Connecting to 10.107.192.148:8090... connected.Proxy request sent, awaiting response...1 HTTP/1.1 401 Authorization Required2 Date: Mon, 27 Sep 2004 15:29:19 GMT3 Server: Apache/1.3.27 (Unix) tomcat/1.04 WWW-Authenticate: Basic realm="IP/TV Restricted Zone"5 Content-Type: text/html; charset=iso-8859-16 Via: 1.1 Application and Content Networking System Software 5.2.17 Connection: Keep-Alive(1635 to go)0% [ ] 0 --.--K/s ETA --:--Len - 0 ELen - 1635 Keepalive - 1100%[====================================>] 1,635 1.56M/s ETA 00:0002:27:20 (1.56 MB/s) - `/dev/null' saved [1635/1635]The following example shows that the test URL (gmail.google.com) is an HTTPS request that fails because the host is not found:
ContentEngine# test-url https https://gmail.google.com head-only--17:43:13-- https://gmail.google.com/=> `/dev/null'Len - 25 , Restval - 0 , contlen - 0 , Res - 134728056Resolving gmail.google.com...Resolving gmail.google.com failed: Host not found.The following example shows that the test URL is an FTP-over-HTTP request using the Content Engine that has an IP address of 10.77.157.42 as the FTP proxy for the request:
ContentEngine# test-url ftp ftp://1234567:pAB6rB7x@smartfilter.com use-ftp-proxy ? WORD Proxy-url. Format http://proxyIp:proxyPort orhttp://proxyUser:proxypasswd@proxyIp:proxyPortContentEngine# test-url ftp ftp://ssivakum:ssivakum@10.77.157.148/antinat-0.90.tar use-ftp-proxy 10.77.157.42:8080Mar 30 14:34:40 nramaraj-ce admin-shell: %CE-PARSER-6-350232: CLI_LOG shell_parser_log: test-url ftp ftp://ssivakum:ssivakum@10.77.157.148/antinat-0.90.tar use-ftp-proxy 10.77.157.42:8080--14:34:40-- ftp://ssivakum:*password*@10.77.157.148/antinat-0.90.tar=> `/dev/null'Len - 1185 , Restval - 0 , contlen - 0 , Res - 134728552Connecting to 10.77.157.42:8080... connected.Proxy request sent, awaiting response...1 HTTP/1.0 200 OK2 Mime-Version: 1.03 Server: Application and Content Networking System Software 5.1.144 Content-Type: application/x-tar5 Content-Length: 17715206 Last-Modified: Wed Mar 30 03:53:05 20057 X-protocol: ftp8 Date: Wed, 30 Mar 2005 14:04:27 GMT9 Connection: Close(1771520 to go)0% [ ] 0 --.--K/s ETA --:--Len - 1460 ELen - 1771520 Keepalive - 0100%[===================================================================================== >] 1,771,520 145.01K/s ETA 00:0014:34:53 (145.01 KB/s) - `/dev/null' saved [1771520/1771520]14:34:53 URL:ftp://10.77.157.148/antinat-0.90.tar [1771520/1771520]ContentEngine#The following example tests the accessibility to the URL ftp://ssivakum:ssivakum@10.77.157.148 using FTP:
ContentEngine# test-url ftp ftp://ssivakum:ssivakum@10.77.157.148/antinat-0.90.tarMar 30 14:33:44 nramaraj-ce admin-shell: %CE-PARSER-6-350232: CLI_LOG shell_parser_log: test-url ftp ftp://ssivakum:ssivakum@10.77.157.148/antinat-0.90.tar--14:33:44-- ftp://ssivakum:*password*@10.77.157.148/antinat-0.90.tar=> `/dev/null'Connecting to 10.77.157.148:21... connected.Logging in as ssivakum ...220 (vsFTPd 1.1.3)--> USER ssivakum331 Please specify the password.--> PASS Turtle Power!230 Login successful. Have fun.--> SYST215 UNIX Type: L8--> PWD257 "/home/ssivakum"--> TYPE I200 Switching to Binary mode.==> CWD not needed.--> PORT 10,1,1,52,82,16200 PORT command successful. Consider using PASV.--> RETR antinat-0.90.tar150 Opening BINARY mode data connection for antinat-0.90.tar (1771520 bytes).Length: 1,771,520 (unauthoritative)0% [ ] 0 --.--K/s ETA --:--Len - 0 ELen - 1771520 Keepalive - 0100%[===================================================================================== >] 1,771,520 241.22K/s ETA 00:00226 File send OK.14:33:53 (241.22 KB/s) - `/dev/null' saved [1771520]ContentEngine#Related Commands
acquirer test-url
tftp-server
To configure the Content Engine to act as a Trivial File Transfer Protocol (TFTP) server or as a gateway that serves TFTP requests by accessing content on HTTP or FTP servers, use the tftp-server global configuration command. To disable TFTP server options, use the no form of this command.
tftp-server access-list {std-acl-name | std-acl-num}
tftp-server dir directory
tftp-server gw proto {http | ftp} server {hostname | ip_address} pri priority [name name passwd password] [path directory]
no tftp-server {access-list [std-acl-name | std-acl-num] | dir directory | gw proto {http | ftp} server {hostname | ip_address} pri priority [name name passwd password] [path directory]}
Syntax Description
Defaults
By default, TFTP service is disabled and access to the TFTP server is denied.
The default local directory assigned to the TFTP server is /tftpboot. However, this directory must be created using the mkdir command.
The TFTP timeout value is fixed at 5 seconds. The number of retries is fixed at five retries. These values are not configurable.
Maximum size for a transferred file is 32 MB.
Command Modes
global configuration
Usage Guidelines
In the ACNS software, the Content Engine can act as a TFTP server and process TFTP requests sent to the Content Engine. In addition, the Content Engine can act as a TFTP gateway, allowing users to obtain files from HTTP or FTP servers in response to a TFTP request.
Note
Authenticated objects are never cached by the Content Engine for HTTP or FTP. If you want to cache these objects, leave the username and password fields in the tftp-server gw command blank. When used with FTP, this configuration is equivalent to allowing anonymous access.
Using the TFTP Server or Gateway
You can use the tftp-server command to configure the TFTP server and gateway to serve the content in response to TFTP requests in three ways:
•
•
•
When both the TFTP server and gateway are enabled, the Content Engine responds to TFTP requests by searching for files in its default local directory if the full pathname is not specified in the request. Otherwise, it looks in the local directory that matches the directory in the pathname. If the file is not found in a TFTP server directory, the Content Engine forwards the request to the caching application using the HTTP or FTP protocol, and one of the following events occurs:
•
•
•
Note
Note
In addition to enabling the TFTP server, you must perform some additional steps depending on the functionality that you want to use. These additional steps are described in the following sections.
Serving Local Content
To serve requests for local content, you must enable the TFTP server and also configure the local directories to use. This functionality is available on any ACNS device, including a Content Engine, Content Router, Content Distribution Manager, or IP/TV Program Manager. To configure the local TFTP directories, follow these steps:
1.
2.
When you use the tftp-server dir command to identify one or more local directories, the first directory identified becomes the default directory. Enter the tftp-server dir command once for each directory that you want to identify.
The TFTP server searches for files without a fully qualified pathname in its default directory. The TFTP server only looks for files in the other local directories if the TFTP request explicitly identifies the directory.
If you do not configure any local directories, /tftpboot is automatically assigned as the default directory. However, you would still need to create the /tftpboot directory using the mkdir command before the TFTP server can serve requests.
Serving the Pre-Positioned Content
To serve the pre-positioned content, you must enable the TFTP server and also identify the remote server from which the files have been pre-positioned. This functionality is available only on a Content Engine.
To identify where the files have been pre-positioned, use the tftp-server gw proto server hostname path directory command. Replace hostname with the name of the origin server from which the pre-positioned files are acquired. Replace directory with the location where the files were pre-positioned through the acquisition process.
Using the TFTP Gateway to Serve Content from Remote Servers
To serve the content from remote servers, you must enable the TFTP server and also identify the remote servers to which the TFTP gateway will direct requests. This functionality is available only on a Content Engine.
To identify the servers to which the Content Engine will direct requests when it cannot find the requested files in its local directories, use the tftp-server gw proto command. To complete this command, identify the protocol (HTTP or FTP), the hostname or IP address of the server, and any authentication information required to access the remote server. You can enter the tftp-server gw proto command twice to configure a primary and a backup HTTP or FTP server. Use the priority option to specify whether the server is primary (priority = 1) or backup (priority = 2).
Note
Using IP ACLs to Control TFTP Access
You can enable TFTP applications to be attached to a particular interface (such as management services to the private IP address space) so that the Content Engine can have one interface in the customer's IP address space that serves the content, and another interface in a private IP address space that the administrator uses for management purposes. This setting ensures that clients can access the Content Engine only in the public IP address space for serving content and not access it for management purposes. A device attempting to access one of these applications associated with an access control list (ACL) must be on the list of trusted devices to be allowed access.
Examples
The following example enables the TFTP server:
ContentEngine(config) inetd enable tftpThe following example defines an access list that permits access to the TFTP service for TFTP clients on the 192.168.1.0 subnetwork:
ContentEngine(config)# ip access-list standard 1ContentEngine(config-std-nacl)# ip access-list permit 192.168.1.0 0.0.0.255ContentEngine(config-std-nacl)# exitThe following example configures two local directories from which the Content Engine will try to fulfill TFTP requests:
ContentEngine(config)# mkdir /local1/mydirContentEngine(config)# mkdir /local1/clientsContentEngine(config)# tftp-server dir /local1/mydirContentEngine(config)# tftp-server dir /local1/clientsThe first directory specified, /local1/mydir, is considered the default directory.
The following example identifies the IP access list that permits access to the TFTP service:
ContentEngine(config)# tftp-server access-list 1The following example identifies an FTP server to which the Content Engine will forward requests when it cannot find the file in its local directories:
ContentEngine(config)# tftp-server gw proto ftp 192.168.100.1 pri 1 path /myremotedir name myuser passwd mypasswordThe directory name /myremotedir is used in the URL sent by the caching application to obtain the file from the remote server. The URL created by using this example configuration would be as follows:
ftp://myuser:mypasswd@192.168.100.1/myremotedir/requested-file-name
The following example identifies the remote server from which files have been pre-positioned and allows the TFTP gateway to serve TFTP requests from the pre-positioned content:
ContentEngine(config)# tftp-server gw proto http 192.168.100.2 pri 1 path /myremotedir name myuser passwd mypasswordThe URL formed by using this example configuration would be as follows:
http://myuser:mypasswd@192.168.100.2/myremotedir/requested-file-name
In this case, the caching application searches for the requested file in the pre-positioned directory. If the requested file is not found, the caching application makes a request to the remote server that is specified by the URL.
Related Commands
debug http header
debug http all
debug tftp-server
inetd enable tftp
ip access-list
mkdir
show inetd
show statistics tftp
show tftp-servertraceroute
To trace the route to a remote host, use the traceroute EXEC command.
traceroute {hostname | ip-address}
Syntax Description
Defaults
No default behavior values
Command Modes
EXEC
Usage Guidelines
Traceroute is a widely available utility on most operating systems. Similar to ping, traceroute is a valuable tool for determining connectivity in a network. Ping allows the user to find out if there is a connection between the two end systems. Traceroute does this as well, but additionally lists the intermediate routers between the two systems. Users can see the routes that packets can take from one system to another. Use the traceroute command to find the route to a remote host when either the hostname or the IP address is known.
The traceroute command uses the TTL field in the IP header to cause routers and servers to generate specific return messages. Traceroute starts by sending a UDP datagram to the destination host with the TTL field set to 1. If a router finds a TTL value of 1 or 0, it drops the datagram and sends back an ICMP time-exceeded message to the sender. The traceroute facility determines the address of the first hop by examining the source address field of the ICMP time-exceeded message.
To identify the next hop, traceroute sends a UDP packet with a TTL value of 2. The first router decrements the TTL field by 1 and sends the datagram to the next router. The second router sees a TTL value of 1, discards the datagram, and returns the time-exceeded message to the source. This process continues until the TTL is incremented to a value large enough for the datagram to reach the destination host (or until the maximum TTL is reached).
To determine when a datagram has reached its destination, traceroute sets the UDP destination port in the datagram to a very large value that the destination host is unlikely to be using. When a host receives a datagram with an unrecognized port number, it sends an ICMP "port unreachable" error to the source. This message indicates to the traceroute facility that it has reached the destination.
Examples
The following example shows how to trace the route to a remote host from the Content Engine:
CONTENTENGINE# traceroute 10.77.157.43traceroute to 10.77.157.43 (10.77.157.43), 30 hops max, 38 byte packets1 10.1.1.50 (10.1.1.50) 2.024 ms 2.086 ms 2.219 ms2 sblab2-rtr.cisco.com (192.168.10.1) 3.718 ms 172.19.231.249 (172.19.231.249) 0.653 ms 0.606 ms3 sjc22-00lab-gw1.cisco.com (172.24.115.65) 0.666 ms 0.624 ms 0.597 ms4 sjc20-lab-gw2.cisco.com (172.24.115.109) 0.709 ms 0.695 ms 0.616 ms5 sjc20-sbb5-gw2.cisco.com (128.107.180.97) 0.910 ms 0.702 ms 0.674 ms6 sjc20-rbb-gw5.cisco.com (128.107.180.9) 0.762 ms 0.702 ms 0.664 ms7 sjc12-rbb-gw4.cisco.com (128.107.180.2) 0.731 ms 0.731 ms 0.686 ms8 sjc5-gb3-f1-0.cisco.com (10.112.2.158) 1.229 ms 1.186 ms 0.753 ms9 capnet-hkidc-sjc5-oc3.cisco.com (10.112.2.238) 146.784 ms 147.016 ms 147.051 ms10 hkidc-capnet-gw1-g3-1.cisco.com (10.112.1.250) 147.163 ms 147.319 ms 148.050 ms11 hkidc-gb3-g0-1.cisco.com (10.112.1.233) 148.137 ms 148.332 ms 148.361 ms12 capnet-singapore-hkidc-oc3.cisco.com (10.112.2.233) 178.137 ms 178.273 ms 178.005 ms13 singapore-capnet2-fa4-0.cisco.com (10.112.2.217) 179.236 ms 179.606 ms 178.714 ms14 singapore-gb1-fa2-0.cisco.com (10.112.2.226) 179.499 ms 179.914 ms 179.873 ms15 capnet-chennai-singapore-ds3.cisco.com (10.112.2.246) 211.858 ms 212.167 ms 212.854 ms16 hclodc1-rbb-gw2-g3-8.cisco.com (10.112.1.213) 213.639 ms 212.580 ms 211.211 ms17 10.77.130.18 (10.77.130.18) 212.248 ms 212.478 ms 212.545 ms18 codc-tbd.cisco.com (10.77.130.34) 212.315 ms 212.688 ms 213.063 ms19 10.77.130.38 (10.77.130.38) 212.955 ms 214.353 ms 218.169 ms20 10.77.157.9 (10.77.157.9) 217.217 ms 213.424 ms 222.023 ms21 10.77.157.43 (10.77.157.43) 212.750 ms 217.260 ms 214.610 msThe following example shows how the traceroute command fails to trace the route to a remote host from the Content Engine:
CONTENTENGINE# traceroute 10.0.0.1traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 38 byte packets1 10.1.1.50 (10.1.1.50) 2.022 ms 1.970 ms 2.156 ms2 sblab2-rtr.cisco.com (192.168.10.1) 3.955 ms 172.19.231.249 (172.19.231.249) 0.654 ms 0.607 ms3 sjc22-00lab-gw1.cisco.com (172.24.115.65) 0.704 ms 0.625 ms 0.596 ms4 sjc20-lab-gw1.cisco.com (172.24.115.105) 0.736 ms 0.686 ms 0.615 ms5 sjc20-sbb5-gw1.cisco.com (128.107.180.85) 0.703 ms 0.696 ms 0.646 ms6 sjc20-rbb-gw5.cisco.com (128.107.180.22) 0.736 ms 0.782 ms 0.750 ms7 sjce-rbb-gw1.cisco.com (171.69.7.249) 1.291 ms 1.314 ms 1.218 ms8 sjce-corp-gw1.cisco.com (171.69.7.170) 1.477 ms 1.257 ms 1.221 ms9 * * *10 * * *...29 * * *30 * * *Table 2-173 describes the fields in the traceroute command output.
Related Commands
ping
transaction-log force
To force the archive or export of the transaction log, use the transaction-log force EXEC command.
transaction-log force {archive | export}
Syntax Description
archive
Forces the archive of the working.log file.
export
Forces the archived files to be exported to an FTP server.
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
The transaction-log force archive command causes the transaction log working.log file to be archived to the Content Engine hard disk following the next transaction. This command has the same effect as the clear transaction-log command.
The transaction-log force export command causes the transaction log to be exported to an FTP server designated by the transaction-logs export ftp-server command.
The transaction-log force commands do not change the configured or default schedule for archive or export of transaction log files. If the archive interval is configured in seconds or the export interval is configured in minutes, the forced archive or export interval period is restarted after the forced operation.
If a scheduled archive or export job is in progress when a corresponding transaction-log force command is entered, the command has no effect. If a transaction-log force command is in progress when an archive or export job is scheduled to run, the forced operation is completed and the archive or export is rescheduled for the next configured interval.
Examples
The following example shows how to archive the transaction log file to the Content Engine hard disk:
ContentEngine# transaction-log force archiveThe following example shows that the Content Engine is configured to export its transaction logs to two FTP servers:
ContentEngine(config)# transaction-logs export ftp-server 10.1.1.1 mylogin mypasswd /ftpdirectoryContentEngine(config)# transaction-logs export ftp-server myhostname mylogin mypasswd /ftpdirectoryThe following example shows how to export the transaction log file from the Content Engine hard disk to an FTP server designated by the transaction-logs export ftp-server command:
ContentEngine# transaction-log force exportRelated Commands
clear statistics transaction-logs
clear transaction-log
show statistics transaction-logs
show transaction-logging
transaction-logstransaction-logs
To configure and enable transaction logs, use the transaction-logs command in global configuration mode. To disable transaction logs, use the no form of this command.
transaction-logs archive interval seconds
transaction-logs archive interval every-day {at hour:minute | every hours}
transaction-logs archive interval every-hour {at minute | every minutes}
transaction-logs archive interval every-week [on weekdays at hour:minute]
transaction-logs archive max-file-size filesize
transaction-logs enable
transaction-logs export compress
transaction-logs export enable
transaction-logs export ftp-server {hostname | servipaddrs} login passw directory
transaction-logs export interval minutes
transaction-logs export interval every-day {at hour:minute | every hours}
transaction-logs export interval every-hour {at minute | every minutes}
transaction-logs export interval every-week [on weekdays at hour:minute]
transaction-logs export sftp-server {hostname | servipaddrs} login passw directory
transaction-logs file-marker
transaction-logs format {apache | custom string | extended-squid | squid}
transaction-logs log-windows-domain
transaction-logs logging {enable | entry-type {all | request-auth-failures} | facility {parameter} | host {hostname | ip-address [port port-num | rate-limit rate]}}
transaction-logs sanitize
no transaction-logs {archive {interval | max-file-size} | enable | export {compress | enable | ftp-server {hostname | servipaddrs} | interval | sftp-server {hostname | servipaddrs}} | file-marker | format | log-windows-domain | logging {enable | entry-type | facility | host {hostname | ip-address} [port port-number] [rate-limit rate]} | sanitize}
Syntax Description
Defaults
archive: disabled
enable: disabled
export compress: disabled
export: disabled
file-marker: disabled
sanitize: disabled
archive interval: every day, every one hour
archive max-file-size: 2,000,000 KB
export interval: every day, every one hour
format: Squid native log format
logging port port-num: 514
Command Modes
global configuration
Usage Guidelines
Content Engines that are running the ACNS 5.x software can record all errors and access activities. In the ACNS 5.x software, each content service module on the Content Engine provides logs of the requests that were serviced. These logs are referred to as transaction logs.
Typical fields in the transaction log are the date and time when a request was made, the URL that was requested, whether it was a cache hit or a cache miss, the type of request, the number of bytes transferred, and the source IP address. Transaction logs are used for problem identification and solving, load monitoring, billing, statistical analysis, security problems, and cost analysis and provisioning.
The translog module on the Content Engine handles transaction logging and supports the Apache Common Log Format (CLF), Squid format, Extended Squid format, and the World Wide Web Consortium (W3C) customizable logging format.
Note
Note
Enable transaction log recording with the transaction-logs enable command. The transactions that are logged include HTTP and FTP. In addition, ACNS 5.5 software supports Extensible Markup Language (XML) logging for MMS-over-HTTP and MMS-over-RTSP (RTSP over Windows Media Services 9).
When enabled, daemons create a working.log file in /local1/logs/ on the sysfs volume for HTTP and FTP transactions and a separate working.log file in /local1/logs/export for Windows Media transactions. The posted XML log file from the Windows Media Player to the Content Engine (Windows Media server) can be parsed and saved to the normal WMT transaction logs that are stored on the Content Engine.
The working.log file is a link to the actual log file with the timestamp embedded in its filename. When you configure the transaction-logs archive interval command, the first transaction that arrives after the interval elapses is logged to the working.log file as usual, and then actual log file is archived and a new log file is created. Only transactions subsequent to the archiving event are recorded in the new log file. The working.log file is then updated to point to the newly created log file. The transaction log archive file naming conventions are shown in Table 2-177. The Content Engine default archive interval is once an hour every day.
Use the transaction-logs archive max-file-size command to specify the maximum size of an archive file. The working.log file is archived when it attains the maximum file size if this size is reached before the configured archive interval time.
Use the transaction-logs file-marker option to mark the beginning and end of the HTTP, HTTPS, and FTP proxy logs. By examining the file markers of an exported archive file, you can determine whether the FTP process transferred the entire file. The file markers are in the form of dummy transaction entries that are written in the configured log format.
The following example shows the start and end dummy transactions in the default native Squid log format.
•
•
Use the format option to format the HTTP, HTTPS, and FTP proxy log files for custom format, native Squid or Extended Squid formats, or Apache Common Log Format (CLF).
The transaction-logs format custom command allows you to use a log format string to log additional fields that are not included in the predefined native Squid or Extended Squid formats or the Apache CLF format. The log format string is a string that contains the tokens listed in Table 2-174 and mimics the Apache log format string. The log format string can contain literal characters that are copied into the log file. Two backslashes (\\) can be used to represent a literal backslash, and a backslash followed by a single quotation mark (\') can be used to represent a literal single quotation mark. A literal double quotation mark cannot be represented as part of the log format string. The control characters \t and \n can be used to represent a tab and a new line character, respectively.
Table 2-174 lists the acceptable format tokens for the log format string. The ellipsis (...) portion of the format tokens shown in this table represent an optional condition. This portion of the format token can be left blank, as in %a. If an optional condition is included in the format token and the condition is met, then what is shown in the Value column of Table 2-174 is included in the transaction log output. If an optional condition is included in the format token but the condition is not met, the resulting transaction log output is replaced with a hyphen (-). The form of the condition is a list of HTTP status codes, which may or may not be preceded by an exclamation point (!). The exclamation point is used to negate all of the status codes that follow it, which means that the value associated with the format token is logged if none of the status codes listed after the exclamation point (!) match the HTTP status code of the request. If any of the status codes listed after the exclamation point (!) match the HTTP status code of the request, then a hyphen (-) is logged.
For example, %400,501{User-Agent}i logs the User-Agent header value on 400 errors and 501 errors (Bad Request, Not Implemented) only, and %!200,304,302{Referer}i logs the Referer header value on all requests that did not return a normal status.
The custom format currently supports the following request headers:
•
•
•
•
The output of each of the following Request, Referer, and User-Agent format tokens specified in the custom log format string is always enclosed in double quotation marks in the transaction log entry:
%r
%{Referer}i
%{User-Agent}i
The %{Cookie}i format token is generated without the surrounding double quotation marks, because the Cookie value can contain double quotes. The Cookie value can contain multiple attribute-value pairs that are separated by spaces. We recommend that when you use the Cookie format token in a custom format string, you should position it as the last field in the format string so that it can be easily parsed by the transaction log reporting tools. By using the format token string \'%{Cookie}i\' the Cookie header can be surrounded by single quotes (').
The following command can generate the well-known Apache Combined Log Format:
transaction-log format custom "[%{%d}t/%{%b}t/%{%Y}t:%{%H}t:%{%M}t:%{%S}t %{%z}t] %r %s %b %{Referer}i %{User-Agent}i"
The following transaction log entry example in the Apache Combined Format is configured using the preceding custom format string:
[11/Jan/2003:02:12:44 -0800] "GET http://www.cisco.com/swa/i/site_tour_link.gif HTTP/1.1" 200 3436 "http://www.cisco.com/" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
Table 2-174 Custom Format "Log Format String" Values
%...a
IP address of the requesting client.
%...A
IP address of the Content Engine.
%...B
%...bBytes sent excluding HTTP headers.
%...c
Connection status when response is completed where
X = Connection was aborted before the response was completed.
+ = Connection can be kept alive after the response is sent.
- = Connection is closed after the response is sent.%...f
Filename.
%...h
Remote host (IP address of the requesting client is logged).
%...H
Request protocol.
%...{Foobar}i
Contents of Foobar: header lines in the request that is sent to the server. The value of Foobar can be one of the following headers: User-Agent, Referer, Host, or Cookie.
%...l
Remote log name.
Not implemented on the Content Engine, so a hyphen (-) is logged.
%...m
Request method.
%...p
Canonical port of the server servicing the request. Not applicable on the Content Engine, so a hyphen (-) is logged.
%...P
Process ID of the child that serviced the request.
%...q
Query string (that is preceded by a question mark (?) if a query string exists; otherwise, it is an empty string).
%...r
First line of the request.
%...s
Status. The translog code always returns the HTTP response code for the request.
%...t
Time in common log time format (or standard English format).
%...{format}t
Time in the form given by the format token specified in Table 2-175.
%...T
Time consumed to serve the request in seconds (a floating point number with three decimal places).
%...u
Remote user.
%...U
URL path requested not including query strings.
%...v
%...VValue of the host request header field reported if the host appeared in the request. If the host did not appear in the host request header, the IP address of the server specified in the URL is reported.
Table 2-175 specifies the format token for the date and time of the format token %...{format}t that is listed in Table 2-176.
The Extended Squid log format uses the RFC 981 field of the Squid log format for the username. The Extended Squid format logs the associated username for authentication for each record in the log file, if available. The username is also used for billing purposes.
The W3C Customizable Logging Format is limited in that it was defined from the HTTP web server perspective and does not offer certain web cache-specific custom options such as those supplied by the fixed Squid format. Additional format tokens that are extensions to the W3C Customized Logging Format were added in the ACNS 5.3 software release to support additional Cisco and Squid customized logging fields. These new format tokens provide support for a Squid-like logging format from within the W3C customizable token set.
In the ACNS 5.3 software release, the following transaction logging support was added:
•
•
In the ACNS 5.3 software release, the W3C Customizable Logging Format was extended to include support for the following special token sequence:
%...{<translog-token>}C
The ellipsis (...) is optional. If specified, it can be a sequence of conditional HTTP response codes separated by commas. The uppercase C defines the extended customizable behavior token set, for which tokens are defined by the <translog-token> directive, which is a two-character token directive.
Table 2-176 lists the existing and new <translog-token> directives from the Extended Squid format, which are not immediately supported by the W3C definitions but are supported in the ACNS 5.3 software and later releases.
In addition to the tokens listed in Table 2-176, you can condense multiple %...{xx}C style tokens into a single embedded token sequence within the %...{xx}C style. A limited customized logging string validation mechanism has been implemented for all the %...{xy}C style format tokens. This mechanism ensures that the tokens are valid and rejects invalid tokens. To condense multiple style tokens into a single embedded token sequence, you must specify multiple tokens within the {} braces and prefix each token with the percent (%) symbol as follows:
%{rh}C %{rt}C %{as}C
can be reexpressed in a condensed embedded token format as the following:
%{%rh %rt %as}C
The command line syntax accepts single tokens represented as the following:
%{%rh}C
and
%{rh}C
as equivalents.
Any character that is not part of an embedded token sequence (for example, the space character) is repeated verbatim in the output file.
The above set of tokens allow you to configure an extended Squid-like format line within the W3C Customizable Logging format specification as follows:
%{es}C.%{em}C %{te}C %a %{rd}C/%s %{cs}C %m %{ru}C %u %{rh}C %{rt}C %{as}C
The following is an example of a Extended Squid-like format that specifies that user-readable time-stamps are used instead of Squid's "seconds-since-epoch" time-stamp format, and that a configured out-going proxy (as specified by "%...{rH}C") is logged:
[%{%d/%b/%Y:%H:%M:%S %z}t] %{te}C %a %{rd}C/%s %{cs}C %m %{ru}C %u %{rH}C %{rt}C %{as}C
Unknown or unsupported translog tokens are logged within the log file as the characters that made up the token. For example, %{xy}C is logged into the log file as xy. All characters outside of a token specification sequence are repeated verbatim within the log file.
Sanitizing Transaction Logs
Use the sanitized option to disguise the IP address of clients in the transaction log file. The default is that transaction logs are not sanitized. A sanitized transaction log disguises the network identity of a client by changing the IP address in the transaction logs to 0.0.0.0.
The no form of this command disables the sanitize feature. The transaction-logs sanitize command does not affect the client IP (%a) value associated with a custom log format string that is configured with the CLI (configured with the transaction-logs format custom string global configuration command in which the string is the quoted log format string that contains the custom log format). To hide the identity of the client IP in the custom log format, either hard code 0.0.0.0 in the custom log format string or exclude the %a token, which represents the client IP, from the format string.
Exporting Transaction Log Files
To facilitate the postprocessing of cache log files, you could export transaction logs to an external host.
This feature allows log files to be exported automatically by FTP to an external host at configurable intervals. The username and password used for FTP are configurable. The directory to which the log files are uploaded is also configurable.
The log files automatically have the following filename:
type_ipaddr_yyyymmdd_hhmmss.txt
where
•
•
•
Note
Exporting and Archiving Intervals
The transaction log archive and export functions are configured with the following commands:
•
•
The following limitations apply:
•
•
•
•
•
Transaction Log Archive Filenaming Convention
The archive transaction log file is named as follows for HTTP and WMT caching:
celog_10.1.118.5_20001228_235959.txtmms_export_10.1.118.5_20001228_235959If the export compress feature is enabled when the file is exported, then the file extension will be .gz after the file is compressed for the export operation, as shown in the following example:
celog_10.1.118.5_20001228_235959.txt.gzmms_export_10.1.118.5_20001228_235959.gzTable 2-177 describes the name elements.
Table 2-178 lists the directory names and the corresponding examples of the archive filenames.
Compressing Archive Files
The transaction-logs export compress option compresses an archive into a gzip file format before exporting it. Compressing the archive file uses less disk space on both the Content Engine and the FTP export server. The compressed file uses less bandwidth when transferred. The archive filename of the compressed file has the extension .gz.
Exporting Transaction Logs to External FTP Servers
The transaction-logs export ftp-server option can support up to four FTP servers. To export transaction logs, you must first enable the feature and configure the FTP server parameters. The following information is required for each target FTP server:
•
The Content Engine translates the hostname with a DNS lookup and then stores the IP address in the configuration.
•
•
Use a fully qualified path or a relative path for the user login. The user must have write permission to the directory.
Use the no form of the transaction-logs export enable command to disable the entire transaction logs feature while retaining the rest of the configuration.
Exporting Transaction Logs to External SFTP Servers
Use the transaction-logs export sftp-server option to export transaction logs. You must first enable the feature and configure the Secure File Transfer Protocol (SFTP) server parameters. The following information is required for each target SFTP server:
•
The Content Engine translates the hostname with a DNS lookup and then stores the IP address in the configuration.
•
•
Use a fully qualified path or a relative path for the user login. The user must have write permission to the directory.
Use the no form of the transaction-logs export enable command to disable the entire transaction logs feature while retaining the rest of the configuration.
Receiving a Permanent Error from the External FTP Server
A permanent error (Permanent Negative Completion Reply, RFC 959) occurs when the FTP command to the server cannot be accepted, and the action does not take place. Permanent errors can be caused by invalid user logins, invalid user passwords, and attempts to access directories with insufficient permissions.
When an FTP server returns a permanent error to the Content Engine, the export is retried at 10-minute intervals or sooner if the configured export interval is sooner. If the error is a result of a misconfiguration of the transaction-logs export ftp server command, then you must reenter the Content Engine parameters to clear the error condition. The show statistics transaction-logs command displays the status of logging attempts to export servers.
The show statistics transaction-logs command shows that the Content Engine failed to export archive files.
The transaction-logs format command has four options: squid, extended-squid, apache, and custom. The default format is squid.
Use the no form of the transaction-logs export enable command to disable the entire transaction logs feature while retaining the rest of the configuration.
Configuring Intervals Between 1 Hour and 1 Day
The archive or export interval can be set for once a day with a specific time stamp. It can also be set for hour frequencies that align with midnight. For example, every 4 hours means archiving occurs at 0000, 0400, 0800, 1200, and 1600. It is not possible to archive at half-hour intervals such as 0030, 0430, or 0830. The following intervals are acceptable: 1, 2, 3, 4, 6, 8, 12, and 24.
Configuring Intervals of 1 Hour or Less
The interval can be set for once an hour with a minute alignment. It can also be set for frequencies of less than an hour; these frequencies will align with the top of the hour. Every 5 minutes means that archiving will occur at 1700, 1705, and 1710.
Configuring Export Interval on Specific Days
The export interval can be set for specific days of the week at a specific time. One or more days can be specified. The default time is midnight.
You must be aware that archived logs are automatically deleted when free disk space is low. It is important to select an export interval that exports files frequently enough so that files are not automatically removed prior to export.
Logging Windows Domain with Authenticated Usernames
If your Content Engine is configured for NTLM authentication and uses the Extended Squid-style or custom format, the transaction-logs log-windows-domain global configuration command records the Windows domain name and username in the username field of the transaction log. If the domain name is available, both the domain name and the username are recorded in the username field, in the form domain\username. If only the username is available, only the username is recorded in the username field. If neither a domain name nor a username is available, a hyphen (-) is recorded in the field.
The Windows domain name that is used for NTLM authentication appears in the username field of the transaction log. The username appears in the domain\username format in the Extended Squid-style and custom transaction log formats that contain the username using the %u format token. (The %u format token specifies the day of the week as a decimal; the range is 1 to 7 with Monday as 1.)
Use the no transaction-logs log-windows-domain global configuration command to negate logging NTLM parameters to the transaction log in Extended Squid-style or Custom formats.
Monitoring HTTP Request Authentication Failures in Real Time
The ACNS 5.2 software and later releases support sending HTTP transaction log messages to a remote syslog server so that you can monitor the remote syslog server for HTTP request authentication failures in real time. This real-time transaction log allows you to monitor transaction logs in real time for particular errors such as HTTP request authentication errors. The existing transaction logging to the local file system remains unchanged.
Note
To support the real-time transaction logging feature, the following commands are supported in the ACNS 5.2 software and later releases:
[no] transaction-logs logging enable
[no] transaction-logs logging host {hostname | ipaddr} [port port-num rate-limit msgs-per-sec]
[no] transaction-logs logging facility fac-name[no] transaction-logs logging entry-type entry-type [request-auth-failures | all]
These commands allow you to specify a remote syslog host that will receive transaction log messages in real time. The configurable rate-limiting option (the rate-limit option) was added to limit the rate at which the transaction logger is allowed to send messages to the remote syslog server (messages per second). You can configure the Content Engine to send transaction log messages in real time to one remote syslog host.
Configuring the Remote syslog Host for Real-Time Transaction Logging
To configure a Content Engine to send transaction log messages in real time to a remote syslog host, use the transaction-logs logging host global configuration command.
The ACNS 5.2 software and later releases support Content Engine syslog messages to report communication errors with the remote syslog host that is configured for transaction logging. These syslog messages are in the error message range: %CE-TRNSLG-6-460013 to %CE-TRNSLG-3-460016. The last error message (%CE-TRNSLG-3-460016), shows level 3 (for error-level messages) instead of 6 (for information-level messages). Information-level messages are reported when messages are dropped due to rate limiting and the number of dropped messages are reported.
Configuring a Transaction Log Facility when Logging to a Remote syslog Host
When logging transactions to a remote syslog host, use the transaction-logs logging facility global configuration command to configure a transaction log facility.
Specifying the Transaction Log Entry Type when Logging to a Remote syslog Host
With the ACNS 5.2 software and later releases, use the transaction-logs logging entry-type global configuration command to configure the Content Engine to send only the transactions associated with HTTP request authentication failures or to send all of the transactions.
When you specify the transaction-logs logging enable global configuration command, the logging of only HTTP request authentication failures is the default. If you want to change this default and log all transactions, then you must enter the transaction-log logging entry-type all global configuration command on the Content Engine. However, if you log all transactions, there may be a significant UDP drop rate if your syslog host cannot handle the rate of incoming traffic.
Examples
The following example shows how to configure an FTP server:
ContentEngine(config)# transaction-logs export ftp-server 10.1.1.1 mylogin mypasswd /ftpdirectoryContentEngine(config)# transaction-logs export ftp-server myhostname mylogin mypasswd /ftpdirectoryThe following example shows how to delete an FTP server:
ContentEngine(config)# no transaction-logs export ftp-server 10.1.1.1ContentEngine(config)# no transaction-logs export ftp-server myhostnameUse the no form of the command to disable the entire transaction log export feature while retaining the rest of the configuration:
ContentEngine(config)# no transaction-logs export enableThe following example shows how to change a username, password, or directory:
ContentEngine(config)# transaction-logs export ftp-server 10.1.1.1 mynewname mynewpass /newftpdirectory
Note
The following example shows how to restart the export of archive transaction logs:
ContentEngine(config)# transaction-logs export ftp-server 172.16.10.5 goodlogin pass /ftpdirectoryThe following example shows how to delete an SFTP server from the current configuration:
ContentEngine(config)# no transaction-logs export sftp-server sftphostnameThe following example shows how to display information on exported log files:
ContentEngine# show transaction-loggingTransaction log configuration:---------------------------------------Logging is enabled.End user identity is visible.File markers are disabled.Archive interval: every-day every 1 hour.Maximum size of archive file: 2000000 KBExporting files to ftp servers is enabled.File compression is disabled.Export interval: every-day every 1 hour.ftp-server username directory10.1.1.1 mylogin /ftpdirectory10.2.2.2 mylogin /ftpdirectoryWorking Log file - size: 103age: 0The following examples show how to configure the archiving intervals:
ContentEngine(config)# transaction-logs archive interval every-dayat Specify the time at which to archive each dayevery Specify the interval in hours. It will align with midnightContentEngine(config)# transaction-logs archive interval every-day at<0-23>: Time of day at which to archive (hh:mm)ContentEngine(config)# transaction-logs archive interval every-day every<1-24> Interval in hours: {1, 2, 3, 4, 6, 8, 12 or 24}The following example shows that the Content Engine has failed to export archive files:
ContentEngine# show statistics transaction-logsTransaction Log Export Statistics:Server:172.16.10.5Initial Attempts:1Initial Successes:0Initial Open Failures:0Initial Put Failures:0Retry Attempts:0Retry Successes:0Retry Open Failures:0Retry Put Failures:0Authentication Failures:1Invalid Server Directory Failures:0The following example shows how to correct a misconfiguration:
ContentEngine(config)# transaction-logs export ftp-server 10.1.1.1 goodlogin pass /ftpdirectoryThe working.log file and archived log files are listed for HTTP and WMT.
The following example shows how to export transaction logs to an SFTP server:
ContentEngine(config)# transaction-logs export sftp-server 10.1.1.100 mylogin mypasswd /mydirThe following example shows how to archive every 4 hours and align with the midnight local time (0000, 0400, 0800, 1200, 1600, and 2000):
ContentEngine(config)# transaction-logs archive interval every-day every 4The following example shows how to export once a day at midnight local time:
ContentEngine(config)# transaction-logs export interval every-day every 24The following example shows how to configure export intervals:
ContentEngine(config)# transaction-logs archive interval every-hour ?at Specify the time at which to archive each dayevery Specify interval in minutes. It will align with top of the hourContentEngine(config)# transaction-logs archive interval every-hour at ?<0-59> Specify the minute alignment for the hourly archiveContentEngine(config)# transaction-logs archive interval every-hour every ?<2-30> Interval in minutes: {2, 5, 10, 15, 20, 30}The following example shows how to create a separate log on the remote syslog host for real-time transaction log entries and how to configure a unique facility (for example, local1) on the Content Engine:
ContentEngine(config)# transaction-logs logging facility local1Related Commands
clear transaction-log
show statistics transaction-logs
show transaction-logging
transaction-log forcetvout
To enable and configure TV-out service, use the tvout global configuration command. Use the no form of this command to disable TV-out service.
tvout {enable | signal {ntsc | pal}}
no tvout {enable | signal {ntsc | pal}}
Syntax Description
Defaults
The default TV-out signal format is NTSC.
Command Modes
global configuration
Usage Guidelines
The TV-out service provides capability for local playback of the pre-positioned MPEG content through a hardware decoder that converts the digital information into an analog TV signal. The TV-out service is enabled or disabled on the Content Engine. The tvout enable command is only functional if a supported MPEG hardware decoder is installed.
You can combine media from multiple channels in the playlist and add image overlays to media files in TV-out programs. Before you create a TV-out program, you must first enable the TV-out feature on the Content Engine and designate the format of the signal output.
Content Engines that are equipped with an integrated Moving Picture Experts Group (MPEG) decoder can convert digital media into analog TV signals. These Content Engines play media files using NTSC or PAL video signals and can play video directly to a TV monitor for applications such as kiosks, cable TV systems, and video walls.
Note
In the ACNS 5.2.3 software and later releases, the following changes that are related to the TV-out service were incorporated:
•
•
Examples
The following example enables TV-out on the Content Engine:
ContentEngine(config)# tvout enableThe following example configures TV-out format on the Content Engine as NTSC:
ContentEngine(config)# tvout signal ntscThe following example configures TV-out format on the Content Engine as PAL:
ContentEngine(config)# tvout signal palRelated Commands
show running-config
show tvouttype
To display a file, use the type EXEC command.
type filename
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Use this command to display the contents of a file within any Content Engine file directory. This command may be used to monitor features such as transaction logging or system logging (syslog).
Examples
The following example displays the syslog file on the Content Engine:
ContentEngine# type /local1/syslog.txtJan 10 22:02:46 (none) populate_ds: %CE-CLI-5-170050: Cisco ACNS software starts bootingJan 10 22:02:47 (none) create_etc_hosts.sh: %CE-CLI-5-170051: HOSTPLUSDOMAIN: NO-HOSTNAMEJan 10 22:02:47 NO-HOSTNAME : %CE-CLI-5-170053: Recreated etc_hosts (1, 0)Jan 10 22:02:48 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330082: [CLI_VER_NTP] requests stop service ntpdJan 10 22:02:49 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330082: [ver_tvout] requests stop service tvoutsvrJan 10 22:02:50 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330084: [ver_rtspg] requests restart service rtspgJan 10 22:02:50 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330082: [ver_iptv] requests stop service sbssJan 10 22:02:51 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330080: [ver_telnetd] requests start service telnetdJan 10 22:02:52 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330082: [ver_wmt] requests stop service wmt_mmsJan 10 22:02:53 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330082: [ver_wmt] requests stop service wmt_logdJan 10 22:02:55 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330082: [Unknown] requests stop service mcast_senderJan 10 22:02:55 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330082: [Unknown] requests stop service mcast_receiverJan 10 22:02:56 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330024: Service 'populate_ds' exited normally with code 0Jan 10 22:02:56 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330040: Start service 'parser_server' using: '/ruby/bin/parser_server' with pid: 1753Jan 10 22:02:56 NO-HOSTNAME Nodemgr: %CE-NODEMGR-5-330040: Start service 'syslog_bootup_msgs' using: '/ruby/bin/syslog_bootup_msgs' with pid:1754Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4>Linux version 2.4.16 (cnbuild@builder2.cisco.com) (gcc version 3.0.4) #1SMP Fri Jan 7 19:26:58 PST 2005Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <6>setup.c: handling flash window at [15MB..16MB)Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <6>BIOS-provided physical RAM map:Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4> BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4> BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4> BIOS-e820: 00000000000e0800 - 0000000000100000 (reserved)Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4> BIOS-e820: 0000000000100000 - 0000000000f00000 (usable)Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4> BIOS-e820: 0000000000f00000 - 0000000001000000 (reserved)Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4> BIOS-e820: 0000000001000000 - 0000000010000000 (usable)Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4> BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <6>setup.c: reserved bootmem for INITRD_START = 0x6000000, INITRD_SIZE = 11709348Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4>On node 0 totalpages: 65536Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4>zone(0): 4096 pages.Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4>zone(1): 61440 pages.Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4>zone(2): 0 pages.Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4>Local APIC disabled by BIOS -- reenabling.Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4>Found and enabled local APIC!Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <4>Kernel command line: root=/dev/ram ramdisk_size=100000 ramdisk_start=0x6000000 console=ttyS0,9600n8Jan 10 22:02:56 NO-HOSTNAME syslog_bootup_msgs: %CE-SYS-5-900001: <6>Initializing CPU#0--More--..Related Commands
cpfile
dir
lls
ls
mkfiletype-tail
To view a specified number of lines of the end of a log file or to view the end of the file continuously as new lines are added to the file, use the type-tail command in EXEC mode.
type-tail filename [line | follow]
Syntax Description
Defaults
Ten lines shown
Command Modes
EXEC
Usage Guidelines
This command allows you to monitor a log file by letting you view the end of the file. You can specify the number of lines at the end of the file that you want to view, or you can follow the last line of the file as it continues to log new information. To stop the last line from continuously scrolling, press Ctrl-C.
Examples
The following example shows the list of log files in the /local1 directory:
stream-ce# ls /local1WS441WebsenseWebsenseEnterpriseWebsense_config_backupWsInstallLogbadfile.txtcodecoveragecore.stunnel.5.3.0.b100.cnbuild.5381core_dircrashcrka.logcse_livecse_voddbdowngrade.logdbupgrade.logdowngradeerrorloghttp_authmod.unstripindex.htmllogslost+foundnetscape-401-proxynetscape-401-proxy1netscape-dumpnewwebsenseoldWsInstallLogpreload_dirproxy-basic1proxy1proxy2proxy3proxy4proxy5proxy6proxy7proxy8proxyreplyproxyreply-407real_vodruby.bin.cli_fixruby.bin.no_ws_fixruby.bin.ws_edir_fixsaservice_logssmartfiltersmfnaveensuperwebsensesyslog.txtsyslog.txt.1syslog.txt.2temptwo.txturl.txturllist.txtvarvpd.propertieswebsense.pre-200webtarball44webtarball520wmt_vodws_upgrade.logThe following example displays the last ten lines of the syslog.txt file. In this example, the number of lines to display is not specified; however, ten lines is the default.
stream-ce# type-tail /local1/syslog.txtOct 8 21:49:15 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:15 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:15 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:17 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:17 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:17 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:19 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:19 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:19 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:21 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0The following example displays the last 20 lines of the syslog.text file:
stream-ce# type-tail /local1/syslog.txt 20Oct 8 21:49:11 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:11 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:13 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:13 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:13 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:15 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:15 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:15 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:17 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:17 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:17 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:19 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:19 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:19 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:21 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:21 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:21 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:23 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:23 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:23 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLThe following example follows the file as it grows:
stream-ce# type-tail /local1/syslog.txt ?<1-65535> The numbers of lines from endfollow Follow the file as it grows<cr>stream-ce# type-tail /local1/syslog.txt followOct 8 21:49:39 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:41 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:41 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:41 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:43 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:43 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:43 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:45 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:45 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:45 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:47 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:47 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:47 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLOct 8 21:49:49 stream-ce syslog:(26830)TRCE:input_serv.c:83-> select_withreturn 0, ready = 0Oct 8 21:49:49 stream-ce syslog:(26832)TRCE:al_master.c:246-> select_withreturn 0, ready = 0Oct 8 21:49:49 stream-ce syslog:(26832)TRCE:in_mms.c:1747-> tv = NULLundebug
To disable debugging functions, use the undebug EXEC command.
undebug option
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
We recommend that you use the debug and undebug commands only at the direction of Cisco TAC. See the "Obtaining Technical Assistance" section on page -xvii for more information.
See the "debug" section on page 2-128 for more information about debug functions.
Related Commands
debug
no debug
show debugurl-filter (EXEC)
To reload new local good sites or good sites' lists on the Content Engine when the url-filter feature is enabled, use the url-filter local-list-reload EXEC command.
url-filter local-list-reload {http | rtsp | wmt}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
When you update the badurl.lst or goodurl.lst file, use the url-filter local-list-reload command to reload the latest good sites or good sites' lists that you created or edited using the url-filter command.
Examples
The following example shows how to reload new good sites' list or bad sites' list on the Content Engine for HTTP:
ContentEngine# url-filter local-list-reload httpThe following example shows how to reload new good sites' list or bad sites' list on the Content Engine for RTSP:
ContentEngine# url-filter local-list-reload rtspThe following example shows how to reload new good sites' list or bad sites' list on the Content Engine for WMT:
ContentEngine# url-filter local-list-reload wmtRelated Commands
url-filter (global configuration mode)
url-filter (global configuration)
To configure URL filtering over HTTP, RTSP, or WMT, use the url-filter global configuration command. Use the no form of this command to disable selected options.
url-filter http bad-sites-deny {enable | file filename}
url-filter http custom-message dirname
url-filter http good-sites-allow {enable | file filename}
url-filter http N2H2 {allowmode enable | enable | server {hostname | ip-address} [port portnum [timeout seconds]]}
url-filter http smartfilter enable
url-filter http websense {allowmode enable | enable | server {hostname | ip-address | local}[port portnum [timeout seconds [connections connection]]]}
url-filter rtsp {bad-sites-deny {enable | file filename}}
url-filter rtsp {good-sites-allow {enable | file filename}}
url-filter wmt {bad-sites-deny {enable | file filename}}
url-filter wmt {good-sites-allow {enable | file filename}}
no url-filter {http {bad-sites-deny {enable | file} | custom-message | good-sites-allow {enable | file} | N2H2 {allowmode enable | enable | server} | smartfilter enable | websense {allowmode enable | enable | server {hostname | ip-address | local} [port portnum [timeout seconds [connections connection]]]}} | {rtsp | wmt}{bad-sites-deny {enable | file} | good-sites-allow {enable | file}}}
Syntax Description
Defaults
url-filter N2H2 allowmode: enabled
url-filter websense allowmode: enabled
N2H2 server port portnum: 4005
N2H2 sever timeout seconds: 5
websense server port portnum: 15868
websense server timeout seconds: 20
connections: 40 per CPU
Command Modes
global configuration
Usage Guidelines
Table 2-179 lists the various URL filtering schemes that you can use to configure a Content Engine to control client access to websites.
Table 2-179 URL Filtering Mechanisms with Content Engines
Local list files
Deny access to URLs specified in a list. Permit access only to URLs specified in a list. See the "URL Filtering with Local Lists" section.
N2H2 external servers
Direct client requests for content to an external N2H2 server for URL filtering. See the "URL Filtering with the N2H2 Server" section.
Websense server
Direct client requests for content to either the local Websense plug-in or to an external Websense server for URL filtering. See the "URL Filtering with the Websense Enterprise Server" section.
SmartFilter plug-in
Direct client requests for content to the SmartFilter plug-in for URL filtering. See the "URL Filtering with SmartFilter Software" section.
Although only one form of URL filtering scheme can be active at a time per protocol, many URL filtering schemes can be supported at one time. For example, if an N2H2 filter is applied to HTTP requests, then no other URL filtering scheme (for instance, Websense or SmartFilter) can be applied to this protocol. However, you could apply the local list URL filtering scheme (good sites' list and bad sites' list) to the streaming media protocols (WMT client requests and client requests over RTSP). The scheme enabled for a particular protocol is independent from that of other protocols.
URL filtering allows the Content Engine to control client access to websites in any of the following ways:
•
•
•
•
•
URL filtering for RTSP requests is used when the client is a Windows Media 9 player and the server is a Windows Media 9 server. If an earlier version of the Windows Media player is used (for example, Windows Media 7 players), MMS is used instead of RTSP to service the content request from the Windows Media player.
Note
To ensure that URL filtering applies to every URL that passes through the Content Engine, disable all bypass features. Bypass features, the error-handling transparent and bypass load global configuration commands, are enabled initially by default and must be disabled manually. For error handling, use the error-handling send-cache-error or error-handling reset-connection command instead.
URL filtering existed in the Cache software 2.x releases. URL filtering in the ACNS 4.x and 5.x software differs from the URL feature in other releases as follows:
•
•
•
•
•
URL Filtering with Local Lists
You can configure Content Engines to deny client requests for URLs that are listed in a badurl.lst file, or configure them to fulfill only requests for URLs in a goodurl.lst file. The use of local list files (URL lists) applies to HTTP (HTTP, HTTPS-over-HTTP, and FTP-over-HTTP protocols) and streaming media protocols such as RTSP. This type of URL filtering is referred to as local list URL filtering.
Tip
The local list file for each protocol should not contain URLs that belong to other protocols. The HTTP local list file should contain only HTTP, HTTPS, or FTP URLs. The HTTP local list file should contain only the following types of URLs; HTTP, HTTPS, or FTP URLs. In the ACNS 5.3 software and later releases, the WMT local list file can contain RTSP URLs.
Caution
You can configure a Content Engine to use local list URL filtering to filter the following types of client requests for content:
•
•
•
Note
Support for RTSP-over-RTP (referred to as WMT RTSP requests) for Windows Media 9 players is available in the ACNS 5.3 software and later releases. For WMT RTSP requests, there are three possible protocol prefixes: rtsp, rtspu, and rtspt.
If the user enters rtsp: as the protocol prefix for the URL, the Windows Media 9 player can choose to use RTSPT or RTSPU. If the RTSP bad file has a URL of rtsp://hostname/pathname and the user's URL request is rtspt://hostname/pathname, then the RTSP request from a Windows Media 9 player might get through the URL filtering. Special URL filtering for RTSP requests from Windows Media 9 players was added in the ACNS 5.3 software.
For WMT URL filtering, filtering for RTSP URLs (rtsp://) is only supported; there is no separate filtering support for RTSPT and RTSPU URLs. However, if you configure an RTSP URL in the badurl.lst file, then it will block both the RTSPT and RTSPU URLs.
Local list URL filtering is the only supported filtering mechanism for WMT requests and RTSP requests (requests from RealMedia players). The third-party URL filtering mechanisms (N2H2, SmartFilter, and Websense software) are not supported for WMT and RTSP requests. For HTTP requests, the local list URL filtering mechanism and N2H2, SmartFilter, and Websense URL filtering are supported.
URL Filtering with URL Lists
You can configure the Content Engine to deny client requests for URLs that are listed in a badurl.lst file, or configure it to fulfill only requests for URLs in a goodurl.lst file.
Note
Use the url-filter wmt global configuration commands to configure local list URL filtering for WMT requests. If you configure an RTSP URL in a WMT good sites' list, it blocks both the RTSPT and RTSPU URLs and the RTSP URL that is specified in the good sites' list.
Note
Custom Blocking Messages
In the case of local list URL filtering, the Content Engine with the ACNS 5.x software can be configured to return a customized blocking message to the client. The custom message must be an administrator-created HTML page named block.html. Make sure to copy all embedded graphics associated with the custom message HTML page to the same directory that contains the block.html file. To enable the customized blocking message, use the url-filter http custom-message command and specify the directory name.
To disable the custom message, use the no url-filter http custom-message command.
The url-filter http custom-message command can be enabled and disabled without affecting the good-sites-allow and bad-sites-deny configuration.
Note
In the block.html file, objects (such as .gif, .jpeg, and so on) must be referenced with the string /content/engine/blocking/url, as shown as follows:
<TITLE>Cisco Content Engine example customized message for url-filtering</TITLE><p><H1><CENTER><B><I><BLINK><FONT COLOR="#800000">P</FONT><FONT COLOR="#FF00FF">R</FONT><FONT COLOR="#00FFFF">A</FONT><FONT COLOR="#FFFF00">D</FONT><FONT COLOR="#800000">E</FONT><FONT COLOR="#FF00FF">E</FONT><FONT COLOR="#00FFFF">P</FONT><FONT COLOR="#FF8040">'</FONT><FONT COLOR="#FFFF00">S</FONT></BLINK><FONT COLOR ="#0080FF">Blocked Page</FONT></I></B></CENTER></H1><p><p><IMG src="/content/engine/blocking/url/my.gif"><p>This page is blocked by the Content Engine.<p>A block.html file displays the following custom message when the Content Engine intercepts a request to the blocked site:
This page is blocked by the Content EngineContact your administrator if you have any questions concerning access to the blocked site that you requested.
RADIUS and URL Filtering
When both RADIUS authentication and URL filtering are enabled on the Content Engine, users can be configured to bypass URL filtering using the user Filter-Id attribute in the RADIUS server database.
The following is an example of a user Filter-Id attribute entry in the RADIUS server database:
test Password = "test"Service-Type = Framed-User,Filter-Id = "No-Web-Blocking"The Filter-Id attribute is defined as either No-Web-Blocking or Yes-Web-Blocking. If blocking is not specified, Yes-Web-Blocking is the default RADIUS filter. Yes-Web-Blocking means that the request is subject to URL filtering and No-Web-Blocking means that the request is not subject to the URL filtering.
URL Filtering with the N2H2 Server
Content Engines can use an N2H2 enterprise server as a filtering engine and enforce the filtering policy configured on the N2H2 server. The Content Engine and the N2H2 server use Internet Filtering Protocol (IFP) Version 2 to communicate with each other. When the Content Engine receives a URL request, it sends an IFP request to the N2H2 server with the requested URL. The N2H2 server does some necessary lookups for the URL and sends back an IFP response. Based on the N2H2 server's IFP response, the Content Engine either blocks the HTTP request by redirecting the browser to a page where a blocking message is displayed or proceeds with normal HTTP processing by sending the URL request to an origin server.
Note
URL Filtering with the Websense Enterprise Server
The Content Engine can use a Websense enterprise server as a filtering engine and enforce the filtering and enforce the filtering policy configured on Websense server. You can also configure a Content Engine to use the integrated Websense server. The integrated Websense server is an internal server that runs on the Content Engine and is referred to as the local Websense server.
Note
About Websense Server Failover
In the ACNS software, Release 5.2, a Websense server failover feature was added. This feature allows you to configure a Content Engine to use up to two Websense servers for failover purposes (one primary and one secondary server) for URL filtering. Table 2-180 lists the supported Websense server failover configurations.
The order in which you configure Websense servers determines which server is designated as the primary Websense server. The first configured Websense server is designated as the primary server. Configuration of a secondary Websense server is optional.
If both the primary and secondary Websense servers fail (if there is no response from Websense server), the Content Engine will time out all HTTP requests (HTTP, FTP-over-HTTP, or HTTPS-over-HTTP requests) and either allow or block all traffic based on the allowmode configuration.
If the primary Websense server is down, HTTP requests are redirected to the configured secondary Websense server. The Content Engine sends a request to the primary Websense server at certain polling intervals to determine when the primary Websense server comes back online. If the secondary Websense server is also down (assuming that the primary Websense server is already down), the Content Engine sends a request to the secondary Websense server at certain polling intervals to determine when the secondary Websense server comes back online. All HTTP requests received at that time are either blocked or allowed depending on the allowmode configuration. When the designated primary Websense server is back online, the Content Engine establishes connections with the primary server and sends client requests for filtering.
Also, primary and secondary Websense servers can be running any possible combination of Websense server Version 4.0.3 or later. While downgrading from the ACNS 5.2 and later releases to an earlier release of the ACNS 5.x software, the secondary Websense server configuration, if any, would be removed.
URL Filtering with SmartFilter Software
SmartFilter software running on Content Engines provides employee Internet management (EIM) functionality when used with proxy servers, firewalls, and caching appliances. SmartFilter filtering is available as an add-on service on a Content Engine that is running the ACNS 5.x software. The SmartFilter add-on service is licensed directly through Cisco. The Content Engine uses a suite of plug-in APIs to allow the SmartFilter software to implement hooks at strategic points during an HTTP transaction.
Note
To configure this SmartFilter add-on service, you use an end user management tool called the sfadmin console, and a management server tool called the sfadmin server. You use the sfadmin console to configure SmartFilter and then store the configuration on the sfadmin server. The sfadmin server propagates this configuration to the end client Content Engines to be used by the SmartFilter software that is running on the Content Engines. Use the url-filter http smartfilter enable global configuration command to enable SmartFilter URL filtering on a Content Engine. To use SmartFilter URL filtering with a cluster of Content Engines, make sure to enter the url-filter http smartfilter enable command on each Content Engine in the cluster to ensure that all traffic is filtered.
Note
About the SmartFilter Control List
These 30 categories are set to Deny in the default SmartFilter software policy. SmartFilter software also provides ten user-defined categories that allow you to define and filter sites that are not included in the SmartFilter Control List. You can exempt any site that you would like specific groups or individuals to access quickly and easily. You can use the SmartFilter Administration Console to define a SmartFilter Control List download schedule. The Download Setup window tracks the download site, your username, and your password. If you do not download an updated SmartFilter Control List at least monthly, the SmartFilter software considers the Control List expired, and invokes the action that you specified in the SmartFilter License window.
Note
Examples
The following example shows how to block a list of URLs:
ContentEngine(config)# url-filter http bad-sites-deny badurl.lstThe following example shows how to disable URL blocking:
ContentEngine(config)# no url-filter http bad-sites-deny enableContentEngine(config)# no url-filter http good-sites-allow enableThe following example shows how to enable a custom message by specifying the directory in which the block.html file is located and then entering the enable command:
ContentEngine(config)# url-filter http custom-message /local1/url_dirContentEngine(config)# url-filter http custom-message enableThe following example shows how to configure a Content Engine to use N2H2 URL filtering with IP address 172.16.22.10, port 4008, and a 6-second timeout:
ContentEngine(config)# url-filter http N2H2 server 172.16.22.10 port 4008 timeout 6The following example shows how to configure a Content Engine to use Websense URL filtering with IP address 172.16.11.22, port 15900, and a 4-second timeout:
ContentEngine(config)# url-filter websense server 172.16.11.22 port 15900 timeout 4The following example shows how to enable a Content Engine to use SmartFilter URL filtering:
ContentEngine(config)# url-filter smartfilter enablestarting smartfilterThe following example shows how to display a Websense server configuration:
ContentEngine# show url-filter httpURL filtering is DISABLEDLocal list configurations==================================Good-list file name : /local1/good.listBad-list file name : /local1/bad.listCustom message directory :Websense server configuration==================================Websense server IP : <none>Websense server port : 15868Websense server timeout: 20 (in seconds)Websense server connections: 40Websense allow mode is ENABLEDN2H2 server configuration==============================N2H2 server IP : <none>N2H2 server port : 4005N2H2 server timeout : 5 (in seconds)N2H2 allow mode is ENABLEDRelated Commands
clear statistics url-filter http
debug url-filter
show statistics url-filter http
show url-filter
url-filter local-list-reload (EXEC mode)
websense-server enableusername
To establish username authentication, use the username global configuration command.
username name {{cifs-password | samba-password} {0 plainword | 1 lancrypto ntcrypto | cleartext} | password {0 plainword | 1 cryptoword | cleartext} [uid uid] | privilege {0 | 15}}
no username name
Syntax Description
Defaults
The password value is set to 0 (clear text) by default.
Default administrator account:
•
•
•
•
Command Modes
global configuration
Usage Guidelines
The username global configuration command changes the password and privilege level for existing user accounts.
User Authentication
User access is controlled at the authentication level. For every HTTP or HTTPS request that applies to the administrative interface, including every CLI and API request that arrives at the ACNS network devices, the authentication level has visibility into the supplied username and password. Based on CLI-configured parameters, a decision is then made to either accept or reject the request. This decision is made either by checking local authentication or by performing a query against a remote authentication server. The authentication level is decoupled from the authorization level, and there is no concept of role or domain at the authentication level.
When local CLI authentication is used, all configured users can be displayed by entering the show running-config command. Normally, only administrative users need to have username authentication configured.
Note
User Authorization
Domains and roles are applied by the Content Distribution Manager at the authorization level. Requests must be accepted by the authentication level before they are considered by the authorization level. The authorization level regulates the access to resources based on the Content Distribution Manager GUI role and domain configuration.
Regardless of the authentication mechanism, all user authorization configuration is visible in the GUI.
Examples
When you first connect an ACNS device to an ACNS network, you should immediately change the password for the username admin, which has the password default, and the privilege level superuser.
The following example shows how to change the password:
ContentEngine(config)# username admin password yoursecretThe following example shows how passwords and privilege levels are reconfigured:
ContentEngine# show user username abeddoeUid : 2003Username : abeddoePassword : ghQ.GyGhP96K6Privilege : normal userContentEngine# show user username bwhidneyUid : 2002Username : bwhidneyPassword : bhlohlbIwAMOkPrivilege : normal userContentEngine(config)# username bwhidney password 1 victoriaContentEngine(config)# username abeddoe privilege 15User's privilege changed to super user (=15)ContentEngine# show user username abeddoeUid : 2003Username : abeddoePassword : ghQ.GyGhP96K6Privilege : super userContentEngine# show user username bwhidneyUid : 2002Username : bwhidneyPassword : mhYWYw.7P1Ld6Privilege : normal userRelated Commands
show user
show userswccp access-list
To configure an IP access list for inbound WCCP GRE-encapsulated traffic, use the wccp access-list global configuration command.
wccp access-list {acl-name | acl-num}
no wccp access-list [acl-name | acl-num]
Syntax Description
Defaults
WCCP access lists are not configured by default.
Command Modes
global configuration
Usage Guidelines
In the ACNS 5.2 software and later releases, you can specify an IP access list that the Content Engine applies to WCCP GRE-encapsulated traffic that it receives inbound by using the wccp access-list global configuration command. Because the default is that no WCCP access list is configured, the WCCP access lists are not shown as part of the Content Engine's configuration.
You can enable WCCP applications to be attached to a particular interface (such as management services to the private IP address space) so that the Content Engine can have one interface in the customer's IP address space that serves the content, and another interface in a private IP address space that the administrator uses for management purposes. This setting ensures that clients can access the Content Engine only in the public IP address space for serving the content and not access it for management purposes. A device attempting to access one of these applications associated with an access control list (ACL) must be on the list of trusted devices to be allowed access.
The wccp access-list acl-num global configuration command configures an access control list to allow access to WCCP applications. The acl-num variable is a number in the range 1 to 99, indicating a standard access control list or a number in the range 100 to 199, indicating an extended access control list. WCCP checks against the specified access control list before accepting or dropping incoming packets.
See the Cisco ACNS Software Configuration Guide for Locally Managed Deployments for a description on how to use standard IP ACLs to control WCCP access on a Content Engine.
Examples
The following example configures the Content Engine to apply IP access list number 10 to the inbound WCCP traffic:
ContentEngine(config)# wccp access-list 10The following example shows sample output from the show ip access-list EXEC command from a Content Engine that has several WCCP access lists configured:
ContentEngine# show ip access-listSpace available:40 access lists489 access list conditionsStandard IP access list 101 deny 10.1.1.12 deny any(implicit deny any: 0 matches)total invocations: 0Standard IP access list 981 permit any(implicit deny any: 0 matches)total invocations: 0Extended IP access list 1001 permit icmp any any(implicit fragment permit: 0 matches)(implicit deny ip any any: 0 matches)total invocations: 0Extended IP access list 1011 permit ip any any(implicit fragment permit: 0 matches)(implicit deny ip any any: 0 matches)total invocations: 0Extended IP access list 1021 permit icmp 0.0.1.1 255.255.0.0 any(implicit fragment permit: 0 matches)(implicit deny ip any any: 0 matches)total invocations: 0Extended IP access list 1111 permit gre 0.1.1.1 255.0.0.0 any(implicit fragment permit: 0 matches)(implicit deny ip any any: 0 matches)total invocations: 0Extended IP access list 1121 permit ip any any(implicit fragment permit: 0 matches)(implicit deny ip any any: 0 matches)total invocations: 0Extended IP access list 1131 permit gre 0.1.1.1 255.0.0.0 any(implicit fragment permit: 0 matches)(implicit deny ip any any: 0 matches)total invocations: 0Extended IP access list ext_acl_21 permit gre any any(implicit fragment permit: 0 matches)(implicit deny ip any any: 0 matches)total invocations: 0Extended IP access list extended_ip_acl1 permit tcp any eq 2 any eq exec(implicit fragment permit: 0 matches)(implicit deny ip any any: 0 matches)total invocations: 0Interface access list references:PortChannel 2 inbound extended_ip_aclPortChannel 2 outbound 101Application access list references:snmp-server standard 2UDP ports: none (List Not Defined)tftp_server standard 98UDP ports: 69WCCP either 10Any IP ProtocolContentEngine#The following example shows sample output from the show wccp gre EXEC command when WCCP access lists are defined on the Content Engine:
Content Engine# show wccp greTransparent GRE packets received: 366Transparent non-GRE packets received: 0Transparent non-GRE packets passed through: 0Total packets accepted: 337Invalid packets received: 0Packets received with invalid service: 0Packets received on a disabled service: 0Packets received too small: 0Packets dropped due to zero TTL: 0Packets dropped due to bad buckets: 0Packets dropped due to no redirect address: 0Packets dropped due to loopback redirect: 0Connections bypassed due to load: 0Packets sent back to router: 0Packets sent to another CE: 0GRE fragments redirected: 0Packets failed GRE encapsulation: 0Packets dropped due to invalid fwd method: 0Packets dropped due to insufficient memory: 0Packets bypassed, no conn at all: 0Packets bypassed, no pending connection: 0Packets due to clean wccp shutdown: 0Packets bypassed due to bypass-list lookup: 0Packets received with client IP addresses: 0Conditionally Accepted connections: 0Conditionally Bypassed connections: 0L2 Bypass packets destined for loopback: 0Packets w/WCCP GRE received too small: 0Packets dropped due to IP access-list deny: 29L2 Packets fragmented for bypass: 0Content Engine#Related Commands
show ip access-list
show wccp grewccp custom-web-cache
To enable the Content Engine to accept redirected HTTP traffic on a port other than 80, use the wccp custom-web-cache global configuration command. To disable custom web caching, use the no form of this command.
wccp custom-web-cache {mask {[dst-ip-mask hex_num] [dst-port-mask port_hex_num] [src-ip-mask hex_num] [src-port-mask port_hex_num]} | router-list-num num port port [assign-method-strict] [hash-destination-ip] [hash-destination-port] [hash-source-ip] [hash-source-port] [l2-redirect] [mask-assign] [password key] [weight percentage]}
no wccp custom-web-cache
Syntax Description
mask
Sets the mask used for Content Engine assignment. Configure at least one mask; the maximum is four masks.
dst-ip-mask
(Optional) Sets the mask used to match the packet destination IP address.
hex_num
IP address mask defined by a hexadecimal number (for example, 0xFC000000). The range is 0x00000000-FE000000.
dst-port-mask
(Optional) Sets the mask used to match the packet destination port number.
port_hex_num
Port mask defined by a hexadecimal number (for example, 0xFC00). The port range is 0-65535.
src-ip-mask
(Optional) Sets the mask used to match the packet source IP address.
src-port-mask
(Optional) Sets the mask used to match the packet source port number.
router-list-num
Sets the router list number.
num
Router list number (1-8).
port
Sets the port number.
port
Port number (1-65535).
assign-method-strict
(Optional) Forces WCCP to strictly use only the configured assignment method. For more information, see the "Assignment Method" section.
hash-destination-ip
(Optional) Defines the load-balancing hash of the destination IP address (the default).
hash-destination-port
(Optional) Defines the load-balancing hash of the destination port.
hash-source-ip
(Optional) Defines the load-balancing hash of the source IP address.
hash-source-port
(Optional) Defines the load-balancing hash of the source port.
l2-redirect
(Optional) Sets the packet forwarding by Layer 2 redirect. For more information, see the "WCCP Layer 2 Support" section.
mask-assign
(Optional) Uses the mask method for the Content Engine assignment.
password
(Optional) Sets the authentication password to be used for secure traffic among the Content Engines within a cluster and the router for a specified service.
Note
key
WCCP service password key. Passwords must not exceed eight characters.
weight
(Optional) Sets the weight percentage for load balancing. For more information, see the "Load Balancing" section.
percentage
Percentage value (0-100).
Defaults
wccp custom-web-cache: default
dst-ip-mask: 0x00001741
src-ip-mask: 0x00000000
dst-port-mask: 0x0
src-port-mask: 0x0
Command Modes
global configuration
Usage Guidelines
The wccp custom-web-cache command causes the Content Engine to establish WCCP Version 2 redirection services automatically with a Cisco router on a user-specified port number. The Content Engine then performs transparent web caching for all HTTP requests over that port while port 80 transparent web caching continues without interruption. For custom web caching, service 98 must be enabled on the router. WCCP Version 1 does not support custom web caching.
Transparent caching on ports other than port 80 can be performed by the Content Engine when WCCP is not enabled or when client browsers have previously been configured to use a legacy proxy server. See the http proxy command for further information.
WCCP Layer 2 Support
WCCP on a router or switch can take advantage of switching hardware that either partially or fully implements the traffic interception and redirection functions of WCCP in the hardware at Layer 2. This WCCP function allows the Content Engine to perform a Layer 2 or MAC address rewrite redirection if it is directly connected to a compatible Cisco switch. This redirection processing is accelerated in the switching hardware, which makes this method more efficient than Layer 3 redirection using GRE.
The Content Engine must have a Layer 2 connection with the switch. Because there is no requirement for a GRE tunnel between the switch and the Content Engine, the switch can use a cut-through method of forwarding encapsulated packets by entering the l2-redirect option in the CLI.
Layer 2 Multicast Addresses
The IEEE LAN specifications made provisions for the transmission of broadcast and multicast packets. In the 802.3 standard, bit 0 of the first octet is used to indicate a broadcast or multicast frame. This bit indicates that the frame is destined for a group of hosts or all hosts on the network (in the case of the broadcast address 0xFFFF.FFFF.FFFF).
IP multicast sends IP packets to a group of hosts on a LAN segment.
Note
The IANA owns a block of Ethernet MAC addresses that start with 01:00:5E in hexadecimal format. Half of this block is allocated for multicast addresses. The range from 0100.5e00.0000 through 0100.5e7f.ffff is the available range of Ethernet MAC addresses for IP multicast.
This allocation allows for 23 bits in the Ethernet address to correspond to the IP multicast group address. The mapping places the lower 23 bits of the IP multicast group address into these available 23 bits in the Ethernet address. Because the upper five bits of the IP multicast address are dropped in this mapping, the resulting address is not unique; 32 different multicast group IDs map to the same Ethernet address. For example, 224.1.1.1 and 225.1.1.1 map to the same multicast MAC address on a Layer 2 switch. If one user subscribed to Group A (as designated by 224.1.1.1) and the other users subscribed to Group B (as designated by 225.1.1.1), they would both receive both A and B streams. This situation limits the effectiveness of this multicast deployment.
You can specify one load-balancing method (hashing and masking) per WCCP service in a Content Engine cluster. For example, if you define three WCCP services for Content Engine Cluster A, two of the services in Cluster A could be using the hash load-balancing method, and the third service in Cluster A could be using the mask load-balancing method.
Note
Note
Note
Assignment Method
The assignment method denotes the method used by WCCP to perform load distribution across Content Engines. There are two possible load-balancing methods assignment methods: hashing and masking. If the mask load-balancing method is not specified, then the hash load-balancing method, which is the default method, is used.
The redirection mode is controlled by the Content Engine. The first Content Engine that joins the WCCP service group decides the forwarding method (GRE or Layer 2 redirection) and the assignment method (hashing or masking). The mask assignment is used to refer to WCCP Layer 2 Policy Feature Card 2 (PFC2) input redirection.
The Content Engine falls back to the assignment method supported in the hardware unless the assign-method-strict option is used (for example, if the wccp custom-web-cache assign-method-strict command is used to specify the assign-method-strict option for the custom-web-cache service) rather than remain out of the Content Engine cluster indefinitely. If masking is selected with WCCP output redirection, then the Content Engine falls back to the original hardware acceleration that is used with the Multilayer Switch Feature Card (MSFC) and the Policy Feature Card (PFC).
For example, WCCP Version 2 filters packets to determine which redirected packets have been returned from the Content Engine and which packets have not returned. It does not redirect the packets that have been returned, because the Content Engine has determined that these packets should not be processed. WCCP Version 2 returns packets that the Content Engine does not service to the same router from which they were transmitted.
Load Balancing
WCCP Version 2 supports dynamic load distribution that allows the routers to adjust the loads that are forwarded to the individual Content Engines in the cluster. It uses two techniques to perform this task:
The weight parameter represents a percentage of the load that is redirected to the Content Engine cluster (for example, a Content Engine with a weight of 30 receives 30 percent of the total load). If the total of all weight parameters in the Content Engine cluster exceeds 100, the percentage load for each Content Engine is recalculated as the percentage that its weight parameter represents of the combined total.
See the Cisco ACNS Software Configuration Guide for Locally Managed Deployments for a description on how to configure the custom-web-cache service (service 98) on a Content Engine and a router.
Examples
The following example shows the configuration for starting custom web caching on Ethernet interface 3 of a WCCP Version 2-enabled router:
Router(config): ip wccp 98[Output not shown]Router(config): ip interface ethernet 3Router(config-if): ip web-cache 98 redirect out[Output not shown]The following example shows how to enable WCCP Version 2 on the Content Engine:
ContentEngine(config)# wccp version 2The Content Engine must be running WCCP Version 2 to support the custom-web-cache service (service 98). WCCP Version 2 is required for any of the WCCP services other than the standard web-cache service (service 0).
The following example creates a router list that specifies the routers that will support the custom-web-cache service. In this example, there is only one router on router list 1 (the router that you just configured for the custom-web-cache service, which has an IP address of 10.0.1.1). The l2-redirect option specifies Layer 2 redirection as the packet-forwarding method (instead of GRE) and the mask-assign option specifies the mask assignment as the load-balancing method for this WCCP service.
ContentEngine(config)# wccp router-list 1 10.0.1.1 l2-redirect mask-assignThe following example shows how to inform the WCCP-enabled router in the specified router list that this Content Engine is accepting redirected custom web cache requests on port 31:
ContentEngine(config)# wccp custom-web-cache router-list-num 1 port 31The following example shows how to turn on WCCP Version 2 on the router:
Router# configure terminalRouter(config)# ip wccp version 2The following example shows the configuration on the Content Engine:
ContentEngine(config)# wccp custom-web-cache router-list-num 5 port 82 weight 30 password Allied hash-destination-ip hash-source-portContentEngine(config)# http proxy outgoing ans.allied.com 82 no-local-domainThe following example shows the running configuration on the Content Engine:
ContentEngine# show running-configBuilding configuration...Current configuration:!....!http proxy outgoing 192.168.200.68 82 no-local-domain!wccp router-list 5 10.1.1.1wccp custom-web-cache router-list 5 port 82 weight 30 password Allied hash-destination-ip hash-source-portwccp home-router 10.1.1.2wccp version 2!endRelated Commands
http proxy incoming
http proxy outgoing
show wccp content-engines
show wccp flows web-cache
show wccp masks web-cache
show wccp routers
show wccp slowstart web-cache
show wccp status
wccp version 2
wccp web-cachewccp dns
To allow a WCCP-enabled router to intercept packets, process them, and reinsert them into the request stream, use the wccp dns global configuration command. To disable this function, use the no form of this command.
wccp dns {mask {[dst-ip-mask hex_num] [dst-port-mask port_hex_num] [src-ip-mask hex_num] [src-port-mask port_hex_num]} | router-list-num num [assign-method-strict] [hash-destination-ip] [hash-destination-port] [hash-source-ip] [hash-source-port] [l2-redirect] [mask-assign] [password key] [weight percentage]}
no wccp dns
Syntax Description
mask
Sets the mask used for the Content Engine assignment. Configure at least one mask; the maximum is four masks.
dst-ip-mask
(Optional) Sets the mask used to match the packet destination IP address.
hex_num
IP address mask defined by a hexadecimal number (for example, 0xFC000000). The range is 0x00000000-FE000000.
dst-port-mask
(Optional) Sets the mask used to match the packet destination port number.
port_hex_num
Port mask defined by a hexadecimal number (for example, 0xFC00). The port range is 0-65535.
src-ip-mask
(Optional) Sets the mask used to match the packet source IP address.
src-port-mask
(Optional) Sets the mask used to match the packet source port number.
router-list-num
Sets the router list number.
num
Router list number (1-8).
assign-method-strict
(Optional) Forces WCCP to strictly use only the configured assignment method. For more information, see the "Assignment Method" section.
hash-destination-ip
(Optional) Defines the load-balancing hash of the destination IP address (the default).
hash-destination-port
(Optional) Defines the load-balancing hash of the destination port.
hash-source-ip
(Optional) Defines the load-balancing hash of the source IP address.
hash-source-port
(Optional) Defines the load-balancing hash of the source port.
l2-redirect
(Optional) Sets the packet forwarding by Layer 2 redirect. For more information, see the "WCCP Layer 2 Support" section.
mask-assign
(Optional) Uses the mask method for the Content Engine assignment.
password
(Optional) Sets the authentication password to be used for secure traffic among the Content Engines within a cluster and the router for a specified service.
Note
key
WCCP service password key. Passwords must not exceed eight characters.
weight
(Optional) Sets the weight percentage for load balancing. For more information, see the "Load Balancing" section.
percentage
Percentage value (0-100).
Defaults
wccp dns-cache: disabled
dst-ip-mask: 0x00001741
src-ip-mask: 0x00000000
dst-port-mask: 0x0
src-port-mask: 0x0
Command Modes
global configuration
Usage Guidelines
For transparent interception of DNS requests using WCCP, you must configure the DNS caching service (service 53) on the Content Engine and on a router that supports WCCP Version 2.
The DNS process interacts with the WCCP process in these ways:
•
•
•
By default, the ACNS DNS caching service (service 53) uses the DNS servers configured on the Content Engine rather than the original DNS server. For information about how to configure a list of DNS servers on the Content Engine, see the next section, "Configuring DNS Servers for the DNS Caching Service (Service 53)."
The advantages of having the Content Engines intercept DNS requests are as follows:
•
•
•
You can partition your network with a series of forwarding servers, each with its own DNS cache with the following results:
•
•
Typically, this partitioning also results in a performance improvement if a cluster of requests occurs, especially on high-latency interconnections.
Configuring DNS Servers for the DNS Caching Service (Service 53)
By default, the Content Engine uses a DNS server from its list of configured DNS servers for domain name resolution as follows:
•
•
If DNS WCCP interception is enabled (that is, service 53 is configured on the Content Engine and a WCCP Version 2-enabled router), you can use the dns use-original-server global configuration command to define which DNS server a Content Engine should use to resolve a domain name, as described in Table 2-181.
The DNS caching service (the dns service [service 53]) is the WCCP service that permits WCCP Version 2-enabled routers to redirect client requests transparently to a Content Engine for the Content Engine to resolve the DNS name. After the Content Engine resolves the DNS name, it stores the resolved DNS name locally so that it can use these resolved names for future DNS requests.
See the Cisco ACNS Software Configuration Guide for Locally Managed Deployments for a description on how to configure DNS caching for a Content Engine.
Examples
The following example shows the configuration for starting DNS caching on Ethernet interface 2 of a WCCP Version 2-enabled router:
Note
Router# configure terminalRouter(config)# ip wccp version 2Router(config)# ip wccp 53Router(config)# interface ethernet 2Router(config-if)# ip wccp 53 redirect outThe following example configures the Content Engine to run WCCP Version 2 and enable the DNS caching service:
ContentEngine(config)# wccp version 2ContentEngine(config)# wccp dnsThe following example shows how to configure the DNS server port to listen for new client queries and invoke the query resolution routines. Once the hostname has been resolved to an IP address, it is stored in the memory-based DNS cache. In the following example, the listener IP address, port number, and hostname are configured first and then DNS caching is enabled on the Content Engine:
ContentEngine(config)# dns listen 10.1.1.0 port 53 hostname acmeContentEngine(config)# dns enableThe following example shows how to configure router list 1 to include a single WCCP Version 2 router, the router with the IP address of 10.77.157.41, to redirect DNS requests to this Content Engine:
ContentEngine(config)# wccp router-list 1 10.77.157.41The following example shows how to configure the Content Engine to accept redirected DNS requests for routers that are part of router list 1. The l2-redirect option specifies Layer 2 redirection as the packet-forwarding method (instead of GRE). In the following example, the mask-assign option specifies mask assignment as the load-balancing method for this WCCP service:
ContentEngine(config)# wccp dns router-list-num 1 l2-redirect mask-assignRelated Commands
dns
show dns
show statistics dns-cache
show wccp content-engines
show wccp flows dns
show wccp masks dns
show wccp routers
show wccp slowstart dns
show wccp status
wccp version 2wccp flow-redirect enable
To enable WCCP flow redirection, use the wccp flow-redirect enable global configuration command. To disable flow redirection, use the no form of this command.
wccp flow-redirect enable
no wccp flow-redirect enable
Syntax Description
Defaults
Enabled
Command Modes
global configuration
Usage Guidelines
When transparent traffic interception or redirection first begins, WCCP flow protection ensures that no existing HTTP flows are broken by allowing preexisting, established HTTP flows to continue. WCCP flow protection also ensures that when a new Content Engine joins an existing Content Engine cluster, existing flows serviced by preexisting Content Engines in the cluster will continue to receive those existing flows.
The mechanisms used by WCCP flow protection result in all of the benefits of maintaining per flow state information in a centralized location but without the overhead, scaling issues, and redundancy or resiliency issues (for example, asymmetrical traffic flows) associated with keeping per flow state information in the switching layer.
Use the wccp flow-redirect enable global configuration command to implement WCCP flow protection. This command works with WCCP Version 2 only. Flow protection is designed to keep the TCP flow intact as well as to not overwhelm Content Engines when they are first started up or are reassigned new traffic. This feature also has a slow-start mechanism that allows the Content Engines to take a load that is appropriate for their capacity.
Note
Examples
The following example shows how to enable WCCP flow protection on a Content Engine:
ContentEngine(config)# wccp flow-redirect enableThe following example shows how to disable WCCP flow protection on a Content Engine:
ContentEngine(config)# no wccp flow-redirect enableRelated Commands
wccp slow-start enable
wccp ftp-native
To instruct the router to enable or disable transparent interception of FTP native traffic with WCCP Version 2, use the wccp ftp-native global configuration command. To disable this function, use the no form of this command.
wccp ftp-native {mask {dst-ip-mask hex_num [src-ip-mask hex_num] | src-ip-mask hex_num [dst-ip-mask hex_num]} | router-list-num num [assign-method-strict] [l2-redirect] [mask-assign] [password key] [weight percentage]}
no wccp ftp-native
Syntax Description
mask
Sets the mask used for the Content Engine assignment. Configure the mask for the destination IP address, the source IP address, or both.
dst-ip-mask
(Optional) Sets the mask used to match the packet destination IP address. The default is 0x00001741.
hex_num
IP address mask defined by a hexadecimal number (for example, 0xFC000000). The range is 0x00000000-FE000000.
src-ip-mask
(Optional) Sets the mask used in the packet source IP address. The default is 0x00000000.
router-list-num
Sets the router list number.
num
Router list number (1-8).
assign-method-strict
(Optional) Forces WCCP to strictly use only the configured assignment method. For more information, see the "Assignment Method" section.
l2-redirect
(Optional) Sets the packet forwarding by Layer 2 redirect. For more information, see the "WCCP Layer 2 Support" section.
mask-assign
(Optional) Uses the mask method for the Content Engine assignment.
password
(Optional) Sets the authentication password to be used for secure traffic among the Content Engines within a cluster and the router for a specified service. Be sure to enable all other Content Engines and routers within the cluster with the same password.
key
WCCP service password key. Passwords must not exceed eight characters.
weight
(Optional) Sets the weight percentage for load balancing. For more information, see the "Load Balancing" section.
percentage
Percentage value (0-100).
Defaults
wccp ftp-native: disabled
dst-ip-mask: 0x00001741
src-ip-mask: 0x00000000
Command Modes
global configuration
Usage Guidelines
Use this command to enable traffic interception of FTP native traffic with WCCP Version 2. With FTP native service, the router balances the traffic load within a Content Engine cluster based on the destination IP address (for example, FTP server IP address).
Note
You must set the wccp router-list command before you use this command.
Both weight and password are optional and can be used together or separately.
To enable the use of a password for secure FTP native traffic, use the password key option and be sure to enable all other Content Engines and routers within the cluster with the same password.
The l2-redirect option permits the Content Engine to receive transparently redirected FTP native traffic from a WCCP Version 2-enabled switch or router if the Content Engine has a Layer 2 connection with the device, and the device is configured for Layer 2 redirection.
The weight parameter represents a percentage of the total load redirected to the Content Engine (for example, a Content Engine with a weight of 30 receives 30 percent of the total load). If the total of all weight parameters in a Content Engine cluster exceeds 100, the percentage load for each Content Engine is recalculated as the percentage that its weight parameter represents of the combined total.
WCCP service ID 60 is associated with the FTP native service on the router, and it must be configured on the router using the ip wccp 60 router configuration command.
The wccp ftp-native router-list-number and wccp ftp-native mask global configuration commands support native FTP caching on a Content Engine that is operating in transparent proxy mode.
See the Cisco ACNS Software Configuration Guide for Locally Managed Deployments for a description on how to configure transparent FTP native caching with a Content Engine (transparent proxy server) and a WCCP Version 2-enabled router.
Examples
The following example configures WCCP to use the router list numbered 1:
ContentEngine(config)# wccp ftp-native router-list-num 1The following example shows how to configure native FTP caching on a WCCP Version 2 router to transparently intercept FTP native requests and redirect them to the Content Engine by turning on native FTP caching. The service group number for this service is 60.
ContentEngine(config)# ip wccp 60Service 60 is a predefined WCCP Version 2 caching service that permits WCCP Version 2-enabled routers to redirect FTP native requests transparently to a single port on the Content Engine. The Content Engine retrieves the requested FTP content, stores a copy locally, and serves the requested content to the requester.
The following example shows how to specify an interface on which the native FTP caching service will run:
ContentEngine(config)# interface ethernet 0The following example shows how to specify out for the native FTP caching service:
ContentEngine(config-if)# ip wccp 60 redirect outThe following example disables transparent interception of FTP traffic with WCCP Version 2:
ContentEngine(config)# no wccp ftp-nativeThe following example shows how to configure transparent FTP native caching on the Content Engine by defining a list of routers that will be used to redirect FTP native requests to this Content Engine:
ContentEngine(config)# wccp router-list 1 10.77.157.41The example shows how to configure router list 1 to include a single WCCP Version 2 router, the router with the IP address of 10.77.157.41.
The following example shows how to specify the router list that the Content Engine should accept redirected FTP native requests from:
ContentEngine(config)# wccp ftp-native router-list-num 1The example shows how to configure the Content Engine to accept redirected FTP native requests for routers that are part of router list 1.
The following example shows how to specify Layer 2 redirection as the packet-forwarding method (instead of GRE) and specify the mask assignment as the load-balancing method (instead of the default hash assignment method) for the FTP native caching service:
ContentEngine(config)# wccp ftp-native router-list-num 1 l2-redirect mask-assignWCCP configuration for FTP succeeded.Please remember to config WCCP service 60 on the corresponding router.ContentEngine(config)#The l2-redirect option in the previous example specifies Layer 2 redirection as the packet-forwarding method (instead of GRE).
The following example shows how to enable FTP native active mode on the Content Engine:
ContentEngine(config)# ftp-native proxy active-mode enableIn FTP native caching mode, if this command is specified, then the Content Engine uses the same mode (active or passive) with the origin FTP server for the data connection as the client used to access the Content Engine. If this command is not specified, the Content Engine uses passive mode with the origin FTP server for the data connection.
The following example shows how to specify the maximum size of an FTP object for FTP native caching:
ContentEngine(config)# ftp-native object max-size 2000This parameter can be configured for either directory listings or particular objects in the cache. The previous example sets the maximum size for an FTP object size to 2 megabytes for FTP native caching.
The following example shows the output of the show wccp modules EXEC command to verify that the FTP proxy is enabled on the Content Engine:
ContentEngine# show wccp modulesModules registered with WCCP on this Content EngineModule Socket Expire(sec) Name Supported Services------ ------ ----------- --------------- ------------------2 13 4 WMT Proxy WMT3 14 4 MMSU WMT Proxy MMSU6 15 4 WMT-RTSPU RTSPU1 16 4 RTSP Proxy RTSP0 17 3 HTTP Proxy Web CacheReverse ProxyCustom Web CacheHTTPS CacheWCCPv2 Service 90WCCPv2 Service 91WCCPv2 Service 92WCCPv2 Service 93WCCPv2 Service 94WCCPv2 Service 95WCCPv2 Service 96WCCPv2 Service 975 22 3 FTP Proxy FTPContentEngine#The following example shows the output of the show wccp services EXEC command to verify that transparent FTP native caching (shown as FTP in the following command output) is configured on the Content Engine:
ContentEngine# show wccp servicesServices configured on this Content EngineWeb CacheReverse ProxyRTSPWMTMMSUDNSFTPRTSPUHTTPS CacheContentEngine#The following example shows the output of the show ftp-native EXEC command to view the current FTP native proxy configuration:
ContentEngine# show ftp-nativeWCCP FTP service status: ENABLEDMaximum size of a FTP cacheable object: 2096128 KBytesFTP data connection mode with Server: Adhere to Client's mode (active or passive)Incoming Proxy-Mode:Configured Proxy mode Native FTP connections on ports: 1 2 3 4 5 6 7 8Related Commands
ftp-native
show ftp-native
show statistics ftp-native
show wccp content-engines
show wccp flows ftp
show wccp masks ftp
show wccp routers
show wccp slowstart ftp
show wccp status
wccp version 2wccp home-router
To configure a WCCP Version 1 router IP address, use the wccp home-router global configuration command. To disable this function, use the no form of this command.
wccp home-router ip-address
no wccp home-router
Syntax Description
Defaults
Disabled
Command Modes
global configuration
Usage Guidelines
With WCCP Version 1, only a single WCCP-enabled router services a Content Engine cluster, becoming the default home router for the cluster. With WCCP Version 1, this single router that is servicing the cluster is the device that performs all the IP packet redirection.
To use WCCP Version 1 with the Content Engine, you must also point the Content Engine to a designated home router by entering the wccp home-router ip-address command. This IP address may also be the address of the IP default gateway.
Make sure that WCCP Version 1 is enabled on the router.
Examples
The following example shows how to configure a WCCP Version 1 router IP address on the Content Engine:
ContentEngine(config)# wccp home-router 172.16.65.243The following example shows how to disable the home router configured on the Content Engine:
ContentEngine(config)# no wccp home-router 172.16.65.243Related Commands
show wccp routers
wccp version 1wccp https-cache
To enable WCCP flow redirection to a Content Engine configured as an HTTPS server, use the wccp https-cache global configuration command. To disable this function, use the no form of this command.
wccp https-cache {accept-all | mask {[dst-ip-mask hex_num] [dst-port-mask port_hex_num] [src-ip-mask hex_num] [src-port-mask port_hex_num]} | router-list-num num [assign-method-strict] [hash-destination-ip] [hash-destination-port] [hash-source-ip] [hash-source-port] [l2-redirect] [mask-assign] [password key] [weight percentage]}
no wccp https-cache
Syntax Description
accept-all
Enables the the Content Engine to accept all HTTPS traffic by default, regardless of whether the origin HTTPS server is configured on the Content Engine.
mask
Sets the mask used for Content Engine assignment. Configure at least one mask; the maximum is four masks.
dst-ip-mask
(Optional) Sets the mask used to match the packet destination IP address.
hex_num
IP address mask defined by a hexadecimal number (for example, 0xFC000000). The range is 0x00000000-FE000000.
dst-port-mask
(Optional) Sets the mask used to match the packet destination port number.
port_hex_num
Source port mask defined by a hexadecimal number (for example, 0xFC00). The port range is 0-65535.
src-ip-mask
(Optional) Sets the mask used to match the packet source IP address.
src-port-mask
(Optional) Sets the mask used to match the packet source port number.
router-list-num
Sets the router list number.
num
Router list number (1-8).
assign-method-strict
(Optional) Forces WCCP to strictly use only the configured assignment method. For more information, see the "Assignment Method" section.
hash-destination-ip
(Optional) Defines the load-balancing hash of the destination IP address (the default).
hash-destination-port
(Optional) Defines the load-balancing hash of the destination port.
hash-source-ip
(Optional) Defines the load-balancing hash of the source IP address.
hash-source-port
(Optional) Defines the load-balancing hash of the source port.
l2-redirect
(Optional) Sets the packet forwarding by Layer 2 redirect. For more information, see the "WCCP Layer 2 Support" section.
mask-assign
(Optional) Uses the mask method for the Content Engine assignment.
password
(Optional) Sets the authentication password to be used for secure traffic among the Content Engines within a cluster and the router for a specified service. Be sure to enable all other Content Engines and routers within the cluster with the same password.
key
WCCP service password key. Passwords must not exceed eight characters.
weight
(Optional) Sets the weight percentage for load balancing. For more information, see the "Load Balancing" section.
percentage
Percentage value (0-100).
Defaults
wccp https-cache: disabled
dst-ip-mask: 0x00001741
src-ip-mask: 0x00000000
dst-port-mask: 0x0
src-port-mask: 0x0
Command Modes
global configuration command
Usage Guidelines
By default, the wccp https-cache command instructs the corresponding router to intercept port 443 TCP traffic and forward it to the Content Engine. However, the Content Engine will only accept the traffic if the HTTPS server is configured using the https server command.
The router administrator must use the ip wccp 70 and ip wccp 70 redirect out commands on the redirect interface of the WCCP router.
In the ACNS 5.1.x software, only one interception mode (the accept-only mode) was supported for the https-cache service. With the accept-only mode, the Content Engine can only accept requests that are directed to configured HTTPS servers.
The Content Engine accepts redirected HTTPS traffic only if the HTTPS server was configured on the Content Engine (if you entered the https server global configuration command to specify the IP address or hostname and the private key and certificate of the origin HTTPS server on the Content Engine).
In the ACNS 5.2 software and later releases, another interception mode (the accept-all mode) is available for the https-cache service (service 70). The accept-all mode was added to support the filtering of HTTPS traffic. The accept-all mode works the same way as the traditional WCCP services do (for example, the standard web-cache service [service 0] that intercepts all web traffic by default).
WCCP service number 70 handles HTTPS traffic (the default port for such traffic is 443), and instructs the corresponding router to intercept port 443 TCP traffic and forward it to the Content Engine. The HTTPS service has a special feature that other WCCP services do not have. It uses an accept list of destination IP addresses to selectively redirect traffic to an application instead of redirecting all traffic to related applications. When the destination server's IP address in a client request matches any of the destination IP addresses in the accept list, WCCP redirects HTTPS traffic to the proper listening application. All other traffic is redirected to the corresponding router (normal bypass behavior). If static bypass is configured to allow traffic from specified sources to bypass the Content Engine, traffic is intercepted and is passed directly to the origin server. If an IP address is present on both the accept list and the bypass list, the Content Engine can return traffic to the WCCP-enabled router or switch and inform the router or switch to forward the packets as if the Content Engine were not present.
To intercept all HTTPS requests, use the wccp https-cache accept-all command regardless of whether the origin HTTPS servers are configured on the Content Engine. If the private key or certificate of the origin HTTPS server is not configured on the Content Engine, the Content Engine tunnels (no SSL termination) the request to the origin HTTPS server. The Content Engine can negotiate an SSL connection with the client and serve HTTPS requests if the origin HTTPS server is configured on the Content Engine. Otherwise, HTTPS traffic is tunneled through the Content Engine (no SSL termination; the Content Engine passes traffic from client to server without modifying anything, except for filtering). When the SmartFilter software or Websense filtering software is enabled on the Content Engine, the Content Engine sends URLs corresponding to tunneled HTTPS traffic to the filtering server. Filtering servers might decide to block or pass the traffic. If traffic needs to be blocked, the Content Engine closes the connection with the client, and the request is not served.
To configure a Content Engine to support HTTPS transparent caching, you must configure the Content Engine and a router to support the WCCP Version 2 HTTPS caching service. The https-cache service is the WCCP HTTPS caching service that permits WCCP Version 2-enabled routers to intercept port 443 TCP traffic and redirect this HTTPS traffic to the Content Engine (that is acting as a transparent forward proxy server, which is configured for HTTPS transparent caching). The Content Engine retrieves the requested content, stores a copy locally (performs HTTPS transparent caching) if the content is cacheable, and serves the requested content to the client.
The Content Engine listens for redirected HTTPS requests on the standard HTTPS port (default port 443). To intercept HTTPS traffic on ports other than the default port, configure a user-defined WCCP service (services 90 to 97). For more information on this topic, see the "wccp service-number" section.
See the Cisco ACNS Software Configuration Guide for Locally Managed Deployments for a description on how to configure HTTPS transparent caching on a Content Engine and a single router running WCCP Version 2.
Examples
The following example enables the Content Engine to accept redirected HTTPS requests from a WCCP-enabled router:
ContentEngine(config)# wccp version 2ContentEngine(config)# wccp https-cache router-list-num 1ContentEngine(config)# wccp router-list 1 172.16.202.1The following example shows how to configure the WCCP-enabled router to support the https-cache service (service 70) by enabling WCCP Version 2 on the router (for example, Router A):
RouterA# configure terminalRouterA(config)# ip wccp version 2The following example shows how to configure Router A to run the https-cache service (service 70):
RouterA(config)# ip wccp 70The following example shows how to configure Router A to intercept all outgoing HTTPS traffic:
Router(config)# ip wccp 70 redirect outThe following example shows how to configure the Content Engine to support the https-cache service by configuring the list of routers to support the https-cache service:
ContentEngine(config)# wccp router-list 1 10.1.202.1In this example, router list number 1 is created and consists of only one router (Router A, which has an IP address of 10.2.202.1).
The following example shows how to configure the Content Engine to accept transparently redirected HTTPS requests from the routers listed in router list 1 (Router A):
ContentEngine(config)# wccp https-cache router-list-num 1 l2-redirect mask-assignThe l2-redirect option specifies Layer 2 redirection as the packet-forwarding method (instead of GRE). The mask-assign option specifies the mask assignment as the load-balancing method for this WCCP service.
The following example shows how to enable WCCP Version 2 on the Content Engine:
ContentEngine(config)# wccp version 2The following example shows how to enable the Content Engine to intercept all HTTPS traffic and tunnel the HTTPS traffic for which it does not have a private key or certificate and how to enable the accept-all mode on the Content Engine:
ContentEngine(config)# wccp https-cache accept-allThis feature is typically used for filtering purposes (for example, to enable the Content Engine to use SmartFilter or Websense software to filter tunneled HTTPS requests).
The following example shows how to specify the server name of an origin HTTPS server from which the Content Engine caches the content:
ContentEngine(config)# https server abc1ContentEngine(config-https)#In the example, the origin HTTPS server named abc1 is configured on the Content Engine. After you specify the server name, the submode for HTTPS configuration is invoked and the prompt changes to ContentEngine(config-https)#.
The following example shows how to enter the certificate, the private key, and the hostname of the HTTPS server (abc1), and then enable these settings (enter enable from the submode, as shown below) on the Content Engine from HTTPS configuration submode:
ContentEngine(config-https)# cert ?ContentEngine(config-https)# cert mycert createContentEngine(config-https)# cert mycert import http://www.myca.com/myservercertContentEngine(config-https)# cert mykey createContentEngine(config-https)# cert mykey import http://www.myca.com/myprivatekeyContentEngine(config-https)# host abc1ContentEngine(config-https)# enableThese settings are the minimal settings for HTTPS that you need for enabling the content caching of the specified HTTPS server.
The cert and key command options configure a Content Engine to use a set of SSL certificates and keys that enables the Content Engine to act as the origin HTTPS server. The Content Engine is able to decode HTTPS traffic from a client and perform normal HTTP operations on it, such as caching and request processing. The Content Engine is able to initiate HTTPS connections to an origin server and fetch the content from origin servers upon a cache miss (or a cache validation). For more information, see the "https server" section on page 2-243.
The following example shows how to configure the Content Engine to use SSL Version 2 only either from HTTPS configuration submode or global configuration mode:
CONTENTENGINE(config-https)# protocol-version sslv2-onlyor
CONTENTENGINE(config)# https server name protocol-version sslv2-onlyRelated Commands
https server
show https
show statistics https
show wccp content-engines
show wccp flows https-cache
show wccp masks https-cache
show wccp routers
show wccp slowstart https-cache
show wccp status
wccp version 2wccp port-list
To associate ports with specific WCCP Version 2 dynamic services, use the wccp port-list global configuration command. To disassociate ports from WCCP Version 2 dynamic services, use the no form of this command.
wccp port-list listnum portnum
no wccp port-list listnum portnum
Syntax Description
listnum
Port list number (1-8).
portnum
Port number (1-65535). Up to eight ports per list number are allowed.
Defaults
No default behavior or values
Command Modes
global configuration
Usage Guidelines
With WCCP Version 1, web-cached information can only be redirected to a Content Engine if it was destined for TCP port 80. Many applications require packets intended for other ports to be redirected, for example, proxy web cache handling, web caching for ports other than port 80, RealAudio, and video. If a router is configured for WCCP Version 2 instead of WCCP Version 1, then additional TCP ports other than port 80 can be configured on the WCCP-enabled router to redirect traffic to a Content Engine.
Up to eight port numbers can be included in a single port list. The port list is referenced by the
wccp service-number command that configures a specific WCCP Version 2 dynamic service (90-97) to operate on the listed ports.By default, the Content Engine listens for incoming traffic on port 80. Create one port list for each of the eight user-defined WCCP services that you will be creating (services 90 to 97). You can define up to eight ports per port list.
Examples
The following example shows that ports 10, 200, 3000, 110, 220, 330, 440, and 40000 are included in port list 3:
ContentEngine(config)# wccp port-list 3 10 200 3000 110 220 330 440 40000Related Commands
wccp service-number
wccp reverse-proxy
To enable WCCP Version 2 reverse proxy service, use the wccp reverse-proxy global configuration command. To disable this function, use the no form of this command.
wccp reverse-proxy {mask {[dst-ip-mask hex_num] [dst-port-mask port_hex_num] [src-ip-mask hex_num] [src-port-mask port_hex_num]} | router-list-num num [assign-method-strict] [l2-redirect] [mask-assign] [password key] [weight percentage]}
no wccp reverse-proxy
Syntax Description
mask
Sets the mask used for the Content Engine assignment. Configure at least one mask; the maximum is four masks.
dst-ip-mask
(Optional) Sets the mask used to match the packet destination IP address.
hex_num
IP address mask defined by a hexadecimal number (for example, 0xFC000000). The range is 0x00000000-FE000000.
dst-port-mask
(Optional) Sets the mask used to match the packet destination port number.
port_hex_num
Port mask defined by a hexadecimal number (for example, 0xFC00). The port range is 0-65535.
src-ip-mask
(Optional) Sets the mask used to match the packet source IP address.
src-port-mask
(Optional) Sets the mask used to match the packet source port number.
router-list-num
Sets the router list number.
num
Router list number (1-8).
assign-method-strict
(Optional) Forces WCCP to strictly use only the configured assignment method. For more information, see the "Assignment Method" section.
l2-redirect
(Optional) Sets the packet forwarding by Layer 2 redirect.
mask-assign
(Optional) Uses the mask method for the Content Engine assignment.
password
(Optional) Sets the authentication password.
key
WCCP service password key. Passwords must not exceed eight characters.
weight
(Optional) Sets the weight percentage for load balancing.
percentage
Percentage value (0-100).
Defaults
wccp reverse-proxy: disabled
dst-ip-mask: 0x00000000
src-ip-mask: 0x00001741
dst-port-mask: 0x0
src-port-mask: 0x0
Command Modes
global configuration
Usage Guidelines
This command applies only to WCCP Version 2.
The reverse-proxy service (service 99) is the predefined WCCP Version 2 service that permits WCCP Version 2-enabled routers to redirect reverse proxy packets to a Content Engine that is functioning as a transparent reverse proxy server.
You must configure the wccp router-list command before you use this command. The routers in the list must have WCCP reverse proxy service enabled (service 99).
By default, the router does load balancing across the various Content Engines in a cluster based on the destination IP address (for example, web server IP address). When WCCP reverse proxy is enabled, the router does load balancing in a cluster based on the source IP address (for example, the client's browser IP address).
To enable the use of a password for a secure reverse proxy cache within a cluster, use the wccp reverse-proxy password key command to be sure to enable all other Content Engines and routers within the cluster with the same password.
The l2-redirect option permits the Content Engine to receive transparently redirected traffic from a WCCP Version 2-enabled switch or router if the Content Engine has a Layer 2 connection with the device and the device is configured for Layer 2 redirection.
The weight parameter represents a percentage of the total load redirected to the Content Engine in a cluster (for example, a Content Engine with a weight of 30 receives 30 percent of the total load). If the total of all weight parameters in a Content Engine cluster exceeds 100, the percentage load for each Content Engine is recalculated as the percentage that its weight parameter represents of the combined total.
See the Cisco ACNS Software Configuration Guide for Locally Managed Deployments for a description on how to configure the reverse-proxy service (service 99) on a Content Engine and a WCCP router.
Examples
The following example associates the router list 8 with the reverse-proxy service, sets the authentication password to be used for secure traffic among the Content Engines within a cluster and the router for the reverse-proxy service, and sets the weight percentage for load balancing:
ContentEngine(config)# wccp reverse-proxy router-list-num 8 password mysecret weight 100The following example disables the reverse-proxy service:
ContentEngine(config)# no wccp reverse-proxyThe following example shows how to configure the Content Engine to support the reverse-proxy service by enabling WCCP Version 2 on the Content Engine:
ContentEngine(config)# wccp version 2The Content Engine must be running WCCP Version 2 to support the reverse-proxy service. WCCP Version 1 only supports the standard web-cache service (service 0); it does not support the reverse-proxy service.
The following example shows how to create a router list that specifies the routers that will support the reverse-proxy service:
ContentEngine(config)# wccp router-list 1 10.0.1.1The IP address or multicast address specifies which router will support this WCCP service. If different routers will be used for different WCCP services, you must create more than one router list. In this example, there is only one router on router list 1 (the router that you just configured for the reverse proxy cache service, which has an IP address of 10.0.1.1).
The following example shows how to inform the WCCP-enabled router in the specified router list that this Content Engine is accepting redirected reverse proxy cache requests on port 80:
ContentEngine(config)# wccp reverse-proxy router-list-num 1 l2-redirect mask-assignThe l2-redirect option specifies Layer 2 redirection as the packet-forwarding method (instead of GRE). The mask-assign option specifies the mask assignment as the load-balancing method for this WCCP service.
The following example shows how to write the running configurations to nonvolatile memory:
ContentEngine# write memoryThe following example shows how to configure a WCCP-enabled router to support the reverse-proxy service by turning on WCCP Version 2 on the router:
Router# configure terminalRouter(config)# ip wccp version 2The following example shows how to turn on the reverse-proxy service (service 99) on the router:
Router(config)# ip wccp 99The following example shows how to specify the interface on which the reverse-proxy service will run:
Router(config)# interface ethernet 0In the example, the Ethernet 0 interface on the router is configured to run the reverse-proxy service.
The following example shows how to configure the router to use the outbound interface for the reverse-proxy service:
Router(config-if)# ip wccp 99 redirect outThe router will check the reverse proxy packets on Ethernet interface 0 to determine if it should transparently redirect these packets to the Content Engine the (transparent reverse proxy server).
Related Commands
show wccp content-engines
show wccp flows reverse-proxy
show wccp masks reverse-proxy
show wccp routers
show wccp services
show wccp slowstart reverse-proxy
show wccp status
wccp router-list
wccp version 2wccp router-list
To configure a router list for WCCP Version 2, use the wccp router-list global configuration command. To disable this function, use the no form of this command.
wccp router-list number ip-address
no wccp router-list number ip-address
Syntax Description
Defaults
Disabled
Command Modes
global configuration
Usage Guidelines
As part of configuring a WCCP Version 2 service on a Content Engine, you must create a list of WCCP Version 2-enabled routers that will support a specific WCCP Version 2 service (for example, the rtsp service) for the Content Engine.
Use the wccp router-list command to configure various router lists for use with WCCP Version 2 services. Enter the IP address of every WCCP Version 2-enabled router that will support a particular WCCP service for the Content Engine. If different routers will be used for different WCCP services, you must create more than one router list. When you create a router list, up to six IP addresses can be added per line. Multiple lines can be used to represent a router list with a maximum of 32 routers. For example, you can specify one router list for the WCCP Version 2 web cache service and another list for reverse proxy at the same time without having to reconfigure groups of routers or Content Engines. You can add up to 8 router lists and up to 32 IP addresses per list.
With WCCP Version 1, you can only configure a single WCCP-enabled router to support the standard web-cache service (service 0). Even if there is a cluster of Content Engines, only a single WCCP Version 1-enabled router services a cluster of Content Engines, becoming the default home router for the cluster.
Note
When configuring a Content Engine for WCCP Version 2, you can configure an IP multicast address instead of a list of routers on the Content Engine. Using a list of routers on the Content Engine precludes the need to use IP multicast but requires more configuration on each Content Engine. Using an IP multicast address reduces the configuration on the Content Engine and the protocol overhead.
With IP multicasting, an IP multicast address is configured on the Content Engine. The WCCP Version 2-enabled routers are configured to receive the IP multicast address on one or more interfaces. These routers then send their redirected requests to the specified IP multicast address on the Content Engine. Multicast addresses must be between 224.0.0.0 and 239.255.255.255. The Internet Assigned Numbers Authority (IANA) controls the assignment of IP multicast addresses. The IANA has assigned the IPv4 Class D address space to be used for IP multicast. Therefore, all IP multicast group addresses fall in the range from 224.0.0.0 through 239.255.255.255. However, some combinations of source and group address should not be routed for multicasting purposes.
Additional configuration is required on the WCCP Version 2-enabled routers that are intended to become members of the service group when IP multicast is used is as follows:
•
•
For the network configurations in which another router must be traversed to get to the target router, you must configure the router being traversed to perform IP multicast routing as follows:
•
•
Examples
The following example shows how router list number 7 is created and contains a single router (the WCCP Version 2-enabled router with IP address 172.31.68.98):
ContentEngine(config)# wccp router-list 7 172.31.68.98The following example deletes the router list number 7 created in the previous example:
ContentEngine(config)# no wccp router-list 7 172.31.68.98The following example shows how to create a router list (router list 1) and then configure the Content Engine to accept redirected WMT traffic (the WCCP service named wmt) from the WCCP Version 2-enabled router on router list 1:
ContentEngine(config)# wccp router-list 1 10.10.10.2ContentEngine(config)# wccp wmt router-list 1ContentEngine(config)# wccp version 2Related Commands
wccp reverse-proxy
wccp version 2
wccp web-cache
