Table Of Contents
Configuring IP Routing and DHCP Services
Configuring Static and Default Routes
Configuring a Static Route
Configuring a Default Route
Configuring OSPF
OSPF Overview
Enabling OSPF
Redistributing Routes Between OSPF Processes
Adding a Route Map
Redistributing Static, Connected, or OSPF Routes to an OSPF Process
Configuring OSPF Interface Parameters
Configuring OSPF Area Parameters
Configuring OSPF NSSA
Configuring Route Summarization Between OSPF Areas
Configuring Route Summarization When Redistributing Routes into OSPF
Generating a Default Route
Configuring Route Calculation Timers
Logging Neighbors Going Up or Down
Displaying OSPF Update Packet Pacing
Monitoring OSPF
Restarting the OSPF Process
Configuring RIP
RIP Overview
Enabling RIP
Dynamic Routing and Failover
Configuring Multicast Routing
Multicast Routing Overview
Enabling Multicast Routing
Configuring IGMP Features
Disabling IGMP on an Interface
Configuring Group Membership
Configuring a Statically Joined Group
Controlling Access to Multicast Groups
Limiting the Number of IGMP States on an Interface
Modifying the Query Interval and Query Timeout
Changing the Query Response Time
Changing the IGMP Version
Configuring Stub Multicast Routing
Configuring a Static Multicast Route
Configuring PIM Features
Disabling PIM on an Interface
Configuring a Static Rendezvous Point Address
Configuring the Designated Router Priority
Filtering PIM Register Messages
Configuring PIM Message Intervals
For More Information about Multicast Routing
Configuring DHCP
Configuring a DHCP Server
Enabling the DHCP Server
Configuring DHCP Options
Using Cisco IP Phones with a DHCP Server
Configuring DHCP Relay Services
Configuring the DHCP Client
Configuring IP Routing and DHCP Services
This chapter describes how to configure IP routing and DHCP on the security appliance. This chapter includes the following sections:
•
Configuring Static and Default Routes
•
Configuring OSPF
•
Configuring RIP
•
Dynamic Routing and Failover
•
Configuring Multicast Routing
•
Configuring DHCP
Configuring Static and Default Routes
This section describes how to configure static routes on the security appliance.
Multiple context mode does not support dynamic routing, so you must use static routes for any networks to which the security appliance is not directly connected; for example, when there is a router between a network and the security appliance.
You might want to use static routes in single context mode in the following cases:
•
Your networks use a different router discovery protocol from RIP or OSPF.
•
Your network is small and you can easily manage static routes.
•
You do not want the traffic or CPU overhead associated with routing protocols.
The simplest option is to configure a default route to send all traffic to an upstream router, relying on the router to route the traffic for you. However, in some cases the default gateway might not be able to reach the destination network, so you must also configure more specific static routes. For example, if the default gateway is outside, then the default route cannot direct traffic to any inside networks that are not directly connected to the security appliance.
In transparent firewall mode, for traffic that originates on the security appliance and is destined for a non-directly connected network, you need to configure either a default route or static routes so the security appliance knows out of which interface to send traffic. Traffic that originates on the security appliance might include communications to a syslog server, Websense or N2H2 server, or AAA server. If you have servers that cannot all be reached through a single default route, then you must configure static routes.
The security appliance supports up to three equal cost routes on the same interface for load balancing.
This section includes the following topics:
•
Configuring a Static Route
•
Configuring a Default Route
For information about configuring IPv6 static and default routes, see the "Configuring IPv6 Default and Static Routes" section on page 9-3.
Configuring a Static Route
To add a static route, enter the following command:
hostname(config)# route if_name dest_ip mask gateway_ip [distance]
The dest_ip and mask is the IP address for the destination network and the gateway_ip is the address of the next-hop router.The addresses you specify for the static route are the addresses that are in the packet before entering the security appliance and performing NAT.
The distance is the administrative distance for the route. The default is 1 if you do not specify a value. Administrative distance is a parameter used to compare routes among different routing protocols. The default administrative distance for static routes is 1, giving it precedence over routes discovered by dynamic routing protocols but not directly connect routes. The default administrative distance for routes discovered by OSPF is 110. If a static route has the same administrative distance as a dynamic route, the static routes take precedence. Connected routes always take precedence over static or dynamically discovered routes.
Static routes remain in the routing table even if the specified gateway becomes unavailable. If the specified gateway becomes unavailable, you need to remove the static route from the routing table manually. However, static routes are removed from the routing table if the specified interface goes down. They are reinstated when the interface comes back up.
Note
If you create a static route with an administrative distance greater than the administrative distance of the routing protocol running on the security appliance, then a route to the specified destination discovered by the routing protocol takes precedence over the static route. The static route is used only if the dynamically discovered route is removed from the routing table.
The following example creates a static route that sends all traffic destined for 10.1.1.0/24 to the router (10.1.2.45) connected to the inside interface:
hostname(config)# route inside 10.1.1.0 255.255.255.0 10.1.2.45 1
You can define up to three equal cost routes to the same destination per interface. ECMP is not supported across multiple interfaces. With ECMP, the traffic is not necessarily divided evenly between the routes; traffic is distributed among the specified gateways based on an algorithm that hashes the source and destination IP addresses.
The following example shows static routes that are equal cost routes that direct traffic to three different gateways on the outside interface. The security appliance distributes the traffic among the specified gateways.
hostname(config)# route outside 10.10.10.0 255.255.255.0 192.168.1.1
hostname(config)# route outside 10.10.10.0 255.255.255.0 192.168.1.2
hostname(config)# route outside 10.10.10.0 255.255.255.0 192.168.1.3
Configuring a Default Route
A default route identifies the gateway IP address to which the security appliance sends all IP packets for which it does not have a learned or static route. A default route is simply a static route with 0.0.0.0/0 as the destination IP address. Routes that identify a specific destination take precedence over the default route.
Note
In ASA software Versions 7.0 and later, if you have two default routes configured on different interfaces that have different metrics, the connection to the ASA firewall that is made from the higher metric interface fails, but connections to the ASA firewall from the lower metric interface succeed as expected. PIX software Version 6.3 supports connections from both the the higher and the lower metric interfaces.
You can define up to three equal cost default route entries per device. Defining more than one equal cost default route entry causes the traffic sent to the default route to be distributed among the specified gateways. When defining more than one default route, you must specify the same interface for each entry.
If you attempt to define more than three equal cost default routes, or if you attempt to define a default route with a different interface than a previously defined default route, you receive the message "ERROR: Cannot add route entry, possible conflict with existing routes."
You can define a separate default route for tunneled traffic along with the standard default route. When you create a default route with the tunneled option, all encrypted traffic that arrives on the security appliance and cannot be routed using learned or static routes is sent to this route. Otherwise, if the traffic is not encrypted, the standard default route entry is used. You cannot define more than one default route with the tunneled option; ECMP for tunneled traffic is not supported.
To define the default route, enter the following command:
hostname(config)# route if_name 0.0.0.0 0.0.0.0 gateway_ip [distance | tunneled]
Tip
You can enter 0 0 instead of 0.0.0.0 0.0.0.0 for the destination network address and mask, for example: hostname(config)# route outside 0 0 192.168.1 1
The following example shows a security appliance configured with three equal cost default routes and a default route for tunneled traffic. Unencrypted traffic received by the security appliance for which there is no static or learned route is distributed among the gateways with the IP addresses 192.168.2.1, 192.168.2.2, 192.168.2.3. Encrypted traffic receive by the security appliance for which there is no static or learned route is passed to the gateway with the IP address 192.168.2.4.
hostname(config)# route outside 0 0 192.168.2.1
hostname(config)# route outside 0 0 192.168.2.2
hostname(config)# route outside 0 0 192.168.2.3
hostname(config)# route outside 0 0 192.168.2.4 tunneled
Configuring OSPF
This section describes how to configure OSPF. This section includes the following topics:
•
OSPF Overview
•
Enabling OSPF
•
Redistributing Routes Between OSPF Processes
•
Configuring OSPF Interface Parameters
•
Configuring OSPF Area Parameters
•
Configuring OSPF NSSA
•
Configuring Route Summarization Between OSPF Areas
•
Configuring Route Summarization When Redistributing Routes into OSPF
•
Generating a Default Route
•
Configuring Route Calculation Timers
•
Logging Neighbors Going Up or Down
•
Displaying OSPF Update Packet Pacing
•
Monitoring OSPF
•
Restarting the OSPF Process
OSPF Overview
OSPF uses a link-state algorithm to build and calculate the shortest path to all known destinations. Each router in an OSPF area contains an identical link-state database, which is a list of each of the router usable interfaces and reachable neighbors.
The advantages of OSPF over RIP include the following:
•
OSPF link-state database updates are sent less frequently than RIP updates, and the link-state database is updated instantly rather than gradually as stale information is timed out.
•
Routing decisions are based on cost, which is an indication of the overhead required to send packets across a certain interface. The security appliance calculates the cost of an interface based on link bandwidth rather than the number of hops to the destination. The cost can be configured to specify preferred paths.
The disadvantage of shortest path first algorithms is that they require a lot of CPU cycles and memory.
The security appliance can run two processes of OSPF protocol simultaneously, on different sets of interfaces. You might want to run two processes if you have interfaces that use the same IP addresses (NAT allows these interfaces to coexist, but OSPF does not allow overlapping addresses). Or you might want to run one process on the inside, and another on the outside, and redistribute a subset of routes between the two processes. Similarly, you might need to segregate private addresses from public addresses.
Redistribution between the two OSPF processes is supported. Static and connected routes configured on OSPF-enabled interfaces on the security appliance can also be redistributed into the OSPF process. You cannot enable RIP on the security appliance if OSPF is enabled. Redistribution between RIP and OSPF is not supported.
The security appliance supports the following OSPF features:
•
Support of intra-area, interarea, and external (Type I and Type II) routes.
•
Support of a virtual link.
•
OSPF LSA flooding.
•
Authentication to OSPF packets (both password and MD5 authentication).
•
Support for configuring the security appliance as a designated router or a designated backup router. The security appliance also can be set up as an ABR; however, the ability to configure the security appliance as an ASBR is limited to default information only (for example, injecting a default route).
•
Support for stub areas and not-so-stubby-areas.
•
Area boundary router type-3 LSA filtering.
•
Advertisement of static and global address translations.
Enabling OSPF
To enable OSPF, you need to create an OSPF routing process, specify the range of IP addresses associated with the routing process, then assign area IDs associated with that range of IP addresses.
Note
You cannot enable OSPF if RIP is enabled.
To enable OSPF, perform the following steps:
Step 1
To create an OSPF routing process, enter the following command:
hostname(config)# router ospf process_id
This command enters the router configuration mode for this OSPF process.
The process_id is an internally used identifier for this routing process. It can be any positive integer. This ID does not have to match the ID on any other device; it is for internal use only. You can use a maximum of two processes.
Step 2
To define the IP addresses on which OSPF runs and to define the area ID for that interface, enter the following command:
hostname(config-router)# network ip_address mask area area_id
The following example shows how to enable OSPF:
hostname(config)# router ospf 2
hostname(config-router)# network 10.0.0.0 255.0.0.0 area 0
Redistributing Routes Between OSPF Processes
The security appliance can control the redistribution of routes between OSPF routing processes. The security appliance matches and changes routes according to settings in the redistribute command or by using a route map. See also the "Generating a Default Route" section for another use for route maps.
Note
The security appliance cannot redistribute routes between routing protocols. However, the security appliance can redistribute static and connected routes.
This section includes the following topics:
•
Adding a Route Map
•
Redistributing Static, Connected, or OSPF Routes to an OSPF Process
Adding a Route Map
To define a route map, perform the following steps:
Step 1
To create a route map entry, enter the following command:
hostname(config)# route-map name {permit | deny} [sequence_number]
Route map entries are read in order. You can identify the order using the sequence_number option, or the security appliance uses the order in which you add the entries.
Step 2
Enter one or more match commands:
•
To match any routes that have a destination network that matches a standard ACL, enter the following command:
hostname(config-route-map)# match ip address acl_id [acl_id] [...]
If you specify more than one ACL, then the route can match any of the ACLs.
•
To match any routes that have a specified metric, enter the following command:
hostname(config-route-map)# match metric metric_value
The metric_value can be from 0 to 4294967295.
•
To match any routes that have a next hop router address that matches a standard ACL, enter the following command:
hostname(config-route-map)# match ip next-hop acl_id [acl_id] [...]
If you specify more than one ACL, then the route can match any of the ACLs.
•
To match any routes with the specified next hop interface, enter the following command:
hostname(config-route-map)# match interface if_name
If you specify more than one interface, then the route can match either interface.
•
To match any routes that have been advertised by routers that match a standard ACL, enter the following command:
hostname(config-route-map)# match ip route-source acl_id [acl_id] [...]
If you specify more than one ACL, then the route can match any of the ACLs.
•
To match the route type, enter the following command:
hostname(config-route-map)# match route-type {internal | external [type-1 | type-2]}
Step 3
Enter one or more set commands.
If a route matches the match commands, then the following set commands determine the action to perform on the route before redistributing it.
•
To set the metric, enter the following command:
hostname(config-route-map)# set metric metric_value
The metric_value can be a value between 0 and 294967295
•
To set the metric type, enter the following command:
hostname(config-route-map)# set metric-type {type-1 | type-2}
The following example shows how to redistribute routes with a hop count equal to 1. The security appliance redistributes these routes as external LSAs with a metric of 5, metric type of Type 1.
hostname(config)# route-map 1-to-2 permit
hostname(config-route-map)# match metric 1
hostname(config-route-map)# set metric 5
hostname(config-route-map)# set metric-type type-1
Redistributing Static, Connected, or OSPF Routes to an OSPF Process
To redistribute static, connected, or OSPF routes from one process into another OSPF process, perform the following steps:
Step 1
If you have not already done so, enter the router configuration mode for the OSPF process you want to redistribute into by entering the following command:
hostname(config)# router ospf process_id
Step 2
To specify the routes you want to redistribute, enter the following command:
hostname(config-router)# redistribute {ospf process_id
[match {internal | external 1 | external 2}] | static | connect} [metric metric-value]
[metric-type {type-1 | type-2}] [tag tag_value] [subnets] [route-map map_name]
The ospf process_id, static, and connect keywords specify from where you want to redistribute routes.
You can either use the options in this command to match and set route properties, or you can use a route map. The tag and subnets options do not have equivalents in the route-map command. If you use both a route map and options in the redistribute command, then they must match.
The following example shows route redistribution from OSPF process 1 into OSPF process 2 by matching routes with a metric equal to 1. The security appliance redistributes these routes as external LSAs with a metric of 5, metric type of Type 1, and a tag equal to 1.
hostname(config)# route-map 1-to-2 permit
hostname(config-route-map)# match metric 1
hostname(config-route-map)# set metric 5
hostname(config-route-map)# set metric-type type-1
hostname(config-route-map)# set tag 1
hostname(config-route-map)# router ospf 2
hostname(config-router)# redistribute ospf 1 route-map 1-to-2
The following example shows the specified OSPF process routes being redistributed into OSPF process 109. The OSPF metric is remapped to 100.
hostname(config)# router ospf 109
hostname(config-router)# redistribute ospf 108 metric 100 subnets
The following example shows route redistribution where the link-state cost is specified as 5 and the metric type is set to external, indicating that it has lower priority than internal metrics.
hostname(config)# router ospf 1
hostname(config-router)# redistribute ospf 2 metric 5 metric-type external
Configuring OSPF Interface Parameters
You can alter some interface-specific OSPF parameters as necessary. You are not required to alter any of these parameters, but the following interface parameters must be consistent across all routers in an attached network: ospf hello-interval, ospf dead-interval, and ospf authentication-key. Be sure that if you configure any of these parameters, the configurations for all routers on your network have compatible values.
To configure OSPF interface parameters, perform the following steps:
Step 1
To enter the interface configuration mode, enter the following command:
hostname(config)# interface interface_name
Step 2
Enter any of the following commands:
•
To specify the authentication type for an interface, enter the following command:
hostname(config-interface)# ospf authentication [message-digest | null]
•
To assign a password to be used by neighboring OSPF routers on a network segment that is using the OSPF simple password authentication, enter the following command:
hostname(config-interface)# ospf authentication-key key
The key can be any continuous string of characters up to 8 bytes in length.
The password created by this command is used as a key that is inserted directly into the OSPF header when the security appliance software originates routing protocol packets. A separate password can be assigned to each network on a per-interface basis. All neighboring routers on the same network must have the same password to be able to exchange OSPF information.
•
To explicitly specify the cost of sending a packet on an OSPF interface, enter the following command:
hostname(config-interface)# ospf cost cost
The cost is an integer from 1 to 65535.
•
To set the number of seconds that a device must wait before it declares a neighbor OSPF router down because it has not received a hello packet, enter the following command:
hostname(config-interface)# ospf dead-interval seconds
The value must be the same for all nodes on the network.
•
To specify the length of time between the hello packets that the security appliance sends on an OSPF interface, enter the following command:
hostname(config-interface)# ospf hello-interval seconds
The value must be the same for all nodes on the network.
•
To enable OSPF MD5 authentication, enter the following command:
hostname(config-interface)# ospf message-digest-key key_id md5 key
Set the following values:
–
key_id—An identifier in the range from 1 to 255.
–
key—Alphanumeric password of up to 16 bytes.
Usually, one key per interface is used to generate authentication information when sending packets and to authenticate incoming packets. The same key identifier on the neighbor router must have the same key value.
We recommend that you not keep more than one key per interface. Every time you add a new key, you should remove the old key to prevent the local system from continuing to communicate with a hostile system that knows the old key. Removing the old key also reduces overhead during rollover.
•
To set the priority to help determine the OSPF designated router for a network, enter the following command:
hostname(config-interface)# ospf priority number_value
The number_value is between 0 to 255.
•
To specify the number of seconds between LSA retransmissions for adjacencies belonging to an OSPF interface, enter the following command:
hostname(config-interface)# ospf retransmit-interval seconds
The seconds must be greater than the expected round-trip delay between any two routers on the attached network. The range is from 1 to 65535 seconds. The default is 5 seconds.
•
To set the estimated number of seconds required to send a link-state update packet on an OSPF interface, enter the following command:
hostname(config-interface)# ospf transmit-delay seconds
The seconds is from 1 to 65535 seconds. The default is 1 second.
The following example shows how to configure the OSPF interfaces:
hostname(config)# router ospf 2
hostname(config-router)# network 2.0.0.0 255.0.0.0 area 0
hostname(config-router)# interface inside
hostname(config-interface)# ospf cost 20
hostname(config-interface)# ospf retransmit-interval 15
hostname(config-interface)# ospf transmit-delay 10
hostname(config-interface)# ospf priority 20
hostname(config-interface)# ospf hello-interval 10
hostname(config-interface)# ospf dead-interval 40
hostname(config-interface)# ospf authentication-key cisco
hostname(config-interface)# ospf message-digest-key 1 md5 cisco
hostname(config-interface)# ospf authentication message-digest
The following is sample output from the show ospf command:
hostname(config)# show ospf
Routing Process "ospf 2" with ID 20.1.89.2 and Domain ID 0.0.0.2
Supports only single TOS(TOS0) routes
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
Number of external LSA 5. Checksum Sum 0x 26da6
Number of opaque AS LSA 0. Checksum Sum 0x 0
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
External flood list length 0
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm executed 2 times
Number of LSA 5. Checksum Sum 0x 209a3
Number of opaque link LSA 0. Checksum Sum 0x 0
Number of DCbitless LSA 0
Number of indication LSA 0
Configuring OSPF Area Parameters
You can configure several area parameters. These area parameters (shown in the following task table) include setting 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 ABR, 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 command on the ABR to prevent it from sending summary link advertisement (LSA type 3) into the stub area.
To specify area parameters for your network, perform the following steps:
Step 1
If you have not already done so, enter the router configuration mode for the OSPF process you want to configure by entering the following command:
hostname(config)# router ospf process_id
Step 2
Enter any of the following commands:
•
To enable authentication for an OSPF area, enter the following command:
hostname(config-router)# area area-id authentication
•
To enable MD5 authentication for an OSPF area, enter the following command:
hostname(config-router)# area area-id authentication message-digest
•
To define an area to be a stub area, enter the following command:
hostname(config-router)# area area-id stub [no-summary]
•
To assign a specific cost to the default summary route used for the stub area, enter the following command:
hostname(config-router)# area area-id default-cost cost
The cost is an integer from 1 to 65535. The default is 1.
The following example shows how to configure the OSPF area parameters:
hostname(config)# router ospf 2
hostname(config-router)# area 0 authentication
hostname(config-router)# area 0 authentication message-digest
hostname(config-router)# area 17 stub
hostname(config-router)# area 17 default-cost 20
Configuring OSPF NSSA
The OSPF implementation of an NSSA is similar to an 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 ABRs, which are flooded throughout the whole routing domain. Summarization and filtering are supported during the translation.
You can simplify administration if you are an 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 an OSPF stub area because routes for the remote site could not be redistributed into the 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 for your network as needed to configure OSPF NSSA, perform the following steps:
Step 1
If you have not already done so, enter the router configuration mode for the OSPF process you want to configure by entering the following command:
hostname(config)# router ospf process_id
Step 2
Enter any of the following commands:
•
To define an NSSA area, enter the following command:
hostname(config-router)# area area-id nssa [no-redistribution]
[default-information-originate]
•
To summarize groups of addresses, enter the following command:
hostname(config-router)# summary address ip_address mask [not-advertise] [tag tag]
This command helps reduce the size of the routing table. Using this command for OSPF causes an OSPF ASBR to advertise one external route as an aggregate for all redistributed routes that are covered by the address.
OSPF does not support summary-address 0.0.0.0 0.0.0.0.
In the following example, the summary address 10.1.0.0 includes address 10.1.1.0, 10.1.2.0, 10.1.3.0, and so on. Only the address 10.1.0.0 is advertised in an external link-state advertisement:
hostname(config-router)# summary-address 10.1.1.0 255.255.0.0
Before you use this feature, consider these guidelines:
–
You can set a type 7 default route that can be used to reach external destinations. When configured, the router generates a type 7 default into the NSSA or the NSSA area boundary router.
–
Every router within the same area must agree that the area is NSSA; otherwise, the routers will not be able to communicate.
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 advertises 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 define an address range for route summarization, perform the following steps:
Step 1
If you have not already done so, enter the router configuration mode for the OSPF process you want to configure by entering the following command:
hostname(config)# router ospf process_id
Step 2
To set the address range, enter the following command:
hostname(config-router)# area area-id range ip-address mask [advertise | not-advertise]
The following example shows how to configure route summarization between OSPF areas:
hostname(config)# router ospf 1
hostname(config-router)# area 17 range 12.1.0.0 255.255.0.0
Configuring 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 security appliance 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 the following steps:
Step 1
If you have not already done so, enter the router configuration mode for the OSPF process you want to configure by entering the following command:
hostname(config)# router ospf process_id
Step 2
To set the summary address, enter the following command:
hostname(config-router)# summary-address ip_address mask [not-advertise] [tag tag]
OSPF does not support summary-address 0.0.0.0 0.0.0.0.
The following example shows how to configure route summarization. The summary address 10.1.0.0 includes address 10.1.1.0, 10.1.2.0, 10.1.3.0, and so on. Only the address 10.1.0.0 is advertised in an external link-state advertisement:
hostname(config)# router ospf 1
hostname(config-router)# summary-address 10.1.0.0 255.255.0.0
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 generate a default route, perform the following steps:
Step 1
If you have not already done so, enter the router configuration mode for the OSPF process you want to configure by entering the following command:
hostname(config)# router ospf process_id
Step 2
To force the autonomous system boundary router to generate a default route, enter the following command:
hostname(config-router)# default-information originate [always] [metric metric-value]
[metric-type {1 | 2}] [route-map map-name]
The following example shows how to generate a default route:
hostname(config)# router ospf 2
hostname(config-router)# default-information originate always
Configuring Route Calculation Timers
You can configure the delay time between when OSPF receives a topology change and when it starts an SPF calculation. You also can configure the hold time between two consecutive SPF calculations.
To configure route calculation timers, perform the following steps:
Step 1
If you have not already done so, enter the router configuration mode for the OSPF process you want to configure by entering the following command:
hostname(config)# router ospf process_id
Step 2
To configure the route calculation time, enter the following command:
hostname(config-router)# timers spf spf-delay spf-holdtime
The spf-delay is the delay time (in seconds) between when OSPF receives a topology change and when it starts an SPF calculation. It can be an integer from 0 to 65535. The default time is 5 seconds. A value of 0 means that there is no delay; that is, the SPF calculation is started immediately.
The spf-holdtime is the minimum time (in seconds) between two consecutive SPF calculations. It can be an integer from 0 to 65535. The default time is 10 seconds. A value of 0 means that there is no delay; that is, two SPF calculations can be done, one immediately after the other.
The following example shows how to configure route calculation timers:
hostname(config)# router ospf 1
hostname(config-router)# timers spf 10 120
Logging Neighbors Going Up or Down
By default, the system sends a system 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 ospf adjacency 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.
To log neighbors going up or down, perform the following steps:
Step 1
If you have not already done so, enter the router configuration mode for the OSPF process you want to configure by entering the following command:
hostname(config)# router ospf process_id
Step 2
To configure logging for neighbors going up or down, enter the following command:
hostname(config-router)# log-adj-changes [detail]
Note
Logging must be enabled for the the neighbor up/down messages to be sent.
The following example shows how to log neighbors up/down messages:
hostname(config)# router ospf 1
hostname(config-router)# log-adj-changes detail
Displaying OSPF Update Packet Pacing
OSPF update packets are automatically paced so they are not sent less than 33 milliseconds apart. Without pacing, some update packets could get lost in situations where the link is slow, a neighbor could not receive the updates quickly enough, or the router could run out of buffer space. For example, without pacing packets might be dropped if either of the following topologies exist:
•
A fast router is connected to a slower router over a point-to-point link.
•
During flooding, several neighbors send updates to a single router at the same time.
Pacing is also used 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, enter the following command:
hostname# show ospf flood-list if_name
Monitoring OSPF
You can display specific statistics such as the contents of IP routing tables, caches, and databases. You can use the information provided 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 the following tasks, as needed:
•
To display general information about OSPF routing processes, enter the following command:
hostname# show ospf [process-id [area-id]]
•
To display the internal OSPF routing table entries to the ABR and ASBR, enter the following command:
hostname# show ospf border-routers
•
To display lists of information related to the OSPF database for a specific router, enter the following command:
hostname# show ospf [process-id [area-id]] database
•
To display a list of LSAs waiting to be flooded over an interface (to observe OSPF packet pacing), enter the following command:
hostname# show ospf flood-list if-name
•
To display OSPF-related interface information, enter the following command:
hostname# show ospf interface [if_name]
•
To display OSPF neighbor information on a per-interface basis, enter the following command:
hostname# show ospf neighbor [interface-name] [neighbor-id] [detail]
•
To display a list of all LSAs requested by a router, enter the following command:
hostname# show ospf request-list neighbor if_name
•
To display a list of all LSAs waiting to be resent, enter the following command:
hostname# show ospf retransmission-list neighbor if_name
•
To display a list of all summary address redistribution information configured under an OSPF process, enter the following command:
hostname# show ospf [process-id] summary-address
•
To display OSPF-related virtual links information, enter the following command:
hostname# show ospf [process-id] virtual-links
Restarting the OSPF Process
To restart an OSPF process, clear redistribution, or counters, enter the following command:
hostname(config)# clear ospf pid {process | redistribution | counters
[neighbor [neighbor-interface] [neighbor-id]]}
Configuring RIP
This section describes how to configure RIP. This section includes the following topics:
•
RIP Overview
•
Enabling RIP
RIP Overview
Devices that support RIP send routing-update messages at regular intervals and when the network topology changes. These RIP packets contain information about the networks that the devices can reach, as well as the number of routers or gateways that a packet must travel through to reach the destination address. RIP generates more traffic than OSPF, but is easier to configure initially.
RIP has advantages over static routes because the initial configuration is simple, and you do not need to update the configuration when the topology changes. The disadvantage to RIP is that there is more network and processing overhead than static routing.
The security appliance uses a limited version of RIP; it does not send out RIP updates that identify the networks that the security appliance can reach. However, you can enable one or both of the following methods:
•
Passive RIP—The security appliance listens for RIP updates but does not send any updates about its networks out of the interface.
Passive RIP allows the security appliance to learn about networks to which it is not directly connected.
•
Default Route Updates—Instead of sending normal RIP updates that describe all the networks reachable through the security appliance, the security appliance sends a default route to participating devices that identifies the security appliance as the default gateway.
You can use the default route option with passive RIP, or alone. You might use the default route option alone if you use static routes on the security appliance, but do not want to configure static routes on downstream routers. Typically, you would not enable the default route option on the outside interface, because the security appliance is not typically the default gateway for the upstream router.
Enabling RIP
To enable RIP on an interface, enter the following command:
hostname(config)# rip interface_name {default | passive} [version {1 | 2
[authentication {text | md5} key key_id]}]
You can enable both the passive and default modes of RIP on an interface by entering the rip command twice, one time for each method. For example, enter the following commands:
hostname(config)# rip inside default version 2 authentication md5 scorpius 1
hostname(config)# rip inside passive version 2 authentication md5 scorpius 1
If you want to enable passive RIP on all interfaces, but only enable default routes on the inside interface, enter the following commands:
hostname(config)# rip inside default version 2 authentication md5 scorpius 1
hostname(config)# rip inside passive version 2 authentication md5 scorpius 1
hostname(config)# rip outside passive version 2 authentication md5 scorpius 1
Note
Before testing your configuration, flush the ARP caches on any routers connected to the security appliance. For Cisco routers, use the clear arp command to flush the ARP cache.
You cannot enable RIP if OSPF is enabled.
Dynamic Routing and Failover
Dynamic routes are not replicated to the standby unit or failover group in a failover configuration. Therefore, immediately after a failover occurs, some packets received by the security appliance may be dropped because of a lack of routing information or routed to a default static route while the routing table is repopulated by the configured dynamic routing protocols.
Configuring Multicast Routing
This section describes how to configure multicast routing. This section includes the following topics:
•
Multicast Routing Overview
•
Enabling Multicast Routing
•
Configuring IGMP Features
•
Configuring Stub Multicast Routing
•
Configuring a Static Multicast Route
•
Configuring PIM Features
•
For More Information about Multicast Routing
Multicast Routing Overview
The security appliance supports both stub multicast routing and PIM multicast routing. However, you cannot configure both concurrently on a single security appliance.
Stub multicast routing provides dynamic host registration and facilitates multicast routing. When configured for stub multicast routing, the security appliance acts as an IGMP proxy agent. Instead of fully participating in multicast routing, the security appliance forwards IGMP messages to an upstream multicast router, which sets up delivery of the multicast data. When configured for stub multicast routing, the security appliance cannot be configured for PIM.
The security appliance supports both PIM-SM and bi-directional PIM. PIM-SM is a multicast routing protocol that uses the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a single Rendezvous Point per multicast group and optionally creates shortest-path trees per multicast source.
Bi-directional PIM is a variant of PIM-SM that builds bi-directional shared trees connecting multicast sources and receivers. Bi-directional trees are built using a DF election process operating on each link of the multicast topology. With the assistance of the DF, multicast data is forwarded from sources to the Rendezvous Point, and therefore along the shared tree to receivers, without requiring source-specific state. The DF election takes place during Rendezvous Point discovery and provides a default route to the Rendezvous Point.
Note
If the security appliance is the PIM RP, use the untranslated outside address of the security appliance as the RP address.
Enabling Multicast Routing
Enabling multicast routing lets the security appliance forward multicast packets. Enabling multicast routing automatically enables PIM and IGMP on all interfaces. To enable multicast routing, enter the following command:
hostname(config)# multicast-routing
The number of entries in the multicast routing tables are limited by the amount of RAM on the system. Table 8-1 lists the maximum number of entries for specific multicast tables based on the amount of RAM on the security appliance. Once these limits are reached, any new entries are discarded.
Table 8-1 Entry Limits for Multicast Tables
Table
|
16 MB
|
128 MB
|
128+ MB
|
MFIB
|
1000
|
3000
|
5000
|
IGMP Groups
|
1000
|
3000
|
5000
|
PIM Routes
|
3000
|
7000
|
12000
|
Configuring IGMP Features
IP hosts use IGMP to report their group memberships to directly connected multicast routers. IGMP uses group addresses (Class D IP address) as group identifiers. Host group address can be in the range 224.0.0.0 to 239.255.255.255. The address 224.0.0.0 is never assigned to any group. The address 224.0.0.1 is assigned to all systems on a subnet. The address 224.0.0.2 is assigned to all routers on a subnet.
When you enable multicast routing on the security appliance, IGMP Version 2 is automatically enabled on all interfaces.
Note
Only the no igmp command appears in the interface configuration when you use the show run command. If the multicast-routing command appears in