- Index
- Preface
- Product Overview
- Command-Line Interfaces
- Configuring the Switch for the First Time
- Administering the Switch
- Configuring VSS
- Configuring the Cisco IOS In-Service Software Upgrade Process
- Configuring the Cisco IOS XE In Service Software Upgrade Process
- Configuring Interfaces
- Checking Port Status and Connectivity
- Configuring Trustsec
- Configuring Supervisor Engine Redundancy Using RPR and SSO on Supervisor Engine 6-E and Supervisor Engine 6L-E
- Configuring Supervisor Engine Redundancy Using RPR and SSO on Supervisor Engine 7-E and Supervisor Engine 7L-E
- Configuring Cisco NSF with SSO Supervisor Engine Redundancy
- Environmental Monitoring and Power Management
- Configuring Power over Ethernet
- Configuring the Catalyst 4500 Series Switch with Cisco Network Assistant
- Configuring VLANs, VTP, and VMPS
- Configuring IP Unnumbered Interface
- Configuring Layer 2 Ethernet Interfaces
- Configuring SmartPort Macros
- Configuring Cisco IOS Auto Smartport Macros
- Configuring STP and MST
- Configuring Flex Links and MAC Address-Table Move Update
- Configuring Resilient Ethernet Protocol
- Configuring Optional STP Features
- Configuring EtherChannel and Link State Tracking
- Configuring IGMP Snooping and Filtering
- Configuring IPv6 MLD Snooping
- Configuring 802.1Q Tunneling, VLAN Mapping, and Layer 2 Protocol Tunneling
- Configuring CDP
- Configuring LLDP, LLDP-MED, and Location Service
- Configuring UDLD
- Configuring Unidirectional Ethernet
- Configuring Layer 3 Interfaces
- Configuring Cisco Express Forwarding
- Configuring Unicast Reverse Path Forwarding
- Configuring IP Multicast
- Configuring ANCP Client
- Configuring Bidirection Forwarding Detection
- Configuring Policy-Based Routing
- Configuring VRF-lite
- Configuring Quality of Service
- Configuring Voice Interfaces
- Configuring Private VLANs
- Configuring MACsec Encryption
- Configuring 802.1X Port-Based Authentication
- Configuring the PPPoE Intermediate Agent
- Configuring Web-Based Authentication
- Configuring Port Security
- Configuring Control Plane Policing and Layer 2 Control Packet QoS
- Configuring Dynamic ARP Inspection
- Configuring DHCP Snooping, IP Source Guard, and IPSG for Static Hosts
- Configuring Network Security with ACLs
- Support for IPv6
- Port Unicast and Multicast Flood Blocking
- Configuring Storm Control
- Configuring SPAN and RSPAN
- Configuring Wireshark
- Configuring Enhanced Object Tracking
- Configuring System Message Logging
- Configuring OBFL
- Configuring SNMP
- Configuring NetFlow-lite
- Configuring Flexible NetFlow
- Configuring Ethernet OAM and CFM
- Configuring Y.1731 (AIS and RDI)
- Configuring Call Home
- Configuring Cisco IOS IP SLA Operations
- Configuring RMON
- Performing Diagnostics
- Configuring WCCP Version 2 Services
- Configuring MIB Support
- ROM Monitor
- Acronyms and Abbreviations
Configuring Unicast Reverse Path Forwarding
This chapter describes the Unicast Reverse Path Forwarding (Unicast RPF) feature. The Unicast RPF feature helps to mitigate problems that are caused by malformed or forged IP source addresses that are passing through a switch.
For a complete description of the Unicast RPF commands in this chapter, refer to the chapter "Unicast Reverse Path Forwarding Commands" of the Cisco IOS Security Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the "Identifying Supported Platforms" section in the chapter "Using Cisco IOS Software."
This chapter includes the following sections:
•About Unicast Reverse Path Forwarding
•Unicast RPF Configuration Tasks
•Monitoring and Maintaining Unicast RPF
•Unicast RPF Configuration Example: Inbound and Outbound Filters
Note For complete syntax and usage information for the switch commands used in this chapter, first look at the Cisco Catalyst 4500 Series Switch Command Reference and related publications at this location:
http://www.cisco.com/en/US/products//hw/switches/ps4324/index.html
If the command is not found in the Catalyst 4500 Series Switch Command Reference, it will be found in the larger Cisco IOS library. Refer to the Cisco IOS Command Reference and related publications at this location:
http://www.cisco.com/en/US/products/ps6350/index.html
About Unicast Reverse Path Forwarding
The Unicast RPF feature helps to mitigate problems that are caused by the introduction of malformed or forged (spoofed) IP source addresses into a network by discarding IP packets that lack a verifiable IP source address. For example, a number of common types of denial-of-service (DoS) attacks, including Smurf and Tribal Flood Network (TFN), can take advantage of forged or rapidly changing source IP addresses to allow attackers to thwart efforts to locate or filter the attacks. For Internet service providers (ISPs) that provide public access, Unicast RPF deflects such attacks by forwarding only packets that have source addresses that are valid and consistent with the IP routing table. This action protects the network of the ISP, its customer, and the rest of the Internet.
This section covers the following information:
•Related Features and Technologies
•Prerequisites to Configuring Unicast RPF
How Unicast RPF Works
When Unicast RPF is enabled on an interface, the switch examines all packets received as input on that interface to make sure that the source address and source interface appear in the routing table and match the interface on which the packet was received. This ability to look backwards is available only when Cisco Express Forwarding (CEF) is enabled on the switch, because the lookup relies on the presence of the Forwarding Information Base (FIB). CEF generates the FIB as part of its operation.
Note Unicast RPF is an input function and is applied only on the input interface of a switch at the upstream end of a connection.
Unicast RPF checks to see if any packet received at a switch interface arrives on the best return path (return route) to the source of the packet. Unicast RPF does this by doing a reverse lookup in the CEF table. If the packet was received from one of the best reverse path routes, the packet is forwarded as normal. If there is no reverse path route on the same interface from which the packet was received, it might mean that the source address was modified. If Unicast RPF does not find a reverse path for the packet, the packet is dropped.
Note With Unicast RPF, all equal-cost "best" return paths are considered valid. This means that Unicast RPF works in cases where multiple return paths exist, provided that each path is equal to the others in terms of the routing cost (number of hops, weights, and so on) and as long as the route is in the FIB. Unicast RPF also functions where EIGRP variants are being used and unequal candidate paths back to the source IP address exist.
When a packet is received at the interface where Unicast RPF and ACLs have been configured, the following actions occur:
Step 1 Input ACLs configured on the inbound interface are checked.
Step 2 Unicast RPF checks to see if the packet has arrived on the best return path to the source, which it does by doing a reverse lookup in the FIB table.
Step 3 CEF table (FIB) lookup is carried out for packet forwarding.
Step 4 Output ACLs are checked on the outbound interface.
Step 5 The packet is forwarded.
This section provides information about Unicast RPF enhancements:
•Access control lists and logging
•Per-interface statistics
Figure 35-1 illustrates how Unicast RPF and CEF work together to validate IP source addresses by verifying packet return paths. In this example, a customer has sent a packet having a source address of 192.168.1.1 from interface Gigabit Ethernet 1/1. Unicast RPF checks the FIB to see if 192.168.1.1 has a path to Gigabit Ethernet 1/1. If there is a matching path, the packet is forwarded. If there is no matching path, the packet is dropped.
Figure 35-1 Unicast RPF Validating IP Source Addresses
Figure 35-2 illustrates how Unicast RPF drops packets that fail validation. In this example, a customer has sent a packet having a source address of 209.165.200.225, which is received at interface Gigabit Ethernet 1/1. Unicast RPF checks the FIB to see if 209.165.200.225 has a return path to Gigabit Ethernet 1/1. If there is a matching path, the packet is forwarded. There is no reverse entry in the routing table that routes the customer packet back to source address 209.165.200.225 on interface Gigabit Ethernet 1/1, and so the packet is dropped.
Figure 35-2 Unicast RPF Dropping Packets That Fail Verification
Implementing Unicast RPF
Unicast RPF has several key implementation principles:
•The packet must be received at an interface that has the best return path (route) to the packet source (a process called symmetric routing). There must be a route in the FIB matching the route to the receiving interface. Adding a route in the FIB is done with a static route, network statement, or dynamic routing. (ACLs permit the use of Unicast RPF when packets will arrive by specific, less optimal asymmetric input paths.)
•IP source addresses at the receiving interface must match the routing entry for the interface.
•Unicast RPF is an input function and is applied only on the input interface of a switch at the upstream end of a connection.
Given these implementation principles, Unicast RPF becomes a tool that network administrators can use not only for their customers but also for their downstream network or ISP, even if the downstream network or ISP has other connections to the Internet.
This section provides information about the implementation of Unicast RPF:
•Security Policy and Unicast RPF
•Unicast RPF with BOOTP and DHCP
Security Policy and Unicast RPF
Consider the following points in determining your policy for deploying Unicast RPF:
•Unicast RPF must be applied at the interface downstream from the larger portion of the network, preferably at the edges of your network.
•The farther downstream you apply Unicast RPF, the finer the granularity you have in mitigating address spoofing and in identifying the sources of spoofed addresses. For example, applying Unicast RPF on an aggregation switch helps mitigate attacks from many downstream networks or clients and is simple to administer, but it does not help identify the source of the attack. Applying Unicast RPF at the network access server helps limit the scope of the attack and trace the source of the attack; however, deploying Unicast RPF across many sites does add to the administration cost of operating the network.
•The more entities that deploy Unicast RPF across Internet, intranet, and extranet resources, the better the chances of mitigating large-scale network disruptions throughout the Internet community, and the better the chances of tracing the source of an attack.
•Unicast RPF will not inspect IP packets encapsulated in tunnels, such as GRE, LT2P, or PPTP. Unicast RPF must be configured at a home gateway so that Unicast RPF processes network traffic only after the tunneling and encryption layers have been stripped off the packets.
Where to Use Unicast RPF
Unicast RPF can be used in any single-homed environment where there is essentially only one access point out of the network; that is, one upstream connection. Networks having one access point offer the best example of symmetric routing, which means that the interface where a packet enters the network is also the best return path to the source of the IP packet. Unicast RPF is best used at the network perimeter for Internet, intranet, or extranet environments, or in ISP environments for customer network terminations.
Enterprise Networks with a Single Connection to an ISP
In enterprise networks, one objective of using Unicast RPF for filtering traffic at the input interface (a process called ingress filtering) is for protection from malformed packets arriving from the Internet. Traditionally, local networks with one connection to the Internet use ACLs at the receiving interface to prevent spoofed packets from the Internet from entering their local network.
ACLs work well for many single-homed customers; however, there are trade-offs when ACLs are used as ingress filters, including two commonly referenced limitations:
•Packet per second (PPS) performance at very high packet rates
Note This restriction applies only to software packet forwarding. Hardware packet forwarding is the same on both ACL and uRPF.
•Maintenance of the ACL (whenever new addresses are added to the network)
Unicast RPF is one tool that addresses both of these limitations. With Unicast RPF, ingress filtering is done at CEF PPS rates. This processing speed makes a difference when the link is more than 1 Mbps. Additionally, since Unicast RPF uses the FIB, no ACL maintenance is necessary, and thus the administration overhead of traditional ACLs is reduced. The following figure and example demonstrate how Unicast RPF is configured for ingress filtering.
Figure 35-3 illustrates an enterprise network that has a single link to an upstream ISP. In this example, Unicast RPF is applied at interface Gigabit Ethernet 1/1 on the Enterprise switch for protection from malformed packets arriving from the Internet. Unicast RPF is also applied at interface
Gigabit Ethernet 2/1 on the ISP switch for protection from malformed packets arriving from the enterprise network.
Figure 35-3 Enterprise Network Using Unicast RPF for Ingress Filtering
Using the topography in Figure 35-3, a typical configuration (assuming that CEF is turned on) on the ISP switch appears as follows:
interface Gigabit Ethernet 2/1
description Link to Enterprise Network
ip address 192.168.3.1 255.255.255.255
no switchport
ip address 10.1.1.2 255.255.255.0
ip verify unicast source reachable-via rx allow-default
The gateway switch configuration of the enterprise network (assuming that CEF is turned on) appears as follows:
interface Gigabit Ethernet 1/2
description ExampleCorp LAN
ip address 192.168.10.1 255.255.252.0
no ip redirects
no ip directed-broadcast
no ip proxy-arp
interface Gigabit Ethernet 1/1
description Link to Internet
no switchport
ip address 10.1.1.1 255.255.255.0
ip verify unicast source reachable-via allow-default
no ip proxy-arp
no ip redirects
no ip directed-broadcast
Unicast RPF works with a single default route. No additional routes or routing protocols exist. Network 192.168.10.0/22 is a connected network. Packets arriving from the Internet with a source address in the range 192.168.10.0/22 are dropped by Unicast RPF.
Routing Table Requirements
To work correctly, Unicast RPF needs proper information in the CEF tables. This requirement does not mean that the switch must have the entire Internet routing table. The amount of routing information needed in the CEF tables depends on where Unicast RPF is configured and what functions the switch performs in the network. For example, in an ISP environment, a switch that is a leased-line aggregation switch for customers needs only the information based on the static routes redistributed into the IGP or IBGP (depending on which technique is used in the network). Unicast RPF is configured on the customer interfaces, creating the requirement for minimal routing information. In another scenario, a single-homed ISP could place Unicast RPF on the gateway link to the Internet. The full Internet routing table is required. Requiring the full routing table helps protect the ISP from external DoS attacks that use addresses that are not in the Internet routing table.
Where Not to Use Unicast RPF
Do not use Unicast RPF on interfaces that are internal to the network. Internal interfaces are likely to have routing asymmetry (see Figure 35-4), meaning multiple routes to the source of a packet. Apply Unicast RPF only where there is natural or configured symmetry. Provided administrators carefully plan which interfaces they activate Unicast RPF on, routing asymmetry is not a serious problem.
For example, switches at the edge of the network of an ISP are more likely to have symmetrical reverse paths than switches that are in the core of the ISP network. Switches that are in the core of the ISP network have no guarantee that the best forwarding path out of the switch is the path selected for packets returning to the switch. We do not recommend that you apply Unicast RPF where there is a chance of asymmetric routing, unless you use ACLs to allow the switch to accept incoming packets. ACLs permit the use of Unicast RPF when packets will arrive by specific, less optimal asymmetric input paths. However, it is simplest to place Unicast RPF only at the edge of a network or, for an ISP, at the customer edge of the network.
Figure 35-4 illustrates how Unicast RPF can block legitimate traffic in an asymmetrical routing environment.
Figure 35-4 Unicast RPF Blocking Traffic in an Asymmetrical Routing Environment
Unicast RPF with BOOTP and DHCP
Unicast RPF will allow packets with 0.0.0.0 source and 255.255.255.255 destination to pass so that Bootstrap Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP) functions work properly.
Restrictions
Restrictions for applying Unicast RPF to multihomed clients include the following:
•Clients should not be multihomed to the same switch because action defeats the purpose of building a redundant service for the client.
•Customers must ensure that the packets flowing up the link (out to the Internet) match the route advertised out the link. Otherwise, Unicast RPF filters those packets as malformed packets.
Limitation
Unicast loose mode is not supported.
Related Features and Technologies
For more information about Unicast RPF-related features and technologies, review the following:
•Unicast RPF requires Cisco express forwarding (CEF) to function properly on the switch. For more information about CEF, refer to the Cisco IOS Switching Services Configuration Guide.
•Unicast RPF can be more effective at mitigating spoofing attacks when combined with a policy of ingress and egress filtering using Cisco IOS access control lists (ACLs).
–Ingress filtering applies filters to traffic received at a network interface from either internal or external networks. With ingress filtering, packets that arrive from other networks or the Internet and that have a source address that matches a local network, private, or broadcast address are dropped. In ISP environments, for example, ingress filtering can apply to traffic received at the switch from either the client (customer) or the Internet.
–Egress filtering applies filters to traffic exiting a network interface (the sending interface). By filtering packets on switches that connect your network to the Internet or to other networks, you can permit only packets with valid source IP addresses to leave your network.
For more information on network filtering, refer to RFC 2267 and to the Cisco IOS IP Configuration Guide.
Prerequisites to Configuring Unicast RPF
Prior to configuring Unicast RPF, configure ACLs:
•Configure standard or extended ACLs to mitigate transmission of invalid IP addresses (perform egress filtering). Permit only valid source addresses to leave your network and get onto the Internet. Prevent all other source addresses from leaving your network for the Internet.
•Configure standard or extended ACLs entries to drop (deny) packets that have invalid source IP addresses (perform ingress filtering). Invalid source IP addresses include the following types:
–Reserved addresses
–Loopback addresses
–Private addresses (RFC 1918, Address Allocation for Private Internets)
–Broadcast addresses (including multicast addresses)
–Source addresses that fall outside the range of valid addresses associated with the protected network
Unicast RPF Configuration Tasks
The following sections describe the configuration tasks for Unicast RPF. Each task in the list is identified as either optional or required.
•Configuring Unicast RPF (Required)
•Verifying Unicast RPF (Optional)
See the section "Unicast RPF Configuration Example: Inbound and Outbound Filters" at the end of this chapter.
Configuring Unicast RPF
Unicast RPF is an input-side function that is enabled on an interface operates on IP packets received by the switch.
To configure Unicast RPF, perform the following task:
Verifying Unicast RPF
To verify that Unicast RPF is operational, use the show cef interface command. The following example shows that Unicast RPF is enabled at interface Gigabit Ethernet 3/1:
Switch# show cef interface gigabitEthernet 3/1
GigabitEthernet3/1 is up (if_number 79)
Corresponding hwidb fast_if_number 79
Corresponding hwidb firstsw->if_number 79
Internet address is 10.1.1.1/24
ICMP redirects are always sent
IP unicast RPF check is enabled <======
Input features: uRPF <=====
Inbound access list is not set
Outbound access list is not set
IP policy routing is disabled
BGP based policy accounting on input is disabled
BGP based policy accounting on output is disabled
Hardware idb is GigabitEthernet3/1
Fast switching type 1, interface type 155
IP CEF switching enabled
IP CEF switching turbo vector
IP Null turbo vector
IP prefix lookup IPv4 mtrie 8-8-8-8 optimized
Input fast flags 0x4000, Output fast flags 0x0
ifindex 78(78)
Slot 3 Slot unit 1 VC -1
Transmit limit accumulator 0x0 (0x0)
IP MTU 1500
Monitoring and Maintaining Unicast RPF
To monitor and maintain Unicast RFP, perform this task:
|
|
---|---|
Switch# show ip traffic |
Displays global switch statistics about Unicast RPF drops and suppressed drops. |
Switch(config-if)# no ip verify unicast |
Disables Unicast RPF at the interface. |
Unicast RPF counts the number of packets dropped or suppressed because of malformed or forged source addresses. Unicast RPF counts dropped or forwarded packets that include the following global and per-interface information:
• Global Unicast RPF drops
• Per-interface Unicast RPF drops
• Per-interface Unicast RPF suppressed drops
The show ip traffic command shows the total number (global count) of dropped or suppressed packets as dropped by software; it does not include those dropped by hardware. The Unicast RPF drop count is included in the IP statistics section.
Switch# show ip traffic
IP statistics:
Rcvd: 1471590 total, 887368 local destination
0 format errors, 0 checksum errors, 301274 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options, 0 with options
Opts: 0 end, 0 nop, 0 basic security, 0 loose source route
0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 0 alert, 0 other
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
0 fragmented, 0 couldn't fragment
Bcast: 205233 received, 0 sent
Mcast: 463292 received, 462118 sent
Sent: 990158 generated, 282938 forwarded
! The second line below ("0 unicast RPF") displays Unicast RPF packet dropping information.
Drop: 3 encapsulation failed, 0 unresolved, 0 no adjacency
0 no route, 0 unicast RPF, 0 forced drop
A nonzero value for the count of dropped or suppressed packets can mean one of two things:
•Unicast RPF is dropping or suppressing packets that have a bad source address (normal operation).
•Unicast RPF is dropping or suppressing legitimate packets because the route is misconfigured to use Unicast RPF in environments where asymmetric routing exists; that is, where multiple paths can exist as the best return path for a source address.
The show ip interface command shows the total of dropped or suppressed packets at a specific interface. If Unicast RPF is configured to use a specific ACL, that ACL information is displayed along with the drop statistics.
Switch> show ip interface fast 2/1
Unicast RPF ACL 197
1 unicast RPF drop
1 unicast RPF suppressed drop
The show access-lists command displays the number of matches found for a specific entry in a specific access list.
Switch> show access-lists
Extended IP access list 197
deny ip 192.168.201.0 0.0.0.63 any log-input (1 match)
permit ip 192.168.201.64 0.0.0.63 any log-input (1 match)
deny ip 192.168.201.128 0.0.0.63 any log-input
permit ip 192.168.201.192 0.0.0.63 any log-input
Unicast RPF Configuration Example: Inbound and Outbound Filters
The following example uses a very simple single-homed ISP to demonstrate the concepts of ingress and egress filters used in conjunction with Unicast RPF. The example illustrates an ISP-allocated classless interdomain routing (CIDR) block 209.165.202.128/28 that has both inbound and outbound filters on the upstream interface. Be aware that ISPs are usually not single-homed. Provisions for asymmetrical flows (when outbound traffic goes out one link and returns by using a different link) must be designed into the filters on the border switches of the ISP.
ip cef distributed
!
interface Serial 5/0/0
description Connection to Upstream ISP
ip address 209.165.200.225 255.255.255.252
no ip redirects
no ip directed-broadcast
no ip proxy-arp
ip verify unicast reverse-path rx allow-default
ip access-group 111 in
ip access-group 110 out
!
access-list 110 permit ip 209.165.202.128 0.0.0.31 any
access-list 110 deny ip any any log
access-list 111 deny ip host 0.0.0.0 any log
access-list 111 deny ip 127.0.0.0 0.255.255.255 any log
access-list 111 deny ip 10.0.0.0 0.255.255.255 any log
access-list 111 deny ip 172.16.0.0 0.15.255.255 any log
access-list 111 deny ip 192.168.0.0 0.0.255.255 any log
access-list 111 deny ip 209.165.202.128 0.0.0.31 any log
access-list 111 permit ip any any