Feedback
Table Of Contents
Setting up a Single-Chassis Configuration
Setting Up a Dual-Chassis Configuration
Receiving Requests and Sending Syslog Traps
Compiling Cisco Syslog MIB Files
Using the Firewall and Memory Pool MIBs
Configuring OSPF Routing Support
Configuring OSPF Interface Parameters
Configuring OSPF Area Parameters
Configuring Route Summarization Between OSPF Areas
Configuring Route Summarization when Redistributing Routes into OSPF
Changing the OSPF Administrative Distances
Configuring Route Calculation Timers
Logging Neighbors Going Up or Down
LSA Group Pacing with Multiple Timers
Displaying OSPF Update Packet Pacing
Area Border Router Type 3 LSA Filtering
Configuring ABR Type 3 LSA Filtering
Monitoring and Maintaining OSPF
Configuring IPSec for Management
Configuring Firewall Services
This chapter describes how to configure firewall services and contains these sections:
•
Configuring Firewall Failover
•
•
Configuring Firewall Failover
Failover uses two modules that must have identical configurations. You can configure the modules in the following ways:
•
•
Note
This section describes how to configure failover on the Firewall Services Module:
•
•
Setting up a Single-Chassis Configuration
To set up failover on a single chassis, install two firewall modules on the same chassis and assign the same firewall VLAN group to both modules.
Figure 4-1 Failover Single Chassis Configuration
To configure failover in a single chassis, perform this task:
This example shows how to configure failover in a single chassis:
Router(config)# firewall vlan-group 10 10,20,30,40,50Router(config)# firewall module 4 vlan-group 10Router(config)# failover lan interface 1Router(config)# firewall module 6 vlan-group 10Setting Up a Dual-Chassis Configuration
To set up failover across two chassis, install a firewall module in each chassis and assign the same firewall VLAN group to both modules.
To set up a dual-chassis configuration, perform this task:
Figure 4-2 shows a dual-chassis configuration.
Figure 4-2 Dual-Chassis Failover Configuration
This example shows how to configure failover in two chassis:
Router1(config)# firewall vlan-group 10 10,20,30,40Router1(config)# firewall module 4 vlan-group 10Router2(config)# firewall vlan-group 20 10,20,30,40Router2(config)# firewall module 5 vlan-group 20Configuring Failover
For a failover configuration, both firewall modules need to have the same RAM and Flash memory size and be running the same software version.
To configure failover, follow these steps:
Step 1
Note
Step 2
Note
Step 3
Step 4
Step 5
This is the IP address used by the primary module on failover interface
Step 6
Step 7
This is the IP address used by the secondary module on failover interface.
Step 8
This command specifies the IP address used by the standby module on other firewall interfaces. The client hosts are not expected to use this IP address to communicate to the module.
Step 9
Step 10
Note
Step 11
Step 12
Step 13
The primary and the secondary module should have the identical failover configuration, except for the failover LAN module configuration as primary and secondary.
Note
Note
Step 14
Enter the icmp permit 0 0 if_name command to configure the failover interface to allow the ping to go through the firewall.
Step 15
The secondary module should detect the primary module and then switch to standby. The firewall configuration is synchronized from the active module to the standby module.
Warning
Step 16
Step 17
Note
These examples show how to configure failover on a pair of Firewall Services Modules.
The modules are located in two different switches. A dedicated VLAN (vlan 4000) is created for the failover protocol. The following conditions apply:
•
•
•
•
•
•
This example shows how to configure the primary module:
FWSM(config)# show vlan30, 40, 4000FWSM(config)#FWSM(config)# fail lan unit priFWSM(config)# nameif 4000 fover 50FWSM(config)# nameif 30 outside 0FWSM(config)# nameif 40 inside 100FWSM(config)# ip address fover 10.40.40.1 255.255.255.0FWSM(config)# ip address inside 10.2.1.1 255.255.255.0FWSM(config)# ip address outside 10.11.1.2 255.255.255.0FWSM(config)# fail ip address fover 10.40.40.2 255.255.255.0FWSM(config)# fail ip address inside 10.2.1.2 255.255.255.0FWSM(config)# fail ip address outside 10.11.1.3 255.255.255.0FWSM(config)# fail lan int foverFWSM(config)# logg onFWSM(config)# logg monitor 7FWSM(config)# logg con 7111008: User 'enable_15' executed the 'logging con 7' command.FWSM(config)# no logg mess 111008FWSM(config)# no logg mess 111009FWSM(config)# fail105002: (Primary) Enabling failover.FWSM(config)#No Response from Mate. Switching to ActiveYou can begin to configure the standby module at this time:
Sync Process StartSync Process End709004: (Primary) End Configuration Replication (ACT)105003: (Primary) Monitoring on interface 2 waiting105003: (Primary) Monitoring on interface 1 waiting105004: (Primary) Monitoring on interface 2 normal105004: (Primary) Monitoring on interface 1 normal302010: 0 in use, 0 most used302010: 0 in use, 0 most usedThis example shows how to configure the standby or secondary module:
FWSM(config)# fail lan unit secFWSM(config)# nameif 4000 fover 50FWSM(config)# ip address fover 10.40.40.1 255.255.255.0FWSM(config)# fail ip address fover 10.40.40.2 255.255.255.0FWSM(config)# fail lan int foverFWSM(config)# failFWSM(config)# logg onFWSM(config)# logg mon 7FWSM(config)# logg con 7FWSM(config)# 111008: User 'enable_15' executed the 'logging con 7' command.Detected an Active mate. Switching to StandbySwitching to Standby.FWSM(config)#Beginning configuration replication from mate.This unit is in syncing state. 'failover' command will not be effective at this timeEnd configuration replication from mate.709006: (Secondary) End Configuration Replication (STB)Access Rules Download Complete: Memory Utilization < 1%105003: (Secondary) Monitoring on interface 2 waiting105003: (Secondary) Monitoring on interface 1 waiting105004: (Secondary) Monitoring on interface 2 normal105004: (Secondary) Monitoring on interface 1 normalThis example shows how to monitor the failover status on the primary and secondary modules:
Primary module:
FWSM(config)# show failFailover OnFailover unit PrimaryFailover LAN Interface foverReconnect timeout 0:00:00Poll frequency 15 secondsThis host: Primary - ActiveActive time: 29925 (sec)Interface outside (10.11.1.2): NormalInterface inside (10.2.1.1): NormalOther host: Secondary - StandbyActive time: 285 (sec)Interface outside (10.11.1.3): NormalInterface inside (10.2.1.2): NormalStateful Failover Logical Update StatisticsLink : Unconfigured.Secondary module:
FWSM(config)# show failFailover OnFailover unit SecondaryFailover LAN Interface foverReconnect timeout 0:00:00Poll frequency 15 secondsThis host: Secondary - StandbyActive time: 285 (sec)Interface inside (10.2.1.2): NormalInterface outside (10.11.1.3): NormalOther host: Primary - ActiveActive time: 30750 (sec)Interface inside (10.2.1.1): NormalInterface outside (10.11.1.2): NormalStateful Failover Logical Update StatisticsLink : Unconfigured.FWSM(config)#Using SNMP
You can monitor system events on the Firewall Services Module by using SNMP. You can read SNMP events, but information on the module cannot be changed with SNMP.
Use CiscoWorks for Windows or any other SNMP V1, MIB-II-compliant browser to receive SNMP traps and browse a MIB. SNMP traps occur at UDP port 162.
Note
You can browse the System and Interface groups of MIB-II. Browsing an MIB is different from sending traps. Browsing involves doing an snmpget or snmpwalk of the MIB tree from the management station to determine values.
This section describes how to use SNMP on the Firewall Services Module:
•
•
MIB Support
The Firewall Services Module supports the Cisco Firewall MIB and Cisco Memory Pool MIB.
The Firewall Services Module does not support the following in the Cisco Firewall MIB:
•
•
•
•
•
•
SNMP Traps
Traps are unsolicited "comments" from the managed device to the management station for specific events, such as link up, link down, and syslog event generation.
The snmp-server command causes the Firewall Services Module to send SNMP traps so that the module can be monitored remotely. Use the snmp-server host command to specify which systems receive the SNMP traps.
An SNMP object ID (OID) for the module displays in SNMP event traps sent from the module. The Firewall Services Module provides the system OID in SNMP event traps and SNMP mib-2.system.sysObjectID equal to the (1.3.6.1.4.1.9.1.227) original PIX firewall OID.
The module responds to an SNMP request from a management station and then the module sends an event notification trap.
The Firewall Services Module SNMP traps available to an SNMP management station are as follows:
•
–
–
–
•
–
–
–
Receiving Requests and Sending Syslog Traps
To receive requests and send traps from the Firewall Services Module to an SNMP management station, follow these steps:
Step 1
Step 2
You do not need to do further configuration if you only want to send the cold start, link up, and link down generic traps, and you only want to receive SNMP requests.
Step 3
Step 4
logging history debuggingWe recommend that you use the debugging level during initial setup and during testing. After setup, set the level from debugging to a lower value.
The logging history command sets the severity level for SNMP syslog messages.
Step 5
Step 6
Compiling Cisco Syslog MIB Files
To receive security and failover SNMP traps from the Firewall Services Module, compile the Cisco SMI MIB and the Cisco syslog MIB into your SNMP management application. If you do not compile the Cisco syslog MIB into your application, you receive only traps for link up or down, firewall cold start, and authentication failure.
To obtain the Cisco MIB files go to the following URLs:
•
•
•
•
•
•
•
•
To compile Cisco syslog MIB files into your browser using CiscoWorks for Windows (SNMPc), follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Note
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
Step 14
Step 15
Step 16
Step 17
Step 18
Using the Firewall and Memory Pool MIBs
You can poll failover and system status using the Cisco Firewall and Memory Pool MIBs. With the MIB tables, you can view failover status, memory usage, connection count, and system buffer usage.
Viewing Failover Status
The Cisco Firewall MIB cfsHardwareStatusTable indicates whether failover is enabled, and which module is active. The Cisco Firewall MIB indicates failover status in two rows in the cfwHardwareStatusTable object. From the Firewall Services Module command line, you can view failover status using the show failover command. You can access the object table from the following path:
.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoFirewallMIB. ciscoFirewallMIBObjects.cfwSystem.cfwStatus.cfwHardwareStatusTableTable 4-1 lists which objects provide failover information.
Table 4-1 Failover Status Objects
cfwHardwareType (table index)
Hardware
6 (primary module)1
6 (primary module)
7 (secondary module)
cfwHardwareInformation
SnmpAdminString
blank
blank
blank
cfwHardwareStatusValue
HardwareStatus
0 (not used)
active or 9 (active module) or standby or 10 (standby module)
active or 9 (active module) or standby or 10 (standby module)
cfwHardwareStatusDetail
SnmpAdminString
Failover Off
blank
blank
1 The type of returned values are shown in parentheses.
In the HP OpenView Browse MIB application's MIB values window, if failover is disabled, a sample MIB query displays the following information:
cfwHardwareInformation.6:cfwHardwareInformation.7 :cfwHardwareStatusValue.6 :0cfwHardwareStatusValue.7 :0cfwHardwareStatusDetail.6 :Failover OffcfwHardwareStatusDetail.7 :Failover OffIn this list, the table index, cfwHardwareType, appears as either .6 or .7 appended to the end of each of the subsequent objects. The cfwHardwareInformation field is blank, the cfwHardwareStatusValue is 0, and the cfwHardwareStatusDetail contains Failover Off, which indicates the failover status.
When failover is enabled, a sample MIB query displays the following information:
cfwHardwareInformation.6 :cfwHardwareInformation.7 :cfwHardwareStatusValue.6 : activecfwHardwareStatusValue.7 : standbycfwHardwareStatusDetail.6 :cfwHardwareStatusDetail.7 :In this list, only the cfwHardwareStatusValue contains either active or standby values to indicate the status of each module.
Verifying Memory Usage
You can determine how much free memory is available with the Cisco Memory Pool MIB. From the Firewall Services Module command line, use the show memory command to view the memory usage. The following is sample output from the show memory command:
Router(config)# show memory16777216 bytes total, 5595136 bytes freeYou can access the MIB objects from the following path:
.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.ciscoMemoryPoolTableTable 4-2 lists which objects provide memory usage information.
In the HP OpenView Browse MIB application's MIB values window, a sample MIB query displays the following information:
ciscoMemoryPoolName.1 :FWSM system memoryciscoMemoryPoolAlternate.1 :0ciscoMemoryPoolValid.1 :trueciscoMemoryPoolUsed.1 :12312576ciscoMemoryPoolFree.1 :54796288ciscoMemoryPoolLargestFree.1 :0In this list, the table index, ciscoMemoryPoolName, appears as the .1 value at the end of each subsequent object value. The ciscoMemoryPoolUsed object lists the number of bytes currently in use (12312576) and the ciscoMemoryPoolFree object lists the number of bytes currently free (54796288). The other objects always list the values described in Table 4-2.
Viewing the Connection Count
You can view the number of connections in use from the cfwConnectionStatTable in the Cisco Firewall MIB. From the Firewall Services Module command line, enter the show conn command to view the connection count. The following is sample output from the show connection command:
show connection count15 in useThe cfwConnectionStatTable object table can be accessed from the following path:
.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoFirewallMIB.ciscoFirewallMIBObjects.cfwSystem.cfwStatistics.cfwConnectionStatTableTable 4-3 lists which objects provide connection count information.
In the HP OpenView Browse MIB application's MIB values window, a sample MIB query displays the following information:
cfwConnectionStatDescription.40.6 :number of connections currently in use by the entire firewallcfwConnectionStatDescription.40.7 :highest number of connections in use at any one time since system startupcfwConnectionStatCount.40.6 :0cfwConnectionStatCount.40.7 :0cfwConnectionStatValue.40.6 :15cfwConnectionStatValue.40.7 :15In this list, the table index, cfwConnectionStatService, appears as the .40 appended to each subsequent object. The table index, cfwConnectionStatType, appears as either .6 to indicate the number of connections in use or as .7 to indicate the most used number of connections. The cfwConnectionStatValue object lists the connection count. The cfwConnectionStatCount object always returns 0 (zero).
Viewing System Buffer Usage
You can view the system buffer usage from the Cisco Firewall MIB in multiple rows of the cfwBufferStatsTable. The system buffer usage provides an early warning that the Firewall Services Module is reaching its capacity limit. On the command line, enter the show blocks command to view this information. The following is sample output from the show blocks command to demonstrate how cfwBufferStatsTable is populated:
show blocksSIZE MAX LOW CNT4 1600 1600 160080 100 97 97256 80 79 791550 780 402 40465536 8 8 8You can view cfwBufferStatsTable at the following path:
.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoFirewallMIB. ciscoFirewallMIBObjects.cfwSystem.cfwStatistics.cfwBufferStatsTableTable 4-4 lists the objects required to view the system block usage.
Note
In the HP OpenView Browse MIB application's MIB values window a sample MIB query displays the following information:
cfwBufferStatInformation.4.3 :maximum number of allocated 4 byte blockscfwBufferStatInformation.4.5 :fewest 4 byte blocks available since system startupcfwBufferStatInformation.4.8 :current number of available 4 byte blockscfwBufferStatInformation.80.3 :maximum number of allocated 80 byte blockscfwBufferStatInformation.80.5 fewest 80 byte blocks available since system startupcfwBufferStatInformation.80.8 :current number of available 80 byte blockscfwBufferStatInformation.256.3 :maximum number of allocated 256 byte blockscfwBufferStatInformation.256.5 :fewest 256 byte blocks available since system startupcfwBufferStatInformation.256.8 :current number of available 256 byte blockscfwBufferStatInformation.1550.3 :maximum number of allocated 1550 byte blockscfwBufferStatInformation.1550.5 :fewest 1550 byte blocks available since system startupcfwBufferStatInformation.1550.8 :current number of available 1550 byte blockscfwBufferStatValue.4.3: 1600cfwBufferStatValue.4.5: 1600cfwBufferStatValue.4.8: 1600cfwBufferStatValue.80.3: 400cfwBufferStatValue.80.5: 396cfwBufferStatValue.80.8: 400cfwBufferStatValue.256.3: 1000cfwBufferStatValue.256.5: 997cfwBufferStatValue.256.8: 999cfwBufferStatValue.1550.3: 1444cfwBufferStatValue.1550.5: 928cfwBufferStatValue.1550.8: 932In this list, the first table index, cfwBufferStatSize, appears as first number appended to the end of each object, such as .4 or .256. The other table index, cfwBufferStatType, appears as .3, .5, or .8 after the first index. For each block size, the cfwBufferStatInformation object identifies the type of value and the cfwBufferStatValue object identifies the number of bytes for each value.
Using the ipAddrTable
When you use the SNMP ipAddrTable entry, all interfaces must have unique addresses. If interfaces have not been assigned IP addresses, their IP addresses are all set to 127.0.0.1 by default. Duplicate IP addresses cause the SNMP management station to loop indefinitely. If this situation occurs, assign each interface a different address. For example, you can set one address to 127.0.0.1, another to 127.0.0.2, and so on.
SNMP uses a sequence of GetNext operations to traverse the MIB tree. Each GetNext request is based on the result of the previous request. If two consecutive interfaces have the same IP 127.0.0.1 (table index), the GetNext function returns 127.0.0.1, which is correct. However, when SNMP generates the next GetNext request using the same result (127.0.0.1), the request is identical to the previous one, which causes the management station to loop infinitely. For example:
GetNext(ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.127.0.0.1)With SNMP, the MIB table index must be unique for the agent to identify a row from the MIB table. The table index for ip.ipAddrTable is the module interface IP address, which requires that the IP address is unique. The SNMP agent might become confused and may return information of another interface (row), which has the same IP (index).
SNMP Usage Notes
The following notes apply:
•
•
•
•
Configuring OSPF Routing Support
The Firewall Services Module can run two processes of Open Shortest Path First (OSPF) protocol simultaneously. Each of the OSPF processes runs on a different set of interfaces. RIP cannot be enabled on any of the same interfaces as the interfaces that OSPF is enabled on.
Redistribution between the two OSPF processes is supported. Redistribution between RIP and OSPF is not supported in the current release. Static and connected routes configured on OSPF-enabled interfaces on the Firewall Services Module can also be redistributed into the OSPF process. For further information on how to configure OSPF redistribution on the Firewall Services Module, refer to the "Configuring IP Routing Protocol-Independent Features" section in the Cisco IOS IP and IP Routing Configuration Guide.
OSPF is not supported in topologies where the same router or networks are connected to two different interfaces of the Firewall Services Module. OSPF does not handle the address translations configured between interfaces. Care should be taken in the network design to not advertise private addresses into the global networks. Use separate OSPF processes or use filtering mechanisms.
OSPF allows the module to maintain its own routing table. The OSPF protocol provides the following features for the module:
•
•
•
•
•
•
•
•
This section describes how to use OSPF on the Firewall Services Module:
•
•
•
•
•
•
•
•
•
•
•
Enabling OSPF
As with other routing protocols, to enable OSPF you need to create an OSPF routing process, specify the range of IP addresses to be associated with the routing process, and assign area IDs to be associated with that range of IP addresses. To enable OSPF, perform this task, beginning in global configuration mode:
This example shows how to enable OSPF:
FWSM(config)# router ospf 2FWSM(config-router)# network 2.0.0.0 255.0.0.0 area 0Configuring OSPF Interface Parameters
Cisco OSPF implementation allows you to alter some interface-specific OSPF parameters as necessary. You are not required to alter any of these parameters, but some interface parameters must be consistent across all routers in an attached network. You configure the parameters by using the ospf hello-interval, ospf dead-interval, and ospf authentication-key interface configuration commands. Be sure that if you do configure any of these parameters, the configurations for all routers on your network have compatible values.
To specify interface parameters for your network, perform this task in interface configuration mode:
This example shows how to configure the OSPF interfaces:
FWSM(config)# router ospf 2FWSM(config-router)# network 2.0.0.0 255.0.0.0 area 0FWSM(config-router)# interface insideFWSM(config-interface)# ospf cost 20FWSM(config-interface)# ospf retransmit-interval 15FWSM(config-interface)# ospf transmit-delay 10FWSM(config-interface)# ospf priority 20FWSM(config-interface)# ospf hello-interval 10FWSM(config-interface)# ospf dead-interval 40FWSM(config-interface)# ospf authentication-key ciscoFWSM(config-interface)# ospf message-digest-key 1 md5 ciscoFWSM(config-interface)# ospf authentication message-digestFWSM(config-interface)# exitFWSM(config)# show ip ospfRouting Process "ospf 2" with ID 20.1.89.2 and Domain ID 0.0.0.2Supports only single TOS(TOS0) routesSupports opaque LSASPF schedule delay 5 secs, Hold time between two SPFs 10 secsMinimum LSA interval 5 secs. Minimum LSA arrival 1 secsNumber of external LSA 5. Checksum Sum 0x 26da6Number of opaque AS LSA 0. Checksum Sum 0x 0Number of DCbitless external and opaque AS LSA 0Number of DoNotAge external and opaque AS LSA 0Number of areas in this router is 1. 1 normal 0 stub 0 nssaExternal flood list length 0Area BACKBONE(0)Number of interfaces in this area is 1Area has no authenticationSPF algorithm executed 2 timesArea ranges areNumber of LSA 5. Checksum Sum 0x 209a3Number of opaque link LSA 0. Checksum Sum 0x 0Number of DCbitless LSA 0Number of indication LSA 0Number of DoNotAge LSA 0Flood list length 0Configuring OSPF Area Parameters
You can configure several area parameters using Cisco OSPF software. These area parameters (shown in the following task table) include authentication, defining stub areas, and assigning specific costs to the default summary route. Authentication provides password-based protection against unauthorized access to an area.
Stub areas are areas into which information on external routes is not sent. Instead, there is a default external route generated by the area border router, into the stub area for destinations outside the autonomous system. To take advantage of the OSPF stub area support, default routing must be used in the stub area. To further reduce the number of LSAs sent into a stub area, you can configure the no-summary keyword of the area stub router configuration command on the area border router to prevent it from sending summary link advertisement (LSAs type 3) into the stub area.
To specify an area parameter for your network, perform this task in router configuration mode:
This example shows how to configure the OSPF area parameters:
FWSM(config)# router ospf 2FWSM(config-router)# area 0 authenticationFWSM(config-router)# area 0 authentication message-digestFWSM(config-router)# area 17 stubFWSM(config-router)# area 17 default-cost 20Configuring OSPF NSSA
The OSPF implementation of NSSA is similar to OSPF stub area. NSSA does not flood type 5 external LSAs from the core into the area, but it can import autonomous system external routes in a limited way within the area.
NSSA imports type 7 autonomous system external routes within an NSSA area by redistribution. These type 7 LSAs are translated into type 5 LSAs by NSSA area border routers, which are flooded throughout the whole routing domain. Summarization and filtering are supported during the translation.
You can simplify administration if you are an Internet service provider (ISP) or a network administrator that must connect a central site using OSPF to a remote site that is using a different routing protocol using NSSA.
Before the implementation of NSSA, the connection between the corporate site border router and the remote router could not be run as OSPF stub area because routes for the remote site could not be redistributed into stub area, and two routing protocols needed to be maintained. A simple protocol such as RIP was usually run and handled the redistribution. With NSSA, you can extend OSPF to cover the remote connection by defining the area between the corporate router and the remote router as an NSSA.
To specify area parameters as needed to configure OSPF NSSA, perform this task in router configuration mode:
Defines an NSSA area.
This example shows how to define an NSSA area:
FWSM(config-router)# area 17 nssaTo control summarization and filtering of type 7 LSAs into type 5 LSAs, perform this task in router configuration mode on the area border router:
Controls the summarization and filtering during the translation.
This example shows how to control summarization and filtering:
FWSM(config-router)# summary-address 12.1.0.0 255.255.0.0Before you use this feature, consider these guidelines:
•
•
Configuring Route Summarization Between OSPF Areas
Route summarization is the consolidation of advertised addresses. This feature causes a single summary route to be advertised to other areas by an area boundary router. In OSPF, an area boundary router will advertise networks in one area into another area. If the network numbers in an area are assigned in a way such that they are contiguous, you can configure the area boundary router to advertise a summary route that covers all the individual networks within the area that fall into the specified range.
To specify an address range, perform this task in router configuration mode:
.
Specifies an address range for which a single route will be advertised.
This example shows how to configure route summarization between OSPF areas:
FWSM(config-router)# area 17 range 12.1.0.0 255.255.0.0Configuring Route Summarization when Redistributing Routes into OSPF
When routes from other protocols are redistributed into OSPF, each route is advertised individually in an external LSA. However, you can configure the Cisco IOS software to advertise a single route for all the redistributed routes that are covered by a specified network address and mask. This configuration decreases the size of the OSPF link-state database.
To configure the software advertisement on one summary route for all redistributed routes covered by a network address and mask, perform this task in router configuration mode:
This example shows how to configure route summarization when redistributing routes into OSPF:
FWSM(config-router)# summary-address 12.1.0.0 255.255.0.0Creating Virtual Links
With OSPF all areas must be connected to a backbone area. If there is a break in backbone continuity, or the backbone is purposefully partitioned, you can establish a virtual link. The two end points of a virtual link are area border routers. The virtual link must be configured in both routers. The configuration information in each router consists of the other virtual end point (the other area border router) and the nonbackbone area that the two routers have in common (called the transit area). Virtual links cannot be configured through stub areas.
To establish a virtual link, follow this task in router configuration mode:
.
This example shows how to create virtual links:
FWSM(config-router)# area 16 virtual-link 1.1.1.1To display information about virtual links, use the show ip ospf virtual-links EXEC command.
To display the router ID of an OSPF router, use the show ip ospf EXEC command
Generating a Default Route
You can force an autonomous system boundary router to generate a default route into an OSPF routing domain. Whenever you specifically configure redistribution of routes into an OSPF routing domain, the router automatically becomes an autonomous system boundary router. However, an autonomous system boundary router does not by default generate a default route into the OSPF routing domain.
To force the autonomous system boundary router to generate a default route, perform this task in router configuration mode:
This example shows how to generate a default route:
FWSM(config-router)# default-information originate alwaysChanging the OSPF Administrative Distances
An administrative distance is a rating of the trustworthiness of a routing information source, such as an individual router or a group of routers. An administrative distance numerically is an integer from 0 to 255. In general, the higher the value, the lower the trust rating. An administrative distance of 255 means the routing information source cannot be trusted and should be ignored.
OSPF uses three different administrative distances: intra-area, interarea, and external. Routes within an area are intra-area; routes to another area are interarea; and routes from another routing domain learned through redistribution are external. The default distance for each type of route is 110.
To change any of the OSPF distance values, perform this task in router configuration mode:
Changes the OSPF distance values.
This example shows how to change the OSPF administrative distance:
FWSM(config-router)# distance intra-ares 90 inter-area 95 external 100Configuring Route Calculation Timers
You can configure the delay time between when OSPF receives a topology change and when it starts a shortest path first (SPF) calculation. You also can configure the hold time between two consecutive SPF calculations. To configure the route calculation time, perform this task in router configuration mode:
Configures route calculation timers.
This example shows how to configure route calculation timers:
FWSM(config-router)# timers spf 10 120Logging Neighbors Going Up or Down
By default, the system sends a syslog message when an OSPF neighbor goes up or down.
Configure this command if you want to know about OSPF neighbors going up or down without turning on the debug ip ospf adjacency EXEC command. The log-adj-changes router configuration command provides a higher level view of the peer relationship with less output. Configure log-adj-changes detail if you want to see messages for each state change.
Sends syslog message when an OSPF neighbor goes up or down.
If you turned off this feature and want to restore it, perform this task in router configuration mode:
This example shows how to log neighbors:
FWSM(config-router)# log-adj-changes detailChanging the LSA Group Pacing
The OSPF LSA group pacing feature allows the router to group OSPF LSAs and pace the refreshing, check summing, and aging functions. Group pacing results in more efficient use of the router.
The router groups OSPF LSAs and paces these functions so that sudden increases in CPU usage and network resources are avoided. This feature is most beneficial to large OSPF networks.
OSPF LSA group pacing is enabled by default. The default group pacing interval for refreshing, check summing, and aging usually is appropriate, and you need not configure this feature.
Original LSA Behavior
Each OSPF LSA has an age, which indicates whether the LSA is still valid. When the LSA reaches the maximum age (1 hour), it is discarded. During the aging process, the originating router sends a refresh packet every 30 minutes to refresh the LSA. Refresh packets are sent to keep the LSA from expiring, whether there has been a change in the network topology or not. Check summing is performed on all LSAs every 10 minutes. The router keeps track of LSAs it generates and LSAs it receives from other routers. The router refreshes LSAs it generated; it ages the LSAs it received from other routers.
Before the LSA group pacing feature was introduced, the Cisco IOS software would perform refreshing on a single timer, and check summing and aging on another timer. In the case of refreshing, for example, the software would scan the whole database every 30 minutes, refreshing every LSA the router generated, regardless of how old it was.
Figure 4-3 shows all the LSAs being refreshed at the same time. This process wasted CPU resources because only a small portion of the database needed to be refreshed. A large OSPF database (several thousand LSAs) might have thousands of LSAs with different ages. Refreshing on a single timer resulted in the age of all LSAs becoming synchronized, which resulted in increased CPU processing at once. A large number of LSAs might cause a sudden increase of network traffic, consuming a large amount of network resources in a short period of time.
Figure 4-3 OSPF LSAs on a Single Timer Without Group Pacing
LSA Group Pacing with Multiple Timers
This problem is solved by configuring each LSA to have its own timer. Each LSA gets refreshed when it is 30 minutes old, independent of other LSAs, so the CPU is used only when necessary. However, LSAs being refreshed at frequent, random intervals would require many packets for the few refreshed LSAs the router must send out, which would be inefficient use of bandwidth.
Therefore, the router delays the LSA refresh function for an interval of time instead of performing it when the individual timers are reached. The accumulated LSAs constitute a group, which is then refreshed and sent out in one packet or more. The refresh packets are paced as are the check summing and aging. The pacing interval is configurable; it defaults to 4 minutes, which is randomized to further avoid synchronization.
Figure 4-4 shows refresh packets. The first timeline shows individual LSA timers; the second timeline shows individual LSA timers with group pacing.
Figure 4-4 OSPF LSAs on Individual Timers with Group Pacing
The group pacing interval is inversely proportional to the number of LSAs the router is refreshing, check summing, and aging. For example, if you have approximately 10,000 LSAs, decreasing the pacing interval would benefit you. If you have a very small database (40 to 100 LSAs), increasing the pacing interval to 10 to 20 minutes might benefit you slightly.
The default value of pacing between LSA groups is 240 seconds (4 minutes). The range is from 10 seconds to 1800 seconds (30 minutes). To change the LSA group pacing interval, perform this task in router configuration mode:
Changes the group pacing of LSAs.
The following example changes the OSPF pacing between LSA groups to 280 seconds:
FWSM(config-router)# timers lsa-group-pacing 280FWSM(config-router)# interface insideBlocking OSPF LSA Flooding
By default, OSPF floods new LSAs over all interfaces in the same area, except the interface on which the LSA arrives. Some redundancy is desirable, because it ensures substantial flooding. However, too much redundancy can waste bandwidth and might destabilize the network due to excessive link and CPU usage in certain topologies, such as a fully meshed topology.
You can block OSPF flooding of LSAs two ways, depending on the type of networks:
•
•
On broadcast, nonbroadcast, and point-to-point networks, to prevent flooding of OSPF LSAs, perform this task in interface configuration mode:
FWSM(config-if)# ospf database-filter all outBlocks the flooding of OSPF LSA packets to the interface.
On point-to-multipoint networks, to prevent flooding of OSPF LSAs, perform this task in router configuration mode:
Blocks the flooding of OSPF LSA packets to the specified neighbor.
Ignoring MOSPF LSA Packets
Cisco routers do not support LSA type 6 Multicast OSPF (MOSPF). If the routers receive these packets, they generate syslog messages. If the router is receiving many MOSPF packets, you might want to configure the router to ignore the packets, which prevent a large number of syslog messages. To configure the router to ignore these packets, perform this task in router configuration mode:
Prevents the router from generating syslog messages when it receives MOSPF LSA packets.
The following example shows how to prevent flooding of OSPF LSAs to broadcast, nonbroadcast, or point-to-point networks reachable through Ethernet interface 0:
FWSM(config-router)# router ospf 2FWSM(config-router)# ignore lsa mospfFWSM(config-interface)# ospf database-filter all outFWSM(config-interface)# router ospf 2FWSM(config)# show ip ospf flood-list insideInterface inside, Queue length 0The following example shows how to prevent flooding of OSPF LSAs to point-to-multipoint networks to the neighbor at IP address 1.2.3.4:
FWSM(config-router)# router ospf 109FWSM(config-router)# neighbor 1.2.3.4 database-filter all outDisplaying OSPF Update Packet Pacing
The former OSPF implementation for sending update packets was not efficient. Some update packets were getting lost in situations where the link was slow, a neighbor could not receive the updates quickly enough, or the router was out of buffer space. For example, packets might be dropped if either of the following topologies existed:
•
•
OSPF update packets are now automatically paced so they are not sent less than 33 milliseconds apart. Pacing is also added between resends to increase efficiency and minimize lost retransmissions. You also can display the LSAs waiting to be sent out an interface. The benefit of the pacing is that OSPF update and retransmission packets are sent more efficiently.
There are no configuration tasks for this feature; it occurs automatically. To observe OSPF packet pacing by displaying a list of LSAs waiting to be flooded over a specified interface, perform this task in EXEC mode:
Router# show ip ospf flood-list interface-type interface-numberDisplays a list of LSAs waiting to be flooded over an interface.
Area Border Router Type 3 LSA Filtering
The area border router Type 3 LSA filtering feature extends the capability of an area border router that is running the OSPF protocol to filter type 3 LSAs between different OSPF areas. This feature allows only specified prefixes to be sent from one area to another area and restricts all other prefixes. This type of area filtering can be applied out of a specific OSPF area, into a specific OSPF area, or into and out of the same OSPF areas at the same time. This feature is supported by the addition of the area filter-list command.
The OSPF ABR Type 3 LSA filtering feature provides improved control of route distribution between OSPF areas.
Only Type 3 LSAs that originate from an area border router are filtered.
Configuring ABR Type 3 LSA Filtering
To filter interarea routes into a specified area, perform this task beginning in router configuration mode:
To filter interarea routes out of a specified area, perform the following task beginning in router configuration mode:
Monitoring and Maintaining OSPF
You can display specific statistics such as the contents of IP routing tables, caches, and databases. Information provided can be used to determine resource utilization and solve network problems. You can also display information about node reachability and discover the routing path that your device packets are taking through the network.
To display various routing statistics, perform one of these tasks in EXEC mode, as needed:
To restart an OSPF process, perform this task in configuration mode:
FWSM(config)# clear ip ospf pid {process | redistribution | counters [neighbor [neighbor-interface] [neighbor-id]]}Clears redistribution based on the OSPF routing process ID.
Configuring IPSec for Management
Internet Protocol Security (IPSec) provides security for transmission of sensitive information over unprotected networks such as the Internet. IPSec operates at the network layer, protecting and authenticating IP packets between participating IPSec devices (peers), such as Firewall Services Modules.
IPSec provides the following optional network security services. A local security policy determines the use of one or more of these services:
•
•
•
•
Note
IPSec provides controlled tunnels between two peers, such as two Firewall Services Modules. These tunnels are sets of security associations that are established between two remote IPSec peers (modules). You define which packets are considered sensitive and should be sent through these controlled tunnels, and you define the parameters that should be used to protect these sensitive packets by specifying the characteristics of these tunnels. When the IPSec peer sees a sensitive packet, it sets up the appropriate controlled tunnel and sends the packet through the tunnel to the remote peer.
For detailed information about IPSec, refer to the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_60/ipsec/index.htm
The following steps describe a minimal IPSec configuration where the IPSec security associations are established through Internet Key Exchange (IKE).
To configure IPSec with IKE for the module, perform this task:
Step 1
FWSM(config)# access-list access-list-module {deny | permit} ip source source-netmask destination destination-netmaskCreates an access list to define the traffic to protect.
Step 2
FWSM(config)# crypto ipsec transform-set transform-set-module transform1 [transform2, transform3]Configures a transform set that defines how the traffic will be protected. You can configure multiple transform sets, and then specify one or more of these transform sets in a crypto map entry in Step 6.
Step 3
Creates a crypto map entry in IPSec ISAKMP mode.
Step 4
Assigns an access list to a crypto map entry.
Step 5
Specifies the peer to which the IPSec-protected traffic can be forwarded.The security association is set up with the peer having an IP address of 192.168.1.100. Specify multiple peers by repeating this command.
Step 6
Specifies which transform sets are allowed for this crypto map entry. Lists multiple transform sets in order of priority (highest priority first). You can specify up to six transform sets.
Step 7
FWSM(config)# crypto map map-module seq-num set security-association lifetime {seconds seconds | kilobytes kilobytes}(Optional) Specifies a security association lifetime for the crypto map entry, if you want the security associations for this entry to be negotiated using different IPSec security association lifetimes other than the global lifetimes.
Step 8
(Optional) Specifies that IPSec should require perfect forward secrecy (PFS) when requesting new security associations for this crypto map entry, or should require PFS in requests received from the peer.
Step 9
FWSM(config)# crypto dynamic-map dynamic-map-module dynamic-seq-num match address access-list-module(Optional) Assigns an access list to a dynamic crypto map entry, which determines which traffic should be protected and which traffic should not protected.
Step 10
FWSM(config)# crypto dynamic-map dynamic-map-module dynamic-seq-num set peer ip-address(Optional) Specifies the peer to which the IPSec-protected traffic can be forwarded. This is rarely configured in dynamic crypto map entries because dynamic crypto map entries are often used for unknown peers.
Step 11
FWSM(config)# crypto dynamic-map dynamic-map-module dynamic-seq-num set transform-set transform-set-module1, [transform-set-module2, transform-set-module9]Specifies which transform sets are allowed for this dynamic crypto map entry. Lists multiple transform sets in order of priority (highest priority first).
Step 12
FWSM(config)# crypto dynamic-map dynamic-map-module dynamic-seq-num set security-association lifetime {seconds seconds | kilobytes kilobytes}(Optional) Specifies a security association lifetime for the dynamic crypto map entry, if you want the security associations for this entry to be negotiated using different IPSec security association lifetimes other than the global lifetimes.
Step 13
(Optional) Specifies that IPSec should request PFS when requesting new security associations for this dynamic crypto map entry, or should demand PFS in requests received from the peer.
Step 14
Adds the dynamic crypto map set into a static crypto map set. Be sure to set the crypto map entries referencing dynamic maps to be the lowest-priority entries (highest sequence numbers) in a crypto map set.
Step 15
Applies a crypto map set to an interface on which the IPSec traffic will be evaluated.
Step 16
Specifies that IPSec traffic be implicitly trusted (permitted).
In the Firewall Services Module, VPN and IPSec are available only for management purposes. You cannot establish IPSec tunnels across the firewall; any tunnel initiated by a VPN client on another switch should terminate at the Firewall Services Module. The CLI commands you use to configure IPSec for management have not changed from PIX except for those listed in Table A-6 on page A-5. Refer to the PIX documentation for details about configuring IPSec.
