Shaji, The only way to deploy the ASA 1000V is as a Layer3 hop in the path. There is no way to retain Physical Server and Virtual Servers in the same subnet. As a workaround, you can use NAT on the ASA1000V to translate the Virtual servers IP address to be in the same subnet as the Physic Servers. - Rama
... View more
There are no issues reloading both units at the same time. They will still sync failover. There is an issue if you have two FWSMs in failover and have mismatched partition numbers. You run the risk of losing ACLs during failover sync because there may not be enough partition space on the peer. Before synchronizing failover, ensure that the number of parittions on both FWSM are the same by using the command "show resource acl-partition".
... View more
1. NP1 and NP2 are not virtualized in multiple context mode. Multiple context mode only virtualized the FWSM software environment, not the hardware environment. All the NPs are shared across all contexts based on the traffic processing needs of the context. 2. The classifier is a software based solution that helps the FWSM allocate a packet to the correct context. Here is a document that better explains this: http://www.cisco.com/en/US/docs/security/fwsm/fwsm41/configuration/guide/contxt_f.html#wp1124172
... View more
Dynamic Address Assignment IPv6 prides itself as a protocol that supports many dynamic plug and play functionalities. As a result, there are multiple ways to assign IP addresses in IPv6. This guide will go over two methods of IPv6 address assignment: stateless and stateful Stateful Address Assignment Similar to IPv4, IPv6 can use DHCP to statefully assign IP addresses to any clients. Cisco IOS routers can be configured to be Stateful DHCP servers. Stateful DHCP means that the DHCP server is responsible for assigning the IP address to and client. The DHCP server keeps a record of all clients and the IPv6 address assigned to them. Below is a configuration example of a server and client using stateful DHCP. Server configuration: ipv6 dhcp pool IPV6_DHCPPOOL address prefix 2001:DB8:1000::/64 lifetime infinite infinite link-address 2001:DB8:1000::1/64 dns-server 2001:DB8:1000::1 domain-name cisco.com ! interface Ethernet0/0 ipv6 address 2001:DB8:1000::1/64 ipv6 enable ipv6 nd ra suppress ipv6 dhcp server IPV6_DHCPPOOL Notice how the server can disable RA on its interface facing the client. This is because the DHCP process is completely responsible for assigning IP address to all clients on that Layer 3 segment. Client configuration: interface Ethernet0/0 ipv6 address dhcp ipv6 enable The client configuration is the same in IPv6 as it is for IPv4. Stateless Address Assignment This is a unique feature only to IPv6. Stateless address configuration means that the client picks their own address based on the prefix being advertised on their connected interface. All Cisco devices have the ability to participate in Stateless Autoconfiguration (SLAAC). By default, SLAAC does not provide anything to the client outside of an IPv6 address and a default gateway. Additional configuration on the server is necessary before the same information can be provided to the client as Stateful DHCP. Moreover, it is important to note that SLAAC most commonly uses eui-64 format for address assignment. This means that IPv6 addresses will be built from a combination of the Layer 3 subnet prefix and the MAC address of the client. The requirement for SLAAC is that the LAN segment must use a /64 mask. Cisco IOS routers support both Stateful DHCP and Stateless DHCP. Stateless DHCP does not track IPv6 address bindings per client. Rather, it uses DHCP only to hand out domain-names, DNS servers and other client relevant information. Below is a server and client configuration example for Stateless address assignment. Server configuration: ipv6 dhcp pool IPV6_DHCPPOOL dns-server 2001:DB8:1000::1 domain-name cisco.com ! interface Ethernet0/0 ipv6 address 2001:DB8:1000::1/64 ipv6 enable ipv6 nd other-config-flag ipv6 dhcp server IPV6_DHCPPOOL Notice that the DHCP pool configured on the sever has no address pool assigned. This is because the client will select their own IP address since this is a stateless address assignment solution. The router is acting as a stateless DHCP server. Its only role is to provide DNS server and domain name information to clients on this segment. Client configuration: interface Ethernet0/0 ipv6 address auto-config ipv6 enable The client is configured to use SLAAC by setting the "auto-config" option. This command is unique to IPv6 and is the most common way to obtain IP addresses via IPv6. Relevant Outputs DHCP debugs can be used to verify the information passed from the server to the cilent. Below are two examples of the output of debug ipv6 dhcp detail. If stateful address assignment is configured, the following debugs should seen on the server: *Apr 17 18:23:52.286: IPv6 DHCP: Received RELEASE from FE80::A8BB:CCFF:FE01:F500 on Ethernet0/0 *Apr 17 18:23:52.286: IPv6 DHCP: detailed packet contents *Apr 17 18:23:52.286: src FE80::A8BB:CCFF:FE01:F500 (Ethernet0/0) *Apr 17 18:23:52.286: dst FF02::1:2 *Apr 17 18:23:52.286: type RELEASE(8), xid 13734454 *Apr 17 18:23:52.286: option ELAPSED-TIME(8), len 2 *Apr 17 18:23:52.286: elapsed-time 0 *Apr 17 18:23:52.286: option CLIENTID(1), len 10 *Apr 17 18:23:52.286: 00030001AABBCC01F500 *Apr 17 18:23:52.286: option SERVERID(2), len 10 *Apr 17 18:23:52.286: 00030001AABBCC01F600 *Apr 17 18:23:52.286: option IA-NA(3), len 40 *Apr 17 18:23:52.286: IAID 0x00030001, T1 0, T2 0 *Apr 17 18:23:52.286: option IAADDR(5), len 24 *Apr 17 18:23:52.286: IPv6 address 2001:DB8:1000:0:F5AA:93AF:F2F:3243 *Apr 17 18:23:52.286: preferred INFINITY, valid INFINITY *Apr 17 18:23:52.290: IPv6 DHCP: Using interface pool IPV6_DHCPPOOL *Apr 17 18:23:52.290: IPv6 DHCP: Found address 2001:DB8:1000:0:F5AA:93AF:F2F:3243 in binding for FE80::A8BB:CCFF:FE01:F500, IAID 00030001 *Apr 17 18:23:52.290: IPv6 DHCP: Freeing address 2001:DB8:1000:0:F5AA:93AF:F2F:3243 to internal pool 2001:DB8:1000::/64 *Apr 17 18:23:52.290: IPv6 DHCP: Freeing IA_NA 00030001 from binding for FE80::A8BB:CCFF:FE01:F500 *Apr 17 18:23:52.290: IPv6 DHCP: Freeing binding for FE80::A8BB:CCFF:FE01:F500 from pool IPV6_DHCPPOOL *Apr 17 18:23:52.290: IPv6 DHCP: Sending REPLY to FE80::A8BB:CCFF:FE01:F500 on Ethernet0/0 *Apr 17 18:23:52.290: IPv6 DHCP: detailed packet contents *Apr 17 18:23:52.290: src FE80::A8BB:CCFF:FE01:F600 *Apr 17 18:23:52.290: dst FE80::A8BB:CCFF:FE01:F500 (Ethernet0/0) *Apr 17 18:23:52.290: type REPLY(7), xid 13734454 *Apr 17 18:23:52.290: option SERVERID(2), len 10 *Apr 17 18:23:52.290: 00030001AABBCC01F600 *Apr 17 18:23:52.290: option CLIENTID(1), len 10 *Apr 17 18:23:52.290: 00030001AABBCC01F500 *Apr 17 18:23:52.290: option STATUS-CODE(13), len 9 *Apr 17 18:23:52.290: status code SUCCESS(0) *Apr 17 18:23:52.290: status message: SUCCESS Below are the debugs for stateless address assignment: *Apr 17 18:32:36.866: IPv6 DHCP: Received INFORMATION-REQUEST from FE80::A8BB:CCFF:FE01:F500 on Ethernet0/0 *Apr 17 18:32:36.866: IPv6 DHCP: detailed packet contents *Apr 17 18:32:36.866: src FE80::A8BB:CCFF:FE01:F500 (Ethernet0/0) *Apr 17 18:32:36.866: dst FF02::1:2 *Apr 17 18:32:36.866: type INFORMATION-REQUEST(11), xid 14259361 *Apr 17 18:32:36.866: option ELAPSED-TIME(8), len 2 *Apr 17 18:32:36.866: elapsed-time 0 *Apr 17 18:32:36.866: option CLIENTID(1), len 10 *Apr 17 18:32:36.866: 00030001AABBCC01F500 *Apr 17 18:32:36.866: option ORO(6), len 6 *Apr 17 18:32:36.866: DNS-SERVERS,DOMAIN-LIST,INFO-REFRESH *Apr 17 18:32:36.870: IPv6 DHCP: Using interface pool IPV6_DHCPPOOL *Apr 17 18:32:36.870: IPv6 DHCP: Sending REPLY to FE80::A8BB:CCFF:FE01:F500 on Ethernet0/0 *Apr 17 18:32:36.870: IPv6 DHCP: detailed packet contents *Apr 17 18:32:36.870: src FE80::A8BB:CCFF:FE01:F600 *Apr 17 18:32:36.870: dst FE80::A8BB:CCFF:FE01:F500 (Ethernet0/0) *Apr 17 18:32:36.870: type REPLY(7), xid 14259361 *Apr 17 18:32:36.870: option SERVERID(2), len 10 *Apr 17 18:32:36.870: 00030001AABBCC01F600 *Apr 17 18:32:36.870: option CLIENTID(1), len 10 *Apr 17 18:32:36.870: 00030001AABBCC01F500 *Apr 17 18:32:36.870: option DNS-SERVERS(23), len 16 *Apr 17 18:32:36.870: 2001:DB8:1000::1 *Apr 17 18:32:36.870: option DOMAIN-LIST(24), len 11 *Apr 17 18:32:36.870: cisco.com
... View more
James, When you say weirdness, how is it manifesting at an application level? It looks like you're primarily using video streaming applications. Do these packet-drop syslog coincide with jitter/slowing loading/etc? Also, during this time, is there an active connection for this traffic? You can view the output of: show policy-map type inspect zone-pair sessions This shows all the active connection on the ZBFW. Unfortunately, ZBFW doesn't document all its drop reasons very well. As a result, we should start with the basics to identify the cause of the syslog. Regards, Rama
... View more
Shijo, There is no limitation on the ASA itself with using a dynamic IP address and supporting Remote Access VPN. The difficulty comes in with letting all the users know what IP address to which to connect. As noted by Andrew Prince above, Dynamic DNS may be the best option to resolve your issue. Regards, Rama
... View more
glgersc, I want to start off by stating, that the questions you pose are really well thought out and wonderfully challenging. The hard part here is that it looks like we're trying to drive towards best practices which can be a difficult and elusive subject. Your "four-zone" solution is a solution we see a lot in VPN deployments. See the following documentation: http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5708/ps5710/ps1018/prod_white_paper0900aecd8062a909.html What you see there is that "decrypted VPN traffic" falls into its own "VPN" zone. As a result, encapped VPN traffic traverses the outside-to-self zone while the decapped real traffic traverses the VPN-to-inside zone. Essentially, that is what you are doing, but instead of referencing VPN traffic we're talking about IPv6 traffic. Which changes the game a bit because the IPv6 traffic is being initiated from internal dual stacked hosts, whereas VPN traffic is coming from remote users. From my perspective, that means that the VPN traffic would possibly have more "filtering" and "restrictions" on it than the IPv6 traffic which is truly (and geographically) coming from the inside. At my home I'm running a Ipv6ip tunnel to a tunnel broker. We don't run any ZBFW on our IPv6 router, but if we did we'd probably be inclined to put the Tunnel interface on the "inside" zone. Essentially, all inside traffic and IPv6 tunnel bound traffic would not have to traverse a zone pair. The reason we would opt for this is because, in my mind, the IPv6 traffic and the "inside" traffic are one in the same. Just different protocols. I think our Ipv6ip tunnel uses IP protocol 41 in both directions, but clearly your testing as concluded otherwise. As a result, we may hit the same issue as you, where the "outside-to-self" and "self-to-outside" zone would see different traffic in each direction. Please let me know your thoughts on this matter. I haven't had a chance to test this out on my IPv6 tunnel router at home, but I hope to have some ZBFW testing done by next week. Regards, Rama
... View more
Jan, Unfortunately, the only way to clear these counters is to reload the FWSM. The counters are reset to zero on boot. There is no other output that can be run to reset these counters to zero. As a note, the NP stats counters can be reset to zero using "clear np all stats". Regards, Rama
... View more
Purpose of this document Smart Call Home is a feature introduced into the ASA firewalls in version 8.2 that allows for periodic monitoring of the firewall device. This document how to leverage this feature to monitor and troubleshoot network issues. Configuring Smart Call Home To configure Smart Call Home, use the following document: https://supportforums.cisco.com/docs/DOC-12801 Common Uses Configuration Backups Gathering configuration backups periodically is useful in case of device replacement or change control. It helps to identify the last working configuration and archives changes made to the firewall. hostname (config)# service call-home hostname (config)# call-home hostname (cfg-call-home)# contact-email-addr firstname.lastname@example.org hostname (cfg-call-home)# mail-server 192.168.1.100 priority 1 hostname (cfg-call-home)# profile ConfigBackup-1 hostname (cfg-call-home-profile)# destination address email email@example.com hostname (cfg-call-home-profile)# destination transport-method email hostname (cfg-call-home-profile)# subscribe-to-alert-group configuration export full periodic monthly The configuration alert-group (as configured above with the export full, non-default option) includes the commands: - show call-home registered-module status | exclude disabled - show running-config - show startup-config - show access-list | include elements In the above example, the firewall will send these outputs to the email address firstname.lastname@example.org monthly. Network Profiling using Snapshots Network profiling is an important process that allows a network administrator to understand current utilization levels of their network. This is important for monitoring current load, feature usage as well as anamolous behaviour. Having good archived historical network profile data helps to troubleshoot the most complex networking problems such as oversubscription and load issues. Additionally, it provides an early warning system to help net admins to understand when their network is reaching capacity. Snapshots are a Smart Call Home feature that allows the user to customize which commands are sent by the ASA. In the below example, the network administrator is interested in understanding the network utilization of their ASA. As a result, the snapshot profile is built to gather outputs relevant to network utilization: hostname (config)# service call-home hostname (config)# call-home hostname (cfg-call-home)# contact-email-addr email@example.com hostname (cfg-call-home)# mail-server 192.168.1.100 priority 1 hostname (cfg-call-home)# alert-group-config snapshot hostname (cfg-call-home-snapshot)# add-command "show traffic" hostname (cfg-call-home-snapshot)# add-command "show interface detail" hostname (cfg-call-home-snapshot)# add-command "show perfmon" hostname (cfg-call-home-snapshot)# add-command "show conn count" hostname (cfg-call-home-snapshot)# add-command "show xlate count" hostname (cfg-call-home-snapshot)# add-command "show service-policy" hostname (cfg-call-home)# profile NetworkProfiling-1 hostname (cfg-call-home-profile)# destination address email firstname.lastname@example.org hostname (cfg-call-home-profile)# destination transport-method email hostname (cfg-call-home-profile)# subscribe-to-alert-group snapshot periodic interval 120 These outputs will be gathered periodically every 120 minutes as emails, which the network adminstrator can then parse and format into graphs or charts. In the above example, the network administrator will be able to graph the current traffic rate through all the interfaces, the current rate of connection as well as the current connection and xlate counts. Additionally, the net admin was interested in knowing how much traffic through the firewall was being sent through the service-policy, which is the last output included in the snapshot. Device Oversubscription Issues Networking profiling is very useful to monitor the current status of a network. But, when there is a network load related issue, snapshots can be used to more efficiently isolate the problem. When a network adminsitrator suspects that the firewall is reaching a load limit, they can leverage Smart Call Home and the snapshot feature to provide very specific data that helps to isolate the oversubscription related issues. For more information regarding this specific issue, please refer to the following document: https://supportforums.cisco.com/docs/DOC-12439 Specific to Smart Call Home, the following snapshot profile will help to gather the necessary data: hostname (config)# service call-home hostname (config)# call-home hostname (cfg-call-home)# contact-email-addr email@example.com hostname (cfg-call-home)# mail-server 192.168.1.100 priority 1 hostname (cfg-call-home)# alert-group-config snapshot hostname (cfg-call-home-snapshot)# add-command "show cpu detailed" hostname (cfg-call-home-snapshot)# add-command "show processes cpu-usage" hostname (cfg-call-home-snapshot)# add-command "show processes cpu-hog" hostname (cfg-call-home-snapshot)# add-command "show interface detail | i line|overrun|no buffer" hostname (cfg-call-home-snapshot)# add-command "show memory detail" hostname (cfg-call-home)# profile Oversubscription-1 hostname (cfg-call-home-profile)# destination address email firstname.lastname@example.org hostname (cfg-call-home-profile)# destination transport-method email hostname (cfg-call-home-profile)# subscribe-to-alert-group snapshot periodic interval 120 By using the document linked above, the net admin understands that oversubscription can be primarily caused by cpu utilization and network load. Since the net admin is already gathering network profile information, the only additional information required is with regards to device level utilization. The snapshot profile above gathers information regarding cpu utilization, interface oversubscription and memory levels. The Smart Call Home information gathered in both the network profiling and device oversubscription can be graphed to better understand whether the oversubscription behaviour is periodic or consistent. A consistent problem may indicate a network attack or infected host, while a periodic behaviour tends to be caused by network load. VPN Utilization Since VPN features are licensed on the ASA platforms, it is important for a network administrator to understand utilization levels of the VPN deployment. This will help to forecast VPN expansion requirements to accomodate network growth. Below is a profile that provides the necessary VPN information: hostname (config)# service call-home hostname (config)# call-home hostname (cfg-call-home)# contact-email-addr email@example.com hostname (cfg-call-home)# mail-server 192.168.1.100 priority 1 hostname (cfg-call-home)# alert-group-config snapshot hostname (cfg-call-home-snapshot)# add-command "show vpn-sessiondb" hostname (cfg-call-home-snapshot)# add-command "show crypto ipsec sa" hostname (cfg-call-home-snapshot)# add-command "show crypto isakmp sa" hostname (cfg-call-home-snapshot)# add-command "show webvpn statistics" hostname (cfg-call-home-snapshot)# add-command "show crypto protocol statistics all" hostname (cfg-call-home)# profile VPNUtilization-1 hostname (cfg-call-home-profile)# destination address email firstname.lastname@example.org hostname (cfg-call-home-profile)# destination transport-method email hostname (cfg-call-home-profile)# subscribe-to-alert-group snapshot periodic interval 120
... View more
Authentication Proxy Overview Authentication proxy is a feature on the ASA platforms that allows a network administrator to force users to authenticate to the ASA before users are allowed access through the device. The ASA can authenticate these users using Radius, TACACS or local user databases. Authentication proxy is used to control access through the ASA in a more granular and user based fashion. Authentication Proxy Configuration The following configuration lines will set up authentication proxy for HTTP connections: hostname(config)# aaa-server TACACS protocol tacacs+ hostname(config)# aaa-server TACACS (inside) host 10.0.0.100 hostname(config-aaa-server-host)# key CISCO hostname(config)# access-list AUTH_ACL extended permit tcp any any eq 80 hostname(config)# aaa authentication match AUTH_ACL inside TACACS This configuration will have the ASA intercept all HTTP requests made outbound by inside users. Specifically, if users use Firefox, they will receive a popup window like below: Users of Internet Explorer will see the following window: The network requirements may require HTTPS authenication for web based authentication proxy. If that is the case, run the following command: hostname(config)# aaa authentication secure-http-client Using the above command, the authentication page will now look like: Authentication Proxy Troubleshooting Commands To check the current uauth database, use the show uauth command. hostname# show uauth Current Most Seen Authenticated Users 1 1 Authen In Progress 0 2 user 'cisco' at 10.1.1.2, authenticated absolute timeout: 0:05:00 inactivity timeout: 0:00:00 Additionally, the command test aaa authentication will test a user against the AAA server. hostname# test aaa-server authentication RADIUS username cisco password cisco Server IP Address or name: 10.1.1.1 INFO: Attempting Authentication test to IP address <10.1.1.1> (timeout: 12 seconds) ERROR: Authentication Rejected: AAA failure Integration with ACS Radius Authentication The ASA and Radius can work together using downloadable ACLs and authentication proxy to create per-user customizable access profiles. On the ASA, the following configuration is required: hostname(config)# aaa-server RADIUS protocol radius hostname(config)# aaa-server RADIUS (inside) host 10.0.0.100 hostname(config-aaa-server-host)# key CISCO hostname(config)# access-list AUTH_ACL extended permit tcp any any eq 80 hostname(config)# aaa authentication match AUTH_ACL inside TACACS hostname(config)# virtual http 10.0.0.200 hostname(config)# access-list INSIDE_INBOUND extended permit tcp any host 10.0.0.200 eq 80 hostname(config)# access-group INSIDE_INBOUND in interface inside per-user-override In this condition, the user will be required to access http://10.0.0.200 where the ASA will prompt the user for authentication. Once the user enters the authentication username and password, the ASA will forward this information to the Radius server. The Radius server is configured to return a downloadable ACL via the class 26 vendor specific attribute. The ASA will download this ACL and install it into its database specific to this user. The outputs from a successful authentication are included below: hostname(config)# show uauth Current Most Seen Authenticated Users 1 1 Authen In Progress 0 2 user 'cisco' at 10.1.1.2, authenticated access-list #ACSACL#-IP-cisco-4d30a35b (*) absolute timeout: 0:05:00 inactivity timeout: 0:00:00 The associate ACL lines are included below: access-list #ACSACL#-IP-cisco-4d30a35b; 3 elements; name hash: 0x34134156 (dynamic) access-list #ACSACL#-IP-cisco-4d30a35b line 1 extended permit tcp any any eq www (hitcnt=1) 0x3f7a6230 access-list #ACSACL#-IP-cisco-4d30a35b line 2 extended permit tcp any any eq netbios-ssn (hitcnt=0) 0xbdefa208 access-list #ACSACL#-IP-cisco-4d30a35b line 3 extended permit icmp any any (hitcnt=0) 0x25be1e4f In the above example, the users cannot get out to the internet before authenticating via authentication proxy. After authenticating, the user is able to access all network resources using HTTP, Netbios and ICMP. The above example can be used when trying to mitigate the spread of a worm that uses TCP port 139 as its communication medium. As a result, the network policy dictates that all computers must manually authenticate before they can obtain network access.
... View more
The sysopt np completion-unit is outlined in more detail on these two following links: https://supportforums.cisco.com/docs/DOC-12668#TCP_Reordering http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/command/reference/s8.html#wp2759328 Those should answer your questions in greater detail.
... View more
Khalid, There is no way to view the exact traffic flow that crossed the NP thresholds. When addressing an issue with NP oversubscription, first identify which vlan is seeing the most traffic. After identfiying this vlan, captures but be obtained from the 6500 to see all the traffic on this vlan hitting the FWSM. Using these captures we'd be able to better understand the traffic profile that is causing your NP threshold issue. Currently, there is no way to poll the FWSM via SNMP to get the output of "show np blocks". At the moment, the only way to receive this information is to use a Perl or Expect script to log into the FWSM and gather this output in text format. We have an enhancement request filed to integrate the NP blocks output into an SNMP OID: CSCso68256 Regards, Rama
... View more
This guide is used as a guide to configuring zone based firewall. Pre-requisites: 1. A zones must already be designed and mapped to a router topology 2. Traffic that must pass between zones must already be identified and understood In our example, we'll be using the following diagram: Here is the chart we'll be using to identify inter-zone traffic: Destination Source in dmz out in x http, imap http, ftp dmz - x smtp out - http, smtp x Once we have designed the ZBFW using the above criteria, it is time to apply this configuration. Here are the steps we will execute: 1. Create "match access-list" and "protocol class-map" to identified traffic and apply protocol specific inspection respectively. 2. Create "traffic class-map" to apply "match access-list" and "protocol class-map". 3. Create "traffic policy-map" to inspect, drop or pass the traffic identified by the "traffic class-map". 4. Create "traffic service-policy" and apply "traffic policy-map" created in #3. Step 1: Create "match access-list" and "protocol class-map" Create access-list that will identify traffic to be matched when traversing across the zones. ip access-list extended IN_TO_OUT_ACL 10 permit ip 10.1.1.0 0.0.0.255 any ip access-list extended INT_TO_DMZ_ACL 10 permit ip 10.1.1.0 0.0.0.255 192.168.1.0 0.0.0.255 ip access-list extended DMZ_TO_OUT_ACL 10 permit ip 192.168.1.0 0.0.0.255 any ip access-list extended OUT_TO_DMZ_ACL 10 permit ip any 192.168.1.0 0.0.0.255 class-map type inspect match-any IN_TO_OUT_PROTOCOLS match protocol http match protocol ftp class-map type inspect match-any IN_TO_DMZ_PROTOCOLS match protocol http match protocol imap class-map type inspect match-any DMZ_TO_OUT_PROTOCOLS match protocol smtp class-map type inspect match-any OUT_TO_DMZ_PROTOCOLS match protocol http match protocol smtp Step 2: Create "traffic class-map" Create a class-map to combine the access-list and class-map we identified in step 1. class-map type inspect match-all IN_TO_OUT_CMAP match access-group name IN_TO_OUT_ACL match class-map IN_TO_OUT_PROTOCOLS class-map type inspect match-all IN_TO_DMZ_CMAP match access-group name IN_TO_DMZ_ACL match class-map IN_TO_DMZ_PROTOCOLS class-map type inspect match-all DMZ_TO_OUT_CMAP match access-group name DMZ_TO_OUT_ACL match class-map DMZ_TO_OUT_PROTOCOLS class-map type inspect match-all OUT_TO_DMZ_CMAP match access-group name OUT_TO_DMZ_ACL match class-map OUT_TO_DMZ_PROTOCOLS Step 3: Create "traffic policy-map" Now that we've created the four necessary class-map that identify the traffic, we'll need to apply the action to them. policy-map type inspect IN_TO_OUT_PMAP class IN_TO_OUT_CMAP inspect policy-map type inspect IN_TO_DMZ_PMAP class IN_TO_OUT_CMAP inspect policy-map type inspect DMZ_TO_OUT_PMAP class DMZ_TO_OUT_CMAP inspect policy-map type inspect OUT_TO_DMZ_PMAP class OUT_TO_DMZ_CMAP inspect Step 4: Apply the "traffic service-policy" The last step is to apply the policy-map to each zone-pair, effectively activating the zone based firewall. zone-pair security IN_TO_OUT_ZP source INSIDE destination OUTSIDE service-policy type inspect IN_TO_OUT_PMAP zone-pair security IN_TO_DMZ_ZP source INSIDE destination DMZ service-policy type inspect IN_TO_DMZ_PMAP zone-pair security DMZ_TO_OUT_ZP source DMZ destination OUTSIDE service-policy type inspect DMZ_TO_OUT_PMAP zone-pair security OUT_TO_DMZ_ZP source OUTSIDE destination DMZ service-policy type inspect OUT_TO_DMZ_PMAP Please note that the zones must be predefined or step 4 will fail. If not already done, please create the zones using the following commands zone security INSIDE zone security DMZ zone security OUTSIDE Final Steps Now that the entire ZBFW policy has been built, the last steps are to associate each interface with a zone-member. interface FastEthernet0/0 zone-member INSIDE interface FastEthernet0/1 zone-member DMZ interface FastEthernet0/2 zone-member OUTSIDE
... View more
This guide is meant to provide insight into troubleshooting ACL resource partitions. Multicontext Mode and Resource Partitions An FWSM configured for multiple context mode will be subject to a feature called the resource acl-partition. ACL partitions are used to allocate ACL limitions on contexts which assist in virtualization of the FWSM. A function of the ACL partition is to apply limitations on the number of access-lists used by each FWSM context. ACL Counter Outputs There are easy ways to examine the current utilization of the FWSM with regards to ACL counts. The first output is show resource acl-partition. This output will indicate the number of ACL resource partitions. The maximum number of ACL resource partitions is 12. If a configuration has more than 12 contexts, then some contexts will share an ACL resource partition. In the below example, there are 4 ACL resource partitions. Notice that the count starts from 0. Two of the partitions are utilized and two partitions are not used. The FWSM in question has three contexts: admin, context1 and context2. Currently, this FWSM is configured so that context1 and admin are sharing the first partition space (Partition #0) and context2 is using the second partition space (Partition #1). The number of rules field in the output is an aggregate of all ACLs currently present across all contexts allocated to this partition. The following section will outline outputs that allow a more granular examination of these ACLs. In our case, admin and context1 have 61 total rules combined while context2 has 16 total rules. FWSM/pri/actNoFailover# show resource acl-partition Total number of configured partitions = 4 Partition #0 Mode : non-exclusive List of Contexts : admin, context1 Number of contexts : 2(RefCount:2) Number of rules : 61(Max:49971) Partition #1 Mode : non-exclusive List of Contexts : context2 Number of contexts : 1(RefCount:1) Number of rules : 16(Max:49971) Partition #2 Mode : non-exclusive List of Contexts : none Number of contexts : 0(RefCount:0) Number of rules : 0(Max:49971) Partition #3 Mode : non-exclusive List of Contexts : none Number of contexts : 0(RefCount:0) Number of rules : 0(Max:49971) The output of show np 3 acl count <number> allows the users to view the granular ACL usage on a paritular resource partition. Notice that below, the field is referenced as "tree_id". This actually refers to the partition number from above. FWSM/pri/actNoFailover# show np 3 acl count ? <0-11> tree_id In the above example, it is clear that there are 61 ACLs currently in use in partition #0. In the below output, it can be seen that these 61 rules are made up for 48 fixup rules, 3 console rules and 10 ACL rules. The counters in the heading labeled CLS Rule Current Counts shows the current number of ACLs for each field. Below this heading, there is a field labeled CLS Rule MAX Counts. This field addresses the maximum number of ACLs that can be configured in this partition. FWSM/pri/actNoFailover# show np 3 acl count 0 -------------- CLS Rule Current Counts -------------- CLS Filter Rule Count : 0 CLS Fixup Rule Count : 48 CLS Est Ctl Rule Count : 0 CLS AAA Rule Count : 0 CLS Est Data Rule Count : 0 CLS Console Rule Count : 3 CLS Policy NAT Rule Count : 0 CLS ACL Rule Count : 10 CLS ACL Uncommitted Add : 0 CLS ACL Uncommitted Del : 0 ---------------- CLS Rule MAX Counts ---------------- CLS Filter MAX : 1499 CLS Fixup MAX : 3997 CLS Est Ctl Rule MAX : 249 CLS Est Data Rule MAX : 249 CLS AAA Rule MAX : 3497 CLS Console Rule MAX : 999 CLS Policy NAT Rule MAX : 999 CLS ACL Rule MAX : 38482 -------------- CLS Rule Counter Ranges -------------- CLS L7 Cnt Start - End : 1 - 1499 CLS Est Cnt Start - End : 1500 - 1748 CLS AAA Cnt Start - End : 1749 - 5245 CLS CP Cnt Start - End : 5246 - 6244 CLS Policy Cnt Start - End : 6245 - 7243 CLS ACL Cnt Start - End : 7244 - 45725 CLS DYN Cnt Start - End : 0 - 0 ----- CLS Rule Memory Management (Global) ---- CLS Rules Allocated : 129 CLS Rules Deleted : 52 CLS Rules Flagged : 0 CLS Rules Reclaimed : 0 CLS Rules No Memory : 0 ----- CLS Extension Memory Management (Global) ---- CLS Leaf Extensions Alloced : 14 CLS Leaf Extensions Updated : 2 CLS leaf Extensions Deleted : 4 MPC Leaf Extensions Alloced : 0 MPC Leaf Extensions Deleted : 0 MPC Leaf Ext Alloc Errors : 0 MPC Leaf Ext Free Errors : 0 ----------------------------------------------------- Notice that even though the first output indicated a maximum of 49971 ACL rules, it can clearly be seen that the max is actually 38482 access-control ACL rules. ACL Partition Optimization There are some commands that can be used to tweak the ACL partition settings. By default, the number of ACL rules is set to the max. But, the other ACL rules can be altered using the following command: FWSM(config)# resource rule nat <value1> acl <value2> filter <value3> fixup <value4> est <value5> aaa <value6> console <value7> Note that it is very important that the sum of all the rules is less than the maximum listed in the output of 49971. If the sum is more than the limit, the command line will print the following output: ERROR: New total max rules <sum> are more than the allowed total max rules 49971 The above ACL rules affect all partitions as it is a global configuration. The FWSM allows a per-partition ACL rules configuration, as described below: FWSM(config0# resource partition 0 rule nat <value1> acl <value2> filter <value3> fixup <value4> est <value5> aaa <value6> console <value7> size <0 to max> *where max is the number identified in show resource acl-partition Finally, altering the number of partitions may be a solution based on the ACL requirements of the FWSM. The number of ACL partitions can be configured using the command: FWSM(config)# resource acl-partition <0-12> The number configured above will be the number of ACL partitions. The optimized configuration will have the same number of ACL partitions as contexts. An important concept with regards to ACL partitions is the backup partition. When in multiple context mode, the ACL creates a backup partition which is used when changing an ACL. In the above example, there are 4 partitions in the NP3 ACL space. There is also a backup partition: ------------------------ p1-|-p2-|-p3-|-p4-|-BK-| ------------------------ This partition is used when an ACL that belongs a another partition needs to be changed. The backup partition is designed to make ACL changes as transparent as possible. The backup partition has the same size as all the partitions. If the configuration were changed to only have a single partition, the ACL space still remains the same. As a result, the below diagram shows the ACL partition division: --------------------------- ----p1------|-----BK------| --------------------------- The general rule: - increased number of partitions better utilizes the ACL space but reduces the number of ACLs per partition - decreased number of partitions worsens utilization of the ACL space but increases the number of ACLs per partition This is why it is recommended to only have as many ACL partitions as the number of contexts. Caution: When failover is used, both FWSMs need to be reloaded at the same time after making partition changes. Reloading both FWSMs causes an outage with no possibility for a zero-downtime reload. At no time should two FWSMs with a mismatched number of partitions or rule limits synchronize over failover. *When you replace a hardware failure FWSM, please make sure you re-customized acl partition before config synchornization. References: FWSM 3.1: http://www.cisco.com/en/US/docs/security/fwsm/fwsm31/command/reference/fwsm_ref.html FWSM 3.2: http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/command/reference/fwsm_ref.html FWSM 4.0: http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/command/reference/qr.html#wp1622931 FWSM 4.1: http://www.cisco.com/en/US/docs/security/fwsm/fwsm41/command/reference/qr.html#wp1622931
... View more
Optimizing Traffic Flow through a 4GE SSM Currenlty, there is a document available on Cisco.com that outlines how to properly design your ASA to optimize traffic flow when using a 4GE SSM: https://www.cisco.com/en/US/docs/security/asa/asa72/getting_started/asa5550/quick/guide/thru_n.html To make the correct choice when deciding if a new link added to the firewall will plug into an onboard port versus an offboard port (on the 4GE SSM), one must understand how much traffic each interface is expected to process. Once the two interfaces with the highest data rate have been determined, one link should be connected to an onboard ASA port and the other on a 4GE SSM port. This will optimize the traffic by spreading the traffic processing load across both internal buses. Design Considerations The hardware design recommendation outlined in the above guide is best used with the two highest utilization interfaces on the ASA. Then putting one onboard and one on the 4GE SSM is appropriate, as it maximizes the utilization. There are certain conditions where your network will require more than two high utilization interfaces. Before allocating this third interface, an understanding of the functionality of the 4GE SSM is required. Since the ASA process switches all traffic, any packet that arrives to a port on the 4GE SSM must be passed to the CPU on the ASA itself. To get traffic from the 4GE SSM port to the CPU, the traffic must traverse the internal GigabitEthernet port. This internal GigabitEthernet port may pose a potential bottle neck. To avoid this problem, we would want to allocate any additional high utilization ports to the onboard NICs. For example, lets say a design requires two interfaces: inside and outside. These interfaces would be placed with the inside onboard (GigabitEthernet0/0) and outside on the 4GE SSM (GigabitEthernet1/0). Now the network requires a DMZ interface, which will pass just as much traffic as the inside interface. It would be best to place this DMZ interface on the onboard NIC (Gigabit0/1). The DMZ interface should be placed onboard to avoid hitting a bandwidth limitation on the single internal connection. Being aware of this hardware design will avoid unexpected performance issues. 4GE SSM Card hardware outline Each port in the 4GE SSM card is a GigabitEthernet link. But aggregated across the backplane is a single GigabitEthernet connection to the ASA. These interfaces can be viewed by issuing the command "show interface detail": Interface Internal-Data0/0 "", is up, line protocol is up Hardware is i82547GI rev00, BW 1000 Mbps, DLY 10 usec (Full-duplex), (1000 Mbps) MAC address 0000.0001.0002, MTU not set IP address unassigned 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 L2 decode drops, 0 demux drops 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 late collisions, 0 deferred 0 input reset drops, 0 output reset drops input queue (curr/max packets): hardware (0/0) software (0/0) output queue (curr/max packets): hardware (0/0) software (0/0) Control Point Interface States: Interface number is 7 Interface config status is active Interface state is active Interface Internal-Data1/0 "", is up, line protocol is up Hardware is VCS7380 rev01, BW 1000 Mbps, DLY 10 usec (Full-duplex), (1000 Mbps) Media-type configured as RJ45 connector MAC address 0000.0003.0002, MTU not set IP address unassigned 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 late collisions, 0 deferred 0 input reset drops, 0 output reset drops input queue (curr/max packets): hardware (0/0) software (0/0) output queue (curr/max packets): hardware (0/0) software (0/0) Control Point Interface States: Interface number is 12 Interface config status is active Interface state is active Internal-Data0/0 is the interface for the ASA itself while Internal-Data1/0 is the link for the 4GE SSM. Diagnosing 4GE SSM Issues In some cases, over-subscription of the 4GE-SSM card might cause the ASA to drop packets, which might result in connectivity issues through the ASA. Symptoms of oversubscription are packet drops resulting in retransmissions, and latency. The easiest way to see oversubscription problems on the 4GE SSM card is to look at the output of show interface detail. In this output, you can view the fields labeled overruns and no buffers. More information can be found in the following document: https://supportforums.cisco.com/docs/DOC-12439 To diagnose a possible issue with the 4GE being oversubscribed, check to see if the overruns are occurring exclusively on the 4GE ports. Also, sometimes you may see overruns on the Internal-Data0/0 interface. If either of these conditions are hit, you will need to reexamine the amount of traffic passed through the 4GE SSM ports. As stated above, moving the oversubscribed interfaces from the 4GE SSM card to an onboard NIC is a possible resolution to oversubscription on the 4GE SSM. Known Bugs Regarding 4GE SSM CSCtd55121 - 4GE-SSM will not transmit all fragments (Resolved in 8.2.3 and 8.3.2) CSCte79575 - ASA: TFW sh fail output shows Normal(waiting) when Sec unit is act (Resolved in 7.2.5 and 8.2.3)
... View more
Cisco Security Manager is a network management tool that allows you to manage and configure firewalls and IPS devices in your network.
When troubleshooting CSM set ups, it may be necessary to gather a database backup. The database backup includes all your device configurations, policy objects as well as your CSM configuration.
Below are the steps to perform the database backup.
1. In the CiscoWorks Homepage, select Common Services > Server > Admin > Backup.
2. At this point, you can generate the backup. A backup request will cause all process to be brought down. During this time the server will not be accessible. The processes will restart automatically once the backup is complete.
3. The gathered backup will show up as a folder labeled with the number "0". You will need to ZIP this folder to make sure no files are lost when uploading it to a TAC case.
Alternatively, you can use command line to gather the backup:
C:\>NMSROOT/bin/backup.pl BackupDirectory [LogFile] [Num_Generations]
BackupDirectory — Directory that you want to be your Backup directory.
LogFile — Log file name.
Num_Generations — Maximum backup generations to be kept in the backup directory.
I would like to know why my backup is not running in the scheduled time. If I chose to run "immediatly" it runs without problems and a folder called "0" is created in the D:\Backup_CSM.Scheduled backup does not run and I see no info in the logs and I receive no emails. How to debug it?
I ran into a similar problem with CSM 4.4 where the problem was the backup process would get an empty space in front of the time and then not run.
A fix for this problem was issued in CSM 4.4SP1 and CSM 4.5.
If you are running CSM 4.4 a workaround would be to schedule the backup between 10.00am & 11.59am or 10.00pm and 11.59pm.
Bug is available in the bug toolkit with bug id CSCug45741
... View more
Golly Wog, SYN cookies will not affect CPU. If you refer back to the doc: https://supportforums.cisco.com/docs/DOC-12713 You'll see that TCP intercept is performed at NP3 while SYN cookies are performed at NP1 and NP2. That means that the TCP intercept feature will be initiated by NP3, and when the connection is validated the two sides of the connection are put together on NP3. Since none of the traffic is even seen by the Control Point, there should be minimal CPU impact due to this feature.
... View more
The FWSM is capable of using TCP intercept to defend against certain types of SYN floods. This feature was introduced way back during the days of FWSM version 1.1. What is a SYN flood? A SYN flood is a form of denial of service (DOS) attack in which an attacker sends a succession of SYN requests to a targeted victim. After the victim responds with a SYN+ACK, the attacker never responds with an ACK to this connection request. As a result, this connection is considered "embryonic" (aka, half-open) since it is never completed. It remains as an open socket on the victim. If enough of these sockets are opened, the victim will no longer be able to establish new connections. Since firewalls are stateful devices, they track the state of connections. As a result, they will also see the connection as embryonic. Luckily, some firewalls have certain attack mitigation features that can limit the number of SYN packets on a per client bases. Therefore, protecting the internal servers from this type of behaviour. What is TCP intercept and SYN cookies? TCP intercept is a feature on the FWSM where the firewall will intercept inbound TCP connection attempts. Its proxies the SYN+ACK on behalf of the internal server in order to validate the legitimacy of the connection initiator. SYN cookies are the proxied SYN+ACK packets by the firewall. SYN cookies are a special feature that prevents a server from dropping packets after its SYN queue is full. The server responds with a SYN+ACK and throws away the SYN packet. If a subsequent ACK is returned from the client, the entire connection is then rebuilt from that ACK. In the case of the FWSM, it proxies the responisiblities of the server. Configuring TCP intercept and SYN cookies on the FWSM TCP intercept can only be configured on the FWSM through a translation configuration. Below is an example where the connection limit is set to 100 and the embryonic connection limit has been set to 50 for the host at 10.1.1.1. static (inside,outside) 10.1.1.1 10.1.1.1 netmask 255.255.255.255 tcp 100 50 If a subnet is used instead of a host in the above static configuration, the TCP per connection limits are applied to each host in the subnet. How the FWSM performs TCP intercept and SYN cookies The FWSM must hit the embryonic connection limit before TCP intercept is engaged. Using the above configuration, the FWSM must see 50 embryonic connections to a specific host located at 10.1.1.1 before TCP intercept is engaged. Once TCP intercept is enabled, you will see the counter labeled "SYN_COOKIE: Total number of Syn Cookie Entries inserted by NP3" increase. This is a counter that shows that NP3 has informed NP1/NP2 to engage TCP intercept and use SYN cookies to prevent a possible attack. This counter increases once we see the 51st SYN packet. Every time NP1/NP2 intercept a TCP connection attempt and respond with a SYN+ACK (ie. a SYN cookie), we will increment the counter labeled "SYN_COOKIE: Total number of SYNs intercepted". SYN cookies will be engaged as long as the embryonic limit is exceed for the host. The current embryonic state can be viewed using the output of "show local-host 10.1.1.1". FWSM/context1/pri/act(config)# sho local-host 10.1.1.1 IPv4 local hosts: local host: <10.1.1.1>, tcp conn(s)/limit = 0/100, embryonic(s)/limit = 50/50 udp conn(s)/limit = 0/0 Xlate(s): Global 10.1.1.1 Local 10.1.1.1 We can see there are there are 0 legitimate TCP connections and 50 embryonic TCP connections to the host located at 10.1.1.1. Interpreting the Output of "show np 1 syn-cookies" Below is the output that shows SYN cookie activity on the FWSM with the feature enabled. FWSM/context1/pri/act(config)# show np 1 syn-cookie ------------------------------------------------------------------------------- Fast Path Syn Cookie Statistics Counters (NP-1) ------------------------------------------------------------------------------- SYN_COOKIE: Syn cookie secret wheel index : 12 SYN_COOKIE: Total number of SYNs intercepted : 20 <-- There were 20 total SYN packets seen since SYN cookies were engaged SYN_COOKIE: Total number of ACKs intercepted : 7 <-- There were 7 ACKs returned to a preexisting SYN+ACK since SYN cookies were engaged SYN_COOKIE: Total number of ACKs dropped after lookup : 0 SYN_COOKIE: Total number of ACKs successfully validated : 7 <-- There were 7 successful ACKs, which means 7 successful legitimateconnections since SYN cookies were triggered SYN_COOKIE: Total number of ACKs Dropped: Secret Expired : 13 <-- There were 13 connections where an ACK was not seen SYN_COOKIE: Total number of ACKs Dropped: Invalid Sequence : 0 SYN_COOKIE: Total number of Syn Cookie Entries inserted by NP3 : 1 <-- The FWSM crossed the embryonic connection limit threshold once SYN_COOKIE: ACKs dropped: Syn cookie ses not yet established : 0 SYN_COOKIE: Leaf allocation failed : 0 SYN_COOKIE: Leaf insertion failed : 0 The above shows that TCP intercept was engaged. We can see in the above that the embryonic connection limit threshold was crossed only once. Since it was crossed, there have been a total of 20 total SYN packets seen to a host who's embryonic limit is exceeded. Of these 20 total SYN packets, 7 were legitimate connections and 13 were connections where an ACK was never seen. You can use these numbers to assess the severity of the attack based on the number of legitimate requests. The configured embryonic connection limit is applied to each NP. So in our example, NP1 and NP2 will allow 50 embryonic connnections each before TCP intercept is engaged. Utilizing "show perfmon" This command can be used to view the rate at which inbound connections are being intercepted by the TCP intercept feature. FWSM/context1/pri/act# sho perfmon Context: context1 PERFMON STATS: Current Average Xlates 0/s 0/s Connections 0/s 0/s TCP Conns 0/s 0/s UDP Conns 0/s 0/s URL Access 0/s 0/s URL Server Req 0/s 0/s TCP Fixup 0/s 0/s HTTP Fixup 0/s 0/s FTP Fixup 0/s 0/s AAA Authen 0/s 0/s AAA Author 0/s 0/s AAA Account 0/s 0/s TCP Intercept 10/s 0/s On the FWSM, there is no way to use "show perfmon" to separate the number of legitimate connections from bogus connections. Use the output of "show np 1 syn-cookies" to compare Additional Notes 1. SYN Cookies will only be effective if NP1 and NP2 are not oversubscribed. 2. SYN Cookies will only be effective if there are already enough active embryonic connections to the victim. If you want TCP intercept to always be engaged, you may need to manually initiate this limit. 3. SYN Cookies do not preserve TCP options.
... View more
Golly Wog, thanks for your kind words. The roles of the NPs is always a question that comes up in TAC cases. To answer your question, this is how the FWSM architecture is designed. Since only NP1 and NP2 have connections to the switch, all inbound packets always hit these two NPs first. Now, depending on what this packet is, it may be forwarded to NP3 and the CP for further processing. When a packet comes into the FWSM and is initially received by NP1 or NP2, we check to see if it matches an existing connection. If it does not match an existing connection and is a SYN packet, we sent it up to NP3 for the "session creation" functionality. This is how we define the phrase "first packet in the flow". This packet is sent to NP3 for the ACL check. Once this TCP SYN packet passes the ACL check, NP3 is responsible for creating the connection and pushing it down to NP1 and NP2. This connection is programmed into the NP1 and NP2 hardware so that all subsequent traffic can match this connection to effectively be "fast switched". Now, every subsequent packet matching this flow will only be passed through NP1 or NP2. A packet matches this flow if it matches the "quintuple" which we define as: source IP, destination IP, source port, destination port, protocol.
... View more
The FWSM architecture is heirachical using four different components: Network Processor 1 (NP1) Network Processor 2 (NP2) Network Processor 3 (NP3) Control Point (CP, PC, CPU) NP1 and NP2 are the front line processors that are responsible for reading and analyzing all traffic initially. NP1 and NP2 are responsible for receiving packets from the switch across the backplane connection. NP1 and NP2 each have three 1 Gigabit connections which connect the FWSM to the backplane of the switch. Adding these all together gives you the 6 Gigabit link as identified in the FWSM datasheets. NP1 and NP2 are responsible for the following functions: - Perform per packet session lookup - Maintain connection table - Perform NAT/PAT - TCP checks - Handle reassembled IP packets (NP2 only) - TCP sequence number shift for "randomization" - Syn Cookies NP3 sits above NP1 and NP2. NP3 is also known as the session manager and performs the following functions: - Processes first packet in a flow - ACL checks - Translation creation - Embryonic/establish connection counts - TCP/UDP checksums - Per-flow offset calculation for TCP sequence number "randomization" - TCP intercept - IP reassembly NP3 talks to NP1 and NP2 as well as the CP. All packets that come to NP3 must first be processed by NP1 and NP2. The Control Point sits above NP3, and similarly only sees traffic that is forwarded via NP3. The Control Point is primarily responsible for performing Layer 7 fixups. For example, traffic that requires embedded NAT or command inspection. The CP is also responsible for handling traffic souced from or destined to the FWSM itself: - Syslogs - AAA (Radius/TACACS+) - URL filtering (Websense/N2H2) - Management traffic (telnet/SSH/HTTPS/SNMP) - Failover communictions - Routing protocols - Most Layer 7 fixups/inspections For further information on NP utilization, please refer to the following document: https://supportforums.cisco.com/docs/DOC-12712
... View more
Problem: Scenario 1: The "show np blocks" outputs measures the state of the three network
processors against three different threshold values. We increment the
appropriate threshold counter each of the 0/1/2 thresholds have been
crossed for the number of free blocks.
FWSM/pri/act# sho np blocks
MAX FREE THRESH_0 THRESH_1 THRESH_2
NP1 (ingress) 32768 32768 0 0 0
(egress) 521206 521206 0 0 0
NP2 (ingress) 32768 32768 0 0 0
(egress) 521206 521206 0 0 0
NP3 (ingress) 32768 32768 0 0 0
(egress) 521206 521206 0 0 0
If the threshold 2 count increases, packets will still be processed and
this is only a warning indicating that we are close to reaching the
If the threshold 1 count increases, then data packets will be dropped,
this includes packets flowing across the firewall and even those sent to
the firewall (IP packets).
If the threshold 0 count increases, then the control packets are
dropped, these control packets are internal packets that are passed
across multiple processors in the system - this is very serious. For further information about the role of each network processor, please reference the following document: https://supportforums.cisco.com/docs/DOC-12713 Scenario 2: Problem: User have a customer who is migrating from a FWSM setup to an ASA5585. They wish to know if Security Context licenses from the FWSM can transfer to the 5585. Solution: No, FWSM and ASA licenses can only be transferred between identical hardware units in the event of an RMA (Return Material Authorization).Migration from one platform to another requires new licenses. Your partner or reseller can advise you as to the possibility of a Technology Migration Program (TMP). Those are sometimes available to give customers a financial incentive (additional discount) to move off of older unsupported platforms.
... View more
Below is an image that shows how to install a console cable into the FWSM's console port. The console port is located on the FWSM board itself. Installing the console cable will require a removal of the FWSM from the chassis. After the console cable is installed into the right most console port, push the FWSM back into the chassis. The console cable will squeeze between the blade and the module above it. The gasket will compresss and the console cable should come out the front of the FWSM just above the blade's faceplate. FWSM console information: Speed: 19,200 8 Data bits 1 stop bits No flow control or hardware handshake
... View more