Implementing a Cisco IOS Zone Based Firewall

Traditionally, Cisco IOS Firewalls were configured as an inspection rule only on interfaces. This has changed, however, with the introduction of zone-based firewalls. This section examines the Cisco IOS unidirectional firewall policy between groups of interfaces known as zones and shows you how to configure a Cisco IOS zone-based policy firewall.

Understanding Cisco IOS Firewalls

The Cisco IOS classic firewall, formerly known as Context-Based Access Control (CBAC), is one of the key feature sets of the Cisco IOS Firewall. This section explores how to configure the Cisco IOS classic firewall, including how to configure Granular Protocol Inspection (GPI) and an application firewall.

The Cisco IOS classic firewall can provide network protection on multiple levels using a variety of functions:

■ Traffic filtering

■ Traffic inspection

■ Alerts and audit trails

■ Intrusion prevention Traffic Filtering

The Cisco IOS classic firewall can intelligently filter TCP and UDP packets based on application layer protocol session information. The Cisco IOS classic firewall can be configured to permit specified TCP and UDP traffic through the firewall only when the connection is initiated from within the network that you want to protect. Traffic inspection for sessions that originate from either side of the firewall is an added capability. The Cisco IOS classic firewall also offers the flexibility to be used for intranet, extranet, and Internet perimeters of your network.

If not for the Cisco IOS classic firewall, traffic filtering would be limited to ACL implementations. Such implementations only examine packets at the network layer or, at most, the transport layer.

An advantage of the Cisco IOS classic firewall is that it examines not only network and transport layer information but also the application layer protocol information in an effort to learn about the state of the session. This enables the Cisco IOS classic firewall to support protocols that involve multiple channels created as a result of negotiations in the control channel. This is essential in supporting most of the multimedia protocols as well as some other protocols (such as FTP, RPC, and SQL*Net) that involve multiple channels.

The Cisco IOS classic firewall offers Java blocking. This blocking can be configured to filter HTTP traffic based on the server address or to deny access to Java applets not embedded in an archived or compressed file. An issue with Java is the potential for a user to inadvertently download destructive applets into your network.

One way to protect against this risk is to require all users to disable Java in their browsers. This may be too limiting, though, and it might not be possible for your organization. If this is the case, you should create a Cisco IOS classic firewall inspection rule and use this to filter Java applets. Taking this step will allow users to download only applets residing within the firewall and trusted applets from outside the firewall. If you require more robust content filtering of Java, ActiveX, or virus scanning, you might want to consider purchasing a dedicated content-filtering product.

Traffic Inspection

One of the key responsibilities of the Cisco IOS classic firewall is to inspect traffic as it travels through the firewall to discover and manage state information for the various TCP and UDP sessions. Using this state information, temporary openings are created in the firewall to allow return traffic as well as additional data connections for sessions that are permitted.

The Cisco IOS classic firewall uses packet inspection at the application layer, and maintenance of TCP and UDP session information, to provide the ability to detect and prevent certain types of network attacks such as TCP SYN flooding attacks. In a TCP SYN flooding attack, an attacker floods a server with a barrage of requests for connection but does not complete the connection. As a result, the volume of half-open connections overwhelms the server, causing it to deny service to valid requests. Attacks such as this, which deny access to a network device or service, are called denial-of-service (DoS) attacks.

The Cisco IOS classic firewall helps protect against attacks in a number of ways. For instance, it inspects packet sequence numbers in TCP connections to see if they are within expected ranges and drops any suspicious packets. Cisco IOS classic firewall also may be configured to drop half-open connections. It also can detect unusually high rates of new connections and issue alert messages.

Cisco IOS classic firewall also can help prevent certain DoS attacks involving fragmented IP packets. For instance, an attacker can overwrite the fragment offset in the noninitial IP fragment packets. If this occurs, when the firewall reassembles the IP fragments, it might create wrong IP packets, causing the memory to overflow or your system to crash. Another form of attack can occur when an attacker makes the fragment size small enough to force Layer 4 (TCP and UDP) header fields into the second fragment. When this occurs, the ACL rules that have been configured for those fields do not match.

In another form of attack, the attacker might send a continuous stream of incomplete IP fragments, causing the firewall to lose CPU processing power and memory while trying to reassemble the bad packets. As you can see, even when the firewall prevents an attacker from making an actual connection to a given host, an attacker can still disrupt services provided by that host.

The Role of Alerts and Audit Trails

Real-time alerts and audit trails generated by the Cisco IOS classic firewall provide a means for you to gain insight into what is happening on your firewall. Syslog provides a means to track all network transactions. With this, you can capture such information as recording time stamps, source host, destination host, ports used, and the total number of transmitted bytes. This allows you to create advanced, session-based reporting. The real-time alert capability sends syslog error messages to central management consoles as soon as suspicious activity is detected. You can also configure alerts and audit trail information on a per-application protocol basis using Cisco IOS classic firewall inspection rules. For example, if you want to generate audit trail information for HTTP traffic, you can specify this in the rule covering HTTP inspection.

Classic Firewall Process

The Cisco IOS classic firewall provides Stateful Packet Inspection (SPI) to inspect traffic and create temporary openings at firewall interfaces. When specified traffic exits your internal network through the firewall, the Cisco IOS classic firewall creates these openings. They allow returning traffic (that would normally be blocked) and additional data channels to enter your internal network through the firewall. This traffic is managed by the firewall and is allowed only if it is part of the same session as the original traffic that triggered Cisco IOS classic firewall when exiting through the firewall.

Figure 10-22 shows the operation of a classic firewall and the flow of traffic as a user connects with a web server on the Internet. The ACL shown in Example 10-9 makes this traffic flow possible from the internal network while blocking traffic from an outside attacker, as shown in Figure 10-22. In this figure and example, traffic is inspected, and a temporary opening is created in the firewall interfaces to permit allowed traffic to pass. Return traffic from sessions initiated inside the internal network is also allowed to enter the internal network through the firewall. All other traffic from the outside is denied in this example.

Figure 10-22 Operation of a Classic Firewall

Classic Firewall uses ACL Bypass to bypass multiple ACL checks.

UserX initiates an HTTP session.

Traffic Inspected After Passing ACLs

Traffic Inspected After Passing ACLs

Fa0/0 S0

Port 80

Fa0/0 S0



Example 10-9 Applying ACLs for Classic Firewall Operation

router(config)# ip access-list 104 deny ip any


router(config)# ip access-list 103 permit http



router(config)# ip inspect name FWRULE tcp

router(config)# interface S0

router(config-if)# ip access-group 103 out

router(config-if)# ip access-group 104 in

router(config-if)# ip inspect FWRULE out

router# show ip inspect sessions

Established Sessions

Session 641721A8 (>(




Stateful Packet Inspection (SPI) was introduced as a feature called Context-Based Access Control (CBAC). Before this, the ACL was the only packet-filtering mechanism offered by Cisco IOS software. CBAC represented a significant advance over ACLs in that it provided stateful packet-filtering capability.

CBAC can monitor several attributes in TCP connections, UDP sessions, and ICMP. This monitoring is done in an effort to be sure that the only traffic allowed through a firewall ACL is the return traffic for a dialogue that was originated on the private side of the firewall.

Cisco IOS SPI provides a mechanism to discover connections that originate on the secure (trusted) side of the firewall, and watch for and allow the return traffic that corresponds with these connections. Connections originating on the unsecure (untrusted) side of the firewall are not allowed to reach the secure network. This is controlled by an ACL facing the unsecure network.

CBAC has undergone a number of changes over the years to enhance its capabilities and increase performance. For instance, inspection of some protocols has been enhanced to ensure protocol compliance or to offer application-level service filtering.

In Cisco IOS software Release 12.3(4)T and continuing forward, substantial improvements in performance and significant changes to the stateful inspection architecture were added through the ACL Bypass feature. Over the years, as CBAC developed and its functionality increased, it was renamed Cisco IOS Stateful Packet Inspection to more accurately reflect its capabilities. You may still hear the term CBAC used, because it is frequently used synonymously with Stateful Packet Inspection, but the CBAC name does not reflect the complete feature set offered by Cisco IOS SPI.

SPI works by inspecting the packet after it passes the inbound ACL of an input interface if the ip inspect in command is applied, or after the outbound ACL of the output interface if the ip inspect out command is used. In this way, outbound traffic must be permitted by input ACLs facing the source and outbound ACLs facing the destination.

Examining the Principles Behind Zone-Based Firewalls

Cisco IOS Release 12.4(6)T introduced a new configuration model for the Cisco IOS Firewall feature set. This new model presented the Cisco IOS zone-based policy. It provides intuitive policies for multiple interface routers, a greater level of granularity with regard to firewall policy application, and the ability to prohibit traffic between firewall zones until an explicit policy is applied to allow desirable traffic via a default deny-all policy.

The new zone-based policy inspection interface supports almost all the firewall features implemented in prior releases:

Stateful packet inspection Application inspection

Virtual private network (VPN) virtual routing and forwarding (VRF)-aware Cisco IOS Firewall

URL filtering

Denial-of-service (DoS) mitigation Cisco IOS Release 12.4(6)T also adds a number of new capabilities and characteristics:

Policies are applied between zones Default deny-all policy Subnet- and host-specific policies

Combining service lists with network and host address lists is allowed Clearer statement of firewall policies Unidirectional policy between zones Multiple traffic classes and actions are applied per zone pair All connection parameters are global unless a parameter map is specified Policies may be made up of combinations of the following:

■ IP addresses or subnets using ACLs

Key Topic

■ Application services

■ Application-specific policies

This move to the Cisco IOS zone-based policy firewall changes the firewall from an interface-based model to a more flexible, easier-to-understand, zone-based configuration model that helps improve performance as well. Under this new model, interfaces are assigned to zones, and then an inspection policy is applied to traffic moving between the zones.

Considerable flexibility and granularity are provided through interzone policies, allowing different inspection policies to be applied to multiple host groups connected to the same router interface. Firewall policies are configured through the Cisco Policy Language, which employs a hierarchical structure to define inspection for network protocols and allows the grouping of hosts to which the inspection policy will be applied.

Changes to Firewall Configuration

Configuration of the Cisco IOS Firewall has completely changed with the new Cisco IOS zone-based policy firewall. Let's examine some of these changes.

First and perhaps most notable is the introduction of zone-based configuration. The Cisco IOS Firewall is the first Cisco IOS software threat defense feature to implement a zone configuration model, but other features may adopt the zone model in the future.

Prior versions of the Cisco IOS Firewall employed stateful inspection and the CBAC interface-based configuration model. This model employed the ip inspect command set, and it will be maintained for a period of time. But few, if any, new features can be configured with the classic command-line interface (CLI). This is because the Cisco IOS zone-based policy firewall does not use the stateful inspection or CBAC commands. Even though this is the case, you may use the two configuration models concurrently on routers, but you may not combine them on interfaces. For instance, an interface cannot be configured as a security zone member and configured for IP inspection simultaneously.

As introduced with Cisco IOS Release 12.4(6)T, zones establish the security borders of your network. The zone itself defines a boundary where traffic is subjected to policy restrictions as it crosses over into another region of your network. The default policy between zones is deny all. This means that if no policy is explicitly configured, all traffic moving between zones is blocked. If you are familiar with the earlier stateful inspection model, you will recognize this as a significant departure. In the former model, traffic was implicitly allowed until it was explicitly blocked with an ACL.

A second significant change with Cisco IOS Release 12.4(6)T is the introduction of a new configuration policy language known as Cisco Policy Language. If you're familiar with the Cisco IOS software modular quality-of-service CLI (MQC), you might recognize the format as similar to how QoS specifies which traffic will be affected by the action applied in a policy map.

Zone Membership Rules

Several rules govern the membership of router network interfaces in zones. These rules pertain to interface behavior as the traffic moves between zone member interfaces. These rules are as follows:

■ Before interfaces can be assigned to the zone, a zone must be configured.

■ Interfaces may be assigned to only one security zone.

■ When an interface is assigned to a zone, all traffic to and from the given interface is implicitly blocked when the interface is assigned to a zone. The exception is traffic to and from other interfaces in the same zone, and traffic to any interface on the router.

■ Among interfaces that are members of the same zone, traffic is implicitly allowed to flow by default.

■ To permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.

■ The only exception to the default deny-all policy is the self zone. Traffic to any router interface is allowed until traffic is explicitly denied.

■ Traffic may not flow between a zone member interface and any other interface that is not a zone member. Pass, inspect, and drop actions can be applied only between two zones.

■ If an interface has not been assigned to a zone, it functions as a classical router port and might still use classical stateful inspection or CBAC configuration.

■ You may still need to put an interface in a zone and configure a pass-all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired, even if it is required that an interface on the box not be part of the zoning or firewall policy.

■ If traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model.

■ The one exception to the preceding deny-by-default approach is traffic to and from the router, which is permitted by default. However, an explicit policy can be configured to restrict such traffic.

To ensure that all interfaces that are assigned to the same zone are protected with a similar level of security, a security zone should be configured for each region of relative security within the network. Figure 10-23 shows a basic firewall topology.

Figure 10-23 Basic Firewall Topology


Figure 10-23 Basic Firewall Topology


• The private zone must reach the Internet, with access to HTTP, SMTP, and DNS services.

• The Internet should not have any inbound access.

• The private zone must reach the Internet, with access to HTTP, SMTP, and DNS services.

• The Internet should not have any inbound access.

Figure 10-23 shows an access router with two interfaces:

■ One interface connected to the public Internet

■ One interface connected to a private LAN that must be able to reach the public Internet Both interfaces in this network are assigned to their own zone.

In this example, each zone holds only one interface. If an additional interface were to be added to the private zone, the hosts connected to the new interface in the zone would be able to pass traffic to all hosts on the existing interface in the same zone. The existing policies would also affect the traffic of local hosts to hosts in other zones in a similar manner.

The network generally has two main policies:

■ Private zone connectivity to the Internet

■ Internet zone connectivity to the private zone

Understanding Security Zones

A security zone consists of a group of interfaces to which a policy can be applied. Two steps are involved when grouping interfaces into zones:

■ Creating a zone so that interfaces can be attached to it

■ Configuring an interface to be a member of a given zone

All traffic to and from an interface (except traffic going to the router or initiated by the router) is dropped when an interface is a member of a security zone. If you want to permit traffic to and from a zone member interface, you must make that zone part of a zone pair and then apply a policy to that zone pair. If the policy has been configured to permit traffic (via inspect or pass actions), traffic can flow through the interface. The default behavior is for traffic to be allowed to flow among interfaces that are members of the same zone. If you want traffic to flow among all the interfaces in a router, each interface must be a member of one security zone or another. However, it is not a requirement for all router interfaces to be members of security zones.

Zones and Inspection

Zone-based policy firewalls examine the source and destination zones from the ingress and egress interfaces for a firewall policy. In this configuration it is not necessary that all traffic flowing to or from an interface be inspected. You can specify that individual flows in a zone pair be inspected through the policy map that is applied across the zone pair. The policy map that you apply will contain class maps that specify the individual flows.

Let's consider an example. We can specify a policy map that performs HTTP URL filtering for hosts on (salespeople) but that only does plain HTTP inspection for (sales managers) for your inside-to-outside traffic.

This results in two flows ( to any, to any), and we can apply different inspection parameters to these flows to configure the different behaviors. Zone-based policy firewalls allow inside-to-Internet traffic (the source zone inside and the destination zone outside).

Security Zone Restrictions

The following are important security zone restrictions:

■ Interfaces may not be part of a zone and a legacy inspection policy at the same time.

■ An interface may be a member of only one security zone.

■ If an interface is a member of a security zone, all traffic to and from that interface is blocked unless you configure an explicit interzone policy on a zone pair involving that zone.

■ It is not possible for traffic to flow between an interface that is a member of a security zone and one that is not a member of a security zone, because a policy can be applied only between two zones.

■ For traffic to flow among all the interfaces on a router, each interface must be a member of one security zone or another. This is key, because after you make an interface a member of a security zone, a policy action (such as inspect or pass) is needed to explicitly allow packets. Without this policy action, all packets are dropped.

■ If an interface on a router cannot be part of a security zone or firewall policy, it may be necessary to put that interface in a security zone and configure a "pass all" policy between that zone and other zones where traffic should flow.

■ An ACL may not be applied between security zones or on a zone pair unless defined within a class map.

■ ACLs may not be applied between security zones and zone pairs. A better means to accomplish this is to include the ACL configuration in a class map and to use policy maps to drop traffic.

■ An ACL on an interface that is a zone member should not be restrictive.

■ Each interface in a given security zone must belong to the same VRF.

■ Policies may be configured between security zones whose member interfaces are in separate VRFs. Traffic may not flow between these VRFs unless the configuration allows it.

■ If traffic does not flow between VRFs, the policy across the VRFs is not executed. This represents a misconfiguration on the routing side, rather than on the policy side.

■ Traffic passes freely between interfaces in the same security zone and is not subjected to any policy.

■ Both the source and destination zones in a zone pair must be members of a security zone.

■ You should not define the same zone as both the source and the destination.

Working with Zone Pairs

Zone pairs are used to allow you to specify a unidirectional firewall policy between two security zones.

To define the zone pair, you need to use the zone-pair security command. We define the direction of the traffic flow by specifying a source and destination zone. These must be security zones. As mentioned previously, remember that the same zone cannot be defined as both the source and the destination.

Let's take a closer look at how this works. If we have an interface that is configured to be a zone member, all the hosts connected to that interface are included in the zone. However, the traffic flowing to and from this router interface is not controlled by the zone policies. Instead, each IP interface on the router is automatically made part of the self zone when the Cisco IOS zone-based policy firewall is configured. If you want to control IP traffic moving to the router interfaces from the various zones on a router, you must apply policies to block or allow traffic, as well as to inspect traffic between the zone and the router self zone, and vice versa.

You may also select the default self zone as either the source or the destination zone if you want to. This zone, the self zone, is a system-defined zone that does not have any interfaces as members. When a zone pair includes the self zone, along with the associated policy, this applies to traffic directed to the router or traffic generated by the router. However, it does not apply to traffic through the router.

A more common usage of firewalls is to apply them to traffic through a router. This means that you usually need at least two zones rather than working with the self zone.

If you want to permit traffic between zone member interfaces, you must first configure a policy permitting (or inspecting) traffic between that zone and another zone.

To attach a firewall policy map to the target zone pair, you use the service-policy type inspect command.

Figure 10-24 shows the application of a firewall policy to traffic flowing from zone Z1 to zone Z2. In this case, the ingress interface for the traffic is a member of zone Z1, and the egress interface is a member of zone Z2.

Key Topic

Figure 10-24 Security Zone Pairs

Figure 10-24 Security Zone Pairs

Security Zone Pair

Source = Z1 Destination = Z2

Security Zone Pair

Source = Z1 Destination = Z2

If you are working with a topology such as this, and there are two zones, and you require policies for traffic going in both directions (from Z1 to Z2 and Z2 to Z1), you must configure two zone pairs (one for each direction).

Traffic is dropped if a policy is not configured between a pair of zones. Even though this is the case, it is not necessary to configure a zone pair and a service policy solely for return traffic. Recall that return traffic is allowed by default, so long as a service policy permits the traffic in the forward direction.

In the example that we have been considering, it would not be mandatory for you to configure a zone pair source Z2 destination Z1 solely to allow return traffic from Z2 to Z1. This is taken care of by the service policy on the Z1-Z2 zone pair.

Security Zone Firewall Policies

To build Cisco IOS zone-based policy firewall policies, you use the Cisco Policy Language framework. Creating Cisco IOS zone-based policy firewall policies involves three main constructs:

■ Parameter map

Let's examine each of these in greater detail.

A class map is a way to identify a set of packets based on its contents using "match" conditions. Classes generally are defined so that you can apply an action on the identified traffic that reflects a policy. The class itself is designated via the class map.

To create a class map, you use the class-map command. After it is created, the class map is used to match packets to a specified class. When packets arrive at the targets (for instance, the input interface, output interface, or zone pair), determined by how the service-policy command is configured, they are checked against the match criteria that have been configured for a class map to determine if the packet belongs to that class.

Actions are associated with traffic classified by class maps using policy maps. An action is defined as a specific functionality and typically is associated with a traffic class. Some common actions are inspect, drop, and pass.

You can use the policy-map command to either create or modify a policy map that can then be attached to one or more targets. This is done to specify a service policy. The policy-map command is used to specify the name of the policy map to be created, added to, or modified. This must be done before you can configure policies for classes whose match criteria are defined in a class map.

Parameter maps are used to specify parameters to be applied to classified traffic.

Using the parameter-map type command, you may specify parameters that control the behavior of actions and match criteria specified under a policy map and a class map.

Table 10-15 defines the three types of parameter maps that are currently available.

Table 10-15 Types of Parameter Maps

Types of Parameter Maps

Table 10-15 Types of Parameter Maps

Types of Parameter Maps

Type of Parameter Map


Inspect parameter map

This is an optional map. If a parameter map is not configured, the software uses default parameters. Any parameters associated with the inspect action apply to all nested actions, if any exist. If parameters are specified in both the top and lower levels, any parameters specified in the lower levels override those in the top levels.

URL filter parameter map

For URL filtering (via the URL filter action in a Layer 3 or Layer 4 policy map and the URL filter parameter map), a parameter map is required.

Protocol-specific parameter map

A parameter map is required for an IM application (Layer 7) policy map.

Class Maps

If you are familiar with MQC class maps, you will recall that they have numerous match criteria. In contrast, firewalls have fewer match criteria. Firewall class maps also have the type of "inspect." This information controls what shows up under firewall class maps. The class map defines the traffic that the firewall selects for the policy application.

The class map uses the logical qualifiers match any or match all to determine how a particular packet is matched against the filters in the class map. Table 10-16 describes the three types of filters you will use.

Table 10-16 Class Map Filters

Class Map Filter


match protocol-name

Used to match Layer 4 protocols (TCP, UDP, and ICMP) and application services such as HTTP, SMTP, and DNS. Any well-known or user-defined service known to Port-to-Application Mapping (PAM) may be specified.

match access-group

{number 1 name}

The source and destination IP address and source and destination port may be used by a standard, extended, or named ACL to filter traffic.

match class-map-name

Used with a subordinate class map nested inside another class map that provides additional match criteria.

The match-any or match-all operators may be applied by class maps to determine how to apply the match criteria. If match-any is specified, traffic must meet only one of the match criteria in the class map. In contrast, if match-all is specified, traffic must match all the class map criteria to belong to that particular class.

In cases in which traffic might meet multiple criteria, you should apply match criteria in order from more specific to less specific. Example 10-10 shows a sample class map.

Example 10-10 Sample Class Map class-map type inspect match-any my-test-cmap match protocol http match protocol tcp

In this case, HTTP traffic must encounter the match protocol http statement first so that the traffic will be handled by the service-specific capabilities of HTTP inspection. What would happen if we reversed the "match" lines so that traffic encounters the match protocol tcp statement before it is compared to the match protocol http statement? If this were the case, the traffic would be classified as TCP traffic and would be inspected according to the capabilities of the TCP inspection component of the firewall. This would create a problem for certain services such as FTP and TFTP, as well as various multimedia and voice signaling services such as H.323, session initiation protocol (SIP), Skinny, RealTime Streaming Protocol (RTSP), and others. It is important that additional inspection capabilities be used to recognize the more complex activities of these services.

An ACL may be applied by class maps as one of the match criteria for policy application. In the case where the only match criteria of a class map is an ACL and the class map is associated with a policy map applying the inspect action, the router applies inspection for all known services (according to the show ip port-map command). In this case, the ACL must apply the restriction to limit traffic to specific desired types. Be aware that the PAM list includes only application services such as HTTP, NetBIOS, H.323, DNS, and so on. A service that is not known to PAM will not be inspected. Because the PAM list tends to include more services with each Cisco IOS software release, be sure to check the port map list to be certain that your services are known to the firewall software.

Verifying Zone-Based Firewall Configuration

When your zone-based firewall is in place, it is important to verify your Cisco IOS zone-based policy firewall configuration and operation. With the Cisco IOS zone-based policy firewall, new commands have been introduced that will enable you to view policy configuration as well as monitor firewall activity. Let's take a look at some of the commands that you might want to use.

You can display zone descriptions along with the interfaces contained in a specified zone using the show zone security [zone-name] command. If the zone name is not included, this command displays information for all the zones that are configured.

If you would like to display the source zone and the destination zone, as well as the policy attached to the zone pair, you can use the show zone-pair security [source source-zone-name] [destination destination-zone-name] command. If no source or destination is specified, all the zone pairs with source, destination, and the associated policy are displayed. In cases in which only the source or destination zone is mentioned, any of the zone pairs that contain this zone as the source or destination are displayed.

To display a specified policy map, you can use the show policy-map type inspect [policy-map-name [class class-map-name]] command. Should the name of a policy map not be specified, this command displays all policy maps of type inspect, including any Layer 7 policy maps that contain a subtype.

Using these commands, you can view configuration details for your Cisco IOS zone-based policy firewall configuration. These commands can also help you verify proper operation and are a good first step in resolving issues that might arise.

+1 0

Post a comment