Immediate Solutions

Configuring Cisco Express Forwarding

On most platforms, CEF is not enabled by default, so security administrators must remember to enable the feature.

Note Cisco Express Forwarding (CEF) is not a security feature; therefore, CEF will not be covered in detail. However, the majority of the security features discussed in this chapter must have CEF enabled to function.

Use the ip cef global configuration command to enable CEF switching or enable the use of distributed CEF by using the ip cef distributed global configuration command. Distributed CEF functions only on platforms that support a distributed architecture.

To give you an idea about how CEF works, Figure 3.2 shows Router C with multiple connections to other networks. The configuration of Router C to support CEF switching is shown here:

#config t

#ip cef distributed #end

#

Figure 3.2: Example of CEF network.

The ip cef distributed global configuration command was used to enable CEF on Router C. After it is enabled on Router C, CEF should create an adjacency table listing each connected device. CEF can create an adjacency by using Address Resolution Protocol (ARP); if Router B is using a routing protocol, an adjacency can be created by using the routing protocol B, and an adjacency can be can be created from a static mapping, using a layer 2 protocol. To verify that CEF created the table, use the show adjacency detail command. Listing 3.1 shows the output of the show adjacency detail command issued on Router B after enabling CEF.

Listing 3.1: The adjacency table of Router B.

93

In Listing 3.1, you can see that Router B has created an adjacency with each of the routers it is connected to. Each of the fields details specifics related to the CEF adjacency. The protocol field lists the routed protocol with which the adjacency is related. The interface field lists the outgoing interface used to reach the adjacency neighbor. The address field is the address of the adjacency and can contain either the adjacency's next−hop address or a point−to−point address. The numbers that are in parentheses in the address field are used only by the local router and as a reference to the adjacency. The next field is an encapsulation string, which is prepended to each packet. And the last field is a timer, which is periodically refreshed for each neighbor. The adjacency table will periodically refresh each of these neighbors with the exception of the neighbor connected via the ATM interface. Because this entry is a permanent circuit, CEF will not refresh the neighbor.

As mentioned in the section "In Brief" earlier in this chapter, CEF builds its table based on information within the route table, and as such, a one−to−one correlation between the CEF table and the route table is maintained. The CEF table is stable as long as the topology of the route table is stable. The CEF table of Router B can be viewed using the show ip cef command. Listing 3.2 shows the output of the command show ip cef entered on Router B.

Listing 3.2: An example CEF table for Router B.

Further information for each CEF table entry can be seen by issuing the sh ip cef network command. The following information is returned:

94

Router−B#sh ip cef 4.24.104.92

4.24.104.92/30, version 1046593, cached adjacency 10.191.150.242 0 packets, 0 bytes

via 192.168.241.2, ATM8/0/0, 0 dependencies next hop 192.168.14.253, ATM8/0/0

valid cached adjacency

The routing table entry for 4.24.104.92 has a next−hop address of 192.168.241.2, which is not directly connected. This entry requires a recursive lookup for the next hop for 192.168.241.2 to determine that 192.168.241.2 can be reached using the next hop of 192.168.14.253, which is reachable sending the packet out interface ATM8/0/0.

Configuring Unicast Reverse Path Forwarding

Enterprise networks should use Unicast RPF as an ingress filter to protect themselves from untrusted networks. Although most enterprises use access lists for ingress filtering, Unicast RPF provides many advantages over the traditional access list approach. The following section will provide some examples of how Unicast RPF can provide valuable protection options for networks connected to the Internet.

Note Unicast RPF should not be configured on any internal network device where asymmetric routing is taking place. This will cause Unicast RPF to drop legitimate return traffic.

When Unicast RPF is enabled on an interface, the router examines all packets received on that interface. The router checks to make sure that the source address appears in the routing table and matches the interface on which the packet was received. To configure Unicast RPF for ingress filtering, follow these steps:

1.Use the ip cef or ip cef distributed command to enable CEF switching or distributed CEF switching.

2.Use the following command to select the input interface on which to apply Unicast RPF:

interface <interface name> <interface number>

The input interface is the receiving interface, which allows Unicast RPF to verify the best return path before forwarding the packet to the destination.

3. Use the following command to enable Unicast RPF on the interface:

ip verify unicast reverse−path <access list number>

The access list number option identifies an optional access list. If the access list denies network access, packets with changed headers are dropped at the interface. If the access list permits network access, packets with changed headers are forwarded to the destination address.

4. Use the following command to define an extended access list and its parameters:

access−list <access−list−number> {deny|permit} <protocol> − <source> <source−wildcard> <destination> <destination>− wildcard>

95

A deny statement configures the router to drop the packet and a permit statement allows the packet to forward out the egress interface toward its destination.

Figure 3.3 displays a network in which Unicast RPF is enabled on both interfaces of Router 1.

Figure 3.3: Unicast RPF.

The objective is to use Unicast RPF for filtering traffic at the ingress interfaces of Router 1 to provide protection from malformed packets arriving from the Internet or from the internal network. The following commands configure Router 1 for Unicast RPF:

Router−1

!

ip cef distributed

!

interface Serial1/0

ip verify unicast reverse−path

!

interface Ethernet0/0

ip verify unicast reverse−path

!

The preceding configuration is all that is needed to have Unicast RPF running on the router. It is very important to remember that CEF must be enabled on the router prior to configuring Unicast RPF. In fact, the router will not allow Unicast RPF to be configured until CEF is enabled, as shown in the following display:

Router−1(config−if)#ip verify unicast reverse−path % CEF not enabled. Enable first

As you can see, the router will display a prompt that demands that you enable CEF on the router prior to configuring Unicast RPF. To verify that Unicast is operational, use the show cef interface <interface name> <interface number> command. The output should verify that Unicast RPF is in fact operational. Listing 3.3 displays the output.

Listing 3.3: An example of the show cef interface command.

Router−1#sh cef interface serial1/0 detail Serial1/0 is up (if_number 3)

Internet address is 172.16.10.1/24 ICMP redirects are always sent

Per packet loadbalancing is disabled IP unicast RPF check is enabled Inbound access list is not set Outbound access list is not set

IP policy routing is disabled Hardware idb is serial1/0

Fast switching type 1, interface type 18 IP CEF switching enabled

IP CEF Feature Fast switching turbo vector Input fast flags 0x4000, Output fast flags 0x0 ifindex 2(2)

Slot 1 Slot unit 0 VC −1

96

Transmit limit accumulator 0x0 (0x0)

IP MTU 1500

Router−1#

Unicast RPF also allows for the configuration of an optional access list to control the exact behavior when the received packet fails the source IP address check. The access list can be defined as a standard access list or as an extended access list. If an access list is defined, then after a packet fails a Unicast RPF check, the access list is checked to see if the packet should be dropped or forwarded. Unicast RPF events can also be logged by specifying the logging option for the access list entries used by Unicast RPF.

The following example configures Router 1 in Figure 3.3 to use access lists and logging with Unicast RPF. In the example in Listing 3.4, the extended access list 114 contains entries that should permit or deny network traffic for specific address ranges received on interface serial1/0. Unicast RPF is configured on interface serial1/0 to check packets arriving at that interface.

Listing 3.4: An example Unicast RPF logging configuration.

ip cef distributed

!

int serial1/0

ip verify unicast reverse−path 114

!

int ethernet0/0

ip verify unicast reverse−path

!

access−list 114 deny ip 192.168.10.0 0.0.0.255 any log−input access−list 114 deny ip 192.168.20.0 0.0.0.255 any log−input access−list 114 deny ip 192.168.30.0 0.0.0.255 any log−input access−list 114 permit ip 192.168.9.0 0.0.0.255 any log−input

The configuration in Listing 3.4 denies packets with a source address of 192.168.10.0, 192.168.20.0, or 192.168.30.0 from arriving at interface serial1/0 because of the deny statement in access list 114. The access lists also logs any packet that is matched by the access list. Packets with a source address within the 192.168.9.0 subnet arriving at interface serial1/0 are forwarded if the source cannot be verified against interface serial1/0 because of the permit statement in access list 114. To verify that logging of the access list entries are taking place, use the show access−lists command:

Router−1# show access−lists Extended IP access list 114\

deny ip 192.168.10.0 0.0.0.255 any log−input (87 match) deny ip 192.168.20.0 0.0.0.255 any log−input (32 match) deny ip 192.168.30.0 0.0.0.255 any log−input (76 match) permit ip 192.168.9.0 0.0.0.255 any log−input (63 match)

Each time a packet is dropped at an interface, information is not only logging globally on the router but also at each interface configured for Unicast RPF. Global statistics about packets that have been dropped provide information about potential attacks. To view the global drop statistics, use the show ip traffic command. Here is the output:

Router−1#show ip traffic IP statistics:

Rcvd: 1290449399 total, 75488293 local destination

0 format errors, 183 checksum errors, 8684 bad hop count

97