-
Access and Communication Servers Configuration Guide
-
About This Manual
-
Access and Comms Server Product Overview
-
Understanding the User Interface
-
Loading System Images and Config. Files
-
Managing the System
-
Configuring Interfaces
-
Configuring Dial on Demand Routing
-
Configuring LAPB and X.25
-
Configuring Frame Relay
-
Configuring SMDS
-
Configuring Telnet
-
Configuring LAT
-
Configuring TN3270
-
Configuring AppleTalk Remote Access
-
Configuring SLIP and PPP
-
Configuring XRemote
-
Configuring AppleTalk Routing
-
Configuring IP
-
Configuring IP Routing
-
Configuring Novell IPX
-
Configuring Protocol Translation
-
Table Of Contents
Assign IP Addresses to Network Interfaces
Assign Multiple IP Addresses to Network Interfaces
Enable IP Processing on a Serial Interface
Configure IP Addressing Options
Map Host Names to IP Addresses
Map IP Addresses to Host Names
Configure HP Probe Proxy Name Requests
Configure the Next Hop Resolution Protocol
Cisco's Implementation of NHRP
Configure a Station's Static IP-to-NBMA Address Mapping
Statically Configure a Next Hop Server (Server Mode)
Suppress Forward and Reverse Record Options
Specify the NHRP Responder Address
Change the Time Period NBMA Addresses Are Advertised as Valid
Configure a GRE Tunnel for Multipoint Operation
Routing Assistance When IP Routing Is Disabled
Configure Broadcast Packet Handling
Enable Directed Broadcast-to-Physical Broadcast Translation
Forward UDP Broadcast Packets and Protocols
Establish an IP Broadcast Address
Disable ICMP Protocol Unreachable Messages
Disable ICMP Redirect Messages
Enable ICMP Mask Reply Messages
Create Standard and Extended Access Lists
Apply an Access List to an Interface or Terminal Line
Configure the Hot Standby Router Protocol
Configure Basic IP Security Options
Enable IPSO and Set the Security Classifications
Specify How IP Security Options Are Processed
Configure Extended IP Security Options
Configure Global Default Settings
Configure the DNSIX Audit Trail Facility
Enable the DNSIX Audit Trail Facility
Specify Hosts to Receive Audit Trail Messages
Specify Transmission Parameters
Configure Performance Parameters
Set the TCP Connection Attempt Time
Control Route Cache Invalidation
Monitor and Maintain the IP Network
Clear Caches, Tables, and Databases
Clear the Access List Counters
Specify the Format of Network Masks
Display System and Network Statistics
Serial Interfaces Configuration Example
Creating a Network from Separated Subnets Example
Establishing IP Domains Example
Configuring HP Hosts on a Network Segment Example
Customizing ICMP Services Example
Examples of Implicit Masks in Access Lists
Examples of Configuring Extended Access Lists
NHRP on a Multipoint Tunnel Example
Configuring IP
The Internet Protocol (IP) is a packet-based protocol used to exchange data over computer networks. IP handles addressing, fragmentation, reassembly, and protocol demultiplexing. It is the foundation on which all other IP protocols, collectively referred to as the IP Protocol suite, are built. IP is a network-layer protocol that contains addressing and control information that allows data packets to be routed.
The Transmission Control Protocol (TCP) is built upon the IP layer. TCP is a connection-oriented protocol that specifies the format of data and acknowledgments used in the transfer of data. TCP also specifies the procedures that the computers use to ensure that the data arrives correctly. TCP allows multiple applications on a system to communicate concurrently because it handles all demultiplexing of the incoming traffic among the application programs.
This chapter describes how to configure the IP protocol. For a complete description of the commands in this chapter, refer to the "IP Commands" chapter of the Access and Communication Servers Command Reference publication. For information on configuring the various IP routing protocols, refer to the "Configuring IP Routing Protocols" chapter of this manual.
Cisco's Implementation of IP
Cisco's implementation of IP provides most of the major services contained in the various protocol specifications. Cisco access servers also provide the TCP and User Datagram Protocol (UDP) services called Echo and Discard, which are described in RFCs 862 and 863, respectively.
Cisco supports both TCP and UDP at the transport layer, for maximum flexibility in services. Cisco also supports all standards for IP broadcasts.
IP Configuration Task List
A number of tasks are associated with configuring IP. 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 IP, complete the tasks in the following sections:
•
Assign IP Addresses to Network Interfaces
•
•
•
•
•
•
•
•
•
•
•
Remember that not all of the tasks in these sections are required. The tasks you need to perform will depend on your network and your needs.
At the end of this chapter, the examples in the "IP Configuration Examples" section illustrate how you might configure your network using IP.
Assign IP Addresses to Network Interfaces
IP addresses identify locations to which IP datagrams can be sent. See the Internetworking Technology Overview publication for detailed information on IP addresses.
Some IP addresses are reserved for special uses and cannot be used for host, subnet, or network addresses. lists ranges of IP addresses and shows which addresses are reserved and which are available for use.
Table 18-1
Reserved and Available IP Addresses
The official description of IP addresses is found in RFC 1166, "Internet Numbers."
To receive an assigned network number, contact your Internet service provider.
To assign an IP address and a network mask to a network interface on the access server, perform the following task in interface configuration mode:
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. Subnets are described in the Internetworking Technology Overview publication.
Note
The tasks required to enable additional, optional, IP addressing features are contained in the following sections:
•
•
Assign Multiple IP Addresses to Network Interfaces
The 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, perform the following task in interface configuration mode:
Assign multiple IP addresses to network interfaces.
ip address ip-address mask secondary
Note
See the "IP Configuration Examples" section at the end of the chapter for an example of creating a network from separated subnets.
Enable Use of Subnet Zero
Subnetting with a subnet address of zero 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 172.16.0.0 is subnetted as 255.255.255.0, subnet zero would be written as 172.16.0.0—which is identical to the network address.
You can use the all zeros and all ones subnet (172.16.255.0), even though it is discouraged. Configuring interfaces for the all ones subnet is explicitly allowed. However, if you need the entire subnet space for your IP address, perform the following task in global configuration mode to enable subnet zero:
Enable the use of subnet zero for interface addresses and routing updates.
ip subnet-zero
Enable 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:
•
•
•
•
Note
To enable IP processing on an unnumbered serial interface, perform the following task in interface configuration mode:
Enable IP processing on a serial or tunnel interface without assigning an explicit IP address to the interface.
ip unnumbered type number
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 must also be enabled (listed as "up" in the show interfaces command display).
An example of how to configure serial interfaces can be found in the "IP Configuration Examples" section at the end of the chapter.
Configure IP Addressing Options
With our IP implementation, you can control interface-specific handling of IP addresses by facilitating address resolution, name services, and other functions. The following sections describe how to configure IP addressing options:
•
•
Establish 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 the device belongs to. 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 will refer to local addresses as MAC addresses, because the Media Access Control (MAC) sublayer within the data link layer processes addresses for the layer.
To communicate with a device on Ethernet, for example, the access server 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 access server uses three forms of address resolution: Address Resolution Protocol (ARP), proxy ARP, and Probe (which is similar to ARP). The access server also uses the Reverse Address Resolution Protocol (RARP). The ARP, proxy ARP, and RARP protocols are defined in RFCs 826, 1027, and 903, respectively. Probe is a protocol developed by the Hewlett-Packard Company for use on IEEE-802.3 networks.
The Address Resolution Protocol (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/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).
The Reverse Address Resolution Protocol (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 access server interface. RARP often is used by diskless nodes that do not know their IP addresses when they boot. Our access servers attempt to use RARP if they do not know the IP address of an interface at startup. Also, the access servers are able to act as RARP servers by responding to RARP requests that they are able to answer. See the "Loading System Images and Configuration Files" chapter to learn how to configure an access server as a RARP server.
Perform the following tasks to set address resolution on the access server:
•
•
•
The procedures for performing these tasks are described in the following sections.
Define 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, you generally do not need to specify static ARP cache entries. If you do need to define them, you can do so globally. Doing this task installs a permanent entry in the ARP cache. The access server uses this entry to translate 32-bit IP addresses into 48-bit hardware addresses.
Optionally, you can specify that the access server respond to ARP requests as if it were the owner of the specified IP address, and you also have the option of specifying an ARP entry timeout period when you define ARP entries.
The following two tables list the tasks to provide dynamic mapping between IP addresses and media address.
Perform either of the following tasks in global configuration mode:
Perform the following task in interface configuration mode:
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 privileged EXEC command clear arp-cache.
Set 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 access server 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 access server can communicate transparently with Hewlett-Packard 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, perform the following task in interface configuration mode:
Specify one of three ARP encapsulation methods for a specified interface.
arp {arpa | probe | snap}
Disable Proxy ARP
The access server 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 access server receives an ARP request for a host that is not on the same network as the ARP request sender, and if the access server has the best route to that host, then the access server sends an ARP reply packet giving its own local data link address. The host that sent the ARP request then sends its packets to the access server, which forwards them to the intended host. Proxy ARP is enabled by default.
To disable proxy ARP, perform the following task in interface configuration mode, as necessary, for your network:
Map Host Names to IP Addresses
Each unique IP address can have a host name associated with it. The access server maintains a cache of host name-to-address mappings for use by the EXEC connect, telnet, ping 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 Systems 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 it 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 Name System (DNS), the Internet's global naming scheme that uniquely identifies network devices. You do these by performing the following tasks:
•
The following sections describe these tasks.
Map IP Addresses to Host Names
The access server maintains a table of host names and their corresponding addresses, also called host name-to-address mapping. Higher-layer protocols such as Telnet use host names to identify network devices (hosts). The access server 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, perform the following task in global configuration mode:
Statically associate host names with IP addresses.
ip host hostname [tcp-port-number] address1
[address2...address8]
Specify the Domain Name
You can specify a default domain name that the access server 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, perform either of the following tasks in global configuration mode:
See the "IP Configuration Examples" section at the end of this chapter for an example of establishing IP domains.
Specify 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 Domain Name System (DNS), perform the following task in global configuration mode:
Specify one or more hosts that supply name information.
ip name-server server-address1
[[server-address2]...server-address6]
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 Internet's global naming scheme, the DNS, accomplishes this task. This service is enabled by default.
Disable the DNS
To disable the DNS, perform the following task in global configuration mode:
See the "IP Configuration Examples" section at the end of this chapter for an example of enabling the DNS.
Configure HP Probe Proxy Name Requests
HP Probe Proxy support allows an access server to respond to HP Probe Proxy name requests. These requests are typically used at sites that have Hewlett-Packard (HP) equipment and are already using HP Probe. Tasks associated with HP Probe Proxy are shown in the following two tables.
To configure HP Probe Proxy, perform the following task in interface configuration mode:
Perform the following task in global configuration mode:
Enter the host name of an HP host (for which the access server is acting as a proxy) into the host table.
ip hp-host hostname ip-address
See the "IP Configuration Examples" section at the end of this chapter for an example of configuring HP hosts on a network segment.
Configure the Next Hop Resolution Protocol
Access servers and hosts can use Next Hop Resolution Protocol (NHRP) to discover the addresses of other access servers and hosts connected to a nonbroadcast, multiaccess (NBMA) network. In the past, partially meshed NBMA networks had to be configured with overlapping LIS (logically independent IP subnets). In such configurations, packets might have had to make several hops over the NBMA network before arriving at the exit access server (the access server nearest the destination network). In addition, such NBMA networks (whether partially or fully meshed) have typically required tedious static configurations. These static configurations provided 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 can dynamically learn the NBMA address of the other systems that are part of that network. These systems can then directly communicate without using an intermediate hop, which reduces traffic.
The NBMA network can be considered anonbroadcast network either because it technically does not support broadcasting (for example, an X.25 network) or because broadcasting is not feasible (for example, an SMDS broadcast group or an extended Ethernet that would be too large).
Cisco's Implementation of NHRP
Cisco's initial implementation of NHRP supports only IP Version 4. Currently, NHRP can run on ATM, Ethernet, SMDS, and multipoint tunnel networks. Although NHRP is available on Ethernet, it is not necessary to implement NHRP over Ethernet media because Ethernet is capable of broadcasting.
Figure 18-1 Next Hop Resolution Protocol (NHRP)
illustrates four access servers connected to an NBMA network. Within the network are ATM or SMDS switches necessary for the access servers to communicate with each other. Assume that the switches have virtual circuit connections represented by hops 1, 2, and 3 of the figure. When Access Server A attempts to forward an IP packet from the source host to the destination host, NHRP is triggered. On behalf of the source host, Access Server A sends an NHRP request packet encapsulated in an IP packet, which takes three hops across the network to reach Access Server D, connected to the destination host. After receiving a positive NHRP reply, Access Server D is determined to be the "NBMA next hop," and Access Server A sends subsequent IP packets for the destination to Access Server D in one hop.
With NHRP, once the NBMA next hop is determined, the source can either start sending IP packets to the destination (in a connectionless NBMA network such as SMDS) or first establish a 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 in use while NHRP is deployed. Hosts that can use only the 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 uses a virtual private network, which is a virtual Layer 3 network that is built on top of an actual Layer 3 network. The topology you can use over the virtual private network can be largely independent of the underlying network, and the protocols you run over it can be completely independent of it.
Connected to the NBMA network are one or more Next Hop servers, which implement NHRP. All of our access servers are capable of implementing NHRP and thus can act as Next Hop servers. A host or access server that is not an NHRP speaker must be configured with the identity of the Next Hop server that serves it.
Each Next Hop server serves a set of destination hosts, which might or might not be directly connected to the NBMA network. Next Hop servers cooperatively resolve the NBMA next hop addresses within their NBMA network. In addition to NHRP, Next Hop servers typically support protocols used to disseminate routing information across (and beyond the boundaries of) the NBMA network\ and might support ARP service also.
A Next Hop server maintains a "next-hop resolution" cache, which is a table of IP-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.
Modes of Operation
NHRP supports two modes of operation: server mode and fabric mode. The modes differ in the way the Next Hop server updates the destination address in the IP packet containing the NHRP Request.
Hosts attached directly to the NBMA network have no knowledge of whether NHRP is deployed in server or fabric mode and host configuration is the same in each case. Regardless of which mode is used, NHRP clients must be configured with the IP address and NBMA address of at least one Next Hop server. In practice, a host's default access server should also be its Next Hop server.
Fabric Mode
In fabric mode, it is expected that all access servers within the NBMA network are NHRP-capable. A Next Hop server that serves a destination must lie along the routed path to that destination. In practice, this means that all egress access servers must double as Next Hop servers serving the destinations beyond them, and that hosts on the NBMA network are served by access servers that double as Next Hop servers.
Server Mode
In server mode, there are few Next Hop servers in an NBMA network. This might occur in networks that have access servers that do not support NHRP or networks that have many directly attached hosts and relatively few access servers.
Server mode requires static configuration of Next Hop server identity in the client stations (hosts or access servers). The client station must be configured with the IP address of one or more Next Hop servers, and there must be a path to that Next Hop server (either directly, in which case the Next Hop server's NBMA address must be known, or indirectly, through an access server whose NBMA address is known). If there are multiple Next Hop servers, they must be configured with each others' addresses, the identities of the destinations they each serve, and a logical NBMA network identifier. (This static configuration requirement, which might also involve authentication, tends to limit the number of Next Hop servers.)
If the NBMA network offers a group addressing or multicast feature, the client station can be configured with a group address assigned to the group of Next Hop servers. The client might then submit NHRP requests to the group address, eliciting a response from one or more Next Hop servers, depending on the response strategy selected.
The servers can also be configured with the group or multicast address of their peers, and a Next Hop server might use this address to forward NHRP requests that its peers cannot satisfy. This might elicit a response (to the Next Hop server) from one or more Next Hop servers, depending on the response strategy. The Next Hop server would then forward the NHRP reply to the NHRP request originator. The purpose of using group addressing or a similar multicast mechanism in this scenario is to eliminate the need to preconfigure each Next Hop server in a logical NBMA network with both the individual identities of other Next Hop servers and the destinations they serve. It reduces the number of Next Hop servers that might be used to process an NHRP request (in those configurations where Next Hop servers either respond or forward via the multicast, only two Next Hop servers would be traversed) and allows the Next Hop server that serves the NHRP request originator to cache next hop information associated with the reply.
NHRP Configuration Task List
To configure NHRP, perform the tasks described in the following sections. The first task is required, the remainder are optional.
•
•
•
•
•
•
•
For NHRP configuration examples, see the section "NHRP Configuration Examples" later in this chapter.
Enable NHRP on an Interface
To enable NHRP for an interface on an access server, perform the following task in interface configuration mode. In general, all NHRP stations within a logical NBMA network must be configured with the same network identifier.
For an example of enabling NHRP, see the section "Enabling NHRP Example" at the end of this chapter.
Configure a Station's Static IP-to-NBMA Address Mapping
To participate in NHRP, a station connected to an NBMA network should be configured with the IP and NBMA addresses of its Next Hop server(s).
Alternatively, the station should be configured with a means of acquiring those addresses, that is, the group address that can be used to reach the Next Hop servers.
A third possibility is that the Next Hop servers can be physically located on the stations's default or peer access servers, so their IP addresses can be obtained from the station's IP forwarding table.
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 access servers 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 access server), perform the following task in interface configuration mode:
Statically Configure a Next Hop Server (Server Mode)
A Next Hop server is configured with its own identity, a set of IP address prefixes that correspond to the IP addresses of the stations it serves, a logical NBMA network identifier, and in the case of server mode, the identities of other Next Hop servers in the same logical NBMA network. If a served station is attached to several link layer networks, the Next Hop server might also need to be configured to advertise routing information to such stations.
If a Next Hop server acts as an egress access server for stations connected to link layer networks other than the NBMA network, the Next Hop server must also be configured to exchange routing information between the NBMA network and these other link layer networks.
In all cases, routing information is exchanged using conventional intradomain or interdomain routing protocols.
To statically configure a Next Hop server, perform the following task in interface configuration mode:
Statically configure a Next Hop server.
ip nhrp nhs nhs-address [net-address [netmask]]
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.
In the absence of static address configurations, a Next Hop server operates in fabric mode and must itself learn the NBMA addresses of the stations it serves dynamically through NHRP.
Configure NHRP Authentication
Configuring an authentication string ensures that only access servers configured with the same string can intercommunicate using NHRP. Therefore, if the authentication scheme is to be used, the same string must be configured in all access servers that are configured for NHRP on a fabric. To specify the authentication string for NHRP on an interface, perform the following task in interface configuration mode:
Control NHRP Initiation
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 can trigger NHRP requests. To limit which IP packets trigger NHRP requests, you must define an access list and then apply it to the interface.
To define an access list, perform one of the following tasks in global configuration mode:
Then apply the IP access list to the interface by performing the following task in interface configuration mode:
Specify an IP access list that controls NHRP requests.
ip nhrp interest access-list-number
Suppress Forward and Reverse Record Options
To dynamically detect link-layer filtering in NBMA networks (for example, X.25 closed user group facility, or SMDS address screens) and to provide loop detection and diagnostic capabilities, NHRP incorporates a Route Record in requests and replies. The Route Record options contain the network (and link layer) addresses of all intermediate Next Hop servers between source and destination (in the forward direction) and between destination and source (in the reverse direction).
By default, forward record options and reverse record options are included in NHRP request and reply packets. To suppress the use of these options, perform the following task in interface configuration mode:
Specify the NHRP Responder Address
If an NHRP requestor wants to know which Next Hop server generates an NHRP reply packet, it can request that information by including the responder address option in its NHRP request packet. The Next Hop server that generates the NHRP reply packet then complies by inserting its own IP address in the NHRP reply. The Next Hop server uses the primary IP address of the specified interface.
To specify which interface the Next Hop server uses for the NHRP responder IP address, perform the following task in interface configuration mode.
Specify which interface the Next Hop server uses to determine the NHRP responder address.
ip nhrp responder interface-type interface-number
If an NHRP reply packet being forwarded by a Next Hop server contains that Next Hop server's own IP address, the Next Hop server generates an Error Indication of type "NHRP Loop Detected" and discards the reply.
Change the Time Period NBMA Addresses Are Advertised as Valid
You can change the length of time that NBMA addresses are advertised as valid in positive and negative NHRP responses. In this context, "advertised" means how long the access server tells other access servers to keep the addresses it is providing in NHRP responses. The default length of time for each response is 7200 seconds (2 hours). To change the length of time, perform the following task in interface configuration mode:
Specify the number of seconds that NBMA addresses are advertised as valid in positive or negative NHRP responses.
ip nhrp holdtime seconds-positive [seconds-negative]
Configure a GRE Tunnel for Multipoint Operation
You can enable a generic route encapsulation (GRE) tunnel to operate in multipoint fashion. A tunnel network of multipoint tunnel interfaces can be thought of as an NBMA network. To configure the tunnel, perform the following tasks in interface configuration mode:
Enable a GRE tunnel to be used in multipoint fashion.
tunnel mode gre multipoint
Configure a tunnel identification key.
tunnel key key-number
The tunnel key should correspond to the NHRP network identifier specified in the ip nhrp network-id command. For an example of NHRP configured on a multipoint tunnel, see the section "NHRP on a Multipoint Tunnel Example" later in this chapter.
Monitor and Maintain NHRP
To monitor the NHRP cache or traffic, perform either of the following tasks in EXEC mode:
The NHRP cache can contain static entries caused by statically configured addresses and dynamic entries caused by the access server learning addresses from NHRP packets. To clear static entries, use the no ip nhrp map command. To clear the NHRP cache of dynamic entries, perform the following task in EXEC mode:
Disable IP Routing
Every access server ships with IP routing automatically enabled. If you choose to set up the access server to bridge rather than route IP datagrams, you must disable IP routing. To disable IP routing, perform the following task in global configuration mode:
When IP routing is disabled, the access server will act as an IP end host for IP packets destined for or sourced by it, whether or not bridging is enabled for those IP packets not destined for the access server. To reenable IP routing, use the ip routing command.
Routing Assistance When IP Routing Is Disabled
The access server software provides three methods by which the access server can learn about routes to other networks when IP routing is disabled and the access server is acting as an IP host:
•
•
•
When IP routing is disabled, the default gateway feature and the router discovery client are enabled, and proxy ARP is disabled. When IP routing is enabled, the default gateway feature is disabled and you can configure proxy ARP and the router discovery servers.
Proxy ARP
The most common method of learning about other routes is by using proxy ARP. Proxy ARP, defined in RFC 1027, enables an Ethernet host with no knowledge of routing to communicate with hosts on other networks or subnets. Such a host assumes that all hosts are on the same local Ethernet and that it can use ARP to determine their hardware addresses.
Under proxy ARP, if an access server receives an ARP Request for a host that is not on the same network as the ARP Request sender, the access server evaluates whether it has the best route to that host. If the access server does have the best route, it sends an ARP Reply packet giving its own Ethernet hardware address. The host that sent the ARP Request then sends its packets to the access server, which forwards them to the intended host. The software treats all networks as if they are local and performs ARP requests for every IP address. This feature is enabled by default.
Proxy ARP works as long as other access servers support it. Many other access servers, especially host-based routing software, do not support it.
Default Gateway
Another method for locating routes is to define a default router (or gateway). The software sends all nonlocal packets to this access server functioning as a router, which either routes them appropriately or sends an Internet Control Message Protocol (ICMP) redirect message back to the access server, telling it of a better route. The ICMP redirect message indicates which local access server the host should use. The software caches the redirect messages and routes each packet thereafter as efficiently as possible. The limitations of this method are that there is no means of detecting when the default access server has crashed or is unavailable, and no method of picking another access server if one of these events should occur.
To set up a default gateway for a host, perform the following task in global configuration mode:
To display the address of the default gateway, use the show ip redirects EXEC command.
Router Discovery Mechanism
The access server software provides a third method, called router discovery, by which the access server can dynamically learn about routes to other networks using the Gateway Discovery Protocol (GDP) or the ICMP Router Discovery Protocol (IRDP) for detecting routers. The software is also capable of wire-tapping Routing Information Protocol (RIP) and Interior Gateway Routing Protocol (IGRP) routing updates and inferring the location of access servers from those updates. The server/client implementation of router discovery does not actually examine or store the full routing tables sent by access servers, it merely keeps track of which systems are sending such data.
This mechanism supports the following protocols:
•
•
•
•
You can configure these protocols in any combination. When possible, use GDP or IRDP because they allow each access server to specify both a priority and the time after which an access server should be assumed down if no further packets are received. Access servers discovered using IGRP are assigned an arbitrary priority of 60. Access servers discovered through RIP are assigned a priority of 50. For IGRP and RIP, the software attempts to measure the time between updates and will assume that the access server is down if no updates are received for 2.5 times that interval.
Each access server discovered becomes a candidate for the default access server. The list of candidates is scanned and a new highest priority access server is selected when any of the following events occur:
•
•
•
To configure the access server discovery feature using the GDP routing protocol, perform the following task in interface configuration mode:
To configure the access server discovery feature using the IRDP routing protocol, perform the following task in interface configuration mode:
To configure the access server discovery feature using the RIP routing protocol, perform the following task in interface configuration mode:
To configure the access server discovery feature using the IGRP routing protocol, perform the following task in interface configuration mode:
Enable IP Bridging
To transparently bridge IP on an interface, perform the following tasks beginning in global configuration mode:
Disable IP routing.
no ip routing
Specify an interface.
interface type number
Add the interface to a bridge group.
bridge-group group1
1 This command is documented in the "Transparent Bridging Commands" chapter of the Access and Communication Servers Command Reference publication.
You can route IP on some interfaces and transparently bridge it on other interfaces simultaneously. To enable concurrent routing and bridging for the router, perform the following task in global configuration mode:
Enable concurrent routing and bridging for the router.
bridge crb1
1 This command is documented in the "Transparent Bridging Commands" chapter of the Access and Communication Servers Command Reference publication.
Configure a Routing Process
At this point in the configuration process, you can configure one or more of the many routing protocols based on your individual network needs. Routing protocols provide topology information of an internetwork. Refer to the "Configuring IP Routing Protocols" chapter for the tasks involved in configuring IP routing protocols. If you want to continue to perform basic IP configuration tasks, continue reading the following sections.
Configure Broadcast Packet Handling
A broadcast is a data packet destined for all hosts on a particular physical network. Network hosts recognize broadcasts by special addresses. Broadcasts are heavily used by some protocols, including several important Internet protocols. Control of broadcast messages is an essential part of the IP network administrator's job.
Our access servers support two kinds of broadcasting: directed broadcasting and flooding. A directed broadcast is a packet sent to a specific network or series of networks, and a flooded broadcast packet is sent to every network. A directed broadcast address includes the network or subnet fields.
Several early IP implementations do not use the current broadcast address standard. Instead, they use the old standard, which calls for all zeros instead of all ones to indicate broadcast addresses. Many of these implementations do not recognize an all-ones broadcast address and fail to respond to the broadcast correctly. Others forward all-ones broadcasts, which causes a serious network overload known as a broadcast storm. Implementations that exhibit these problems include systems based on versions of BSD UNIX prior to Version 4.3.
Routers provide some protection from broadcast storms by limiting their extent to the local cable. Bridges (including intelligent bridges), because they are Layer 2 devices, forward broadcasts to all network segments, thus propagating all broadcast storms.
The best solution to the broadcast storm problem is to use a single broadcast address scheme on a network. Most modern IP implementations allow the network manager to set the address to be used as the broadcast address. Many implementations, including the one on our access server, can accept and interpret all possible forms of broadcast addresses.
For detailed discussions of broadcast issues in general, see RFC 919, "Broadcasting Internet Datagrams," and RFC 922, "Broadcasting IP Datagrams in the Presence of Subnets." The access server support for Internet broadcasts generally complies with RFC 919 and RFC 922; however, it does not support multisubnet broadcasts as defined in RFC 922.
The current broadcast address standard provides specific addressing schemes for forwarding broadcasts. Perform the tasks in the following sections to enable these schemes:
•
•
•
See the "IP Configuration Examples" section at the end of this chapter for broadcasting configuration examples.
Enable Directed Broadcast-to-Physical Broadcast Translation
To enable forwarding of directed broadcasts on an interface where the broadcast becomes a physical broadcast, perform one of the tasks that follow. By default, this feature is enabled only for those protocols configured using the ip forward-protocol global configuration command. You can specify an access list to control which broadcasts are forwarded. When an access list is specified, only those IP packets permitted by the access list are eligible to be translated from directed broadcasts to physical broadcasts.
Perform either of the following tasks in interface configuration mode as required for your network:
Forward UDP Broadcast Packets and Protocols
Network hosts occasionally use UDP broadcasts to determine address, configuration, and name information. If such a host is on a network segment that does not include a server, UDP broadcasts are normally not forwarded. You can remedy this situation by configuring the interface of your access server to forward certain classes of broadcasts to a helper address. You can have more than one helper address per interface.
You can specify a UDP destination port to control which UDP services are forwarded. You can specify multiple UDP protocols. You can also specify the Network Disk (ND) protocol, which is used by older diskless Sun workstations, and you can specify the network security protocol SDNS. By default, both UDP and ND forwarding are enabled if a helper address has been defined for an interface. The description for the ip forward-protocol command in the Router Products Command Reference publication lists the ports that are forwarded by default if you do not specify any UDP ports.
If you do not specify any UDP ports when you configure the forwarding of UDP broadcasts, you are configuring the access server to act as a BOOTP forwarding agent. BOOTP packets carry Dynamic Host Configuration Protocol (DHCP) information. (DHCP is defined in RFC 1531.) This means that the access server is now compatible with DHCP clients.
To enable forwarding and to specify the destination address, perform the following task in interface configuration mode:
Enable forwarding and specify the destination address for forwarding UDP broadcast packets, including BootP.
ip helper-address address
To specify which protocols will be forwarded, perform the following task in global configuration mode:
Specify which protocols will be forwarded over which ports.
ip forward-protocol {udp [port] | nd | sdns}
See the "IP Configuration Examples" section in this publication for an example of how to configure helper addresses.
Establish an IP Broadcast Address
The access server supports IP broadcasts on both local- and wide-area networks. There are several ways to indicate an IP broadcast address. Currently, the most popular way (the default) is an address consisting of all ones (255.255.255.255), although the access servers can be configured to generate any form of IP broadcast address. Our access servers also can receive and understand any form of IP broadcast.
To set the access server's IP broadcast address, perform the following task in interface configuration mode:
Establish a different broadcast address (other than 255.255.255.255).
ip broadcast-address [ip-address]
If the access server does not have nonvolatile memory, and you need to specify the broadcast address to use before the access server has been configured, you have to change the IP broadcast address by setting jumpers in the processor configuration register. Setting bit 10 causes the access server to use all zeros. Bit 10 interacts with bit 14, which controls the network and subnet portions of the broadcast address. Setting bit 14 causes the access server to include the network and subnet portions of its address in the broadcast address. shows the combined effect of setting bits 10 and 14.
Table 18-2 Configuration Register Settings for Broadcast Address Destination
Out
Out
<ones><ones>
Out
In
<zeros><zeros>
In
In
<net><zeros>
In
Out
<net><ones>
Some access server platforms allow the configuration register to be set through the software; see the "Loading System Images and Configuration Files" chapter for details. For other access server platforms, the configuration register can only be changed through hardware; see the appropriate hardware installation and maintenance manual for your system.
Configure IP Services
The IP suite offers a number of services that control and manage IP connections. Many of these services are provided by the Internet Control Message Protocol (ICMP). ICMP messages are sent by access servers to hosts or other access servers when a problem is discovered with the Internet header. For detailed information on ICMP, see RFC 792.
To configure IP services, complete the tasks in the following sections:
•
•
•
•
See the "IP Configuration Examples" section at the end of this chapter for examples of ICMP services.
Disable ICMP Protocol Unreachable Messages
If the access server receives a nonbroadcast packet destined for itself that uses an unknown protocol, it sends an ICMP Protocol Unreachable message back to the source. Similarly, if the access server receives a packet that it is unable to deliver to the ultimate destination because it knows of no route to the destination address, it sends an ICMP Host Unreachable message to the source. This feature is enabled by default.
You can disable this service by performing the following task in interface configuration mode:
Disable the sending of ICMP Protocol Unreachable and Host Unreachable messages.
no ip unreachables
Disable ICMP Redirect Messages
Routes sometimes can become less than optimal. For example, it is possible for the access server to be forced to resend a packet through the same interface on which it was received. If this happens, the access server sends an ICMP Redirect message to the packet's originator telling it that it is on a subnet directly connected to the access server, and that it must forward the packet to another system on the same subnet. It does so because the originating host presumably could have sent that packet to the next hop without involving the access server at all. The Redirect message instructs the sender to remove the access server from the route and substitute a specified device representing a more direct path. This feature is enabled by default.
You can disable the sending of ICMP Redirect messages by performing the following task in interface configuration mode:
