![[previous]](../../../graphics/l_arrow.gif){kind=icon}
![[next]](../../../graphics/r_arrow.gif){kind=icon}
This chapter describes the tools you need to configure the auto startup feature, how to configure the feature, and how the feature works.
The auto startup feature enables the peripheral node (SuperStack II NETBuilder boundary router) in a Boundary Routing topology to boot and become operational with no or minimal software configuration.
Before configuring auto startup, 3Com strongly recommends that you read "How Auto Startup Works" later in this chapter.
For the auto startup feature to work, you need to configure the central node and the BOOTP and Trivial File Transfer Protocol (TFTP) servers on the central site network. (For information on the 3Com bridge/routers that can be used as a central node, see Table 83.)
If you are using a model 42x or 52x SuperStack II bridge/router as a peripheral node and if this node is connected to an Integrated Services Digital Network (ISDN) switch type other than European Telecommunications Standards Institute (ETSI), additional configuration is necessary. For more information, see "Configuring Boundary Router Software on Model 42x or 52x Bridge/Routers" later in this chapter.
For the auto startup feature to work, the central node requires certain software tools and some software configuration.
You need to configure a BOOTP server and a TFTP server on the central site network. Table 85 lists the software tools that offer the servers, indicates if they are mandatory or optional, and provides a short explanation of each tool.
| 1
Use either 3Com's or another vendor's version of a BOOTP server.
|
For information on configuring the BOOTP and TFTP servers, see "Configuring the Central Node and the BOOTP and TFTP Servers" next.
Before beginning this procedure, complete the following tasks on the central node:
The DLCI is normally learned automatically by the interface. However, for the auto startup feature to work properly, you may need to include this value in the bootptab file entry if you are using the 3Com Remote Upgrade Utilities.
Figure 302, Figure 303, and Figure 304 show sample Boundary Routing topologies in which auto startup is configured for Frame Relay, PPP, and ISDN/PPP.
The following items are the same in all the sample topologies
Figure 302 
Configuring Auto Startup for Frame Relay
Figure 303 Configuring Auto Startup for PPP
Figure 304 Configuring Auto Startup for PPP/ISDN
The Frame Relay connection between the central and peripheral nodes in Figure 302 has a DLCI of 30 assigned to it by the Frame Relay service vendor.
To configure the central node and the BOOTP and TFTP servers on the central site network, follow these steps:
1 . Configure the UDP Broadcast Helper on the central node.
SETDefault -UDPHELP CONTrol = Enable
ADD -UDPHELP ActivePorts {<UDP port> | <name>}
BPSERVER is the name reserved for port 67.
For example, to add UDP port 67 to the active port list, enter:
ADD -UDPHELP ActivePorts 67
or
ADD -UDPHELP ActivePorts BPSERVER
ADD -UDPHELP ForwardAddress <UDP port or name> <IP address>
For example, in the sample topologies shown, add the IP address of the BOOTP server (129.213.201.25) to the forward address list by entering:
ADD -UDPHELP ForwardAddress 67 129.213.201.25
For more information on the UDP Broadcast Helper, see the Configuring UDP Broadcast Helper chapter.
2 . Install either 3Com's or another vendor's version of the BOOTP server on your Sun, HP, or PC system. If you plan to install another vendor's version of the BOOTP server, skip this step and see the documentation that accompanies that product for information.
These utilities are provided by 3Com on CD-ROM and contain the 3Com implementation of the Bootpd program, which is defined in RFC 951 and RFC 1048. When Bootpd starts, it reads its configuration file /etc/bootptab, then sends a BOOTREPLY packet based on the contents of the /etc/bootptab file for a BOOTREQUEST.
The distribution diskette contains an installation script and UNIX manual pages to document the command line syntax of the utilities. For more information about the Remote Upgrade Utilities, see Upgrading NETBuilder Family Software.
The /etc/bootptab file contains configuration parameters that must be set up before a SuperStack II boundary router can execute phase 2 of the auto startup process.
The bootptab file has a format similar to that of the termcap file in which two-character, case-sensitive tag symbols are used to represent parameters. The parameter declarations are separated by colons (:). The general format is as follows:
hostname:tg=value.......:tg=value.......:tg=value...
where:
|
hostname |
is the actual name of a BOOTP client (the peripheral node). |
|
tg |
is a two-character tag symbol. Most tags must be followed by an equal sign (=) and a value. |
You can access a complete description of the bootptab file and its construction using the online manual page facility that comes with the utilities package.
Read the contents of the bootptab file. At the end of the file, you will find examples that you can edit to fit your network topology.
For each peripheral node that is expected to request a boot load from the central site server, an entry must be made into the bootptab file. The entry for the sample topology shown in Figure 302 contains the following information:
remote:ip=129.213.201.22:hp=1:sm=255.255.255.0:\
:hd=config-files:bf=boot.68k:bh=129.213.201.21:\
:hh=frame:ci=30:fs=129.213.201.24
where:
Another important parameter is gs, which specifies the IP address of the gateway. If the central node is functioning as a router, you must specify a gateway address.
3 . Set up the TFTP server.
You can create any directory as long as your BOOTP server can support the Root Path option. When you use the 3Com Remote Upgrade Utilities for your BOOTP server, create the directory that is specified in the "hd" parameter in the /etc/bootptab file. Otherwise, create a directory with the pathname as ..../CLIENTS/<MAC address>, where "...." is the path of the host image files' (as specified by the bf parameter in step 2b) grandparent directory and <MAC address> is the MAC address of the SuperStack II boundary router. Make sure that this directory name matches the entry in the bootptab file you created on the BOOTP server.
For example, if the host image file is under /tftpboot/image/boot.29K, create your configuration files directory as /tftpboot/CLIENTS/<MAC address>.
The Boot Image file string /tftpboot/image/boot29k appears as the "file" filed in the BOOTREPLY packet.
For the TFTP server, the pathname is case-sensitive. The directory CLIENTS must be uppercase. System-dependent path separators // or \ are both acceptable characters.
See "Configuring Boundary Router Software From the Central Site" next for information on how to create the configuration files. If your peripheral node is a model 42x or 52x SuperStack II bridge/router, you are using the ISDN interface as the link to the peripheral node, and the ISDN interface is connected to a switch type other than ETSI, also see "Configuring Boundary Router Software on Model 42x or 52x Bridge/Routers" later in this chapter.
Using a text editor, create an ASCII text file named CONFFILE in the same directory on the TFTP server. CONFFILE is a text file that contains configuration filenames. This file must contain the filenames of all the configuration files that the TFTP server provides for the associated client. For example, a CONFFILE can contain the following contents:
ip<sep> iprip<sep>rtmnet<sep>system<sep>
Where <sep> is the separator of each file. The <sep> can be a blank, a tab, a form feed, a carriage return, or a new-line character.
4 . When all the required files and services are in place at the central site, you are ready to set up the SuperStack II boundary router.
5 . Plug in the SuperStack II boundary router.
You must create configuration files containing desired changes to the boundary router software's default settings using Enterprise OS software commands, parameters, and syntax on a platform that is exactly the same as the boundary router that you are configuring. For example, if the boundary router you are configuring is a model 221 SuperStack II bridge/router, then you must create the configuration files on a model 221 bridge/router. Copy the files to the TFTP server. (For complete information on Enterprise OS commands and parameters, see Reference for Enterprise OS Software.)
Table 86 lists the parameters that you need to include in the configuration files to bring up a Frame Relay, PPP, or ISDN/PPP line on a SuperStack II boundary router with an ISDN interface (model 42x or 52x bridge/routers).
For complete information on the syntax for the parameters listed in Table 86, see Reference for Enterprise OS Software.
Upon initial startup, the boundary router attempts to download the configuration files from the TFTP server only if no configuration files exist on the boundary router. This process does not occur when you are using the ISDN interface on model 42x and 52x SuperStack II bridge/routers as your link to the central node, and when the ISDN interface is connected to a switch type other than the default of ETSI. In this situation, you must attach a terminal to the Console connector on the peripheral node and reconfigure the -PATH SwitchType parameter. Reconfiguring this parameter locally causes a ppm configuration file to be created and stored on the SuperStack II boundary router.
You must also create a SYSTEM file on the peripheral node that sets the -SYS GetConfigFiles parameter to ON. Reconfiguring this parameter prevents the peripheral node from assuming that the ppm configuration file that already exists on the peripheral node is sufficient and that configuration file download from the TFTP server is not necessary.
CAUTION: Do not reconfigure the setting of the -SYS GetConfigFiles parameter to ON except in the situation described in this section. Otherwise, configuration files will be downloaded each time you reboot your boundary router, potentially overwriting more current configuration files that may exist on your boundary router.
The auto startup feature is a two-phase process. This section describes what happens during each phase.
Phase 1 of the auto startup process begins when the SuperStack II boundary router is plugged in.
During phase 1, a peripheral node (the SuperStack II boundary router) in a Boundary Routing topology automatically detects certain local and wide area port and path attributes. Table 87 lists the detected attributes.
| 1
Applies to model 32x and 52x bridge/routers only.
2 Applies to model 42x bridge/routers only
|
Phase 1 for model 42x bridge/routers detects the path attributes instantly on initial system startup; however, if the connector is changed during normal operation, it can take several minutes for the auto detection software to sense the connector. For more information, see "Automatic Attribute Detection for DTE Ports on Model 42x Bridge/Routers" next.
After the attributes listed in Table 87 are detected, the boundary router establishes a physical link and then a data link between itself and the central node. Phase 1 is complete, and phase 2 of the auto startup process begins. For more information, see "Auto Startup Phase 2" later in this chapter.
For model 42x SuperStack II bridge/routers, the auto startup phase 1 process also detects the DTE port you have cabled. This process only works only on DTE ports and only when the -PORT OWNer parameter is set to AUTO (default). Autostartup can take several (three to five) minutes if the cable is changed during normal system operation.
When establishing the physical and data links between themselves and the central node, model 42x bridge/routers attempt to detect the connector type, owner, and line type of the path associated with the cabled DTE port. The boundary router detects these path characteristics by first attempting to try connector and line type combinations. The connector and line types are tried in the following order:
The boundary router scans each line quickly to determine the connector type most likely being used. After it successfully detects the connector and line types, the boundary router tries to detect the owner using a similar process. The scanning process continues periodically so that connector changes can be quickly determined.
The possible owners are tried in the following order:
Knowing the order in which the connector and line types and owners are tried can help you anticipate how long the establishment of the physical and data links will take. For example, the detection of a V.36 dial-up line running Frame Relay will take longer than the detection of an RS-232 dial-up line running Frame Relay because the V.36 dial-up line is tried later than an RS-232 dial-up line.
To determine the progress of the establishment of the physical and data links, follow these steps:
1 . Enter:
SHow -PORT DIAGnostics
2 . Look at the LEDs on model 42x bridge/routers associated with the DTE connectors to determine which connector is currently being tried.
Because of a signal irregularity in the RS-449 connector, the auto startup detection feature occasionally reports that the RS-449 connector is a V.35 connector. This condition eventually corrects itself.
During phase 2 of the auto startup process, the peripheral node obtains necessary configuration information from central site servers across the PPP or Frame Relay line. The peripheral node obtains information including:
For phase 2 to work, you must configure the UDP Broadcast Helper feature on the central node and you must configure two servers on the central site network: a BOOTP server and a TFTP server. The BOOTP server "listens" for BOOTP requests and forwards an IP address and boot file location information to the peripheral node. The TFTP server forwards configuration files to the peripheral node.
During phase 2: