Chapter 4: Routing and Multicasting

This chapter will introduce you to the routing and multicasting capabilities of the security appliances. Appliances support static routing and dynamic routing protocols, including RIP, OSPF, and EIGRP, the newest edition. The appliances also have limited multicast capabilities, including support for interaction with multicast clients using the IGMP protocol and routing of multicast traffic. The topics in this chapter include

• Routing features

• Multicast features

Routing Features

You can use two methods to get routing information into your appliance: static routes and a dynamic routing protocol. The three dynamic routing protocols supported include RIP, OSPF, and EIGRP. The appliances need some basic routing information to take incoming packets and forward them out of an appropriate interface to reach a destination that is more than one hop away. The following sections cover the implementation, configuration, and verification of routing on your appliance.

Routing Recommendations

It is important to point out that your appliance is not a full-functioning router. This was very apparent up through version 6.2 of the operating system. With the introduction of version 6.3, OSPF was added as a routing protocol. As you will see later in the “OSPF” section, the appliances have most of the OSPF capabilities of Cisco IOS routers; however, they don’t have all the same capabilities.

You can use two common practices for routing on the appliances, depending on whether the appliance is at the perimeter of your network, or located inside the campus or data center. For small networks, it is common to use a default route pointing to the router connected to the outside interface and to use static routes pointing to your networks connected to your remaining appliance interfaces. For large networks, it is common to use static routing on the perimeter appliances, but to use a dynamic routing protocol for appliances located within the campus or data center.

Tip

The most preferred routing method on a perimeter appliance is to have a default route pointing to the outside interface and to have a specific route(s) pointing to the internal interface(s).

Administrative Distance

If you have multiple paths to reach the same destination within a routing protocol, the appliance uses the lowest metric value when choosing a route and places the lowest metric route in the routing table. However, if more than one routing protocol is learning a route, Cisco uses a proprietary feature called administrative distance to rank the routing protocols. The routing protocol with the lowest administrative distance value will have its route placed in the routing table. Table 4-1 lists the administrative distances of the routing protocols. Note that Cisco uses the same administrative distance values to rank routing protocols on their IOS routers.

Table 4-1: Administrative Distances of Routing Protocols

Routing Protocol	Administrative Distance
Connected interface	0
Static route	1
EIGRP summarized route	5
Internal EIGRP route (within an autonomous system or AS)	90
OSPF	110
RIP	120
External EIGRP route (different AS)	170
Unknown	255

Static Routes

The three kinds of static routes are

• Connected route

• Static route

• Default route

Once you configure an IP address on your appliance’s interface, the appliance automatically creates a static route for the specified network number and associates it with the configured interface. This is referred to as a connected route. When you’re determining what route to use to reach a destination, connected routes have the highest preference (lowest administrative distance). Once you are done configuring your interface IP addresses, the appliance will know about all of the directly connected networks. However, the appliance doesn’t know about networks more than one hop away from itself. To solve this problem, one option is to configure static, or default, routes. This topic is discussed in the next section.

Static Route Configuration

To create a static or default route, use the route command, as shown here:

ciscoasa(config)# route logical_if_name network_number subnet_mask
                        next_hop_IP_address [metric] [tunneled]

As you can see from the syntax, the configuration of this command is not too different from configuring a static route on an IOS router. The first parameter you must enter for the route command is the logical name of the interface where the destination route exists. If you examine Figure 4-1, for 192.168.4.0/24 and 192.168.5.0/24, this would be the inside interface. Next, you follow it with the network number and the subnet mask. For a default route, enter 0.0.0.0 for the network number, or 0 for short, and 0.0.0.0 for the subnet mask, which can also be abbreviated to 0.

Figure 4-1: A sample network with a security appliance

After you’ve entered the network number and subnet mask, specify the router’s IP address that the appliance will forward the traffic to in order to get the traffic to the correct destination. Again, for the 192.168.4.0/24 and 192.168.5.0/24 networks, the next-hop address is 192.168.3.2.

You can optionally add a hop count to rank static routes when your appliance is connected to more than one router and you want the appliance to know about both routing paths—this is configured with the metric parameter. This parameter weights the static routes, giving preference to the one with a lower metric value.

When you create a default route with the tunneled parameter, all encrypted traffic that arrives on the appliance which cannot be routed using a dynamically learned route or a static route is sent to this route. Otherwise, if the traffic is not encrypted, the appliance’s standard default route is used. Two restrictions apply when you’re using the tunneled option:

• You cannot define more than one default route with this option.

• ICMP for tunneled traffic is not supported with this option.

Note

The security appliances will not load-balance between multiple paths—they will only use one path. If the metric is different, the appliance will use the path with the lower metric value. If the metric value is the same, the appliance will use the first route command that you configured.

Route Verification

To view the routes in your appliance’s routing table, use the following command:

ciscoasa# show route [logical_if_name [ip_address [netmask [static]]]]

Here is an example of the use of the show route command:

Listing 4-1: A static route configuration for Figure 4-1

ciscoasa(config)# show route
S    0.0.0.0 0.0.0.0 [1/0] via 192.168.1.2, outside
C    192.168.3.0 255.255.255.0 is directly connected, inside
C*   127.0.0.0 255.255.0.0 is directly connected, cplane
C    192.168.2.0 255.255.255.0 is directly connected, dmz
C    192.168.1.0 255.255.255.0 is directly connected, outside
S    192.168.4.0 255.255.255.0 [1/0] via 192.168.3.2, inside
S    192.168.5.0 255.255.255.0 [1/0] via 192.168.3.2, inside

A static route is represented by an S in the routing table. A directly connected route is represented by C. If you see a 127.0.0.0 route, it indicates that you are on an ASA—this address is used to access the pseudo-console port of an installed IPS or CSC card. For nonconnected routes, as with static routes, you’ll see two numbers in brackets (“[]”). The first number is the administrative distance of the routing protocol, and the second number is the metric of the route.

Static Route Configuration Example

To illustrate the configuration of static routes, I’ll use the network shown previously in Figure 4-1. Here is the configuration to accomplish the routing table output shown previously in Listing 4-1:

ciscoasa(config)# route outside 0 0 192.168.1.2
ciscoasa(config)# route inside 192.168.4.0 255.255.255.0 192.168.3.2
ciscoasa(config)# route inside 192.168.5.0 255.255.255.0 192.168.3.2

Static Route Tracking

One problem with static routes is that the appliance, by default, has no way of knowing if the path to the destination is available unless the interface on the appliance associated with the static route were to go down. However, if the next-hop neighbor were to go down, the appliance would still forward traffic to this destination.

Static route tracking is a new feature, introduced in version 7.2, to deal with this problem when using static routes. This feature allows an appliance to detect that a configured static route that is currently in the routing table is no longer reachable and to use a backup static route that you’ve configured. ICMP is used by the appliance to test connectivity for the static route currently in the appliance routing table. If ICMP echo replies are not received for a preconfigured period from the monitored device associated with the current static route, the appliance can then remove the associated static route from its routing table, and use a configured backup static route.

Note

One restriction with the static route tracking feature is that it cannot be used with a static route that has the tunneled option enabled.

Static Route Tracking Configuration

Use the following commands to configure static route tracking:

ciscoasa(config)# sla monitor SLA_ID
ciscoasa(config-sla-monitor)# type echo protocol ipIcmpEcho
                       monitor_device_IP interface logical_if_name
ciscoasa(config-sla-monitor-echo)# timeout milliseconds
ciscoasa(config-sla-monitor-echo)# frequency #_missed_echo_replies
ciscoasa(config)# sla monitor schedule SLA_ID life forever
                       start-time now
ciscoasa(config)# track track_ID rtr SLA_ID reachability
ciscoasa(config)# route logical_if_name network_number subnet_mask
                       next_hop_IP_address [metric] track track_ID

The sla monitor command specifies how the tracking should be done. The SLA_ID associates an identification value to the tracking process. The type subcommand mode command specifies the protocol to use when performing the test, the device to test access to and the interface the monitored device is connected to. Currently the only protocol supported for testing is ICMP (ipIcmpEcho). The timeout command specifies the number of milliseconds to wait for the echo reply. The frequency command specifies the number of echo replies that must be missed before the tracked static route is considered bad. The sla monitor schedule command specifies when monitoring should start and for how long. Normally you want the tracking to start right now and continue forever, but you can change these values. The track command associates the SLA_ID for monitoring with the tracking ID specified in the route command(s).

Static Route Tracking Configuration Example

To illustrate how static route tracking is used, examine Figure 4-2. In this example, the perimeter appliance is connected to two ISPs via two different perimeter routers, where ISP1 is the default path and ISP2 is the backup. However, if either of these two ISP links were to go down, the appliance, since it is not connected to them, would not know this. Here is the configuration for static route tracking for this example:

ciscoasa(config)# sla monitor 100
ciscoasa(config-sla-monitor)# type echo protocol ipIcmpEcho
               200.1.1.1 interface outside
ciscoasa(config-sla-monitor-echo)# timeout 1000
ciscoasa(config-sla-monitor-echo)# frequency 3
ciscoasa(config-sla-monitor-echo)# exit
ciscoasa(config)# sla monitor schedule 100 life forever start-time now
ciscoasa(config)# track 1 rtr 100 reachability
ciscoasa(config)# route 0 0 outside1 192.168.1.1 1 track 1
ciscoasa(config)# route 0 0 outside2 192.168.2.1 2 track 1

Figure 4-2: Static route tracking example

In the preceding configuration, the appliance is tracking a device, probably a router, in the ISP1 network (200.1.1.1). If an echo reply is not received when tracking within 1 second (1,000 milliseconds) and this process is repeated three times, the primary default route is considered bad (the 192.168.1.1 neighbor with a metric of 1), and the backup default route for the outside2 interface will be used.