-
Cisco IOS Security Command Reference, Release 12.3
-
Introduction
-
Security Commands: aaa accounting through access-template
-
Security Commands: accounting through crypto ca trustpoint
-
Security Commands: crypto dynamic-map through ctype
-
Security Commands: D through ip audit smtp spam
-
Security Commands: ip auth-proxy through ip tcp intercept
-
Security Commands: ip trigger-authentication through pool
-
Security Commands: ppp accounting through radius-server vsa send
-
Security Commands: reverse-route through show crypto isakmp sa
-
Security Commands: show crypto key mypubkey through wins
-
Table Of Contents
ip trigger-authentication (global)
ip trigger-authentication (interface)
ip verify unicast reverse-path
ip verify unicast source reachable-via
ip vrf forwarding (server-group)
ip trigger-authentication (global)
To enable the automated part of double authentication at a device, use the ip trigger-authentication command in global configuration mode. To disable the automated part of double authentication, use the no form of this command.
ip trigger-authentication [timeout seconds] [port number]
no ip trigger-authentication
Syntax Description
Defaults
The default timeout is 90 seconds, and the default port number is 7500.
Command Modes
Global configuration
Command History
Usage Guidelines
Configure this command on the local device (router or network access server) that remote users dial in to. Use this command only if the local device has already been configured to provide double authentication; this command enables automation of the second authentication of double authentication.
The timeout Keyword
During the second authentication stage of double authentication—when the remote user is authenticated—the remote user must send a username and password (or PIN) to the local device. With automated double authentication, the local device sends a UDP packet to the remote user's host during the second user-authentication stage. This UDP packet triggers the remote host to launch a dialog box requesting a username and password (or PIN).
If the local device does not receive a valid response to the UDP packet within a timeout period, the local device will send another UDP packet. The device will continue to send UDP packets at the timeout intervals until it receives a response and can authenticate the user.
By default, the UDP packet timeout interval is 90 seconds. Use the timeout keyword to specify a different interval.
(This timeout also applies to how long entries will remain in the remote host table; see the show ip trigger-authentication command for details.)
The port Keyword
As described in the previous section, the local device sends a UDP packet to the remote user's host to request the user's username and password (or PIN). This UDP packet is sent to UDP port 7500 by default. (The remote host client software listens to UDP port 7500 by default.) If you need to change the port number because port 7500 is used by another application, you should change the port number using the port keyword. If you change the port number you need to change it in both places—both on the local device and in the remote host client software.
Examples
The following example globally enables automated double authentication and sets the timeout to 120 seconds:
ip trigger-authentication timeout 120Related Commands
ip trigger-authentication (interface)
To specify automated double authentication at an interface, use the ip trigger-authentication command in interface configuration mode. To turn off automated double authentication at an interface, use the no form of this command.
ip trigger-authentication
no ip trigger-authentication
Syntax Description
This command has no arguments or keywords.
Defaults
Automated double authentication is not enabled for specific interfaces.
Command Modes
Interface configuration
Command History
Usage Guidelines
Configure this command on the local router or network access server that remote users dial into. Use this command only if the local device has already been configured to provide double authentication and if automated double authentication has been enabled with the ip trigger-authentication (global) command.
This command causes double authentication to occur automatically when users dial into the interface.
Examples
The following example turns on automated double authentication at the ISDN BRI interface BRI0:
interface BRI0ip trigger-authenticationencapsulation pppppp authentication chapRelated Commands
ip trigger-authentication (global)
Enables the automated part of double authentication at a device.
ip urlfilter alert
To enable URL filtering system alert messages, use the ip urlfilter alert command in global configuration mode. To disable the system alert, use the no form of this command.
ip urlfilter alert
no ip urlfilter alert
Syntax Description
This command has no arguments or keywords.
Defaults
URL filtering messages are enabled.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Usage Guidelines
Use the ip urlfilter alert command to display system messages, such as a server entering allow mode, a server going down, or a URL that is too long for the lookup request.
Examples
The following example shows how to enable URL filtering alert messages:
ip inspect name test http urlfilterip urlfilter cache 5ip urlfilter exclusive-domain permit .weapons.comip urlfilter exclusive-domain deny .nbc.comip urlfilter exclusive-domain permit www.cisco.comip urlfilter audit-trailip urlfilter alertip urlfilter server vendor websense 192.168.3.1Afterward, system alert messages such as the following are displayed:
%URLF-3-SERVER_DOWN:Connection to the URL filter server 10.92.0.9 is downThis level three LOG_ERR-type message is displayed when a configured URL filter server (UFS) goes down. When this happens, the firewall will mark the configured server as secondary and try to bring up one of the other secondary servers and mark that server as the primary server. If there is no other server configured, the firewall will enter into allow mode and display the URLF-3-ALLOW_MODE message described.
%URLF-3-ALLOW_MODE:Connection to all URL filter servers are down and ALLOW MODE is OFFThis LOG_ERR type message is displayed when all UFSs are down and the system enters into allow mode.
Note
Whenever the system goes into allow mode (all filter servers are down), a periodic keepalive timer will be triggered that will try to bring up a server by opening a TCP connection.
%URLF-5-SERVER_UP:Connection to an URL filter server 10.92.0.9 is made, the system is returning from ALLOW MODEThis LOG_NOTICE-type message is displayed when the UFSs are detected as being up and the system is returning from allow mode.
%URLF-4-URL_TOO_LONG:URL too long (more than 3072 bytes), possibly a fake packet?This LOG_WARNING-type message is displayed when the URL in a lookup request is too long; any URL longer than 3K will be dropped.
%URLF-4-MAX_REQ:The number of pending request exceeds the maximum limit <1000>This LOG_WARNING-type message is displayed when the number of pending requests in the system exceeds the maximum limit and all further requests are dropped.
ip urlfilter allowmode
To turn on the default mode (allow mode) of the filtering algorithm, use the ip urlfilter allowmode command in global configuration mode. To disable the default mode, use the no form of this command.
ip urlfilter allowmode [on | off]
no ip urlfilter allowmode [on | off]
Syntax Description
Defaults
Allow mode is off.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Usage Guidelines
The system will go into allow mode when connections to all vendor servers (Websense or N2H2) are down. The system will return to normal mode when a connection to at least one web vendor server is up. Allow mode directs your system to forward or drop all packets on the basis of the configurable allow mode setting: if allow mode is on and the vendor servers are down, the HTTP requests will be allowed to pass; if allow mode is off and the vendor servers are down, the HTTP requests will be forbidden.
Examples
The following example shows how to enable allow mode on your system:
ip urlfilter allowmode onAfterward, the following alert message will be displayed when the system goes into allow mode:
%URLF-3-ALLOW_MODE: Connection to all URL filter servers are down and ALLOW MODE if OFFThe following alert message will be displayed when the system returns from allow mode:
%URLF-5-SERVER_UP: Connection to an URL filter server 12.0.0.3 is made, the system is returning from allow modeip urlfilter audit-trail
To log messages into the syslog server or router, use the ip urlfilter audit-trail command in global configuration mode. To disable this functionality, use the no form of this command.
ip urlfilter audit-trail
no ip urlfilter audit-trail
Syntax Description
This command has no arguments or keywords.
Defaults
This command is disabled.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Usage Guidelines
Use the ip urlfilter audit-trail command to log messages such as URL request status (allow or deny) into your syslog server.
Examples
The following example shows how to enable syslog message logging:
ip inspect name test http urlfilterip urlfilter cache 5ip urlfilter exclusive-domain permit .weapons.comip urlfilter exclusive-domain deny .nbc.comip urlfilter exclusive-domain permit www.cisco.comip urlfilter audit-trailip urlfilter alertip urlfilter server vendor websense 209.165.202.130Afterward, audit trail messages such as the following are displayed and logged into the log server:
%URLF-6-SITE_ALLOWED:Client 209.165.201.15:12543 accessed server 10.76.82.21:8080This message is logged for each request whose destination IP address is found in the cache. It includes the source IP address, source port number, destination IP address, and destination port number. The URL is not logged in this case because the IP address of the request is found in the cache; thus, parsing the request and extracting the URL is a waste of time.
%URLF-4-SITE-BLOCKED: Access denied for the site `www.sports.com'; client 209.165.200.230:34557 server 209.165.201.2:80This message is logged when a request finds a match against one of the blocked domains in the exclusive-domain list or the corresponding entry in the IP cache.
%URLF-6-URL_ALLOWED:Access allowed for URL http://www.N2H2.com/; client 209.165.200.230:54123 server 192.168.0.1:80This message is logged for each URL request that is allowed by the vendor server (Websense or N2H2). It includes the allowed URL, source IP address, source port number, destination IP address, and destination port number. Longer URLs will be truncated to 300 bytes and then logged.
%URLF-6-URL_BLOCKED:Access denied URL http://www.google.com; client 209.165.200.230:54678 server 209.165.201.2:80This message is logged for each URL request that is blocked by the vendor server. It includes the blocked URL, source IP address, source port number, destination IP address, and destination port number. Longer URLs will be truncated to 300 bytes and then logged.
ip urlfilter cache
To configure cache parameters, use the ip urlfilter cache command in global configuration mode. To clear the configuration, use the no form of this command.
ip urlfilter cache number
no ip urlfilter cache number
Syntax Description
number
Maximum number of destination IP addresses that can be cached into the cache table. The default value is 5000.
Defaults
Maximum number of destination IP addresses is 5000.
The cache table is cleared out every 12 hours.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Usage Guidelines
The cache table consists of the most recently requested IP addresses and respective authorization status for each IP address.
The caching algorithm involves three parameters—the maximum number of IP addresses that can be cached, an idle time, and an absolute time. The algorithm also involves two timers—idle timer and absolute timer. The idle timer is a small periodic timer (1 minute) that checks to see whether the number of cached IP addresses in the cache table exceeds 80 percent of the maximum limit. If the cached IP addresses have exceeded 80 percent, it will start removing idle entries; if it has not exceeded 80 percent, it will quit and wait for the next cycle. The absolute timer is a large periodic timer (1 hour) that is used to remove all of the elapsed entries. (The age of an elapsed entry is greater than the absolute time.) An elapsed entry will also be removed during cache lookup.
The idle time value is fixed at 10 minutes. The absolute time value is taken from the vendor server look-up response, which is often greater than 15 hours. The absolute value for cache entries made out of exclusive-domains is 12 hours. The maximum number of cache entries is configurable by enabling the ip urlfilter cache command.
Note
Examples
The following example shows how to configure the cache table to hold a maximum of five destination IP addresses:
ip inspect name test http urlfilterip urlfilter cache 5ip urlfilter exclusive-domain permit .weapons.comip urlfilter exclusive-domain deny .nbc.comip urlfilter exclusive-domain permit www.cisco.comip urlfilter audit-trailip urlfilter alertip urlfilter server vendor websense 192.168.3.1Related Commands
clear ip urlfilter cache
Clears the cache table.
show ip urlfilter cache
Displays the destination IP addresses that are cached into the cache table.
ip urlfilter exclusive-domain
To add or remove a domain name to or from the exclusive domain list so that the firewall does not have to send lookup requests to the vendor server, use the ip urlfilter exclusive-domain command in global configuration mode. To remove a domain name from the exclusive domain name list, use the no form of this command.
ip urlfilter exclusive-domain {permit | deny} domain-name
no ip urlfilter exclusive-domain {permit | deny} domain-name
Syntax Description
Defaults
This command is not enabled.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Usage Guidelines
The ip urlfilter exclusive-domain command allows you to specify a list of domain names (exclusive domains) so that the firewall will not create a lookup request for the HTTP traffic that is destined for one of the domains in the exclusive list. Thus, you can avoid sending look-up requests to the web server for HTTP traffic that is destined for a host that is completely allowed to all users.
Flexibility when entering domain names is also provided; that is, the user can enter the complete domain name or a partial domain name.
Complete Domain Name
If the user adds a complete domain name, such as "www.cisco.com," to the exclusive domain list, all HTTP traffic whose URLs are destined for this domain (such as www.cisco.com/news and www.cisco.com/index) will be excluded from the URL filtering policies of the vendor server (Websense or N2H2), and on the basis of the configuration, the URLs will be permitted or blocked (denied).
Partial Domain Name
If the user adds only a partial domain name to the exclusive domain list, such as ".cisco.com," all URLs whose domain names end with this partial domain name (such as www.cisco.com/products and www.cisco.com/eng) will be excluded from the URL filtering policies of the vendor server (Websense or N2H2), and on the basis of the configuration, the URLs will be permitted or blocked (denied).
Examples
The following example shows how to add the complete domain name "www.cisco.com" to the exclusive domain name list. This configuration will block all traffic destined to the www.cisco.com domain.
ip urlfilter exclusive-domain deny www.cisco.comThe following example shows how to add the partial domain name ".cisco.com" to the exclusive domain name list. This configuration will permit all traffic destined to domains that end with .cisco.com.
ip urlfilter exclusive-domain permit .cisco.comip urlfilter max-request
To set the maximum number of outstanding requests that can exist at any given time, use the ip urlfilter max-request command in global configuration mode. To disable this function, use the no form of this command.
ip urlfilter max-request number
no ip urlfilter max-request number
Syntax Description
Defaults
Maximum number of requests is 1000.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Usage Guidelines
If the specified maximum number of outstanding requests is exceeded, new requests will be dropped.
Note
Examples
The following example shows how to configure the maximum number of outstanding requests to 950:
ip inspect name url_filter httpip urlfilter max-request 950Related Commands
ip inspect name
Defines a set of inspection rules.
ip urlfilter server vendor
Configures a vendor server for URL filtering.
ip urlfilter max-resp-pak
To configure the maximum number of HTTP responses that the firewall can keep in its packet buffer, use the ip urlfilter max-resp-pak command in global configuration mode. To return to the default, use the no form of this command.
ip urlfilter max-resp-pak number
no ip urlfilter max-resp-pak number
Syntax Description
Defaults
200 HTTP responses
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Usage Guidelines
When an HTTP request arrives at a Cisco IOS firewall, the firewall forwards the request to the web server while simultaneously sending a URL look-up request to the vendor server (Websense or N2H2). If the vendor server reply arrives before the HTTP response, the firewall will know whether to permit or block the HTTP response; if the HTTP response arrives before the vendor server reply, the firewall will not know whether to allow or block the response, so the firewall will drop the response until it hears from the vendor server. The ip urlfilter max-resp-pak command allows you to configure your firewall to store the HTTP responses in a buffer, which allows your firewall to store a maximum of 200 HTTP responses. Each response will remain in the buffer until an allow or deny message is received from the vendor server. If the vendor server reply allows the URL, the firewall will release the HTTP response from the buffer to the end user; if the vendor server reply denies the URL, the firewall will discard the HTTP response from the buffer and close the connection to both ends.
Examples
The following example shows how to configure your firewall to hold 150 HTTP responses:
ip urlfilter max-resp-pak 150ip urlfilter server vendor
To configure a vendor server for URL filtering, use the ip urlfilter server vendor command in global configuration mode. To remove a server from your configuration, use the no form of this command.
ip urlfilter server vendor {websense | n2h2} ip-address [port port-number] [timeout seconds] [retransmit number]
no ip urlfilter server vendor {websense | n2h2} ip-address [port port-number] [timeout seconds] [retransmit number]
Syntax Description
Defaults
A vendor server is not configured.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Usage Guidelines
Use the ip urlfilter server vendor command to configure a Websense or N2H2 server, which will interact with the Cisco IOS Firewall to filter HTTP requests on the basis of a specified policy—global filtering, user- or group-based filtering, keyword-based filtering, category-based filtering, or customized filtering.
If the firewall has not received a response from the vendor server within the time specified in the timeout seconds keyword and argument, the firewall will check the retransmit number keyword and argument configured for the vendor server. If the firewall has not exceeded the maximum retransmit tries allowed, it will resend the HTTP lookup request. If the firewall has exceeded the maximum retransmit tries allowed, it will delete the outstanding request from the queue and check the status of the allow mode value. The firewall will forward the request if the allow mode is on; otherwise, it will drop the request.
Primary and Secondary Servers
When users configure multiple vendor servers, the firewall will use only one server at a time—the primary server; all other servers are called secondary servers. When the primary server becomes unavailable for any reason, it becomes a secondary server and one of the secondary servers becomes the primary server.
A firewall marks a primary server as down when sending a request to or receiving a response from the server fails. When a primary server goes down, the system will go to the beginning of the configured servers list and try to activate the first server on the list. If the first server on the list is unavailable, it will try the second server on the list; the system will keep trying to activate a server until it is successful or until it reaches the end of the server list. If the system reaches the end of the server list, it will set a flag indicating that all of the servers are down, and it will enter allow mode.
Examples
The following example shows how to configure the Websense server for URL filtering:
ip inspect name test http urlfilterip urlfilter cache 5ip urlfilter exclusive-domain permit .weapons.comip urlfilter exclusive-domain deny .nbc.comip urlfilter exclusive-domain permit www.cisco.comip urlfilter audit-trailip urlfilter alertip urlfilter server vendor websense 192.168.3.1Related Commands
ip urlfilter urlf-server-log
To enable the logging of system messages on the URL filtering server, use the ip urlfilter urlf-server-log command in global configuration mode. To disable the logging of system messages, use the no form of this command.
ip urlfilter urlf-server-log
no ip urlfilter urlf-server-log
Syntax Description
This command has no arguments or keywords.
Defaults
This command is disabled.
Command Modes
Global configuration
Command History
12.2(11)YU
This command was introduced.
12.2(15)T
This command was integrated into Cisco IOS Release 12.2(15)T.
Usage Guidelines
Use the ip urlfilter urlf-server-log command to enable Cisco IOS to send a log request immediately after the URL lookup request. The firewall will not make a URL lookup request if the destination IP address is in the cache, but it will still make a log request to the server. (The log request contains the URL, host name, source IP address, and the destination IP address.) The server records the log request into its own log server so your can view this information as necessary.
Examples
The following example shows how to enable system message logging on the URL filter server:
ip urlfilter urlf-server-logip verify unicast reverse-path
Note
To enable Unicast Reverse Path Forwarding (Unicast RPF), use the ip verify unicast reverse-path command in interface configuration mode. To disable Unicast RPF, use the no form of this command.
ip verify unicast reverse-path [list]
no ip verify unicast reverse-path [list]
Syntax Description
Defaults
Unicast RPF is disabled.
Command Modes
Interface configuration mode
Command History
Usage Guidelines
Use the ip verify unicast reverse-path interface command to mitigate problems caused by malformed or forged (spoofed) IP source addresses that are received by a router. Malformed or forged source addresses can indicate denial of service (DoS) attacks on the basis of source IP address spoofing.
When Unicast RPF is enabled on an interface, the router examines all packets that are received on that interface. The router checks to ensure that the source address appears in the Forwarding Information Base (FIB) and that it matches the interface on which the packet was received. This "look backwards" ability is available only when Cisco Express Forwarding (CEF) is enabled on the router because the lookup relies on the presence of the FIB. CEF generates the FIB as part of its operation.
To use Unicast RPF, enable CEF switching or distributed CEF (dCEF) switching in the router. There is no need to configure the input interface for CEF switching. As long as CEF is running on the router, individual interfaces can be configured with other switching modes.
Note
Note
The Unicast Reverse Path Forwarding feature checks to determine whether any packet that is received at a router interface arrives on one of the best return paths to the source of the packet. The feature does this by doing a reverse lookup in the CEF table. If Unicast RPF does not find a reverse path for the packet, Unicast RPF can drop or forward the packet, depending on whether an ACL is specified in the Unicast Reverse Path Forwarding command. If an ACL is specified in the command, then when (and only when) a packet fails the Unicast RPF check, the ACL is checked to determine whether the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL). Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.
If no ACL is specified in the Unicast Reverse Path Forwarding command, the router drops the forged or malformed packet immediately and no ACL logging occurs. The router and interface Unicast RPF counters are updated.
Unicast RPF events can be logged by specifying the logging option for the ACL entries used by the Unicast Reverse Path Forwarding command. Log information can be used to gather information about the attack, such as source address, time, and so on.
Where to Use RPF in Your Network
Unicast RPF may be used on interfaces in which only one path allows packets from valid source networks (networks contained in the FIB). Unicast RPF may also be used in cases for which a router has multiple paths to a given network, as long as the valid networks are switched via the incoming interfaces. Packets for invalid networks will be dropped. For example, routers at the edge of the network of an Internet Service Provider (ISP) are likely to have symmetrical reverse paths. Unicast RPF may still be applicable in certain multi-homed situations, provided that optional Border Gateway Protocol (BGP) attributes such as weight and local preference are used to achieve symmetric routing.
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 Enhanced Internet Gateway Routing Protocol (EIGRP) variants are being used and unequal candidate paths back to the source IP address exist.
For example, routers at the edge of the network of an ISP are more likely to have symmetrical reverse paths than routers that are in the core of the ISP network. Routers that are in the core of the ISP network have no guarantee that the best forwarding path out of the router will be the path selected for packets returning to the router. In this scenario, you should use the new form of the command, ip verify unicast source reachable-via, if there is a chance of asymmetrical routing.
Examples
The following example shows that the Unicast Reverse Path Forwarding feature has been enabled on a serial interface:
ip cef! or "ip cef distributed" for RSP+VIP based routers!interface serial 5/0/0ip verify unicast reverse-pathThe 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 192.168.202.128/28 that has both inbound and outbound filters on the upstream interface. Be aware that ISPs are usually not single-homed. Hence, provisions for asymmetrical flows (when outbound traffic goes out one link and returns via a different link) need to be designed into the filters on the border routers of the ISP.
ip cef distributed!interface Serial 5/0/0description Connection to Upstream ISPip address 192.168.200.225 255.255.255.255no ip redirectsno ip directed-broadcastno ip proxy-arpip verify unicast reverse-pathip access-group 111 inip access-group 110 out!access-list 110 permit ip 192.168.202.128 10.0.0.31 anyaccess-list 110 deny ip any any logaccess-list 111 deny ip host 10.0.0.0 any logaccess-list 111 deny ip 172.16.0.0 255.255.255.255 any logaccess-list 111 deny ip 10.0.0.0 255.255.255.255 any logaccess-list 111 deny ip 172.16.0.0 255.255.255.255 any logaccess-list 111 deny ip 192.168.0.0 255.255.255.255 any logaccess-list 111 deny ip 209.165.202.129 10.0.0.31 any logaccess-list 111 permit ip any anyThe following example demonstrates the use of ACLs and logging with Unicast RPF. In this example, extended ACL 197 provides entries that deny or permit network traffic for specific address ranges. Unicast RPF is configured on interface Ethernet 0 to check packets arriving at that interface.
For example, packets with a source address of 192.168.201.10 arriving at interface Ethernet 0 are dropped because of the deny statement in ACL 197. In this case, the ACL information is logged (the logging option is turned on for the ACL entry) and dropped packets are counted per-interface and globally. Packets with a source address of 192.168.201.100 arriving at interface Ethernet 0 are forwarded because of the permit statement in ACL 197. ACL information about dropped or suppressed packets is logged (the logging option is turned on for the ACL entry) to the log server.
ip cef distributed!int eth0/1/1ip address 192.168.200.1 255.255.255.255ip verify unicast reverse-path 197!int eth0/1/2ip address 192.168.201.1 255.255.255.255!access-list 197 deny ip 192.168.201.0 10.0.0.63 any log-inputaccess-list 197 permit ip 192.168.201.64 10.0.0.63 any log-inputaccess-list 197 deny ip 192.168.201.128 10.0.0.63 any log-inputaccess-list 197 permit ip 192.168.201.192 10.0.0.63 any log-inputaccess-list 197 deny ip host 10.0.0.0 any log-inputaccess-list 197 deny ip 172.16.0.0 255.255.255.255 any log-inputaccess-list 197 deny ip 10.0.0.0 255.255.255.255 any log-inputaccess-list 197 deny ip 172.16.0.0 255.255.255.255 any log-inputaccess-list 197 deny ip 192.168.0.0 255.255.255.255 any log-inputRelated Commands
ip verify unicast source reachable-via
To enable Unicast Reverse Path Forwarding (Unicast RPF), use the ip verify unicast source reachable-via command in interface configuration mode. To disable Unicast RPF, use the no form of this command.
ip verify unicast source reachable-via {rx | any} [allow-default] [allow-self-ping] [list]
no ip verify unicast source reachable-via
Syntax Description
Command Default
Unicast RPF is disabled.
Command Modes
Interface configuration
Command History
Usage Guidelines
Use the ip verify unicast source reachable-via interface command to mitigate problems caused by malformed or forged (spoofed) IP source addresses that pass through a router. Malformed or forged source addresses can indicate DoS attacks on the basis of source IP address spoofing.
When Unicast RPF is enabled on an interface, the router examines all packets that are received on that interface. The router checks to make sure that the source address appears in the FIB. If the rx keyword is selected, the source address must match the interface on which the packet was received. If the any keyword is selected, the source address must be present only in the FIB. This ability to "look backwards" is available only when Cisco Express Forwarding (CEF) is enabled on the router because the lookup relies on the presence of the FIB. CEF generates the FIB as part of its operation.
Note
To use Unicast RPF, enable CEF switching or distributed CEF (dCEF) switching in the router. There is no need to configure the input interface for CEF switching. As long as CEF is running on the router, individual interfaces can be configured with other switching modes.
Note
Note
The Unicast Reverse Path Forwarding feature checks to determine whether any packet that is received at a router interface arrives on one of the best return paths to the source of the packet. The feature does this checking by doing a reverse lookup in the CEF table. If Unicast RPF does not find a reverse path for the packet, Unicast RPF can drop or forward the packet, depending on whether an ACL is specified in the Unicast Reverse Path Forwarding command. If an ACL is specified in the command, when (and only when) a packet fails the Unicast RPF check, the ACL is checked to determine whether the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL). Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.
If no ACL is specified in the ip verify unicast source reachable-via command, the router drops the forged or malformed packet immediately and no ACL logging occurs. The router and interface Unicast RPF counters are updated.
Unicast RPF events can be logged by specifying the logging option for the ACL entries that are used by the ip verify unicast source reachable-via command. Log information can be used to gather such information about the attack, as source address, time, and so on.
Strict Mode RPF
If the source address is in the FIB and reachable only through the interface on which the packet was received, the packet is passed. The syntax for this method is ip verify unicast source reachable-via rx.
Exists-Only (or Loose Mode) RPF
If the source address is in the FIB and reachable through any interface on the router, the packet is passed. The syntax for this method is ip verify unicast source reachable-via any.
Because this Unicast RPF option passes packets regardless of which interface the packet enters, it is often used on Internet Service Provider (ISP) routers that are "peered" with other ISP routers (where asymmetrical routing typically occurs). Packets using source addresses that have not been allocated on the Internet, which are often used for spoofed source addresses, are dropped by this Unicast RPF option. All other packets that have an entry in the FIB are passed.
allow-default
Normally, sources found in the FIB, but only by way of the default route will be dropped. Specifying the allow-default keyword option will override this behavior. You must specify the allow-default keyword in the command to permit Unicast RPF to successfully match on prefixes that are known through the default route to pass these packets.
allow-self-ping
This keyword allows the router to ping its own interface or interfaces. By default, when Unicast RPF is enabled, packets that are generated by the router and destined to the router are dropped, thereby, making certain troubleshooting and management tasks difficult to accomplish. Issue the allow-self-ping keyword to enable self-pinging.
Caution
Where to Use RPF in Your Network
Unicast RPF strict mode may be used on interfaces in which only one path allows packets from valid source networks (networks contained in the FIB). Unicast RPF strict mode may also be used in cases for which a router has multiple paths to a given network, as long as the valid networks are switched via the incoming interfaces. Packets for invalid networks will be dropped. For example, routers at the edge of the network of an ISP are likely to have symmetrical reverse paths. Unicast RPF strict mode may still be applicable in certain multihomed situations, provided that optional Border Gateway Protocol (BGP) attributes, such as weight and local preference, are used to achieve symmetric routing.
Note
Unicast RPF loose mode may be used on interfaces in which asymmetric paths allow packets from valid source networks (networks contained in the FIB). Routers that are in the core of the ISP network have no guarantee that the best forwarding path out of the router will be the path selected for packets returning to the router.
Examples
The following example uses a very simple single-homed ISP connection to demonstrate the concept of Unicast RPF. In this example, an ISP peering router is connected via a single serial interface to one upstream ISP. Hence, traffic flows into and out of the ISP will be symmetric. Because traffic flows will be symmetric, a Unicast RPF strict-mode deployment can be configured.
ip cef! or "ip cef distributed" for Route Switch Processor+Versatile Interface Processor-(RSP+VIP-) based routers.!interface Serial5/0/0description - link to upstream ISP (single-homed)ip address 192.168.200.225 255.255.255.252no ip redirectsno ip directed-broadcastsno ip proxy-arpip verify unicast source reachable-viaRelated Commands
ip vrf forwarding (server-group)
To configure the Virtual Private Network (VPN) routing and forwarding (VRF) reference of an authentication, authorization, and accounting (AAA) RADIUS server group, use the ip vrf forwarding command in server-group configuration mode. To enable server groups to use the global (default) routing table, use the no form of this command.
ip vrf forwarding vrf-name
no ip vrf forwarding vrf-name
Syntax Description
Defaults
Server groups use the global routing table.
Command Modes
Server-group configuration
Command History
Usage Guidelines
Use the ip vrf forwarding command to specify a VRF for a AAA RADIUS server group. This command enables dial users to utilize AAA servers in different routing domains.
Examples
The following example shows how to configure the VRF user to reference the RADIUS server in a different VRF server group:
aaa group server radius sg_globalserver-private 172.16.0.0 timeout 5 retransmit 3!aaa group server radius sg_waterserver-private 10.10.0.0 timeout 5 retransmit 3 key waterip vrf forwarding waterRelated Commands
ip-address (ca-trustpoint)
To specify a dotted IP address or an interface that will be included in the certificate request, use the ip-address command in ca-trustpoint configuration mode. To restore the default behavior, use the no form of this command.
ip-address {ip-address | interface}
no ip-address
Syntax Description
Defaults
You are prompted for the IP address during certificate enrollment.
Command Modes
Ca-trustpoint configuration
Command History
Usage Guidelines
Before you can issue this command, you must enable the crypto ca trustpoint command, which declares the certification authority (CA) that your router should use and enters ca-trustpoint configuration mode. The ip address command is a subcommand that allows you to specify a certificate enrollment parameter.
Use the ip-address command to include the IP address of the specified interface in the certificate request or to specify that an IP address should not be included in the certificate request.
If this command is enabled, you will not be prompted for an IP address during certificate enrollment.
Examples
The following example shows how to include the IP address of the Ethernet-0 interface in the certificate request for the trustpoint "frog":
crypto ca trustpoint frogenrollment url http://frog.phoobin.com/subject-name OU=Spiral Dept., O=tiedye.comip-address ethernet-0Related Commands
isakmp authorization list
To configure an Internet Key Exchange (IKE) shared secret using the authentication, authorization, and accounting (AAA) server in an Internet Security Association and Key Management Protocol (ISAKMP) profile, use the isakmp authorization list command in ISAKMP profile configuration mode. To disable the shared secret, use the no form of this command.
isakmp authorization list list-name
no isakmp authorization list list-name
Syntax Description
list-name
AAA authorization list used for configuration mode attributes or preshared keys for aggresive mode.
Defaults
No default behaviors or values
Command Modes
ISAKMP profile configuration
Command History
Usage Guidelines
This command allows you to retrieve a shared secret from an AAA server.
Examples
The following example shows that an IKE shared secret is configured using an AAA server on a router:
crypto isakmp profile vpnprofileisakmp authorization list ikessaaalistRelated Commands
