Categories of Problem Areas

CBAC problems arise mainly from lack of understanding and misconfiguration. This section discusses the problems you may run into while running CBAC in your network. It shows a step-by-step troubleshooting process for isolating and fixing any problem. The following list outlines the most typical problems in running CBAC:

  • Selection of software for IOS firewall issues

  • Inability to connect (inbound and outbound) across CBAC

  • Performance problems

  • Intermittent packet drops

  • Non-functioning of IP URL filtering

Selection of Software for IOS Firewall Issues

To turn the router's IOS firewall on, you need a special IOS image that has the firewall feature set, which is a paid feature. Example 5-16 shows the output of the router with the IOS Firewall features.

Example 5-16 shows a Cisco 2600 router with 64 MB of RAM (60416 K + 5120 K), 16 MB of flash memory (16384 K), and a code image called flash: c2600-ik9o3s3-mz.122-15.T5.bin.

Example 5-16. show version Output from an IOS Firewall Router

Router# show version Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-IK9O3S3-M), Version 12.2(15)T5, RELEASE SOFTWARE (fc1) TAC Support: Copyright (c) 1986-2003 by Cisco Systems, Inc. Compiled Thu 12-Jun-03 14:32 by eaarmas Image text-base: 0x80008098, data-base: 0x81934B78 ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1) 2-2-3-2621e uptime is 4 weeks, 18 hours, 39 minutes System returned to ROM by power-on System image file is "flash:c2600-ik9o3s3-mz.122-15.T5.bin" cisco 2621 (MPC860) processor (revision 0x102) with 60416K/5120K bytes of memory. Processor board ID JAD04490M1N (972686017) M860 processor: part number 0, mask 49 Bridging software. X.25 software, Version 3.0.0. 2 FastEthernet/IEEE 802.3 interface(s) 32K bytes of non-volatile configuration memory. 16384K bytes of processor board System flash (Read/Write) Configuration register is 0x2102 Router# 

If for any reason you have changed the name of the IOS code, and show version is not giving you the right information, a quick way to find out if you have the IOS Firewall features or not is to execute ip inspect ? in the global configuration mode. If you have the IOS Firewall feature set, the output shows the options available; otherwise, you receive a message such as "command not recognized."

It is important to note that if the image name contains the letter "o," you have only the CBAC feature on the IOS image. If the image name contains "o3," you have CBAC, IDS and auth-proxy.

Before upgrading or changing an IOS image on the router to add the firewall feature, be sure the router meets the RAM and flash requirements. The best way to find the version needed for the IOS Firewall is to use the Software Advisor Tool in the following location (registered users only):

The Software Advisor tool can be used to determine the appropriate Cisco IOS software image to download, based on feature set, release, and platform. When you use the Software Advisor, search the feature list for "Context-Based Access Control (CBAC)". If you want to upgrade the software from your existing version keeping the same feature sets, you can use the "Compare the feature" option to find the desired version of IOS.

Unable to Connect (Inbound and Outbound) across CBAC

If you are unable to connect to the Internet or from the Internet to the internal network across a CBAC router, you need to first find out if there is any session created (upon seeing the first request packet the inspection engine creates a session). If the session is created, check the state of the session by executing show ip inspect session on the router. If there is no session, the packet is not even reaching the inspection engine. Among many, the following are some of the common causes of this problem:

  • Packet failure to reach the router's incoming interface

  • Misconfigured ACL

  • Misconfigured NAT and routing

  • IP Inspection not applied or applied in the wrong direction

Packet Failure to Reach the Router's Incoming Interface

If there are routing problems, or problems with Layer 2 between the host and the router, the packet may not reach to the router's incoming interface. Send a ping from the host to the router's incoming interface and see if there is any response. If the host is in the same subnet as the router's incoming interface, and you get the ping response, be sure to set up a default gateway on the host pointing to the router's incoming interface. If there is no ping reply, execute show arp on the router and see if the host's arp entry is there. If it is not there, be sure your host is not assigned a duplicate IP address in the network and troubleshoot the problem further on the switch or hub. You may be running into a bad interface, a bad cable, or misconfiguration on the switch.

If the sending host is in a different subnet (multiple hops away), send a ping to the router's incoming interface and see if there is any response. If there is no response, perform a tracert from the host and see where the packets are being dropped. Then troubleshoot the routing issue in that specific device. If you get a reply of the ping packets, be sure to open all the necessary ports for the other traffic there are problems with.

Without the ping test, if you want to see quickly if the packets are reaching the router's incoming interface or not, define an ACL with the log keyword to the end of the ACL. This will send the information about the traffic that is allowed or being dropped by the ACL to syslog. If there is no syslog message generated, the packets are not hitting the router at all. Example 5-17 shows the configuration required to see if the Telnet packets from host are hitting the router's interface Ethernet 0 going to

Example 5-17. Configuration Required Troubleshooting Connectivity Problem

Router(config)#access-list 101 permit tcp host host eq 23 log Router(config)#access-list 101 permit ip any any Router(config)#interface ethernet 0 Router(config-if)#ip access-group 101 in 

Misconfigured ACL

The first packet that the client sends to create a connection must be permitted by both the incoming access list on the interface on which it arrives and the outgoing access list on the interface through which it leaves. CBAC opens channels for the packets only after the conversation initiation packet. If either access list denies the conversation initiation, CBAC does not create a conversation, and therefore won't create the temporary access list entries that permit the return traffic. The packets will be dropped. You can find out if the packet initiation is denied through an ACL with debug ip packet detail ACL command. The ACL in this command defines the source and destination addresses and ports of the initiation traffic. The goal is to see if this initiation is being denied because of misconfigured ACL, NAT, or routing problems.

Example 5-18 shows how to use debug ip packet detail ACL, to capture the debug output when host is trying to send an initial packet for Telnet to the host

Example 5-18. Show How To Use the debug ip packet detail Command

Router(config)# access-list 101 permit tcp host host eq 23 Router# debug ip packet detail 101 Router# 

Misconfigured NAT and Routing

After you have verified that the packets are reaching to the router's interface and are not being dropped by the ACL, verify if you have configured a destination NAT. If so, verify if the NAT translation is being built up or not by executing show ip nat translation. If the proper translation is built up, be sure there is a route for the destination you are trying to reach by executing show ip route destination_ip/network. If you do not find a route, define one for the destination network. Note that the initial packet must leave the router before the inspection engine inspects and creates a session with SIS_OPENING. As discussed earlier, debug ip packet detail ACL can be used in conjunction with the show commands mentioned in this section to determine if the failure of the initial packet is caused either by the NAT or by routing. However, it is beyond the scope of this chapter to go through NAT or routing troubleshooting. However, the debug ip nat command can assist in getting details on why NAT is not working.

IP Inspection Applied In the Wrong Direction

The direction of inspection rule is a point of confusion for many who first configure CBAC because they think of a firewall as filtering traffic coming from an outside network to an inside network. So, the assumption is that the inspection should be applied to traffic coming from the untrusted side. The problem with this is that CBAC works in terms of conversations, not packets. So, if the conversations are initiated from inside (most of the time, this is the case), inspection must be applied to the outbound direction. Here is a useful rule of thumb: Inspection is applied in the direction of conversation initiation and the extended ACL is applied on the opposite direction.

UDP Inspection Is Not Configured

A DNS query works on protocol UDP and port number 53. Assume the DNS server for your corporation is located at the Internet service provider (ISP) network, which is on the unprotected side of the CBAC router. If one of your internal hosts on the protected side of the CBAC router tries to reach a website on the protected or unprotected side using a domain name, it will make a DNS query for name resolution to the IP address, before it can make the actual web connection. If you do not inspect UDP on the CBAC router, this name resolution will fail. This will cause the failure of the actual web request.

After going through the preceding troubleshooting steps, if you are still having issues, execute show ip inspect session again. If the session is there and the status that is shown is anything but SIS_OPEN, troubleshoot this further by checking the following:

  • Return traffic might not be coming back to the router.

  • ICMP traffic is not inspected.

  • There is a problem with inspecting Single Channel Protocol.

  • The required Multi-Channel Protocol is not inspected.

  • IP URL Filtering might be blocking the connection.

  • There is a redundancy or asymmetric routing problem.

Return Traffic Might Not Be Coming Back to the Router

With show ip inspect session command output, if you find that the session is being created but staying half-open, other devices along the path may be blocking the return traffic. There also may be issues with the route on the other destination device. If NAT is not working properly on the router, the destination device may not be able to respond back to the wrongly translated IP address of the source. As shown in Example 5-18, debug ip packet detail ACL can be used with the addition of the following line in the access-list 101 to find out if the return traffic is coming back to the router or not.

access-list 101 permit tcp host eq 23 host 

ICMP Traffic Is Not Inspected

Before version 12.2(11) YU & 12.2(15) T, there was no Internet Control Message Protocol (ICMP) inspection engine in CBAC for ICMP traffic. However, some ICMP packets are either necessary or really helpful on almost every real network. For example, for path MTU discovery, you need to allow ICMP packet-too-big, and for debugging connectivity issue across, you must allow echo and echo reply. However, keep in mind that some ICMP packets are dangerous, and allowing all ICMP packets always creates some level of security risk. So, if you are running a version older than 12.2(11) YU or 12.2 (15) T, allow the necessary ICMP packets for the return traffic on the incoming interface (outside) of the unprotected network. Example 5-19 shows commonly used ICMP services on the ACL applied as inbound on the outside interface.

Example 5-19. Common ICMP Services Allowed on the Outside Interface of a CBAC Router

Router(config)#access-list 100 permit icmp any any administratively-prohibited Router(config)#access-list 100 permit icmp any any echo Router(config)#access-list 100 permit icmp any any echo-reply Router(config)#access-list 100 permit icmp any any packet-too-big Router(config)#access-list 100 permit icmp any any time-exceeded Router(config)#access-list 100 permit icmp any any traceroute Router(config)#access-list 100 permit icmp any any unreachable 

If you are running version 12.2(11) YU or 12.2 (15) T and above, you can configure inspection rules for ICMP inspection.

There Is a Problem with Inspecting Single Channel Protocol

For single channel protocols such as HTTP or SMTP, generic inspection (inspecting TCP) is sufficient. However, to achieve additional security against protocol violation, you have the option of inspecting with SMTP or HTTP. The big confusion comes when inspecting with HTTP. With HTTP inspection (if Java-list is not configured), by default Java filtering is turned on. So, connection requests for all the websites serving Java applets are denied by the CBAC. Hence, if you run into a problem with browsing certain sites, either remove inspection for HTTP or configure Java-list in conjunction with ACL to allow the trusted sites for Java applets.

Before 12.3(7) T, CBAC didn't have any option for inspecting ESMTP traffic. So, if you inspect SMTP, and your mail server runs ESMTP (for example, Microsoft Exchange Server), you will have problems getting e-mail. As work-arounds, either turn off SMTP inspection on the router or turn off ESMTP in the mail server as shown in the following link:

If you are running IOS version 12.3(7)T or above, and want to inspect ESMTP, refer to the following link for more details:

Required Multi-Channel Protocol is Not Inspected

If there are connectivity issues with multi-channel protocols such as FTP or H323 for example, make sure you are inspecting those specific protocols. In multi-channel protocols, the data channels are built up based on the negotiation that takes place using a control channel. So, the IOS firewall engine must inspect the control channel to get the necessary information from the negotiation that takes place to create openings on the ACL for the data channel. So, if you do not inspect the application layer protocol, the inspection engine for that protocol is not used. Instead, a generic inspection engine, such as TCP or UDP, is used, which does not go into the payload to get all the required information for the subsequent data channels once the control channel is built up. Hence the data channels fail. For FTP a typical symptom is this: when you execute ls, it hangs infinitely. If inspecting multi-channel protocol does not resolve the issues, then most likely there is a software bug, which can be confirmed by Cisco Support if presented with the debug ip inspect multi_channel_protcol (for example, FTP).

IP URL Filtering Blocking The Connection

If the IOS firewall is configured with an external URL filtering server, the URL server's policy has determined whether a connection is allowed or denied. So, if there is a configuration error in defining the policy, the connection across the IOS firewall router will fail. Therefore, you will need to recheck the URL server policy to be sure your URL server is not accidentally denying connections due to misconfiguration.

Redundancy or Asymmetric Routing Problems

IOS Firewall does not support router redundancy or load sharing among multiple routers; instead, it supports interface redundancy and load sharing. This means that if the request packet goes through router A, it must return back through router A. Otherwise, if CBAC is configured, router B drops the packets if router B receives them. If the packet leaves from router A serial interface 0 and returns on serial interface 1, if you have the same access-list 101 applied on both of the interfaces, the return packets will make it through and the connection will be established without any problem. This is because when CBAC creates a new channel, it installs the temporary access list entries on the interfaces used for the initial packet, but those same access lists may be installed on backup interfaces that provide additional paths to the same destinations. It is even possible to use CBAC with load sharing, if all the parallel interfaces are configured identically. If you configure the same access list and inspection parameters on two interfaces that are alternate paths to the same destination, connectivity should work. Remember to use the same access lists (with the same access list numbers) on both redundant interfaces. This works fine with dial backup for serial interface.

Performance Issues

If traffic or responses from the Command Line Interface (CLI) parser are slow, use the commands shown in Examples 5-20 and 5-21 to check if you are running short of memory and CPU.

Example 5-20. Sample Output of CPU Utilization Under Normal Conditions

Router#show processes cpu CPU utilization for five seconds: 2%/0%; one minute: 1%; five minutes: 0%  PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process    1           0         2          0  0.00%  0.00%  0.00%   0 Chunk Manager    2          28     91967          0  0.00%  0.00%  0.00%   0 Load Meter    3           0        12          0  0.00%  0.00%  0.00%  61 Modem Autoconfig    4           0         1          0  0.00%  0.00%  0.00%   0 EDDRI_MAIN    5      626536     68810       9105  0.00%  0.16%  0.20%   0 Check heaps    6           0        50          0  0.00%  0.00%  0.00%   0 Pool Manager --More Router# 

Example 5-21. Sample Output of Memory Utilization Under Normal Conditions

Router#show processes memory Total: 95974624, Used: 23276556, Free: 72698068  PID TTY  Allocated      Freed    Holding    Getbufs    Retbufs Process    0   0     211660      28936    6561888          0          0 *Init*    0   0       1044  213092464       1044          0          0 *Sched*    0   0  103793828  105060340   13875032    2973466          0 *Dead*    1   0          0          0       6852          0          0 Chunk Manager    2   0        188        188       3852          0          0 Load Meter    3  61          0          0       6904          0          0 Modem Autoconfig    4   0      65580          0      90432          0          0 EDDRI_MAIN    5   0          0          0       6852          0          0 Check heaps    6   0     126044      59592       7616      81604     105792 Pool Manager --More Router# 

If CPU utilization goes beyond 50%, investigate the issue further to see where the problem is. Find out if there were any changes to the CBAC configuration. If there were no configuration changes, your network may be under attack and running short of memory and CPU, as the router processes all the unnecessary packets. The best way to find that out is to analyze the syslog and see if there is an alert message from the router indicating that the router is going to aggressive mode and calming down. If you realize the system is under attack, it is best to block the traffic from the upstream router with the ACL and inform your ISP about the situation so that they can block the traffic. Because most of the time the traffic comes with spoofed random IP, the upstream router may be configured with rate limiting so that innocent users' traffic is not completely blocked. It is important to note that CBAC protects your internal network from the attack but at the cost of performance, and if an attack continues for a long time, the rate limiting on the upstream router may be applied as a work-around until the ISP identifies the source of the attack.

If you are not under attack and still having performance problems, check the following items to troubleshoot the issue:

  • Timeouts for TCP, UDP, and DNS

  • Short threshold values for half-open or new connections

  • HTTP inspection dilemma

  • Switching path

  • Large ACL

  • Reverse DNS and Identification Protocol (IDENT)

  • The running of old code

Timeouts for TCP, UDP, and DNS

There are a number of timeouts in CBAC configuration. As the TCP is connection-oriented, it has a mechanism for tearing down the connections when the job is finis hed. So, leaving the TCP connection timeout values at the defaults (as shown in Table 5-3) is recommended unless otherwise required for certain applications.

However, UDP connections heavily rely on the CBAC timeout values, which are connectionless, and there is no mechanism to let the other party or the CBAC router know when the job is finished. Choosing an appropriate timeout value for UDP connections is very difficult. For UDP, generic UDP inspection simply creates a channel when it sees the first request packet from the client, and keeps that channel open until no traffic has been seen between the client and the server for a preset time. If you set the timeout for too short a time, you may kill certain types of connections prematurely. For example, a Network File System (NFS) may remain mounted across CBAC for a long time with no activity. As NFS is UDP based, the connection may time out prematurely due to a UDP session timeout on CBAC. Therefore, when NFS is called for on any activity, CBAC requires the rebuilding of the session. Performing NFS across CBAC or any firewall is strongly discouraged. And if you set the idle timeout for UDP too high, you may be accumulating a number of UDP sessions for nothing. The problem is even more serious when you have a DNS server on ISP and your client needs to make the entire DNS query to the ISP DNS server across the firewall. Luckily, the IOS Firewall has the option of setting up the timeout for DNS, which is much shorter than the generic UDP timeout.

Table 5-3 shows different default timeout values for TCP and UDP. With the commands listed in the table, it is possible to reset these timeout values.

Table 5-3. Timeout Options Available in CBAC



Default (in sec)

The length of time the software waits for a TCP session to reach the established state before dropping the session

ip inspect tcp synwait-time seconds


The length of time a TCP session will still be managed after the firewall detects a FIN-exchange

ip inspect tcp finwait-time seconds


The length of time a TCP session will still be managed after no activity (the TCP idle timeout)

ip inspect tcp idle-time seconds


The length of time a UDP session will still be managed after no activity (the UDP idle timeout)

ip inspect udp idle-time seconds


The length of time a DNS name lookup session will still be managed after no activity

ip inspect dns-timeout seconds


Short Threshold Values for Half-open and New Connections

It is extremely important to establish baselines for your network to find out what is normal before performing this function: manipulating different threshold values for the total number of half-open connections, or total new connection request rate. If you ambitiously set these threshold values too low, the router may go into aggressive mode and start dropping legitimate traffic. Because of this, you will not only experience packet drops, but the performance of the connections will be very poor. To prevent this, you must determine the values of these thresholds for your network.

HTTP Inspection Dilemma

If you have inspection turned on for HTTP, Java filtering is turned on by default as discussed before. HTTP inspection causes the packets to be inspected in strict order. So any out-of-order packets received are dropped, causing the packets to be retransmitted. This may cause a delay in downloading web pages. You can verify this by running the following debugs on the router:

debug ip inspect detailed debug ip inspect tcp debug ip inpsect http 

When performance degrades due to out-of-order packets, you will receive a message as follows with the three debug commands listed previously:

Feb 17 17:37:59.428 CST: CBAC* sis 83207F08 L4 inspect result: DROP packet 833BE CC4 ( ( bytes 272 http 

You can get around the problem in two ways: either turn off HTTP inspection or upgrade the code to version 12.3(5.13) or 12.3(5.13) T or above.


Generally per-packet load balancing increases chances of out-of-order packets. Hence, for better performance, install per-flow load balancing instead of per-packet load balancing.

Switching Path

CBAC can work on Process, Fast, or Cisco Express Forwarding (CEF) switching paths. However, CBAC works best with CEF. If there are performance issues with CBAC, first try turning off CBAC and verifying if the performance issue is caused by CBAC. If it is, turn on CBAC with process switching. This may slow down the packets, but it should work. Then turn on CEF or Fast switching and compare the performance. If CEF or Fast switching fails to provide better performance, the most likely cause is IOS software anomalies. For help with IOS software anomalies, consult with Cisco support.

Large ACL

ACL comprises multiple access controls elements (ACEs), and they are processed sequentially in top-down fashion. So it is very important to configure the entries that are most likely to be matched toward the top of the access list. The performance impact of an access list increases linearly with the increase in the number of ACEs. So, try summarizing the address ranges of the ACEs as much as possible. The smaller the list is, the lesser the CPU utilization and time to sequentially search for an entry. If you have a huge number of ACEs even after summarization, configure turbo ACL. Note that the turbo ACL feature is available on only 7200, 7500, and 12000 series routers. To turn on turbo ACL, simply execute the access-list compiled command after creating the ACL. The turbo ACL feature compiles the ACL ACEs into a set of special lookup tables while maintaining the first-match requirement. These tables allow for making permit or deny decisions quickly and consistently, which boosts performance dramatically. Keep in mind, however, the following caution: if you have less than five ACEs, a standard or extended ACL may perform better than turbo ACL. This is because, the turbo ACL compilation may take more CPU cycles than the CPU cycles gained with finding a faster match. Additionally, try to use netflow with ACL to boost the performance, because when net flow is enabled, only the first packet in a given flow goes through ACL checking. The rest of the packets bypass ACL checks. Netflow can be turned on in the Cisco router with the ip route-cache flow command under the interface configuration mode.

Reverse DNS and IDENT Protocols

If there is a problem in which users can connect to servers but have to wait a long before data comes back, something might be preventing the server from doing reverse DNS or IDENTD. To work around the DNS issue, be sure to allow UDP/53 to the DNS server from the destination server, provided the DNS server is behind the CBAC router. To get around the problem for IDENT protocol, be sure to allow TCP/113 through the CBAC router so that the server can communicate with the client on TCP/113.

Running Older Code

If you are running Cisco IOS version less than 12.2(8) T, you should seriously consider upgrading the code base, because a major performance initiative materialized from this specific version. Here are some of the changes that were made to improve the performance of CBAC:

  • Allow users to dynamically change the size of the session hash table from 1K to 8K without reloading the router by using the ip inspect hashtable command. When a packet belonging to an existing session comes into the router, a hash table is used to map the packet to an existing firewall session. By increasing the size of the hash table, the number of sessions per hash bucket can be reduced, and consequently the search time for the session is greatly reduced. This improves the throughput performance of the base engine. You should increase the hash table size when the total number of sessions running through the CBAC router is approximately twice the current hash size; decrease the hash table size when the total number of sessions is reduced to approximately half the current hash size. Essentially, try to maintain a 1:1 ratio between the number of sessions and the size of the hash table.

  • In versions prior to the performance improvement initiative, while processing a packet for connection setup and connection teardown of TCP connections, the base engine of CBAC "bumps up" several packets to the process-switching path. This drastically slows down their processing. Also, the base engine needs to process each packet again when it is bumped up into the process switching path. This whole process of punting packets back and forth degrades performance substantially. The new version prevents these restrictions by allowing only the first packet of any connection to be bumped up to the process-switching path, while the remaining packets are processed by the base engine in the fast path. Thus, the base engine is no longer slowed down by bumping up several packets or by processing packets twice.

  • With the release of version 12.3(7) T, Cisco IOS Firewall Access Control Lists (ACL) bypass enhances the performance of Cisco IOS Firewall by removing multiple lookups on the return traffic passing through the router. Before this release, multiple checks are performed of each packet of the return traffic of an existing firewall flow: the input ACL search, the output ACL search, and the inspection session search. With updated code, a check is performed only once, and packets are marked if they belong to an existing firewall session before the input ACL search. This marking is used to skip the input and output dynamic ACL searches.

Intermittent Packet Drops

Intermittent packet drops can occur for various reasons. Go through the performance troubleshooting steps to be sure you are not hitting any performance issue. In addition, you may need to check the following to troubleshoot the intermittent packet drops issue:

  • Fragmentation issue If you are running a version of IOS code older than 12.3(8) T, you may run into issues with fragmentation. CBAC does not support IP fragments earlier than version 12.3(8) T, so packets may be dropped intermittently if they come out of order. To get around this problem, you may configure IP TCP adjust-mss under the interface facing towards the client, so that MTU negotiation can take place, and both client and server adjust their MTU to avoid the fragmentation.

  • URL filtering If you are running IP URL filtering, be sure that the policy defined in the URL server is not denying the packet.

IP URL Filtering Is Not Working

Troubleshooting IP URL filtering-related issues is fairly simple. With the help of ip urlfilter audit-trail command, to troubleshoot any issue you can turn on an audit trail for IP URL filtering and get all the required messages as shown in Table 5-4.

Table 5-4. Audit Trail with URL Filtering

Audit Trail


%URLF-3-SERVER_DOWN: Connection to the URL filter server is down

Router is unable to talk to the URL server.

%URLF-3-ALLOW_MODE: Connection to all URL filter servers are down and ALLOW MODE is OFF

Router is unable to talk to URL server but the system enters allow mode.

%URLF-5-SERVER_UP: Connection to an URL filter server is made, the system is returning from ALLOW MODE

Router is able to talk to the URL server and it's in allow mode now.

%URLF-4-URL_TOO_LONG: URL too long (more than 3072 bytes), possibly a fake packet?

URL in a lookup request is too long; any URL longer than 3K is dropped.

%URLF-4-MAX_REQ: The number of pending request exceeds the maximum limit <1000>

The number of pending requests in the system exceeds the maximum limit and all further requests are dropped.

%URLF-6-SITE_ALLOWED: Client accessed server

This message is logged for each request whose destination IP address is found in the cache. The URL is not logged because the IP address of the request is found in the cache.

%URLF-4-SITE-BLOCKED: Access denied for the site `'; client server

A request finds a match against one of the blocked domains in the exclusive-domain list or the corresponding entry in the IP cache.

%URLF-6-URL_ALLOWED: Access allowed for URL; client server

URL request that is allowed by a UFS. It includes the allowed URL, source IP address, source port number, destination IP address, and destination port number. Longer URLs will be truncated to 300 bytes and logged.

%URLF-6-URL_BLOCKED: Access denied URL; client server

URL request that is blocked by a UFS. It includes the blocked URL, source IP address, source port number, destination IP address, and destination port number. Longer URLs are truncated to 300 bytes and then logged.

Cisco Network Security Troubleshooting Handbook
Cisco Network Security Troubleshooting Handbook
ISBN: 1587051893
EAN: 2147483647
Year: 2006
Pages: 190
Authors: Mynul Hoda

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: