Case Studies

In this section, we discuss two important features of FWSM in detail:

  • Multiple SVI for FWSM

  • Understanding access-list memory utilization

Case Study 1: Multiple SVI for FWSM

In this case study, you will learn the concept of SVI interfaces on the MSFC and the need for configuring multiple SVI interfaces.

As previously stated, SVI stands for Switched Virtual Interface. It represents a logical Layer 3 interface on a switch. For Catalyst Operating System (CatOS) versions earlier than 7.6(1) and Cisco IOS Software releases earlier than 12.2(14)SY, only one SVI is allowed as part of the Firewall VLANs. In other words, only one Layer 3 interface can be configured between the FWSM and Multilayer Switch Feature Card (MSFC). Attempting to configure multiple SVIs produces a command-line interface (CLI) error message.

For CatOS Versions 7.6(1) and later and Cisco IOS Software releases 12.2(14)SY and later, the FWSM supports multiple SVIs. By default, only one SVI is supported. To enable support for multiple SVIs on your switch on Native IOS, use the following command:

Cat6509(config)# firewall multiple-vlan-interfaces Warning: enabling multiple VLAN interfaces may result in traffic bypassing the F WSM - use with caution! Cat6509(config)# 

On the hybrid mode, you can use the following command to turn on the multiple SVI interface:

Cat6509# set firewall multiple-vlan-interfaces {enable | disable} 

Traffic is sent to the Firewall Services Module (FWSM) by way of Virtual LANs (VLAN) exclusively. The FWSM has no concept of physical ports of its own. Instead, you need to map VLANs to the FWSM interface. For instance, VLAN 30 in Figure 4-7 is mapped to the inside interface, whereas VLAN 20 represents the outside interface. Physical switchports are then placed into either VLAN, and hosts connect to those ports. When communication occurs between VLANs 20 and 30, the FWSM is the only available path, forcing traffic to be inspected statefully.

Figure 4-7. One SVI Interface Typical Setup

In Figure 4-7, the default gateway for the two hosts on VLAN 30 exists only on the FWSM. In other words, no interface VLAN 30 is ever created on the MSFC. VLAN 30 is mapped directly to the inside interface on the FWSM. Software that supports the FWSM (CatOS 7.5(1) or higher; Supervisor IOS 12.1(13)E or higher) automatically includes a built-in security check that prevents a user from creating a second connection to the MSFC, interface VLAN 30. If a user can create such an interface, traffic from the hosts can bypass the FWSM as shown in Figure 4-8.

Figure 4-8. Host Bypassing in Multiple SVI Interfaces

In Figure 4-8, interface VLAN 30 is created on the MSFC and is assigned an IP address Hosts at the bottom of the figure also reside in VLAN 30. Either accidentally or intentionally, the inside users may bypass the FWSM altogether. Besides, discovering these multiple paths may be achieved without much grief, if insiders have bad intentions. The more serious problem is whether outside traffic from non-secure VLAN 10 can reach the inside subnet directly through the MSFC, which creates a major security breach.

Why Change the Existing Model?

As discussed earlier, the automatic check preventing more than one VLAN interface between the MSFC and the FWSM is extremely valuable to prevent accidental security holes. However, there are a few scenarios in which being able to bypass that check is required. CatOS release 7.6(1) or higher and Supervisor IOS 12.2(14)SY has the option of turning on the ability of multiple SVI interfaces to bypass the check. The commands used for both CatOS and Sup IOS are listed in Table 4-5.

Table 4-5. Commands For Multiple SVI Interfaces

CatOS 7.6(1)

Supervisor IOS 12.2(14)SY

set firewall multiple-vlan-interfaces <enable|disable>

[no] firewall multiple-vlan-interfaces

Scenario One: DHCP Helper with FWSM 1.1(x)

When running release 1.1(x), the FWSM drops incoming UDP broadcasts. Protocols such as DHCP (RFC 2131) rely on such packets extensively, and the lack of DHCP helper functionality in the FWSM can be problematic in certain designs. This section explains how the multiple VLAN interfaces can work around that shortcoming. Take a look at the sample topology depicted in Figure 4-9. Suppose two hosts on VLAN 30 (inside screened subnet) would like to acquire an IP address using DHCP. The enterprise's DHCP server is located off another screened subnet on VLAN 10. VLAN 20 represents the outside network and binds the MSFC to the FWSM. Finally, VLAN 500 connects the Catalyst 6500 switch to the "outside world."

Figure 4-9. Hosts Bypassing In Multiple SVI Interfaces for DHCP

First, enable the multi-VLAN knob. Then create an interface VLAN 20 on the MSFC and assign the IP address to it. You can also create an interface VLAN 30 and assign to it. By doing this, you have actually connected the inside subnet directly to the MSFC. This means that your two hosts can bypass the firewall. To prevent this, apply an inbound access-list to interface VLAN 30 to allow only DHCP requests. Here is a quick background on the operation of the DHCP protocol:

  1. Clients broadcast a DHCPDISCOVER.

  2. Servers unicast a DHCPOFFER back.

  3. Clients broadcast a DHCPREQUEST.

  4. Servers unicast a DHCPACK back.

DHCP messages from a client to a server are sent to the UDP port 67, and DHCP messages from a server to a client are sent to UDP port 68. Therefore, in the scenario, a simple input access-list needs to be applied to VLAN 30 on the MSFC to allow only UDP broadcasts where source port=68 and destination port=67. This takes care of allowing client-sourced messages to reach the DHCP server. You then add an IP helper-address statement to point to the DHCP server, as shown in Example 4-27.

Example 4-27. Configuring ip helper-address on MSFC

MSFC(config)# access-list 150 permit udp host eq 68 host eq 67 MSFC(config)# interface Vlan 30 MSFC(config-if)# ip address ! Following assign the dhcp's IP address MSFC(config-if)# ip helper-address MSFC(config-if)# ip access-group 150 in MSFC(config-if)# 

You also need to tell the MSFC how to reach the DHCP server (via the Firewall). Example 4-28 shows the route configuration that is needed to accomplish this.

Example 4-28. Route Needed on the MSFC

MSFC(config)# ip route MSFC(config)# 

This configuration allows the MSFC to receive UDP broadcasts on VLAN 30 and transform them into IP unicast requests destined to (source IP address You need to verify that this traffic is allowed to cross the firewall.

This takes care of the traffic between the client and the server. What about the opposite direction? The server unicasts its replies back to the relay agent's IP address, always. In this case, these packets look like that shown in Table 4-6.

Table 4-6. Packet Format for DHCP

Source IP address

Destination IP address



Source Port


Destination Port


Firewalls in general do not support asymmetric routing. That is, in this case, you have to force the DHCP offer from the DHCP server to go back out VLAN 20, even though VLAN 30 is connected directly. You need to add the route shown in Example 4-29.

Example 4-29. Route Needed for Proper Routing

FWSM(config)# route vlan20 FWSM(config)# 

Return traffic from the DHCP server enters VLAN 10 and is routed onto VLAN 20 directly by the firewall. The relay agent receives the offer packet and in turns hands out an IP address to the DHCP client.

There is still one problem that needs to be solved, however. We have to ensure that traffic originated from the core (off VLAN 500) that is destined to the inside screened subnet (VLAN 30) does not bypass the firewall. By default, it will bypass the firewall because the MSFC has an interface connected to VLAN 30 (admin distance 0). Policy routing comes to the rescue. Apply an incoming policy routing rule on interface VLAN 500 that reads any traffic destined to, your next-hop is Example 4-30 shows the configuration for policy routing.

Example 4-30. Configuration Needed For Policy Routing

MSFC(config)# ip access-list extended internet-to-inside MSFC(config-ext-nacl)# permit ip any MSFC(config-ext-nacl)#exit MSFC(config)# route-map internet-to-inside-policy-routing permit 10 MSFC(config-route-map)# match ip address internet-to-inside MSFC(config-route-map)# set ip next-hop MSFC(config)# interface Vlan 500 MSFC(config-if)# ip address MSFC(config-if)# ip policy route-map internet-to-inside-policy-routing MSFC(config-if)# 

Scenario Two: Alternate Configuration

An alternate configuration is depicted in Figure 4-10.

Figure 4-10. Host Bypassing in Multiple SVI Interfaces for DHCP

It is also possible to instruct the relay agent ( to send packets destined to the DHCP back out interface VLAN 30. This is done by configuring this static route on the MSFC as shown in Example 4-31.

Example 4-31. Route Configuration Needed on the MSFC

MSFC(config)# no ip route MSFC(config)# ip route MSFC(config)# 

This way, the inside interface of the FWSM receives all traffic sourced from this time, in contrast to the previous example in which that traffic comes in via interface VLAN 20. This means the static route previously installed on the FWSM can be removed, as shown in Example 4-32.

Example 4-32. Route Removal on MSFC

FWSM(config)# no route vlan20 FWSM(config)# 

That is because traffic returning from the DHCP server will naturally prefer the directly connected interface to reach The router access-list needs to be slightly modified to resemble Example 4-33, to allow DHCP offer and ack messages sent by the DHCP server.

Example 4-33. Access-list Needed on the MSFC

MSFC(config)# access-list 150 permit udp host eq 68 host  eq 67 MSFC(config)# access-list 150 permit udp host eq 67 host  eq 67 MSFC(config)# 

The policy routing configuration still applies.

Case Study 2: Understanding Access-List Memory Utilization

As stated previously, the Network Processors for the FWSM are used as hardware assistants to the generic CPU, relieving it from heavy packet processing such as access-list verification, network address translation, TCP sequence number randomization, and so on. One of these three network processorsnamely NP3is responsible for permitting or rejecting initial packets depending on the rules specified by the security policy. In other words, NP3 enforces access-list decisions in hardware. To do so, access-lists encoded via the command line interface (CLI) or graphical user interfaces (GUI) are compiled into a form that the hardware can recognize. NP3 comes equipped with 20MB of on-board memory (non-expandable) reserved for rules storage. Those 20MB are reserved for security policy rules exclusively:

  • URL filtering statements

  • Configured fixups

  • Established rules

  • AAA authentication policies

  • Remote access to the FWSM (SSH, Telnet, HTTP)

  • ICMP to the FWSM (as configured using the ICMP CLI)

  • Policy NAT configuration

  • Access-list entries

It is worth noting that translation entries or connection entries do not borrow from that memory space. The goal of this application note is to provide further details regarding the way access-lists are stored and processed on the FWSM.

The Compilation Process: Active and Backup Trees

NP3 carves that 20MB memory space differently depending on the operating mode (single or multiple mode). With the FWSM running in single mode (release 1.1(x) or 2.2(x)), NP3 uses a dual-tree structure and halves the 20MB into two equal-sized chunks. One tree is called the active tree, and the other is called the backup tree. A tree contains a certain number of nodes. A node is a 64-byte data structure used to store IP addresses and masks, and a corresponding action (permit/deny).

Shortly after a new access-list entry has been entered, modified or deleted, a compilation process is run on the generic CPU to transform the human-readable ACL into a form that the hardware can digest. The compilation process is automatically started by defaultthat is, once an access-list entry has been entered, it is shortly thereafter compiled into NP3. The following sequence captured from the CLI illustrates this:

FWSM(config)# access-list test permit udp host any eq 69 Access Rules Download Complete: Memory Utilization: < 1% FWSM(config)# 

At the end of a successful compilation, rules are pushed down to NP3. During the compilation process, it is important that through-traffic still undergoes security checks using the access-list entries already in place. This is the reason for the backup tree. The backup tree is a mirror of the active tree. It is switched to active mode once the compilation process is running, so the compilation can run in the background without interrupting traffic currently switched by the FWSM. Once the compilation is finished, trees are switched back again.

How Memory Is Allocated: Release 1.1(x) or 2.2(1) in Single Mode

With release 1.1(x) or when running 2.2(1) in Single mode, the 20MB memory space is carved up evenly into two 10MB chunks. When the FWSM is running in single mode, a maximum theoretical limit of 63078 ACEs can be configured out of a total of 82819 rules (see Example 4-34 for the breakdowns of this number).

Example 4-34. Breakdowns in the Number of Nodes in NP3 Processors for Memory

FWSM(config)# show np 3 acl stats | include Total nodes ! 157696*64B = ~10MB Total nodes       :      1 (max 157696) FWSM(config)# show np 3 acl count -------------- CLS Rule Current Counts -------------- ! used for URL filtering CLS Filter Rule Count       :             0 ! one per fixup CLS Fixup Rule Count        :            15 ! for the "established" CLS Est Ctl Rule Count      :             0 ! statements CLS Est Data Rule Count     :             0 ! used for AAA auth CLS AAA Rule Count          :             0 ! for http/tnet/ssh/icmp CLS Console Rule Count      :             0 ! for policy nat CLS Policy NAT Rule Count   :             0 ! for actual ACEs CLS ACL Rule Count          :             1 ---------------- CLS Rule MAX Counts ---------------- CLS Filter MAX              :          3942 CLS Fixup MAX               :            32 CLS Est Ctl Rule MAX        :           788 CLS Est Data Rule MAX       :           788 CLS AAA Rule MAX            :          7884 CLS Console Rule MAX        :          2365 CLS Policy NAT Rule MAX     :          3942 CLS ACL Rule MAX            :         63078 


In 2.2 Single mode, there are 2 extra partitions reserved for downloadable ACLs (one active and one backup).

Note that connection entries or NAT translations do not borrow from this memory space. When a modification is made to an ACE (new entry, deletion, modification), the entire tree is recompiled. This is the reason for the sustained high CPU utilization when a substantial amount of ACE is present. The compilation task runs on the generic CPU, but the final result is pushed down to the hardware. Note that the mapping between ACE and node utilization is not necessarily one-to-one. This means that some ACEs such as permit udp can expand into multiple nodes in a tree, resulting in fewer than 63078 total ACEsyour mileage may vary. Optimizations for certain types of ACEs were brought into release 2.2(1.11), significantly reducing the expansion of ACEs using wildcards such as permit udp any any.

How memory is Allocated: Release 2.2(1) in Multiple Mode

When running in Virtual Firewall mode, both the carving scheme and the compilation process are slightly different and optimized for larger configurations. Instead of a dual tree structure, the memory is organized into 15 trees. Out of these 15 trees, two are used for user-downloadable ACE (one active + one backup). This leaves 13 trees: 12 active and one backup.

The 20MB are divided unevenly between the 15 trees: trees 13 and 14 are smaller (3071 entries) because they are reserved for user-downloadable ACEs. Within each one of the 13 other trees, space is allocated as shown in Example 4-35.

Example 4-35. Allocation of Memory Space on One of the Thirteen Trees

FWSM(config)# sh np 3 acl count 0 ---------------- CLS Rule MAX Counts ---------------- CLS Filter MAX              :           606 CLS Fixup MAX               :            32 CLS Est Ctl Rule MAX        :           121 CLS Est Data Rule MAX       :           121 CLS AAA Rule MAX            :          1213 CLS Console Rule MAX        :           363 CLS Policy NAT Rule MAX     :           606 CLS ACL Rule MAX            :          9704 FWSM(config)# 

Where 1.1(x) and 2.2(1) single mode offered a total of 82819 rule entries, multiple mode nearly doubles that figure: (12 x 12766) + (2 x 3071) = 159334. That is normal because the allocation scheme no longer reserves an entire 10MB of space for the backup tree. Each tree being now much smaller, a backup size of 1/13 of the total space is sufficient. This also implies that in multiple mode each tree is compiled independently.

The following formula generally works to compute the maximum number of rules available per FWSM:

  • Total number of nodes = 2 x 160K (64 bytes each = 20MB memory allocated for nodes)

  • Total Number of Trees = X

  • Nodes available per tree = 320K/X

    Best case number of rules = (320K / X)/2 = 160K/X (one rule takes at least two nodes)

With 12 active trees X = 13 (because of the backup tree), so the maximum number of rules per tree with 12 active trees is 160K/13 = roughly 12300. Keep in mind that this includes the number of filter, AAA, ICMP, Telnet rules, and so on. Table 4-7 records the exact maximum numbers per partition.

Table 4-7. Exact Number of Rules Per Part/ Blade, and Maximum Number of ACEs Per Part Based on Partition




max ACEs/part

















































Trees and contexts: A Matter of Mapping

As contexts (virtual firewalls) are created, they are assigned to an ACL memory pool in a round-robin fashion. Although this satisfies a large majority of applications, in some cases this fixed 12-tree allocation of memory space is no longer optimum. Examine the following examples:

  • Three contexts: the first context is assigned to pool 1, the second context to pool 2, and the third context to pool 3. Each context can use a maximum of 9704 ACEs. Nine-twelfths of the total memory cannot be used by these contexts.

  • One context with a very large ACL configuration, five contexts with only 20 ACEs each: each context is assigned to a pool in a round-robin fashion. With six contexts, 50 percent of the rule memory space cannot be usedeven though contexts 2 to 6 use only a total of 100 rules, context 1 cannot borrow from their pools. Context 1t has to deal with the 9704 entries its pool offers.

  • Twenty contexts: after the 12th context is created, the next context shares rule memory space with the first context. Also, if a change is made to an ACE in either context, the first tree is recompiled.

FWSM release 2.3 brings a better ACL partition management scheme to better address the three scenarios just discussed.

FWSM Release 2.3: The ACL Partition Manager

Starting with release 2.3, the system administrator is given the possibility to modify the ACL memory space-carving scheme. Instead of the default 12-pool model plus two trees for downloadable ACLs, the administrator can choose to divide the space into only three large chunks, or eight, or only one, depending on the needs of a particular configuration. Suppose, for instance, that it has been determined that there are never going to be more than six contexts on this FWSM: the super-user can opt for a six-pool allocation scheme.

A new command line interface is introduced for this purpose. It is available only from the system context, for obvious reasons. Note that the module must be reloaded before a new allocation scheme takes effect. Up to 12 partitions can be created, and if you try to create more than 12, following message will be displayed:

FWSM(config)# resource acl-partition 144 ERROR: Incorrect number of partitions. Allowed range is 1 - 12 Usage: resource acl-partition <number-of-partitions> 

The following example shows allocating three partitions:

FWSM(config)# resource acl-partition 3 WARNING: This command leads to re-partitioning of ACL Memory. It will not take affect until you save the configuration and reboot. FWSM(config)# write memory FWSM(config)# reload 

When the system comes back online, the command in Example 4-36 displays the context-to-partition mapping. Note that even though three partitions were specified via the CLI, six partitions are actually created: three as required by the administrator, one backup, and two for downloadable ACLs. By default, a round-robin scheme is applied to map contexts to ACL partitions:

Example 4-36. Resource Allocation for ACL after Changing the ACL-partition to 3

FWSM(config)# show resource acl-partition Total number of configured partitions = 3 Partition #0         Mode                    : non-exclusive         List of Contexts        : admin         Number of contexts      : 1(RefCount:1)         Number of rules         : 3(Max:41393) Partition #1         Mode                    : non-exclusive         List of Contexts        : none         Number of contexts      : 0(RefCount:0)         Number of rules         : 0(Max:41393) Partition #2         Mode                    : non-exclusive         List of Contexts        : none         Number of contexts      : 0(RefCount:0)         Number of rules         : 0(Max:41393) FWSM(config)# 

However, contexts can be manually mapped to a given partition. This is achieved in the context definition, as shown in Example 4-37.

Example 4-37. Allocating Different Partitions from the Context

FWSM(config-context)# ? At the end of show <command>, use the pipe character '|' followed by: begin|include|exclude|grep [-v] <regular_exp>, to filter show output. allocate-acl-partition  Indicates which acl-partition the context belongs to allocate-interface      Indicate interfaces assigned to the context member                  Indicate class membership for a context config-url              Indicate URL for a context configuration description             Provide a description of the context FWSM(config-context)# FWSM(config-context)# allocate-acl 2 FWSM(config-context)# show resource acl Total number of configured partitions = 3 Partition #0         Mode                    : non-exclusive         List of Contexts        : admin         Number of contexts      : 1(RefCount:1)         Number of rules         : 3(Max:41393) Partition #1         Mode                    : non-exclusive         List of Contexts        : none         Number of contexts      : 0(RefCount:0)         Number of rules         : 0(Max:41393) Partition #2         Mode                    : exclusive         List of Contexts        : acl-test         Number of contexts      : 1(RefCount:1)         Number of rules         : 0(Max:41393) FWSM(config-context)# 

Examples of ACL Compilation

Starting from a clean, empty configuration (Version 1.112.2 single mode), the ACL statistics report 0 is as follows:

FWSM(config)# show np 3 acl stats ----------------------------     ACL Tree Statistics ---------------------------- Rule count        :      0 Bit nodes (PSCB's):      0 Leaf nodes        :      0 Total nodes       :      0 (max 157696) Leaf chains       :      0 Total stored rules:      0 Max rules in leaf :      0 Node depth        :      0 ---------------------------- FWSM(config)# 

A simple ACL usually translates to one entry in the hardware, as illustrated in Example 4-38.

Example 4-38. ACL Stats After Creating Just A Single ACL

FWSM(config)# access-l simple permit tcp host host FWSM(config)# Access Rules Download Complete: Memory Utilization: < 1% Access Rules Download Complete: Memory Utilization: < 1% FWSM(config)# show np 3 acl stats ----------------------------     ACL Tree Statistics ---------------------------- Rule count        :      1 Bit nodes (PSCB's):      0 Leaf nodes        :      1 Total nodes       :      1 (max 157696) Leaf chains       :      0 Total stored rules:      1 Max rules in leaf :      1 Node depth        :      1 ---------------------------- FWSM(config)# 

ACEs that use object-groups expand in multiple lines. Example 4-39 results in 12 actual ACEs (3 hosts x 4 ports):

Example 4-39. ACL Statistics Using Object Groups in the ACL

FWSM(config)# show object object-group network my_servers   network-object host   network-object host   network-object host object-group service common_ports tcp   port-object eq www   port-object eq https   port-object eq telnet   port-object eq ftp FWSM(config)# FWSM(config)# access-l simple permit tcp obj my_servers obj  common_ports ! FWSM(config)# show np 3 acl stats ----------------------------     ACL Tree Statistics ---------------------------- Rule count        :     12 Bit nodes (PSCB's):     11 Leaf nodes        :     12 Total nodes       :     23 (max 157696) Leaf chains       :      0 Total stored rules:     12 Max rules in leaf :      1 Node depth        :      5 ---------------------------- FWSM(config)# ! Another example using object-groups FWSM(config)# show object object-group network my_servers   network-object host   network-object host   network-object host object-group service common_ports tcp   port-object eq www   port-object eq https   port-object eq telnet   port-object eq ftp object-group network my_nets   network-object   network-object   network-object object-group service port_range tcp   port-object eq telnet   port-object eq ftp   port-object eq 1501   port-object eq ssh   port-object range 8101 8115   port-object range 8210 8214   port-object range 8250 8252   port-object eq 6502   port-object eq 2100   port-object eq 7091   port-object eq 6000   port-object eq 4900 FWSM(config)# FWSM(config)# access-l simple permit tcp obj my_servers obj port_range obj my_nets  obj common_ports ! FWSM(config)# sh np 3 acl stats -----------------------     ACL Tree Statistics ---------------------------- Rule count        :    432 Bit nodes (PSCB's):    431 Leaf nodes        :    432 Total nodes       :    863 (max 157696) Leaf chains       :      0 Total stored rules:    432 Max rules in leaf :      1 Node depth        :     11 ---------------------------- FWSM(config)# 

One ACE expands into 432 entries, using relatively simple object-groups. This is normal because the ACL would require 432 individual ACEs anyway, if object-grouping was not used:

FWSM(config)# show access-list | include elem access-list simple; 432 elements FWSM(config)# 

Access-lists: Best Practices

The following is a list of rules of thumb that will help you reduce the hardware resources occupied by ACEs:

  • Use contiguous hosts addresses whenever possible. Aggregate host statements in ACEs/object-groups into networks.

  • Use "any" instead of networks, and networks instead of hosts when possible.

  • Try to simplify object-groups. Potentially this can save hundreds of ACEs when the ACLs are expanded. Grouping together individual port statements into a range is an example.

The time it takes to compile a tree is largely irrelevant because while the compilation is taking place, the "old" tree is still in place. Given that compilation time is not a critical factor, the use of a single partition is recommended. For backward compatibility, 2.3(1) ships with 12+2 partitions by default.

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: