-
Cisco IOS IP Configuration Guide, Release 12.2
-
About Cisco IOS Software Documentation
-
Using Cisco IOS Software
-
IP Overview
- Part 1: IP Addressing and Services
- Part 2: IP Routing Protocols
-
Part 3: IP Multicast
-
Configuring IP Multicast Routing
-
Configuring Source Specific Multicast
-
Configuring Bidirectional PIM
-
Configuring Multicast Source Discovery Protocol
-
Configuring PGM Host and Router Assist
-
Configuring Unidirectional Link Routing
-
Using IP Multicast Tools
-
Configuring Router-Port Group Management Protocol
-
Configuring DVMRP Interoperability
-
-
Index
-
Table Of Contents
Assigning IP Addresses to Network Interfaces
Assigning Multiple IP Addresses to Network Interfaces
Disabling Classless Routing Behavior
Enabling IP Processing on a Serial Interface
Configuring Address Resolution Methods
Establishing Address Resolution
Configuring Local-Area Mobility
Mapping Host Names to IP Addresses
Assigning Host Names to IP Addresses
Using the DNS to Discover ISO CLNS Addresses
Providing Service to DNS Clients
Role of the Cisco IOS DNS Server as an Authoritative Name Server
Configuring the Router as a DNS Server
Configuring HP Probe Proxy Name Requests
Configuring the Next Hop Resolution Protocol
The Cisco Implementation of NHRP
Configuring a Static IP-to-NBMA Address Mapping for a Station
Statically Configuring a Next Hop Server
Configuring NHRP Authentication
Controlling the Triggering of NHRP
Triggering NHRP Based on Traffic Thresholds
Controlling the NHRP Packet Rate
Suppressing Forward and Reverse Record Options
Specifying the NHRP Responder Address
Changing the Time Period NBMA Addresses Are Advertised as Valid
Configuring a GRE Tunnel for Multipoint Operation
Configuring NHRP Server-Only Mode
Routing Assistance When IP Routing Is Disabled
ICMP Router Discovery Protocol
Enabling Integrated Routing and Bridging
Configuring Broadcast Packet Handling
Enabling Directed Broadcast-to-Physical Broadcast Translation
Forwarding UDP Broadcast Packets and Protocols
Establishing an IP Broadcast Address
Speeding Up Flooding of UDP Datagrams
Configuring Network Address Translation
Translating Inside Source Addresses
Configuring Static Translation
Configuring Dynamic Translation with an Access List
Configuring Dynamic Translation with a Route Map
Overloading an Inside Global Address
Translating Overlapping Addresses
Configuring Static Translation
Configuring Dynamic Translation
Providing TCP Load Distribution
Monitoring and Maintaining NAT
Deploying NAT Between an IP Phone and Cisco CallManager
Monitoring and Maintaining IP Addressing
Clearing Caches, Tables, and Databases
Specifying the Format of Network Masks
Displaying System and Network Statistics
Monitoring and Maintaining NHRP
Creating a Network from Separated Subnets Example
Serial Interfaces Configuration Example
HP Hosts on a Network Segment Example
Changing the Rate for Triggering SVCs Example
Applying NHRP Rates to Specific Destinations Example
NHRP on a Multipoint Tunnel Example
Flooding of IP Broadcasts Example
Dynamic Inside Source Translation Example
Overloading Inside Global Addresses Example
Translating Overlapping Address Example
Configuring IP Addressing
This chapter describes how to configure IP addressing. For a complete description of the IP addressing commands in this chapter, refer to the "IP Addressing Commands" chapter of the Cisco IOS IP Command Reference, Volume 1 of 3: Addressing and Services publication. To locate documentation of other commands that appear in this chapter, use the command reference master index, or search online.
IP Addressing Task List
A basic and required task for configuring IP is to assign IP addresses to network interfaces. Doing so enables the interfaces and allows communication with hosts on those interfaces using IP. Associated with this task are decisions about subnetting and masking the IP addresses.
To configure various IP addressing features, perform the tasks described in the following sections. The task in the first section is required; the tasks in remaining sections are optional.
•
Assigning IP Addresses to Network Interfaces (Required)
•
•
•
•
•
•
•
•
At the end of this chapter, the examples in the "IP Addressing Examples" section illustrate how you might establish IP addressing in your network.
Assigning IP Addresses to Network Interfaces
An IP address identifies a location to which IP datagrams can be sent. Some IP addresses are reserved for special uses and cannot be used for host, subnet, or network addresses. Table 3 lists ranges of IP addresses, and shows which addresses are reserved and which are available for use.
The official description of IP addresses is found in RFC 1166, Internet Numbers.
To receive an assigned network number, contact your Internet service provider (ISP).
An interface can have one primary IP address. To assign a primary IP address and a network mask to a network interface, use the following command in interface configuration mode:
Router(config-if)# ip address ip-address mask
Sets a primary IP address for an interface.
A mask identifies the bits that denote the network number in an IP address. When you use the mask to subnet a network, the mask is then referred to as a subnet mask.
Note
The tasks to enable or disable additional, optional, IP addressing features are contained in the following sections:
•
•
•
Assigning Multiple IP Addresses to Network Interfaces
Cisco IOS software supports multiple IP addresses per interface. You can specify an unlimited number of secondary addresses. Secondary IP addresses can be used in a variety of situations. The following are the most common applications:
•
•
•
Note
To assign multiple IP addresses to network interfaces, use the following command in interface configuration mode:
Router(config-if)# ip address ip-address mask secondary
Assigns multiple IP addresses to network interfaces.
Note
See the "Creating a Network from Separated Subnets Example" section at the end of this chapter for an example of creating a network from separated subnets.
Enabling Use of Subnet Zero
Subnetting with a subnet address of 0 is illegal and strongly discouraged (as stated in RFC 791) because of the confusion that can arise between a network and a subnet that have the same addresses. For example, if network 131.108.0.0 is subnetted as 255.255.255.0, subnet 0 would be written as 131.108.0.0—which is identical to the network address.
You can use the all 0s and all 1s subnet (131.108.255.0), even though it is discouraged. Configuring interfaces for the all 1s subnet is explicitly allowed. However, if you need the entire subnet space for your IP address, use the following command in global configuration mode to enable subnet 0:
Router(config)# ip subnet-zero
Enables the use of subnet zero for interface addresses and routing updates.
Disabling Classless Routing Behavior
By default, classless routing behavior is enabled on the router. When classless routing is in effect, if a router receives packets destined for a subnet of a network that has no network default route, the router forwards the packet to the best supernet route.
In Figure 1, classless routing is enabled in the router. Therefore, when the host sends a packet to 128.20.4.1, instead of discarding the packet, the router forwards the packet to the best supernet route.
Figure 1 IP Classless Routing
If you disable classless routing, and a router receives packets destined for a subnet of a network that has no network default route, the router discards the packet. Figure 2 shows a router in network 128.20.0.0 connected to subnets 128.20.1.0, 128.20.2.0, and 128.20.3.0. Suppose the host sends a packet to 128.20.4.1. Because there is no network default route, the router discards the packet.
Figure 2 No IP Classless Routing
To prevent the Cisco IOS software from forwarding packets destined for unrecognized subnets to the best supernet route possible, use the following command in global configuration mode:
Enabling IP Processing on a Serial Interface
You might want to enable IP processing on a serial or tunnel interface without assigning an explicit IP address to the interface. Whenever the unnumbered interface generates a packet (for example, for a routing update), it uses the address of the interface you specified as the source address of the IP packet. It also uses the specified interface address in determining which routing processes are sending updates over the unnumbered interface. Restrictions are as follows:
•
•
•
•
If you are configuring Intermediate System-to-Intermediate System (IS-IS) across a serial line, you should configure the serial interfaces as unnumbered, which allows you to conform with RFC 1195, which states that IP addresses are not required on each interface.
Note
To enable IP processing on an unnumbered serial interface, use the following command in interface configuration mode:
Router(config-if)# ip unnumbered type number
Enables IP processing on a serial or tunnel interface without assigning an explicit IP address to the interface.
The interface you specify must be the name of another interface in the router that has an IP address, not another unnumbered interface.
The interface you specify also must be enabled (listed as "up" in the show interfaces command display).
See the "Serial Interfaces Configuration Example" section at the end of this chapter for an example of how to configure serial interfaces.
Configuring Address Resolution Methods
The Cisco IP implementation allows you to control interface-specific handling of IP addresses by facilitating address resolution, name services, and other functions. The following sections describe how to configure address resolution methods:
•
•
•
•
•
Establishing Address Resolution
A device in the IP can have both a local address (which uniquely identifies the device on its local segment or LAN) and a network address (which identifies the network to which the device belongs). The local address is more properly known as a data link address because it is contained in the data link layer (Layer 2 of the OSI model) part of the packet header and is read by data-link devices (bridges and all device interfaces, for example). The more technically inclined person will refer to local addresses as MAC addresses, because the MAC sublayer within the data link layer processes addresses for the layer.
To communicate with a device on Ethernet, for example, the Cisco IOS software first must determine the 48-bit MAC or local data-link address of that device. The process of determining the local data-link address from an IP address is called address resolution. The process of determining the IP address from a local data-link address is called reverse address resolution.
The software uses three forms of address resolution: Address Resolution Protocol (ARP), proxy ARP, and Probe (similar to ARP). The software also uses the Reverse Address Resolution Protocol (RARP). ARP, proxy ARP, and RARP are defined in RFCs 826, 1027, and 903, respectively. Probe is a protocol developed by the Hewlett-Packard Company (HP) for use on IEEE-802.3 networks.
ARP is used to associate IP addresses with media or MAC addresses. Taking an IP address as input, ARP determines the associated media address. Once a media or MAC address is determined, the IP address or media address association is stored in an ARP cache for rapid retrieval. Then the IP datagram is encapsulated in a link-layer frame and sent over the network. Encapsulation of IP datagrams and ARP requests and replies on IEEE 802 networks other than Ethernet is specified by the Subnetwork Access Protocol (SNAP).
RARP works the same way as ARP, except that the RARP request packet requests an IP address instead of a local data-link address. Use of RARP requires a RARP server on the same network segment as the router interface. RARP often is used by diskless nodes that do not know their IP addresses when they boot. The Cisco IOS software attempts to use RARP if it does not know the IP address of an interface at startup. Also, Cisco routers can act as RARP servers by responding to RARP requests that they are able to answer. See the "Configure Additional File Transfer Functions" chapter in the Cisco IOS Configuration Fundamentals Configuration Guide to learn how to configure a router as a RARP server.
The tasks required to set address resolution are contained in the following sections:
•
Defining a Static ARP Cache
ARP and other address resolution protocols provide a dynamic mapping between IP addresses and media addresses. Because most hosts support dynamic address resolution, generally you need not specify static ARP cache entries. If you must define them, you can do so globally. Performing this task installs a permanent entry in the ARP cache. The Cisco IOS software uses this entry to translate 32-bit IP addresses into 48-bit hardware addresses.
Optionally, you can specify that the software respond to ARP requests as if it were the owner of the specified IP address. In case you do not want the ARP entries to be permanent, you have the option of specifying an ARP entry timeout period when you define ARP entries.
The following two tables list the tasks to provide static mapping between IP addresses and a media address.
Use either of the following commands in global configuration mode to specify that the software respond to ARP requests:
Use the following command in interface configuration mode to set the length of time an ARP cache entry will stay in the cache:
Router(config-if)# arp timeout seconds
Sets the length of time an ARP cache entry will stay in the cache.
To display the type of ARP being used on a particular interface and also display the ARP timeout value, use the show interfaces EXEC command. Use the show arp EXEC command to examine the contents of the ARP cache. Use the show ip arp EXEC command to show IP entries. To remove all nonstatic entries from the ARP cache, use the clear arp-cache privileged EXEC command.
Setting ARP Encapsulations
By default, standard Ethernet-style ARP encapsulation (represented by the arpa keyword) is enabled on the IP interface. You can change this encapsulation method to SNAP or HP Probe, as required by your network, to control the interface-specific handling of IP address resolution into 48-bit Ethernet hardware addresses.
When you set HP Probe encapsulation, the Cisco IOS software uses the Probe protocol whenever it attempts to resolve an IEEE-802.3 or Ethernet local data-link address. The subset of Probe that performs address resolution is called Virtual Address Request and Reply. Using Probe, the router can communicate transparently with HP IEEE-802.3 hosts that use this type of data encapsulation. You must explicitly configure all interfaces for Probe that will use Probe.
To specify the ARP encapsulation type, use the following command in interface configuration mode:
Router(config-if)# arp {arpa | probe | snap}
Specifies one of three ARP encapsulation methods for a specified interface.
Enabling Proxy ARP
The Cisco IOS software uses proxy ARP (as defined in RFC 1027) to help hosts with no knowledge of routing determine the media addresses of hosts on other networks or subnets. For example, if the router receives an ARP request for a host that is not on the same interface as the ARP request sender, and if the router has all of its routes to that host through other interfaces, then it generates a proxy ARP reply packet giving its own local data-link address. The host that sent the ARP request then sends its packets to the router, which forwards them to the intended host. Proxy ARP is enabled by default.
To enable proxy ARP if it has been disabled, use the following command in interface configuration mode (as needed) for your network:
Configuring Local-Area Mobility
Local-area mobility provides the ability to relocate IP hosts within a limited area without reassigning host IP addresses and without changes to the host software. Local-area mobility is supported on Ethernet, Token Ring, and FDDI interfaces only.
To create a mobility area with only one router, use the following commands in the interface configuration mode:
To create larger mobility areas, you must first redistribute the mobile routes into your Interior Gateway Protocol (IGP). The IGP must support host routes. You can use Enhanced Interior Gateway Routing Protocol (IGRP), Open Shortest Path First (OSPF), IS-IS, or RIPv2. To redistribute the mobile routes into your existing IGP configuration, use the following commands in configuration mode:
Mobile routes will always be preferred over a subnet boundary or summarized route because they are more specific. It is important to ensure that configured or redistributed static routes do not include any host routes for the potentially mobile hosts; otherwise, a longest match could come up with two routes and cause ambiguity. Mobile routes will be seen as external routes to the configured routing protocol, even within a summarization area; therefore, they will not be properly summarized by default. This is the case even when these routes are advertised at a summarization boundary, if mobile hosts are not on their home subnet.
Mapping Host Names to IP Addresses
Each unique IP address can have an associated host name. The Cisco IOS software maintains a cache of host name-to-address mappings for use by the connect, telnet, and ping EXEC commands, and related Telnet support operations. This cache speeds the process of converting names to addresses.
IP defines a naming scheme that allows a device to be identified by its location in the IP. This is a hierarchical naming scheme that provides for domains. Domain names are pieced together with periods (.) as the delimiting characters. For example, Cisco is a commercial organization that the IP identifies by a com domain name, so its domain name is cisco.com. A specific device in this domain, the File Transfer Protocol (FTP) system, for example, is identified as ftp.cisco.com.
To keep track of domain names, IP has defined the concept of a name server, whose job is to hold a cache (or database) of names mapped to IP addresses. To map domain names to IP addresses, you must first identify the host names, then specify a name server, and enable the Domain Naming System (DNS), the global naming scheme of the Internet that uniquely identifies network devices. These tasks are described in the following sections:
•
•
Assigning Host Names to IP Addresses
The Cisco IOS software maintains a table of host names and their corresponding addresses, also called a host name-to-address mapping. Higher-layer protocols such as Telnet use host names to identify network devices (hosts). The router and other network devices must be able to associate host names with IP addresses to communicate with other IP devices. Host names and IP addresses can be associated with one another through static or dynamic means.
Manually assigning host names to addresses is useful when dynamic mapping is not available.
To assign host names to addresses, use the following command in global configuration mode:
Router(config)# ip host name [tcp-port-number] address1 [address2...address8]
Statically associates host names with IP addresses.
Specifying the Domain Name
You can specify a default domain name that the Cisco IOS software will use to complete domain name requests. You can specify either a single domain name or a list of domain names. Any IP host name that does not contain a domain name will have the domain name you specify appended to it before being added to the host table.
To specify a domain name or names, use either of the following commands in global configuration mode:
See the "IP Domains Example" section at the end of this chapter for an example of establishing IP domains.
Specifying a Name Server
To specify one or more hosts (up to six) that can function as a name server to supply name information for the DNS, use the following command in global configuration mode:
Router(config)# ip name-server server-address1 [server-address2...server-address6]
Specifies one or more hosts that supply name information.
Enabling the DNS
If your network devices require connectivity with devices in networks for which you do not control name assignment, you can assign device names that uniquely identify your devices within the entire internetwork. The global naming scheme of the Internet, the DNS, accomplishes this task. This service is enabled by default.
To re-enable DNS if it has been disabled, use the following command in global configuration mode:
Router(config)# ip domain lookup
Enables DNS-based host name-to-address translation.
See the "Dynamic Lookup Example" section at the end of this chapter for an example of enabling the DNS.
Using the DNS to Discover ISO CLNS Addresses
If your router has both IP and ISO Connectionless Network Service (ISO CLNS) enabled and you want to use ISO CLNS network service access point (NSAP) addresses, you can use the DNS to query these addresses, as documented in RFC 1348. This feature is enabled by default.
To disable DNS queries for ISO CLNS addresses, use the following command in global configuration mode:
Router(config)# no ip domain-lookup nsap
Disables DNS queries for ISO CLNS addresses.
Providing Service to DNS Clients
To configure a router as a DNS server, you should understand the following concept:
Details about configuring a Cisco router as a DNS server are provided in the following sections:
•
•
DNS Overview
If your network devices require connectivity with devices in networks for which you do not control name assignment, you can assign device names that uniquely identify your devices within the entire internetwork. The global naming scheme of the Internet, the DNS, accomplishes this task. This service is enabled by default. The following sections summarize DNS concepts and function:
Host Names for Network Devices
Each unique IP address can have an associated host name. DNS uses a hierarchical scheme for establishing host names for network nodes. This allows local control of the segments of the network through a client-server scheme. The DNS system can locate a network device by translating the host name of the device into its associated IP address.
Domains Names for Groups of Networks
IP defines a naming scheme that allows a device to be identified by its location in the IP. This is a hierarchical naming scheme that provides for domains. On the Internet, a domain is a portion of the naming hierarchy tree that refers to general groupings of networks based on organization type or geography. Domain names are pieced together with periods (.) as the delimiting characters. For example, Cisco is a commercial organization that the IP identifies by a com domain name, so its domain name is cisco.com. A specific device in this domain, the File Transfer Protocol (FTP) system, for example, is identified as ftp.cisco.com.
Name Servers
To keep track of domain names, IP has defined the concept of a name server. Name servers are programs that have complete information about their namespace portion of the domain tree and may also contain pointers to other name servers that can be used to lead to information from any other part of the domain tree. Name servers know the parts of the domain tree for which they have complete information. A name server may also store information about other parts of the domain tree. To map domain names to IP addresses, you must first identify the host names, then specify a name server, and enable the DNS service.
Cache
To speed the process of converting names to addresses, the name server maintains a database, called a cache, of host name-to-address mappings for use by the connect, telnet, and ping EXEC commands, and related Telnet support operations. The cache stores the results from previous responses. Upon receiving a client-issued DNS query, it will check this local storage to see if the answer is available locally.
Name Resolvers
Name resolvers are programs that extract information from name servers in response to client requests. Resolvers must be able to access at least one name server. The resolver either uses that name server's information to answer a query directly or pursues the query using referrals to other names servers. A resolver will typically be a system routine that is directly accessible to user programs. Therefore, no protocol is necessary between the resolver and the user program.
Zones
The domain namespace is divided into areas called zones that are points of delegation in the DNS tree. A zone contains all domains from a certain point downward, except those for which other zones are authoritative.
Authoritative Name Servers
A name server is said to be an authority for the parts of the domain tree for which it has complete information. A zone usually has an authoritative name server, often more than one. An authoritative name server has been configured with host table information or has acquired host table information though a zone transfer (the action that occurs when a secondary DNS server starts up and updates itself from the primary server).
DNS Operation
Within an organization, you can have many name servers, but Internet clients can query only those that the root name servers know. The other name servers answer internal queries only.
A name server handles client-issued queries to the DNS server for locally defined hosts within a particular zone as follows:
•
•
Name servers answer DNS queries (forward incoming DNS queries or resolve internally generated DNS queries) according to the forwarding and lookup parameters configured for the specific domain.
Role of the Cisco IOS DNS Server as an Authoritative Name Server
An authoritative name server usually issues zone transfers or responds to zone transfer requests from other authoritative name servers for the same zone. However, the Cisco IOS DNS server does not perform zone transfers.
When it receives a DNS query, an authoritative name server handles the query as follows:
•
•
•
Configuring the Router as a DNS Server
Perform this task to configure the router as a DNS server.
A Cisco IOS router can provide service to DNS clients, acting as both a caching name server and as an authoritative name server for its own local host table.
When configured as a caching name server, the router relays DNS requests to other name servers that that resolve network names into network addresses. The caching name server caches information learned from other name servers so that it can answer requests quickly, without having to query other servers for each transaction.
When configured as an authoritative name server for its own local host table, the router listens on port 53 for DNS queries and then answers DNS queries using the permanent and cached entries in its own host table.
Note
To configure a Cisco IOS router as a DNS server, use the following commands in global configuration mode as needed:
Example Debugging Output
This section provides examples of debugging output that is logged when a router is configured as an authoritative name server for its own local host table and the debug domain command is in effect:
•
•
Note
Debugging Output for Relaying a DNS Query to Another Name Server: Example
The following is sample output from the debug domain command that corresponds to relaying a DNS query to another name server when the router is configured as an authoritative name server for its own local host table:
Apr 4 22:18:32.183: DNS: Incoming UDP query (id#18713)Apr 4 22:18:32.183: DNS: Type 1 DNS query (id#18713) for host 'ns1.example.com' from 192.0.2.120(1283)Apr 4 22:18:32.183: DNS: Re-sending DNS query (type 1, id#18713) to 192.0.2.121Apr 4 22:18:32.211: DNS: Incoming UDP query (id#18713)Apr 4 22:18:32.211: DNS: Type 1 response (id#18713) for host <ns1.example.com> from 192.0.2.121(53)Apr 4 22:18:32.215: DOM: dom2cache: hostname is ns1.example.com, RR type=1, class=1, ttl=86400, n=4Apr 4 22:18:32.215: DNS: Forwarding back A response - no director requiredApr 4 22:18:32.215: DNS: Finished processing query (id#18713) in 0.032 secsApr 4 22:18:32.215: DNS: Forwarding back reply to 192.0.2.120/1283Debugging Output for Servicing a DNS Query from the Local Host Table: Example
The following is sample output from the debug domain command that corresponds to servicing a DNS query from the local host table when the router is configured as an authoritative name server for its own local host table:
Apr 4 22:16:35.279: DNS: Incoming UDP query (id#8409)Apr 4 22:16:35.279: DNS: Type 1 DNS query (id#8409) for host 'ns1.example.com' from 192.0.2.120(1279)Apr 4 22:16:35.279: DNS: Finished processing query (id#8409) in 0.000 secsConfiguring HP Probe Proxy Name Requests
HP Probe Proxy support allows the Cisco IOS software to respond to HP Probe Proxy name requests. These requests are typically used at sites that have HP equipment and are already using HP Probe Proxy. Tasks associated with HP Probe Proxy are shown in the following two tables.
To configure HP Probe Proxy, use the following command in interface configuration mode:
Router(config-if)# ip probe proxy
Allows the Cisco IOS software to respond to HP Probe Proxy name requests.
To configure HP Probe Proxy, use the following command in global configuration mode:
Router(config)# ip hp-host hostname ip-address
Enters the host name of an HP host (for which the router is acting as a proxy) into the host table.
See the "HP Hosts on a Network Segment Example" section at the end of this chapter for an example of configuring HP hosts on a network segment.
Configuring the Next Hop Resolution Protocol
Routers, access servers, and hosts can use Next Hop Resolution Protocol (NHRP) to discover the addresses of other routers and hosts connected to a nonbroadcast multiaccess (NBMA) network. Partially meshed NBMA networks are typically configured with multiple logical networks to provide full network layer connectivity. In such configurations, packets might make several hops over the NBMA network before arriving at the exit router (the router nearest the destination network). In addition, such NBMA networks (whether partially or fully meshed) typically require tedious static configurations. These static configurations provide the mapping between network layer addresses (such as IP) and NBMA addresses (such as E.164 addresses for SMDS).
NHRP provides an ARP-like solution that alleviates these NBMA network problems. With NHRP, systems attached to an NBMA network dynamically learn the NBMA address of the other systems that are part of that network, allowing these systems to directly communicate without requiring traffic to use an intermediate hop.
The NBMA network is considered nonbroadcast either because it technically does not support broadcasting (for example, an X.25 network) or because broadcasting is too expensive (for example, an SMDS broadcast group that would otherwise be too large).
The Cisco Implementation of NHRP
The Cisco implementation of NHRP supports the IETF draft version 11 of NBMA Next Hop Resolution Protocol (NHRP).
The Cisco implementation of NHRP supports IP Version 4, Internet Packet Exchange (IPX) network layers, and, at the link layer, ATM, Ethernet, SMDS, and multipoint tunnel networks. Although NHRP is available on Ethernet, NHRP need not be implemented over Ethernet media because Ethernet is capable of broadcasting. Ethernet support is unnecessary (and not provided) for IPX.
Figure 3 illustrates four routers connected to an NBMA network. Within the network are ATM or SMDS switches necessary for the routers to communicate with each other. Assume that the switches have virtual circuit (VC) connections represented by hops 1, 2, and 3 of the figure. When Router A attempts to forward an IP packet from the source host to the destination host, NHRP is triggered. On behalf of the source host, Router A sends an NHRP request packet encapsulated in an IP packet, which takes three hops across the network to reach Router D, connected to the destination host. After receiving a positive NHRP reply, Router D is determined to be the "NBMA next hop," and Router A sends subsequent IP packets for the destination to Router D in one hop.
Figure 3 Next Hop Resolution Protocol
With NHRP, once the NBMA next hop is determined, the source either starts sending data packets to the destination (in a connectionless NBMA network such as SMDS) or establishes a virtual circuit VC connection to the destination with the desired bandwidth and quality of service (QoS) characteristics (in a connection-oriented NBMA network such as ATM).
Other address resolution methods can be used while NHRP is deployed. IP hosts that rely upon the Logical IP Subnet (LIS) model might require ARP servers and services over NBMA networks, and deployed hosts might not implement NHRP, but might continue to support ARP variations. NHRP is designed to eliminate the suboptimal routing that results from the LIS model, and can be deployed with existing ARP services without interfering with them.
NHRP is used to facilitate building a Virtual Private Network (VPN). In this context, a VPN consists of a virtual Layer 3 network that is built on top of an actual Layer 3 network. The topology you use over the VPN is largely independent of the underlying network, and the protocols you run over it are completely independent of it.
Connected to the NBMA network are one or more stations that implement NHRP, and are known as Next Hop Servers. All routers running Cisco IOS Release 10.3 or later releases can implement NHRP and, thus, can act as Next Hop Servers.
Each Next Hop Server serves a set of destination hosts, which might be directly connected to the NBMA network. Next Hop Servers cooperatively resolve the NBMA next hop addresses within their NBMA network. Next Hop Servers typically also participate in protocols used to disseminate routing information across (and beyond the boundaries of) the NBMA network, and might support ARP service.
A Next Hop Server maintains a "next hop resolution" cache, which is a table of network layer address to NBMA address mappings. The table is created from information gleaned from NHRP register packets extracted from NHRP request or reply packets that traverse the Next Hop Server as they are forwarded, or through other means such as ARP and preconfigured tables.
Protocol Operation
NHRP requests traverse one or more hops within an NBMA subnetwork before reaching the station that is expected to generate a response. Each station (including the source station) chooses a neighboring Next Hop Server to forward the request to. The Next Hop Server selection procedure typically involves performing a routing decision based upon the network layer destination address of the NHRP request. Ignoring error situations, the NHRP request eventually arrives at a station that generates an NHRP reply. This responding station either serves the destination, is the destination itself, or is a client that specified it should receive NHRP requests when it registered with its server. The responding station generates a reply using the source address from within the NHRP packet to determine where the reply should be sent.
NHRP Configuration Task List
To configure NHRP, perform the tasks described in the following sections. The tasks in the first section are required; the tasks in the remaining sections are optional.
•
•
•
•
•
•
•
•
•
•
•
•
Enabling NHRP on an Interface
To enable NHRP for an interface on a router, use the following command in interface configuration mode. In general, all NHRP stations within a logical NBMA network must be configured with the same network identifier.
See the "Logical NBMA Example" section and the "NHRP over ATM Example" section at the end of this chapter for examples of enabling NHRP.
Configuring a Static IP-to-NBMA Address Mapping for a Station
To participate in NHRP, a station connected to an NBMA network should be configured with the IP and NBMA addresses of its Next Hop Servers. The format of the NBMA address depends on the medium you are using. For example, ATM uses an NSAP address, Ethernet uses a MAC address, and SMDS uses an E.164 address.
These Next Hop Servers may also be the default or peer routers of the station, so their addresses can be obtained from the network layer forwarding table of the station.
If the station is attached to several link layer networks (including logical NBMA networks), the station should also be configured to receive routing information from its Next Hop Servers and peer routers so that it can determine which IP networks are reachable through which link layer networks.
To configure static IP-to-NBMA address mapping on a station (host or router), use the following command in interface configuration mode:
Router(config-if)# ip nhrp map ip-address nbma-address
Configures static IP-to-NBMA address mapping.
Statically Configuring a Next Hop Server
A Next Hop Server normally uses the network layer forwarding table to determine where to forward NHRP packets, and to find the egress point from an NBMA network. A Next Hop Server may alternately be statically configured with a set of IP address prefixes that correspond to the IP addresses of the stations it serves, and their logical NBMA network identifiers.
To statically configure a Next Hop Server, use the following command in interface configuration mode:
Router(config-if)# ip nhrp nhs nhs-address [net-address [netmask]]
Statically configures a Next Hop Server.
To configure multiple networks that the Next Hop Server serves, repeat the ip nhrp nhs command with the same Next Hop Server address, but different IP network addresses. To configure additional Next Hop Servers, repeat the ip nhrp nhs command.
Configuring NHRP Authentication
Configuring an authentication string ensures that only routers configured with the same string can communicate using NHRP. Therefore, if the authentication scheme is to be used, the same string must be configured in all devices configured for NHRP on a fabric. To specify the authentication string for NHRP on an interface, use the following command in interface configuration mode:
Router(config-if)# ip nhrp authentication string
Specifies an authentication string.
Controlling the Triggering of NHRP
On any platform, there are two ways to control when NHRP is triggered. These methods are described in the following sections:
•
•
Triggering NHRP by IP Packets
You can specify an IP access list that is used to decide which IP packets can trigger the sending of NHRP requests. By default, all non-NHRP packets trigger NHRP requests. To limit which IP packets trigger NHRP requests, define an access list and then apply it to the interface.
To define an access list, use the following commands in global configuration mode as needed:
To apply the IP access list to the interface, use the following command in interface configuration mode:
Router(config-if)# ip nhrp interest access-list-number
Specifies an IP access list that controls NHRP requests.
Triggering NHRP on a per-Destination Basis
By default, when the software attempts to send a data packet to a destination for which it has determined that NHRP can be used, it sends an NHRP request for that destination. To configure the system to wait until a specified number of data packets have been sent to a particular destination before NHRP is attempted, use the following command in interface configuration mode:
Router(config-if)# ip nhrp use usage-count
Specifies how many data packets are sent to a destination before NHRP is attempted.
Triggering NHRP Based on Traffic Thresholds
NHRP can run on Cisco Express Forwarding (CEF) platforms when NHRP runs with BGP over ATM media. You can configure NHRP to initiate switched virtual circuits (SVCs) once a configured traffic rate is reached. Similarly, SVCs can be torn down when traffic falls to another configured rate.
Prior to Cisco IOS Release 12.0, a single packet could trigger an SVC. Now you can configure the traffic rate that must be reached before NHRP sets up or tears down an SVC. Because SVCs are created only for burst traffic, you can conserve resources.
Restrictions
Cisco IOS releases prior to Release 12.0 implemented NHRP draft version 4. Cisco IOS Release 12.0 and later implements NHRP draft version 11. These versions are not compatible. Therefore, all routers running NHRP in a network must run the same version of NHRP in order to communicate with each other. All routers must run Cisco IOS Release 12.0 and later, or all routers must run a release prior to Release 12.0, but not a combination of the two.
Additional restrictions:
•
•
•
Prerequisites
Before you configure the feature whereby NHRP initiation is based on traffic rate, the following conditions must exist in the router:
•
•
•
If you have CEF switching or dCEF switching and you want NHRP to work (whether with default values or changed values), the ip cef accounting non-recursive command must be configured.
NHRP Configuration Task List
To configure the NHRP triggering and teardown of SVCs based on traffic rate, perform the tasks described in the following sections. The tasks in the first section are required, the tasks in the remaining section are optional.
•
•
Changing the Rate for Triggering SVCs
When NHRP runs with BGP over ATM media, there is an additional way to control the triggering of NHRP packets. This method consists of SVCs being initiated based on the input traffic rate to a given BGP next hop.
When BGP discovers a BGP next hop and enters this BGP route into the routing table, an NHRP request is sent to the BGP next hop. When an NHRP reply is received, a subsequent route is put in the NHRP cache that directly corresponds to the BGP next hop.
A new NHRP request is sent to the same BGP next hop to repopulate the NHRP cache. When an NHRP cache entry is generated, a subsequent ATM map statement to the same BGP next hop is also created.
Aggregate traffic to each BGP next hop is measured and monitored. Once the aggregate traffic has met or exceeded the configured trigger rate, NHRP creates an ATM SVC and sends traffic directly to that destination router. The router tears down the SVC to the specified destination(s) when the aggregate traffic rate falls to or below the configured teardown rate.
By default, NHRP will set up an SVC for a destination when aggregate traffic for that destination is more than 1 kbps over a running average of 30 seconds. Similarly, NHRP will tear down the SVC when the traffic for that destination drops to 0 k
