700 Series Router Command Glossary | 700 Series Router Command
Reference In depth descriptions of all 700 series router command options |
---|
Listed below in alphabetical order is a complete listing of the commands appearing in the sample 700 series router configurations and is intended as a supplemental cross-reference. The uppercase letters denote the minimum characters required for the command to be accepted. Each entry offers a brief explanation of how and why the command is used in the example scenario. If more information is required, a quick link to the IOS-700 Command Reference is provided for an easy lookup. |
---|
CD [username] | IOS-700 Command Reference |
---|
This is a navigation command used to switch between user and system profiles. The command changes the router command prompt to the profile matching the supplied username. If no username is supplied, the command returns the router command prompt to the system level.
SEt ACtive [username] | IOS-700 Command Reference |
---|
As an alternative to rebooting the router, this command activates a newly created user profile. A profile must be active before the router can automatically initiate outbound ISDN calls from the profile.
Note: Incoming calls associated with the user profile are still answered regardless if the profile is inactive or active.
SEt BRidging ON | OFf | IOS-700 Command Reference |
---|
This command enables or disables the bridging engine for a profile.
SEt DHcp ADdress ip_address [count | all] | IOS-700 Command Reference |
---|
This command configures the range of IP addresses served from the router's DHCP server pool. In the examples, the command "set dhcp address 10.1.1.2 100" in Atlanta's configuration creates a pool of 100 IP addresses that the router can assign to DHCP clients. The router begins with 10.1.1.2 and sequentially serves out addresses until the pool is exhausted. The router may assign up to 255 IP addresses if the IP subnet mask allows.
SEt DHcp DNs PRimary | SEcondary server_address | IOS-700 Command Reference |
---|
This command specifies the IP address of the domain name server (DNS) that the router assigns DHCP clients to use. Up to two different DNS addresses may be specified - a primary and a secondary. A DNS translates names (i.e. www.cisco.com) into IP addresses and is usually supplied by the ISP. In ISP examples, all DHCP workstations use a fictitious IP address of 192.168.1.100 for the DNS server residing at the ISP.
SEt DHcp GAteway PRimary | SEcondary ip_address | IOS-700 Command Reference |
---|
This command specifies the IP address of the default gateway that the router assigns DHCP clients to use. Up to two different default gateway addresses may be specified - a primary and a secondary. A default gateway is a router to which workstations send any traffic that is destined for other IP subnets. In the examples, the default gateway address is the IP address of the 700 series router's LAN profile. Therefore, local workstations on the LAN send all traffic that is destined to remote IP networks to the 700 series router. The router then decides where to send the traffic based upon the routing table.
SEt DHcp NEtmask nnn.nnn.nnn.nnn | IOS-700 Command Reference |
---|
This command specifies the IP netmask that the router assigns DHCP clients to use.
SEt DHcp [SErver | RElay ip_address | OFf] | IOS-700 Command Reference |
---|
This command enables/disables the router to act as either a DHCP server or a DHCP relay agent.
When configured as a DHCP server, the router responds to DHCP client requests directly. The router can dynamically assign an IP address, netmask, default gateway, DNS, and other IP information to a DHCP client workstation.
When configured as a DHCP relay agent, the router relays DHCP client requests to a separate DHCP server with the specified IP address. The remote DHCP server has the responsibility of correctly assigning proper IP information.
Info On DHCP Faxback Document #dhcp |
SEt [1|2] DIrectory [number] | IOS-700 Command Reference |
---|
This command sets the router's local directory number (LDN) assigned by the ISDN service provider for each ISDN B channel. The LDN is local phone number without the area code. In the examples, Atlanta is configured with "set 1 directory 5551111" and "set 2 directory 5552222". 5551111 is the local phone number assigned to Atlanta's B1 channel and 5552222 is the local phone number assigned to Atlanta's B2 channel. The ISDN provider supplies this information.
Note: Directory numbers are not necessary and should not be configured for AT&T 5ESS Custom point-to-point ISDN switch types.
SEt IP ADdress ip-address | IOS-700 Command Reference |
---|
This command configures a profile with an IP address. Due to the profile-based architecture of the 700 series routers, the profile in which an IP address is configured varies if the protocol is bridged or routed. In IP routing examples, the command is entered in the LAN profile. In examples in which IP is bridged, the command is entered in the Internal profile.
Info On
User Profiles And 700 Series Router Architecture Faxback Document #700_profiles |
SEt IP NEtmask mask | IOS-700 Command Reference |
---|
This command configures a profile with an IP netmask in dotted decimal format. For example, a Class C (24bit) netmask is configured as 255.255.255.0
SEt IP PAt ON | OFf | IOS-700 Command Reference |
---|
This command enables port address translation (PAT) on a profile. PAT allows private IP addresses to access the public Internet. If PAT is enabled, the maximum number of user profiles the router may support is two.
Info On PAT Faxback Document #pat |
SEt IP RIp SNapshot CLient ACtive minutes QUiet minutes UPdate ON | OFf | IOS-700 Command Reference |
---|
This command configures a router as a snapshot routing client for IP RIP routing updates. During a specified active time interval, snapshot clients initiate an ISDN connection to exchange routing information with a snapshot server.
The period in which routes are exchanged is known as the active time interval. The duration of the active interval can range from one to 70,000 minutes. The quiet time interval exists between active times and can range from one to 70,000 minutes. During the quiet time, routing updates are suppressed and entries are frozen into the routing table as if they were static entries.
Note: The minimum quiet-time is generally the active-time plus three minutes.
In snapshot routing examples, Boston is configured as a snapshot client and exchanges routing updates with Atlanta during a five minute active interval. After the five minute active time expires, the router stays in quiet mode for eight hours (480 minutes) before reentering the active time.
Info On Snapshot
Routing Faxback Document #snapshot |
SEt IP RIp SNapshot SErver ACtive minutes UPdate ON | OFf | IOS-700 Command Reference |
---|
This command configures a router as a snapshot routing server for IP RIP routing updates. A snapshot server passively answers snapshot client requests for routing updates. For economic use of the ISDN line, snapshot routing confines normal periodic routing updates to a user configurable interval.
The period in which routes are exchanged is known as the active time interval. The duration of the active interval can range from one to 70,000 minutes. The quiet time interval exists between active times and the duration is controlled by the snapshot client. During the quiet time, routing updates are suppressed and entries are frozen into the routing table as if they were static entries.
In snapshot routing examples, Atlanta is configured as a snapshot server and exchanges routing updates with Boston during a five minute active time interval.
Info On Snapshot
Routing Faxback Document #snapshot |
SEt IP RIp UPdate PEriodic | DEmand | SNapshot | LInkup | OFf | IOS-700 Command Reference |
---|
This command defines the method in which a profile forwards IP RIP routing updates.
Periodic RIP updates are sent every 60 seconds. This causes the ISDN line to remain permanently connected and is used in nailed up ISDN example configurations. Demand RIP updates are forwarded when the router first boots up and only when changes occur in the routing table. This option can be used in DDR scenarios, but is only supported between 700 series routers. Snapshot RIP updates are sent using the snapshot routing protocol. Routing updates are sent only during a specified active interval. Snapshot routing is the preferred method for DDR scenarios to Cisco IOS routers. Linkup RIP updates are forwarded only if the ISDN link is active. Updates are sent upon connection establishment and every 30 seconds thereafter for as long as the connection exists. Off RIP updates are disabled for a profile. Static routing examples with no need for routing updates have RIP disabled.
SEt IP RIp VErsion 1 | 2 | BOth | IOS-700 Command Reference |
---|
This command specifies the version of RIP. The example configurations use RIP version 2 to support any potential variable length subnet masks. RIP version 2 is backwards compatible with RIP version 1.
SEt IP ROUTE DEstination network [/bits] GAteway nexthop [PRopagate ON | OFf ] [COst value] | IOS-700 Command Reference |
---|
This command defines a static IP route on the router. Routes are used to direct traffic to their destinations. Normally routes are resolved dynamically using a routing protocol. However, in static routing examples, routing updates are disabled on ISDN profiles. This command instructs the router to use a specified profile and next hop gateway to reach a destination IP network.
In some examples, Atlanta has a static IP route (e.g. set ip route destination 20.0.0.0/8 gateway 20.1.1.1) configured in its Boston user profile. Atlanta knows that IP network 20.0.0.0 with a subnet mask of 8 bits (i.e. 255.0.0.0) is reached via 20.1.1.1 using the Boston profile.
Note: 20.1.1.1 is the IP address assigned to Boston's LAN profile. Normally, the next hop address would be set to the IP address in Boston's profile for Atlanta. However, because the Atlanta profile is unnumbered, the LAN ip address is substituted. Alternatively, the next hop address could have been specified as 0.0.0.0 for an IP unnumbered connection.
In other examples, a static IP default route is defined by using 0.0.0.0/0 as the destination network number. The default route is used if the router does not have an explicit routing table entry for a destination. For instance, in the ISP examples, "set ip route destination 0.0.0.0/0 gateway 0.0.0.0" defines a static IP default route in the ISP profile. Atlanta forwards all non-local traffic onto the ISP.
SEt IP ROuting ON | OFf | IOS-700 Command Reference |
---|
This command turns the IP routing engine on or off for a profile.
SEt IPX FRaming EThernet_II | 802.3 | 802.2 | SNap | NOne | IOS-700 Command Reference |
---|
This command specifies the IPX frame type used on a profile. The frame type used on the LAN profile must match the frame type used by the local IPX servers and clients. The none option specifies IPXCP packet encapsulation and is valid only for PPP connections (i.e. ISDN profiles). ISDN user profiles use IPXCP encapsulation (none) by default.
SEt IPX NETWork network number | IOS-700 Command Reference |
---|
This command binds an IPX network number to a profile. Each IPX network segment requires a unique IPX network number. For the LAN profile, the IPX network number must match the settings bound to the LAN cards in existing local IPX servers. If there are no servers at the site, a new unique IPX network number must be created.
In IPX examples, Atlanta's LAN profile is assigned IPX network 100. IPX network 100 cannot appear in any other location as either an internal or external IPX network number. The ISDN segment between Atlanta and Boston also requires a separate the IPX network number and is assigned IPX network AAAA in the examples.
SEt IPx RIp SNapshot CLient ACtive minutes QUiet minutes UPdate ON | OFf | IOS-700 Command Reference |
---|
This command configures a router as a snapshot routing client for IPX RIP and SAP updates. During a specified active time interval, snapshot clients initiate an ISDN connection to exchange route and service information with a snapshot server.
The period in which route and service updates are exchanged is known as the active time interval. The duration of the active interval can range from one to 70,000 minutes. The quiet time interval exists between active times and can range from one to 70,000 minutes. During the quiet time, route and service updates are suppressed and entries are frozen into the routing table as if they were static entries.
Note: The minimum quiet-time is generally the active-time plus three minutes.
In snapshot routing examples, Boston is configured as a snapshot client and exchanges routing updates with Atlanta during a five minute active interval. After the five minute active time expires, the router stays in quiet mode for eight hours (480 minutes) before reentering the active time.
SEt IPX RIp SNapshot SErver ACtive minutes UPdate ON | OFf | IOS-700 Command Reference |
---|
This command configures a router as a snapshot routing server for IPX RIP and SAP updates. A snapshot server passively answers snapshot client requests for route and service updates. For economic use of the ISDN line, snapshot routing confines normal periodic routing updates to a user configurable interval.
The period in which routes are exchanged is known as the active time interval. The duration of the active interval can range from one to 70,000 minutes. The quiet time interval exists between active times and the duration is controlled by the snapshot client. During the quiet time, routing updates are suppressed and entries are frozen into the routing table as if they were static entries.
In snapshot routing examples, Atlanta is configured as a snapshot server and exchanges IPX RIP and SAP updates with Boston during a five minute active time interval.
SEt IPX RIP UPdate PEriodic | DEmand | SNapshot | OFf | IOS-700 Command Reference |
---|
This command configures the method in which IPX RIP and SAP updates are forwarded.
Periodic IPX RIP and SAP updates are sent every 60 seconds. This setting causes the ISDN line to be permanently active. Periodic is used in nailed up ISDN example configurations. Demand IPX RIP and SAP updates are forwarded when the router first boots up and when a changes occur in the route or service tables. This option can be used in DDR scenarios, but is only supported between 700 series routers. Snapshot IPX RIP and SAP updates are sent using the snapshot routing protocol. Updates are sent only during a specified active interval. Snapshot routing is the preferred method for DDR scenarios to Cisco IOS routers. Off IPX RIP and SAP updates are disabled for a profile. Static routing examples with no need for routing updates have IPX RIP and SAP disabled.
SEt IPX ROUTE DEstination=netnum [GAteway net:node] [HOps=hops] [COst=ticks] | IOS-700 Command Reference |
---|
This command creates a static IPX route. Routes are used to direct traffic to their destinations. Normally routes are resolved dynamically using a routing protocol. However, in static routing examples, routing protocols are disabled on the ISDN user profiles. This command instructs the router to use a specified profile and next hop gateway to reach a destination IPX network. Other routing metrics such as hop count and route cost can be optionally specified. A static route is required for every remote internal and external network number that must be reached.
For example, to access BostonFS, Atlanta needs a static route to the internal IPX network number of BostonFS (IPX network 2000). The command "set ipx route destination 2000 gateway AAAA.0040.f9bb.2222" tells Atlanta that IPX network 2000 can be reached via the next hop IPX address AAAA.0040.f9bb.2222. AAAA is the IPX network number of the ISDN segment between Atlanta and Boston. 0040.f9bb.2222 is the MAC address of the Boston router. To obtain the 700 series router MAC address information, use the "show address" command at the system level. The router's MAC address is prefixed with "INT".
SEt IPX ROuting ON | OFf | IOS-700 Command Reference |
---|
This command turns the IPX routing engine on or off for a profile.
SEt IPX SErvice NAme=service-name TYpe=service-type ADdress=net:node:socket[HOps=hops] | IOS-700 Command Reference |
---|
This command creates a static IPX service announcement that defines the IPX service-type (e.g. type 4 = file service), name, IPX address, IPX socket number, and hops to reach the service. Normally, service announcement information would be resolved automatically with a routing protocol. However, in static IPX routing examples, routing protocols are disabled on the serial interfaces. A static SAP is required for every remote IPX service that must be reached.
For instance, if clients in Atlanta wish to access BostonFS, Atlanta needs a SAP for BostonFS. The command "set ipx service name BostonFS type 4 address 2000:01:0451 hops 2" tells Atlanta that an IPX type 4 file service named BostonFS has an IPX address of 2000:0000.0000.0001, uses IPX socket 451, and is two hops away. 2000 is the internal IPX network number of the file server. 01 is the internal node number of the file server (leading zeros can be ignored but needs a minimum of two characters). The service type, service name, and socket number will vary depending on the service (e.g. print servers, file servers).
SEt IPX SPoofing minutes | OFf | IOS-700 Command Reference |
---|
IPX watchdog packets are keepalives that are sent from servers to clients to verify if idle workstations are still alive. For a DDR connection, the ISDN line drops during periods of inactivity. While the ISDN line is down, workstations are unable to respond to IPX watchdog packets and as a result are logged off of the server. The next time the ISDN line is activated, workstations are forced to login to the server again. This command enables the router to respond to an IPX server's watchdog packets on behalf of a remote client for a specified duration. When the ISDN line drops due to inactivity, the router tricks the server into believing that the remote workstations are still connected. Remote workstations are now spared the pains of logging in every time the ISDN line goes idle. This is often referred to as "spoofing the server."
SEt [1|2] NUmber ISDN-number | IOS-700 Command Reference |
---|
This command configures the phone numbers that the user profile will dial. Any access codes (e.g. "9" to get out of a Centrex, International dialing codes, Area codes, etc.) must also be included if needed. In the sample configurations, Atlanta is configured with "set 1 number 16175553333" and "set 2 number 16175554444". Atlanta dials 16175553333 to bring up the first B channel to Boston and 16175554444 to bring up the second B channel to Boston if needed.
Note: The "set 2 number" command does not configure the router with a backup dial number in the event the first call fails. To set a backup number use the "set backup number" command.
SEt PPp Address NEgotiation LOcal ON | OFf | IOS-700 Command Reference |
---|
User profiles on 700 routers are capable of having IP addresses dynamically assigned to them via IP Control Protocol (IPCP). When PPP address negotiation is on, a dynamically assigned IPCP address is assigned to the user profile. If PPP address negotiation is off, the router first attempts to assign the IPCP negotiated address to the Internal profile. If the Internal profile already has an IP address, the router will then place the address in the user profile.
Info On PPP And IPCP
Address Negotiation Faxback Document #ppp |
SEt PPp AUthentication INcoming {CHap | CHap PAp | PAp CHap | PAp | NOne} | IOS-700 Command Reference |
---|
This command enables PPP authentication for incoming ISDN calls. With this enabled, the router demands to authenticate incoming ISDN callers. Incoming callers must supply a PPP clientname and PPP client password. The router then matches the PPP clientname to one of its user profile names. If successful, the router then matches the PPP client password to the corresponding profile's PPP host password.
The command also specifies the order in which CHAP or PAP protocols are requested. For example, if set to chap pap, both CHAP and PAP protocols are enabled on the interface. The router will first attempt to authenticate incoming users with CHAP authentication and, if unsuccessful, will then attempt PAP.
Info On PPP And IPCP
Address Negotiation Faxback Document #ppp |
SEt PPp AUthentication OUtgoing [CHap] [PAp] [NOne] | IOS-700 Command Reference |
---|
This command configures PPP authentication for outgoing ISDN calls. Enabling authentication on outgoing calls is known as bidirectional authentication. For bidirectional authentication, not only does the answering router authenticate the calling router, but the calling router also authenticates the answering router. In contrast, disabling authentication on outgoing calls (i.e. set ppp authentication outgoing none) is known as unidirectional authentication. In a unidirectional authentication scenario, only the answering router authenticates the calling router.
Cisco routers support both unidirectional and bidirectional authentication. For added security, bidirectional authentication is preferred and is used in all of the examples other than the ISP examples. In bidirectional examples, Atlanta places a call to Boston using the "Boston" profile. Upon connection, Atlanta supplies a PPP clientname (Atlanta) and a PPP secret client (gocisco1) configured in the Boston profile. Boston checks for a user profile that matches the received PPP clientname (Atlanta) and compares the received PPP client secret (gocisco1) against the PPP secret host (gocisco1) configured in the Atlanta profile. Likewise, Atlanta authenticates Boston in the same manner. With bidirectional authentication, Atlanta has the added security that the device answering the ISDN call is intended router.
Unidirectional authentication (i.e. set ppp authentication outgoing none) is used in the ISP sample configurations because non-Cisco routers that are potentially in use at an ISP do not support bidirectional authentication. When Atlanta calls the ISP, Atlanta does not force the ISP to identify itself with a username and password. However, the ISP authenticates Atlanta. Proponents of unidirectional authentication believe that, if Atlanta initiated the call, Atlanta must already know who it is calling.
Info On PPP And IPCP
Address Negotiation Faxback Document #ppp |
SEt PPp CLientname clientname | IOS-700 Command Reference |
---|
This command configures the PPP clientname that is sent by a profile during PPP authentication. If a profile does not have a PPP clientname configured, the router uses the system name.
SEt PPp MUltilink ON | OFf | IOS-700 Command Reference |
---|
This command enables/disables multilink PPP on a user profile. Multilink PPP allows B channel aggregation for higher bandwidth. Routers on both ends of the ISDN link must support multilink PPP for successful negotiation.
SEt PPP [PAssword | SEcret] [HOst | CLient] | IOS-700 Command Reference |
---|
This command configures the passwords used in PPP authentication. After entering this command the router will prompt for the password to be entered and then prompt to reenter the password for confirmation.
Password Client PAP password sent in response to a PAP authentication challenge from a remote router Password Host PAP password the router will expect a remote router to supply to successfully pass PAP authentication. Secret Client CHAP password sent in response to a CHAP authentication challenge from a remote router Secret Host CHAP password the router will expect a remote router to supply to successfully pass CHAP authentication. Note: For simplicity, both PAP and CHAP passwords are configured in the ISP examples. The router is ready to respond to either a PAP or a CHAP authentication challenge if the authentication type used at the ISP is unknown.
SEt [spid id] SPid [SPID number] | IOS-700 Command Reference |
---|
This command configures the service profile identifier (SPID) numbers that are assigned by the ISDN service provider for each B channel. The SPID identifies a subscribed ISDN service. This value is provided by the ISDN service provider and is usually a 10-digit telephone number with some extra digits. In the examples, Atlanta is configured with "set 1 spid 01404555111100" and "set 2 spid 01404555222200" for Atlanta's B1 and B2 channels respectively.
Note: Do NOT configure SPIDS for AT&T 5ESS Custom point-to-point ISDN switches; no SPIDS are needed. The router will be unable to answer and place ISDN calls if SPIDS are configured.
SEt SWitch 5Ess | DMS | NI-1 | INS | VN3 | NET3 | 1TR6 | TPH | PERM64 | PERM128 | IOS-700 Command Reference |
---|
This command specifies the ISDN switch type used at the ISDN provider. The switch type at one location does NOT have to match the switch type at other locations. To illustrate this point, the examples purposely have Boston (5ESS) using a different switch type than Atlanta (NI-1). The ISDN provider provides switch type information.
SEt SYstemname systemname | IOS-700 Command Reference |
---|
This command gives the router an identity and changes the command prompt (e.g. Atlanta>). For PPP authentication, the system name will be sent as the PPP clientname if it is not specified in a user profile.
SEt TIMEout seconds | IOS-700 Command Reference |
---|
This command specifies the number of seconds before the router disconnects an ISDN call due to lack of interesting traffic. If an interesting packet is forwarded over the ISDN line, the counter resets to zero and begins counting up to the timeout value again. If no packets require forwarding before the timeout expires, the router terminates the call. For proper operation, both routers should have matching idle-timeout values. By default, the timeout value is set to OFF and connections will NOT disconnect. A value between one and 32,767 seconds can be set for the call to drop due to inactivity. In the examples, a value of 300 is used to drop the call after five minutes of inactivity.
SEt USer username | IOS-700 Command Reference |
---|
This command creates a user profile. Once entered, the router prompt will change to the new user profile. The profile username is important for PPP authentication. When the router answers an incoming ISDN call, it demands to authenticate the incoming caller. The incoming user responds with a PPP clientname and PPP client password. The router then attempts to match the PPP clientname to one of its user profile names. If successful, the router then tries to match the PPP client password to the corresponding profile's PPP host password.
All contents copyright © Cisco Systems, Inc. Important notices.