IOS Router ISDN Command Glossary | Cisco IOS Command References In depth descriptions of all IOS command options |
---|
Listed below in alphabetical order is a complete listing of the commands appearing in the sample ISDN configurations and is intended as a supplemental cross-reference. Included under each command is 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 Command Reference is provided for an easy lookup. |
---|
access-list access-list-number {deny | permit} source [source-wildcard] | IOS Command Reference |
---|
Access lists create logical filters. The types of traffic an access list will filter depends upon the access-list number assigned to it. For IP access-lists, the source field is the IP network to which the source-wildcard is applied. To understand the source-wildcard, one must break it down into it's binary form. A 0 bit in the source-wildcard indicates a match condition whereas a 1 bit indicates a wildcard "don't care" condition. For example, the command access-list 1 permit 10.0.0.0 0.255.255.255 causes the router to permit any packet sourced with a 10.x.x.x address.
Complex filters can be assembled by grouping multiple definitions under the same access-list number. A packet is stepped through each access-list entry until a match condition is met. If the end of an access-list is reached without matching any conditions, the packet is automatically denied. In the NAT examples, any packet not sourced from either the 10.x.x.x network or the 20.x.x.x network is denied by access-list 1.
Once traffic is passed through a filter, a number of actions (e.g. blocking) can be applied. In the NAT examples, access lists determine which private networks are allowed to be translated into public addresses. For example, the command "ip nat inside source list 1 pool goodnet" determines any packets that match access-list 1 as valid networks to allow NAT translation.
bridge bridge-group protocol {ieee | dec} | IOS Command Reference |
---|
This command enables the router's bridging engine, identifies the bridging process with a bridge-group number, and specifies the particular spanning tree algorithm used to avoid bridging loops. All routers on the network that expect to bridge between each other need to share the same bridge-group number. The selected spanning tree protocol must also be consistent on each router. In bridging examples, both Atlanta and Boston are configured as bridge 1 and both run the IEEE spanning tree algorithm.
bridge-group bridge-group | IOS Command Reference |
---|
Once a bridging engine is enabled on the router with the bridge bridge-group# protocol {ieee | dec}command, the bridging process must be applied to the individual interfaces. This command applies the bridging process to an interface. All non-routed traffic is bridged between interfaces that share the same bridge-group number. In bridging examples, the interfaces on both Atlanta and Boston belong to bridge-group 1.
dialer hold-queue packets | IOS Command Reference |
---|
A hold-queue buffers the specified number of packets instead of dropping them during call setup periods.
dialer idle-timeout seconds | IOS Command Reference |
---|
This command specifies the number of seconds before the router disconnects an ISDN call due to lack of interesting traffic as defined by the dialer-list command. 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 idle-timeout expires, the router terminates the call. For proper operation, both routers should have matching idle-timeout values. The default value is 120 seconds but can be configured to a value between one and 2,147,483 seconds. In the examples, a value of 300 is used to drop the call after five minutes of inactivity.
dialer in-band | IOS Command Reference |
---|
This command specifies an interface as a dialed interface with dialing information passed in-band using V.25bis.
dialer isdn [speed speed] [spc] | IOS Command Reference |
---|
The bit rate used on a B channel may be specified either in the speed field of the dialer map command or with a map class dialer. This command is used in conjunction with the map class dialer command to set the ISDN dialing speed. Map class dialers are only necessary if ISDN calls must be placed at 56Kbps instead of 64Kbps and are typically used in scenarios when a dialer map is not appropriate. An example scenario is if the remote site is dialing into a pool of routers at the central location (like an ISP). Rather than create a separate dialer map for each potential router that may answer the call, the call may be placed with a generic dialer string command. The dialer string then references a map class that will set the dialing speed.
For instance, in the ISP examples, calls are placed with the dialer string 14045553333 class 56K command. "Class 56K" references a map class dialer definition called "56K". Under the map class dialer 56K definition, specific dialer properties can be configured; among these properties is the ISDN dial speed.
Note: The router places ISDN calls at 64Kbps by default. For 64Kbps calls, "map class" commands are not necessary. The dialer string would simply read "dialer string 14045553333" and the "map-class dialer 56K" related commands are omitted.
dialer load-threshold load [outbound | inbound | either] | IOS Command Reference |
---|
This command defines the load level that must be exceeded on the first ISDN B channel before a second B channel is brought up for a multilink PPP connection. The load is a value between one and 255 that defines a fraction taken over 255. The load can be calculated based on outbound, inbound, or either inbound or outbound traffic on the interface. For instance, the example configurations use "dialer load-threshold 200 either". If the combination of both inbound and outbound traffic levels reaches 200/255 (about 80% or roughly 50Kbps) capacity of the first ISDN B channel, the router will attempt to bring up a second B channel to assist with the traffic load. Thus, the second B channel is activated only when the traffic demands exceed the capacity of one B channel.
Note: If both B channels are desired regardless of traffic level, use the value of 1. This causes both B channels to be brought up whenever the router dials.
dialer map protocol next-hop-address [name hostname] [speed 56 | 64] [broadcast] [dial-string[:isdn-subaddress]] | IOS Command Reference |
---|
A router can place ISDN calls either with a dialer map command or a dialer string command. Typically, dialer maps are the preferred method of placing calls whereas a dialer string is reserved for scenarios in which the name of the answering router may not be known (i.e. a router pool). The dialer map command maps a protocol, a protocol address, a name for PPP authentication, and dial information to a specific remote router. It is one of the most important pieces of an ISDN configuration.
- protocol - This is the protocol subject to mapping. Options include IP, IPX, bridge, and snapshot.
- next-hop-address - This is the protocol address of the opposite site's ISDN interface.
In IP examples, Atlanta creates a map to the IP address of Boston's ISDN Dialer0 interface. Since this is IP unnumbered Ethernet0, it is the same IP address as Boston's Ethernet0 interface, 20.1.1.1.
In IPX examples, Atlanta creates a map to the IPX address of Boston's ISDN Dialer0 interface, AAAA.0000.0cbb.2222. AAAA is the IPX network number of the segment between Atlanta and Boston. 0000.0cbb.2222 is the MAC address Boston associates with the IPX routing process. In Boston's configuration, this is the same MAC address that shows up in the ipx routing command.
In snapshot routing examples, both Atlanta and Boston specify an arbitrary address of 1. Any value between 1 and 255 can be used as long as the routers use the same number.
name hostname - This is a required parameter used in PPP authentication. It is the name of the remote site for which the dialer map is created. The name is case sensitive and must match the hostname of the remote router.
speed [56 | 64] - This is an optional parameter to specify the speed at which the ISDN call is placed. If 64K ISDN is not available, the dialer map must include "speed 56" for the router to place calls at 56K. By default, Cisco routers place ISDN calls at 64K if no speed is specified.
broadcast - The broadcast keyword is optional and allows broadcast packets (e.g. IP RIP or IPX RIP/SAP updates) to be forwarded on to the remote destination. In static routing sample configurations, routing updates are not desired and the broadcast keyword is omitted.
dial string - This is the remote site's phone number. Any access codes (e.g. 9' to get out of a Centrex, International dialing codes, Area codes) must be included.
Note: A dialer map command is necessary even if the router does not initiate outbound calls. If a site only accepts incoming calls and never initiates outbound calls, omit the phone number from the dialer map statement. For example, the command would simply read "dialer map ip 20.1.1.1 name Boston". Without a phone number, Atlanta will not be able to initiate an outbound call to Boston.
As an illustration, in IP example configurations, Atlanta contains the command "dialer map ip 20.1.1.1 name Boston speed 56 broadcast 16175553333". This tells Atlanta that the destination IP address, 20.1.1.1, can be reached through a router named Boston. If no ISDN connection to Boston already exists, Atlanta can bring the connection up by dialing 16175553333 at a speed of 56K.
Info On PPP And Authentication Faxback Doc #ppp |
dialer rotary-group number | IOS Command Reference |
---|
This command associates a physical interface with a logical dialer interface defined with the corresponding "interface Dialer" command. In the examples, "dialer rotary-group 0" associates the physical BRI0 interface with a logical Dialer0 interface. ISDN commands pertaining to the physical interface are defined under interface BRI0 (e.g. SPIDs and LDNs) whereas commands related to the logical connection are configured under interface Dialer0 (e.g. dialer maps, ppp authentication, dialer parameters). The separation of physical and logical commands allows the ability to scale as the network grows. In the future, ISDN lines that share the same configurations can be added by simply adding a physical interface to the rotary-group.
dialer string dial-string [class class-name] | IOS Command Reference |
---|
This command is an alternate command to the dialer map command. It is used in scenarios in which the name of the answering router might not be known. In particular, this command appears in the ISP example configurations because many times the ISP router name either is unknown or may vary between a number of possible routers in a pool. The class field is optional and references a map class with a matching class-name. The map class can be used to specify additional dialing parameters. In the ISP sample configurations, a map class named "56K" is referenced that sets the ISDN dial speed to 56Kbps.
dialer-group group-number | IOS Command Reference |
---|
This command directs an interface to use the corresponding dialer-list to determine which traffic types cause the interface to dial and sustain a call. In the examples, interface Dialer0 is configured as "dialer-group 1". The interface will initiate and sustain an ISDN call for any packets that match the criteria defined in dialer-list 1.
dialer-list dialer-group protocol protocol {permit | deny | list access-list-number} | IOS Command Reference |
---|
This command defines the traffic types that will trigger and sustain an ISDN call on interfaces that share the same dialer-group number. In IP examples, "dialer-list 1 protocol ip permit" allows interfaces belonging to dialer-group 1 to dial out and sustain calls for as long as IP traffic needs to be sent. Additional commands such as "dialer-list 1 protocol ipx permit" can be added to the dialer-list. In this case, interfaces that belong to dialer-group 1 may now dial out and sustain the call as long as either IP or IPX traffic needs to be sent.
enable secret password | IOS Command Reference Enable Secret Command | IOS Command Reference Enable Password Command |
This command defines the enable secret password used to protect access to privileged exec commands. The password is case sensitive and can be defined on the router two different ways. A password set with the "enable password" command is stored as clear text, whereas a password set with "enable secret" is encrypted. For security, configuring the router with an enable secret is preferred. The enable secret always takes precedence if both enable secret and enable password are set.
Note: The unencrypted form of the password "cisco" is shown in the sample configurations. In an actual configuration, the password would appear in an encrypted form: (i.e. enable secret 7 13061E010803 --where 7 denotes the encryption type and 13061E010803 is an encrypted form of the password cisco.) When entering or making changes to the enable secret, always type the password in its unencrypted form. Do not enter the encryption type (7); it is set automatically.
encapsulation ppp | IOS Command Reference |
---|
This command specifies ppp encapsulation on an interface.
hostname name | IOS Command Reference |
---|
This command gives the router an identity and changes the command prompt (e.g. Atlanta#). If no PPP username is specified at the interface level, the router will send this hostname as the PPP username during PPP authentication.
interface Dialer number | IOS Command Reference |
---|
This command creates a logical dialer interface. The dialer interface allows a single configuration to be applied to a set of physical interfaces called a rotary-group. In the examples, "dialer rotary-group 0" associates the physical BRI0 interface with the logical Dialer0 interface. ISDN commands pertaining to the physical interface are defined under interface BRI0 (e.g. SPIDs and LDNs) whereas commands relating to the logical connection are configured under interface Dialer0 (e.g. dialer maps, ppp authentication, dialer parameters). The separation of physical and logical commands allows the ability to scale to network growth. In the future, ISDN lines that share the same configurations can be added by simply adding a physical interface to the rotary-group.
ip address ip-address subnet-mask | IOS Command Reference |
---|
This command configures an interface with an IP address and subnet mask. In IP routing examples, 10.1.1.1 is the IP address of the ethernet interface in Atlanta and 255.0.0.0 is the corresponding subnet mask. For examples in which IP is bridged, all interfaces on the router are configured with the same IP address because the router is reduced to a simple node on an IP network with only one IP address.
ip classless | IOS Command Reference |
---|
This command allows the router to forward packets destined to an unrecognized subnet of a directly connected network onto the best supernet route. For example, the 10.0.0.0 network is subnetted with a 255.255.255.0 subnet mask. Let's pretend that the 10.1.1.0 subnet is directly attached to ethernet0 (i.e. interface ethernet0 has the ip address 10.1.1.1 255.255.255.0). Suppose the router receives a packet destined to 10.2.2.0 and the router has no explicit entry for this network. Without the IP classless command, the packet is discarded. However, with the IP classless command, the packet is not discarded, but instead forwarded to the best supernet route if one exists (i.e. a default route).
ip http server | IOS Command Reference |
---|
This command allows remote configuration and management of the router via a web browser and is available in IOS software versions 11.1 and higher. This command has been included as a convenience to the user and is not necessary for configurations to operate properly.
ip nat {inside | outside} | IOS Command Reference |
---|
This command is used on a NAT border router to place an interface either inside the private network or outside on the public network. Traffic entering or leaving an inside interface is subject to NAT translation as defined by the ip nat inside source command. In the NAT examples, only the Atlanta router contains NAT commands since Atlanta is the NAT border router.
ip nat inside source {list {access-list_number | name} interface interface-type | pool name [overload] | static local_ip global_ip} | IOS Command Reference |
---|
This command controls the translation of private source IP addresses into public addresses. In the NAT examples, all workstation traffic destined to the Internet appears to be sent from the public IP address assigned to interface dialer0. Specifically, the command "ip nat inside source list 1 interface dialer 0 overload" applies NAT to any packet whose source IP address matches access-list 1 (i.e. 10.x.x.x or 20.x.x.x). The source address is then changed into the public IP address assigned to interface dialer0. The overload parameter enables multiple private inside addresses to share one public address by identifying connections with different TCP ports.
It is also possible to statically assign a separate public IP address to an inside private device. Static translation is normally reserved for inside devices requiring the same dedicated public IP address (e.g. a web server). In NAT examples, the command "ip nat inside source static 10.1.1.3 215.1.1.2" translates the 10.1.1.3 private address of the web server into a public address of 215.1.1.2. This 215.1.1.2 IP address must be a valid public IP address assigned by the ISP. Once a static translation has been configured, outside users may access the web server at 10.1.1.3 by using the public 215.1.1.2 IP address.
ip nat pool name start-ip end-ip {netmask netmask | prefix-length prefix-length} [type rotary] | IOS Command Reference |
---|
This command defines a pool of public IP addresses that are assigned dynamically to private clients as NAT connections are requested. Public IP addresses are valid Internet addresses assigned by the Internet Service Provider. In the NAT examples, "ip nat pool goodnet 215.1.1.3 215.1.1.254 255.255.255.0" defines a pool named goodnet that contains IP addresses beginning with 215.1.1.3 and ending with 215.1.1.254 using a subnet mask of 255.255.255.0. Notice that the dynamic pool begins with 215.1.1.3 because 215.1.1.1 is reserved for the ISDN interface and 215.1.1.2 is used for a static NAT translation.
ip nat translation {timeout | udp-timeout | dns-timeout | tcp-timeout | finrst-timeout} seconds | IOS Command Reference |
---|
This command controls the amount of time in seconds after which Network Address Translations timeout. In the NAT examples, the NAT table entries will timeout after 1800 seconds of idleness.
ip route network subnet-mask {address | interface} | IOS Command Reference |
---|
This command defines a static IP route. The first and second fields define the destination network number and subnet mask. The third field defines the next hop and can either be specified as an IP address or an interface.
Note: Under most circumstances, the third field contains the IP address of the next hop. However, for routes over unnumbered point-to-point interfaces, specify the interface used to reach the destination.
In some statically routed examples, Atlanta has a static IP route to Boston (e.g. ip route 20.0.0.0 255.0.0.0 Dialer0). In these cases, Atlanta knows that IP network 20.0.0.0 (Boston) with a subnet mask of 255.0.0.0 can be reached via interface Dialer0. In other examples, a static IP default route is defined using 0.0.0.0 as both the destination network number and subnet mask. The default route is used if the router does not already have an explicit routing table entry for a destination network. For instance, in the ISP examples, "ip route 0.0.0.0 0.0.0.0 Dialer0" defines a static IP default route to the ISP. In these cases, Atlanta forwards all packets not destined for its local network onto the ISP using interface Dialer0.
ip subnet-zero | IOS Command Reference |
---|
When subnetting an IP network, the all zeroes subnet and the all ones subnet are normally discarded as invalid. This command allows the router to recognize the zero subnet range as a valid range of addresses. This command is not necessary if the network is not subnetted, although it does not hurt to include the command in the configuration. For instance, if a router is configured with the address of 206.1.1.1 255.255.255.192 without including the ip subnet-zero command, the error "Bad mask /26 for address 206.1.1.1" would be displayed because 206.1.1.1 is part of the zero subnet.
ip unnumbered source-interface | IOS Command Reference |
---|
This command configures a point-to-point interface to use unnumbered IP addressing. IP unnumbered helps conserve IP addresses and network space. Essentially, the IP address of the source interface is borrowed and used on the serial interface. In the examples, Ethernet0 is used as the source interface.
Info On IP Unnumbered Faxback Doc #ip_unnum |
ipx network network [encapsulation encapsulation-type [secondary]] | IOS Command Reference |
---|
This command binds an IPX network number and frame type to an interface. If no IPX frame-type is specified, the router will default to Novell 802.3 encapsulation. The network number and frame-type should match the settings bound to existing IPX servers and clients. If no servers exist at the site a new, unique IPX network number must be created.
Possible IPX Frame Types novell-ether Novell Ethernet 802.3 (default) arpa Novell Ethernet II sap IEEE 802.2 on Ethernet, FDDI, Token Ring snap IEEE 802.2 SNAP on Ethernet, Token Ring, FDDI It is possible to add more than one IPX network to the same LAN interface as long as different frame types are used. The keyword "secondary" flags the router to add a network as an additional network. Secondary networks can be added for each additional frame type. For instance, in IPX examples, Atlanta has two networks on Ethernet0. IPX network 100 is using 802.2 framing and IPX network 101 is using 802.3 framing.
The ISDN interface also requires its own unique IPX network segment. In IPX examples, the IPX network number for the segment between Atlanta and Boston is AAAA. Therefore, Atlanta's interface Dialer0 to Boston is assigned the AAAA IPX network number and Boston's interface Dialer0 to Atlanta is also assigned the AAAA IPX network number.
Note: Depending on the version of IOS, the field "encapsulation NOVELL-ETHER" may not appear in the configuration because NOVELL-ETHER is the default value.
ipx route network network.node | IOS Command Reference |
---|
This command creates a static IPX route. The first field specifies the destination IPX network number. The second field specifies the IPX address of the next hop used to reach the destination. Normally, routing information would be resolved automatically with a routing protocol (e.g. IPX RIP/SAP). However, in the static IPX routing examples, routing protocols are disabled on the dialed interfaces. Instead, each router has a static IPX route entry for every remote IPX internal and external network number.
For example, For workstations in Atlanta to access BostonFS, Atlanta requires a static route to the internal IPX network number of BostonFS (IPX network 2000). The command "ipx route 2000 AAAA.0000.0cbb.2222" informs Atlanta that IPX network 2000 can be reached via the next hop IPX address AAAA.0000.0cbb.2222. AAAA is the IPX network number of the segment between Atlanta and Boston. 0000.0cbb.2222 is the MAC address Boston uses for the IPX routing process. This is the same MAC address that appears in Boston's ipx routing command.
ipx routing [node-address] | IOS Command Reference |
---|
This command enables the IPX RIP/SAP routing engine on the router. The router associates the specified node-address with the IPX routing process. If no node-address value is supplied the router will automatically supply a node address for the routing process. It is recommended that the router assign the address automatically so that accidental node address duplication does not occur.
ipx sap service-type name network.node IPX-socket hop-count | IOS Command Reference |
---|
This command creates a static IPX service announcement and 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 is resolved automatically with a routing protocol (e.g. IPX RIP/SAP). However, in static IPX routing examples, routing protocols are disabled on the dialed interfaces. Instead, a static SAP is created for every remote IPX service that must be reached.
For instance, if clients in Atlanta wish to access BostonFS, Atlanta needs a static SAP for BostonFS. The command "ipx sap 4 BostonFS 2000.0000.0000.0001 451 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. 0000.0000.0001 is the internal node number of the file server. The service type, service name, and socket number will vary depending on the service (e.g. print servers, file servers).
ipx watchdog-spoof | IOS Command Reference |
---|
IPX watchdog packets are keepalives that are sent from servers to clients to verify if an idle workstation is 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. 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."
Note: Before an interface can support this command, the interface must be first configured as a dialed interface (dialer in-band) and then fast-switching and autonomous switching must be disabled (no ipx route-cache).
isdn spid1 spid-number [ldn] | IOS Command Reference |
---|
This command configures the service profile identifier (SPID) number and local directory number (LDN) assigned to the B1 channel by the ISDN service provider. To define the SPID and LDN for the B2 channel, use the corresponding "isdn spid2" command. The SPID identifies a subscribed ISDN service. This number is provided by the ISDN service provider and is usually a 10-digit telephone number with some extra digits. The LDN is the 7-digit local phone number (no area code). In the examples, Atlanta is configured with "isdn spid1 01404555111100 5551111". 01404555111100 is the SPID and 5551111 is the actual 7 digit phone number (LDN) assigned to Atlanta's B1 channel.
isdn switch-type switch-type | IOS Command Reference |
---|
This command specifies the ISDN switch type used by 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 will provide switch type information.
North American ISDN Switch Types basic-5ess AT&T 5ESS custom (point-to-point or multipoint) basic-dms100 NT DMS-100 basic-ni1 National ISDN-1
line vty 0 4 | IOS Command Reference |
---|
This command defines the number of virtual terminal (telnet) sessions to the router. In the examples, five telnet sessions can be accommodated, numbered 0 to 4. The number of telnet sessions supported varies by platform and amount of memory.
map-class dialer classname | IOS Command Reference |
---|
This command defines a class of configuration parameters referenced by either the dialer map or dialer string commands. Under the map class dialer definition, specific dialer properties can be configured; among these properties is the ISDN dial speed. In ISP example configurations, the command illustrates how a 56Kbps ISDN call is placed. Calls to the ISP are placed with the "dialer string 14045553333 class 56K" command. "Class 56K" refers to a map class dialer named "56K". The dial speed is then set with the dialer ISDN command.
Note: The router places ISDN calls at 64Kbps by default. For 64Kbps calls, "map class" commands are not necessary. The dialer string would simply read "dialer string 14045553333" and the "map-class dialer 56K" related commands are omitted.
network network | IOS Command Reference |
---|
This command adds an IP network to RIP routing updates advertised by the router. Only directly connected IP networks should be added. In the examples, Atlanta includes network 10.0.0.0 in its router rip definition because this is directly attached to Ethernet0. Likewise, Boston will include any directly attached networks in its router rip configuration.
Note: Only the major network number is entered for RIP. If a subnet is entered (e.g. 10.1.1.0), it is automatically rounded off to the major network number (e.g. 10.0.0.0).
no auto-summary | IOS Command Reference |
---|
This command turns off auto-summarization of routes. When using RIP version 2, variable length subnet masks are accommodated.
no ip address |
In the examples, no ip address (or IPX network number) is configured on the physical BRI0 interface because all protocol address information is moved to the logical Dialer0 interface.
no ip domain-lookup | IOS Command Reference |
---|
This command disables the router from translating unfamiliar words typed during a console session into IP addresses. During this lookup, a user cannot enter any commands into the router. Though a useful feature to some, many find it frustrating to wait for the lookup to timeout for every mistyped command. Therefore, the command has been included in the configurations as a convenience and is not a necessary parameter for configurations to operate properly.
no ip routing | IOS Command Reference |
---|
IP routing is on by default. For examples in which IP is bridged, this command disables the IP routing engine.
no ipx route-cache | IOS Command Reference |
---|
This command disables IPX fast switching and autonomous switching. For scenarios in which IPX watchdog packets are spoofed.
password password | IOS Command Reference |
---|
This command sets the password for either a console, telnet, or modem connection into the router. A console password is set under line con, a telnet password is set under line vty, and a modem connection password is also set under the corresponding line command.
ppp authentication {chap | chap pap | pap chap | pap} [callin] | IOS Command Reference |
---|
This command enables PPP authentication on an interface and 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 CHAP authentication and, if unsuccessful, will then attempt PAP. The callin keyword is optional and specifies that authentication is forced for incoming calls only. This is known as unidirectional PPP authentication and is implemented in ISP sample configurations.
Cisco routers support bi-directional authentication if the callin keyword is not supplied. All examples, other than ISP examples, illustrate a bi-directional authentication scenario. When Atlanta calls Boston, Atlanta forces Boston to identify itself with a username (Boston) and password (gocisco1). Likewise, Boston forces Atlanta to identify itself with a username (Atlanta) and password (gocisco1). With bi-directional authentication, Atlanta is offered the added security that the device answering the ISDN phone call is indeed the router it intended to call.
Unidirectional authentication is used in ISP sample configurations because non-Cisco routers that do not support bi-direction authentication are potentially in use at the ISP. In these cases, when Atlanta calls the ISP, Atlanta does not authenticate. However, the ISP will authenticate Atlanta before allowing the connection. Proponents of unidirectional authentication believe that, since Atlanta initiated the call, Atlanta must already know who it is calling and therefore authentication is not necessary in that direction.
Info On PPP And Authentication Faxback Doc #ppp |
ppp chap hostname hostname | IOS Command Reference |
---|
The hostname sent by the router during PPP CHAP authentication can be configured at the interface level with this command. This command appears in the example configurations where a dialer map cannot be used.
ppp chap password secret | IOS Command Reference |
---|
The PPP CHAP secret sent by the router during PPP CHAP authentication can be configured at the interface level with this command. This command appears in ISP example configurations where a dialer map cannot be used.
Note: The unencrypted form of the password "gocisco1" is shown in this sample configuration. In the actual configuration, the password appears in an encrypted form: (i.e. ppp chap password 7 13061E010803 --where 7 denotes the encryption type and 13061E010803 is an encrypted form of the password gocisco1.) When entering or making changes to the ppp chap password, always type the password in its unencrypted form. Do not enter the encryption type (7); it is set automatically.
ppp multilink | IOS Command Reference |
---|
This command enables multilink PPP on the ISDN interface. Multilink PPP allows B channel aggregation for higher bandwidth. Routers on both ends of the ISDN link must support multilink PPP for successful negotiation.
ppp pap sent-username username password password | IOS Command Reference |
---|
The PAP username and password sent by the router during PPP PAP authentication can be configured at the interface level with this command. The command appears in ISP example configurations where a dialer map cannot be used.
router rip | IOS Command Reference |
---|
This command enables the RIP routing process on the router for TCP/IP.
snapshot client active-time quiet-time [suppress-statechange-updates] [dialer] | IOS Command Reference |
---|
This command configures a router as a snapshot routing client. During a specified active time interval, snapshot clients initiate an ISDN connection to exchange routing information with a snapshot server. The ISDN call is initiated for a snapshot update using the dialer map command.
The period in which routes are exchanged is known as the active time interval. The duration of the active interval can range from five to 100 minutes. The quiet time interval exists between active times and can range from eight to 100,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 addition to the active time, snapshot routing updates may also be triggered whenever the line protocol on an interface changes state (e.g. up to down). These conditions can be ignored if the suppress-statechange-updates configuration option is included.
The dialer keyword option allows the router to dial the remote site for the exchange of routing updates if the ISDN line is not already active.
Info On Snapshot Routing Faxback Doc #snapshot |
snapshot server active-time [dialer] | IOS Command Reference |
---|
This command configures a router as a snapshot routing server. 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 five to 100 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.
The dialer keyword option allows the router to dial the remote site for the exchange of routing updates if the ISDN line is not already active.
Info On Snapshot Routing Faxback Doc #snapshot |
username name password secret | IOS Command Reference |
---|
This command specifies a PPP CHAP or PAP (depending on which is specified with the ppp authentication command) authentication password for each individual remote user. PPP authentication is implemented with this command in scenarios where dialer maps are used. The username is case sensitive and must match the opposite router's hostname. The password is also case sensitive and must match the password set in the opposite router's corresponding username definition.
For example, Atlanta is configured with "username Boston password gocisco1" and Boston is configured with the command, "username Atlanta password gocisco1". The routers have matching PPP passwords (gocisco1) for each other's username.
Note: The unencrypted form of the password "gocisco1" is shown in the sample configurations. In actual configurations, the password appears in an encrypted form: (i.e. username Boston password 7 13061E010803 - where 7 denotes the encryption type and 13061E010803 is an encrypted form of the password gocisco1.) When entering or making changes to the username and password, type the password in its unencrypted form. Do not enter the encryption type (7); it is set automatically.
Info On PPP And Authentication Faxback Doc #ppp |
version 2 | IOS Command Reference |
---|
This command specifies RIP version 2 as the routing protocol and is available in IOS software versions 11.1 and later. RIP version 2 is backwards compatible with RIP version 1 and adds the enhanced capability to support variable length subnet masks.
All contents copyright © Cisco Systems, Inc. Important notices.