| [ LiB ] |   |
Scenarios
As you have recently learned, PPP is widely used by many telecommuters to access their private corporate networks remotely. In this section, you will configure a remote-access setup. Although each scenario completes its own task, together the scenarios form one logical implementation. Every scenario builds on the previous one. They are based on the topology shown in Figure 5-7.
Figure 5-7. PPP Scenarios Topology
The scenarios show you how to
Configure the PPP communications protocol for operation
Control network access with PAP authentication
Configure PPP compression
Scenario 5-1: Initial Access Server and Network Setup
Before turning to the PPP-specific setup, you need to perform some initial configuration on the access server. The configuration in this section is basic and should be familiar to you.
Configure the username admin password cisco combination for an administrator:
R1(config)#username name password string
Example 5-1 shows the running configuration on R1.
Example 5-1. show running-config Command Output
version 12.2 service timestamps debug datetime localtime service timestamps log datetime localtime no service password-encryption ! username admin password cisco hostname R1 ! line vty 0 4 password cisco
Next, you use the absolute line number to configure an asynchronous link. The absolute line number changes with different router models, so you should verify it. To figure out to which line number the modem is attached, issue the show line command. The line number displayed in the output is the one that needs configuration. In Example 5-2, you can see that the line number corresponds to TTY port 8.
Example 5-2. show line Command Output
R6#show line
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int
* 0 CTY - - - - - 0 0 0/0 -
* 8 AUX 57600/57600 F inout - - - 0 0 0/0 -
After finding the correct line number, you must configure the modem on that line. Because you don't know the modem type, you should use the autoconfigure type default command.
As you can see from Example 5-3, the modem line configuration includes the modem inout and modem autoconfigure commands. If you remember, the default on Cisco routers is to reject the incoming network connections to asynchronous ports. You are also required to specify an incoming transport protocol or, in this case, use the transport input all command to indicate that any type of protocol is allowed.
Example 5-3. Configuring a Line for the Modem
R1(config)#line aux 8 R1(config-line)#modem InOut R1(config-line)#modem autoconfigure discovery R1(config-line)#login local R1(config-line)#transport input all R1(config-line)#flowcontrol hardware
NOTE
Example 5-3 demonstrates the configuration of line 8 for a modem. You should be familiar with all these commands from reading Chapter 3. Refer to that chapter to refresh your memory.
Scenario 5-2: Configuring PPP on the Asynchronous Link
Now that you've enabled the basic configuration on the access server, you can move on to the PPP-related tasks.
Enabling the Autosensing Feature
The first of these tasks is to prepare line 8 for PPP use. You enabled the modem functions on the line in the previous scenario. Now it's time to allow a PPP session to start on the router.
A Cisco access server can be configured to accommodate (autosense) a PPP or SLIP session to start automatically or through the user prompt. If autosensing is not configured on your access server, the router does not recognize a connection attempt and does not respond to the client.
The following command is placed on the absolute line number (line 8 in this case), along with the rest of the modem commands:
R1(config-line)#autoselect [arap | ppp | slip | during-login]
By selecting one of this command's options, you allow the router to start a corresponding process when it receives a starting character. Each of the three protocols as well as the carriage return has a recognizable start character contained in a frame's flag. For instance, when a return character is encountered, the access server knows to start an EXEC session.
Table 5-4 shows the frame flag values in hexadecimal format for the protocols available for autosensing.
Protocol | Flag Value |
|---|---|
Return key | 0d |
ARAP | 10 |
PPP | 7E |
SLIP | c0 |
When configuring the autoselect command, you need to specify which of the three protocols is allowed to start a session. In this scenario, it is obviously PPP. Also, use the autoselect command with the during-login keyword to cause the username/password prompt to come up without the user's having to press Enter. Example 5-4 displays the autoselect commands used for this scenario.
Example 5-4. Enabling Autosensing
R1(config)#line 8 R1(config-line)#autoselect during-login R1(config-line)#autoselect ppp
Configuring the Asynchronous Interface
The next task is to configure the router's asynchronous interface and enable PPP on it. The asynchronous interface in question should match the modem line number. Enter interface configuration mode by issuing the int async65 command. After you are in interface configuration mode, you can proceed with the PPP-specific and general statements.
Enabling PPP Encapsulation
To enable PPP on any type of connection, whether synchronous or asynchronous, you need to define PPP encapsulation at the interface level of both ends of the connection by entering the following command:
R1(config-if)#encapsulation ppp
Configuring Local Interface Addressing
The next step involves configuring the network layer address on the local asynchronous interface (8, in this case) in the following manner:
R1(config-if)#ip address address mask
Configuring Interface Addressing of Remote Devices
At this point you need to create a method for assigning an IP address to the PPP client dialing into the router. The IP address for a particular peer can be managed on the NAS in a number of ways:
Static configuration of IP addresses for each interface.
A local pool of IP addresses can be configured on the NAS. In such instances, the IP address is allocated by the pool.
The IP address can be assigned by a Dynamic Host Configuration Protocol (DHCP) server.
The IP address can be assigned by an AAA server.
The peer can request a specific IP address, in which case the NAS would only need to acknowledge the request.
As mentioned earlier, you can set up your configuration so that the peer's IP address is assigned centrally. The following command is used to specify a client's source originating address. When a client dials into the appropriate line, the address is allocated from the specified location.
R1(config-if)#peer default ip address [ip-address | dhcp | pool poolname]
You can see that the available options include a specific IP address, a local pool of addresses, or a DHCP server. If you choose to specify the pool argument, you need to configure a global address pool that matches the name of the peer default ip address command. Here's the command syntax to configure the local pool:
R1(config)#ip local pool pool-name starting-address ending-address
If you decide to go with the dhcp option, you need to configure the ip helper address and ip dhcp-server as well.
To specify dynamic addressing (addressing requested by the user at the EXEC level upon connection), issue the following command:
R1(config-if)#async dynamic address
You may opt to include both default and dynamic options with your configuration. This way, the user will have a choice between the two methods of address assignment. If the user enters the peer's own address, it is used; if the user enters the default keyword, the default address is used instead.
In this scenario, the peer default ip address ip-address option is used. The peer is assigned the address of 10.1.1.254. Example 5-5 demonstrates the interface-level commands used in this scenario.
Example 5-5. Enabling PPP at the Interface Level
R1(config)#int async65 R1(config-if)#encapsulation ppp R1(config-if)#ip address 10.1.1.1 255.255.255.0 R1(config-if)#peer default ip address 10.1.1.254
Verification
Make sure that the previous steps have resulted in the proper configuration. Look at the interface configuration by issuing the show interface async 65 command, as shown in Example 5-6.
Example 5-6. show interface async 65 Command Output
R1#show interfaces async 65 Async65 is up, line protocol is up Hardware is Async Serial MTU 1500 bytes, BW 57600 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 5 seconds on reset LCP Open Closed: BRIDGECP, IPCP, CCP, CDPCP, LLC2, BACP, IPV6CP Last input never, output 00:14:49, output hang never Last clearing of "show interface" counters 00:14:59 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/1/16 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 6 kilobits/sec 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 1 packets output, 24 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
To verify that the line configuration for the modem has been configured correctly, enter the show line x command, as shown in Example 5-7. Note that line 8 is used in this example.
Example 5-7. show line 65 Command Output
R1#show line 8 Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int * 8 AUX 57600/57600 F inout - - - 0 0 0/0 - Line 8, Location: "", Type: "" Length: 24 lines, Width: 80 columns Baud rate (TX/RX) is 57600/57600, no parity, 2 stopbits, 8 databits Status: Ready, Active, No Exit Banner, Modem Configuring, Modem Speed Locked, Modem Signals Polled, Autoconfig Running Capabilities: Autobaud Full Range, Hardware Flowcontrol In, Hardware Flowcontrol Out, Modem Callout, Modem RI is CD, Line usable as async interface, Modem Discovery Modem state: Ready Modem hardware state: CTS DSR DTR RTS Special Chars: Escape Hold Stop Start Disconnect Activation ^^x none - - none Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch 00:10:00 never none not set Login-sequence User Response 00:00:30 Autoselect Initial Wait Modem type is usr_sportster. Session limit is not set. Time since activation: never Editing is enabled. History is enabled, history size is 10. DNS resolution in show commands is enabled Full user help is disabled Allowed input transports are pad v120 telnet rlogin udptn ssh. Allowed output transports are pad v120 telnet rlogin ssh. Preferred transport is telnet. No output characters are padded No special data dispatching characters
Scenario 5-3: Configuring Interface Parameters Available with PPP
A number of interface-level commands can be configured as part of the PPP setup on the NAS. Scenario 5-2 introduced interface parameters that are required with PPP. In this scenario, you will configure optional but highly desirable and widely used PPP services.
Configuring PPP Authentication
Probably the most implemented of all PPP interface parameters is authentication. As you learned earlier in this chapter, PAP and CHAP are the two PPP authentication options. The command to configure authentication is as follows:
R1(config-if)#ppp authentication [pap | chap]
The ppp authentication command can configure either the PAP or CHAP authentication method. The correct method is indicated by the appropriate keyword.
You may use the ppp authentication, ppp authorization, and ppp accounting commands at an interface level.
Configuring Asynchronous Callback
Cisco router interfaces support PPP asynchronous callback. This configuration assumes that other PPP and modem-related features that were covered in previous scenarios are already enabled.
Configuring Callback PPP Clients
There are two types of clients for which you can enable the callback feature on the NAS:
Those that support PPP callback per RFC 1570
Those that do not but instead can put themselves in answer mode, which accepts the router's callback
For clients that are PPP callback-compliant, you can configure the router to accept the clients' callback request with the following command:
R1(config-if)#ppp callback accept
Use this command to configure the callback feature for clients that are not RFC 1570-compliant:
R1(config-if)#ppp callback initiate
Because the client can't request callback itself, the router can initiate on behalf of the client.
Configuring IPCP
Think back to the discussion of the NCP IPCP near the beginning of this chapter. You have an option to specifically include several IPCP parameters with your PPP configuration, such as the primary and secondary DNS and WINS server addresses, the peer-requested address, and so on. Here is the general syntax for the ipcp command:
R1(config-if)#ppp ipcp [accept-address | dns [reject | accept | primary-ip-address [secondary-ip-address] [accept]] | ignore-map | username unique | wins [reject | accept | primary-ip-address [secondary-ip-address] [accept]]]
If you put a question mark after the ppp ipcp interface command, a list of options appears, as shown in Example 5-8. This Example shows the IPCP available parameters specified on R1.
Example 5-8. Available IPCP Options
R1(config-if)#ppp ipcp ?
accept-address Accept any non zero IP address from our peer
address Additional ipcp address options
dns Specify DNS negotiation options
header-compression IPCP header compression option
ignore-map Ignore dialer map when negotiating peer IP address
mask Specify subnet mask negotiation options
predictive Predict peers IPCP requests/replies
username Configure how usernames are handled
wins Specify WINS negotiation options
Table 5-5 explains the options in Example 5-8.
Option | Description |
|---|---|
accept-address | Accepts any nonzero IP address from the peer. |
dns [accept | reject] | Domain Name Server. Accepts a peer request for any nonzero server address. Rejects the IPCP option if received from the peer. |
ignore-map | Ignores the dialer map when negotiating the peer IP address. |
username unique | Ignores a common username when providing an IP address to the peer. |
Wins | Windows Internet Naming Service. |
Example 5-9 displays the IPCP options configured on R1.
Example 5-9. Configuring IPCP Parameters
R1(config)#interface async65 R1(config-if)#ppp ipcp accept-address R1(config-if)#ppp ipcp header-compression ack R1(config-if)#ppp ipcp dns 10.1.1.1 R1(config-if)#ppp ipcp wins 10.1.1.12 R1(config-if)#ppp ipcp mask 255.255.255.0 R1(config-if)#ppp ipcp username-unique R1(config-if)#ppp ipcp ignore-map
Scenario 5-4: Configuring the Asynchronous Interface for DDR
It's time to enable DDR tasks on your router. The commands introduced in this scenario are applied to the asynchronous interface.
Dialer Commands
Remember the peer default ip address command you entered earlier? This command allows the router to accept the peer's address:
R1(config-if)#dialer in-band
Beware of the order in which these commands need to be added to your configuration. The peer default ip address command must come first, followed by the dialer in-band command. If this order is reversed, the peer's IP address will not be accepted.
The following commands allow the definition of interesting traffic to be associated with the interface:
R1(config-if)#dialer-group list-number R1(config-if)#dialer idle-timeout seconds
The idle-timeout period specifies how many seconds free of interesting traffic the line tolerates before disconnecting.
Configuring Dedicated or Interactive PPP Sessions
The following command empowers the user to enter PPP commands, such as the IP address, at the EXEC level. If the async dynamic address command you learned earlier is specified, the router must be put into interactive mode. Dedicated mode does not allow user input.
R1(config-if)#async mode [dedicated | interactive]
Example 5-10 shows all the commands covered in the preceding sections.
Example 5-10. Configuring DDR on the Interface
R1(config)#int async65 R1(config-if)#dialer in-band R1(config-if)#dialer idle-timeout 600 R1(config-if)#dialer-group 8 R1(config-if)#async mode interactive
Specifying Interesting Traffic
Now that you've tied the interesting traffic list to the interface, you need to define the interesting traffic parameters under the global configuration. In other words, you need to create a traffic rule that triggers asynchronous calls:
R1(config)#dialer-list dialer-group protocol protocol-name [permit | deny | list access-list-number | access-group]
As you can see, the interesting traffic definition can get quite extensive, especially if you add access lists to the equation. It is not the intention of this chapter to cover DDR in detail. You will have a chance to learn more about it in subsequent chapters. For this scenario, the dialer list can be kept to its bare minimum (IP routing), because the router is not used to initiate calls or route over the link. Example 5-11 shows R1's complete DDR configuration.
Example 5-11. show running-config Command Output
interface Async65 no ip address encapsulation ppp no ip route-cache no ip mroute-cache dialer in-band dialer fast-idle 122 dialer string 5551212 dialer hold-queue 100 dialer-group 1 ! dialer-list 1 protocol ip permit
Verification
When you complete the preceding tasks, you can test the validity of your configuration. You may check the modem with the debug confmodem and debug modem commands. You can examine the result of issuing these commands in Example 5-12. The AT commands are sent by the router to the modem.
Example 5-12. Output from the debug modem and debug confmodem Commands
R1#clear line 65 R1#debug modem 15:25:51: TTY65: DSR came up 15:25:51: tty65: Modem: IDLE->READY 15:25:51: TTY65: Autoselect started 15:27:51: TTY65: Autoselect failed 15:27:51: TTY65: Line reset <--- Clear line 65 15:27:51: TTY65: Modem: READY->HANGUP 15:27:52: TTY65: dropping DTR, hanging up 15:27:52: tty65: Modem: HANGUP->IDLE 15:27:57: TTY65: restoring DTR 15:27:58: TTY65: DSR came up R1#terminal monitor R1#debug confmodem Modem Configuration Database debugging is on *Mar 3 03:06:30.931: TTY1: detection speed (57600) response ---OK--- *Mar 3 03:06:30.963: TTY1: Modem command: --AT&FS0=1-- *Mar 3 03:06:31.483: TTY1: Modem configuration succeeded *Mar 3 03:06:31.487: TTY1: Detected modem speed 57600 *Mar 3 03:06:31.487: TTY1: Done with modem configuration
Now that you know your physical layer is functioning properly, you can verify the upper layers. You can turn on PPP debugging using the following commands:
R1#debug ppp negotiation R1#debug ppp authentication R1#debug ppp error
When initiating a PPP session to the router by a workstation, note the following processes in the debug output for organized troubleshooting:
PPP initialization when the first PPP string is received
LCP finishes the PPP negotiation
Authentication negotiation finishes successfully
The peer receives the proper IP address
Example 5-13 demonstrates PPP debugging using the debug ppp negotiation, debug ppp authentication, and debug ppp error commands.
Example 5-13. Debugging PPP
R1# debug ppp negotiation *Mar 2 02:25:27.693: %LINK-3-UPDOWN: Interface Async65, changed state to up *Mar 2 02:25:27.693: Se0/0 PPP: Treating connection as a dedicated line *Mar 2 02:25:27.693: Se0/0 PPP: Phase is ESTABLISHING, Active Open *Mar 2 02:25:27.693: Se0/0 LCP: O CONFREQ [Closed] id 11 len 10 *Mar 2 02:25:27.693: Se0/0 LCP: MagicNumber 0x35C4DB07 (0x050635C4DB07) *Mar 2 02:25:27.729: Se0/0 LCP: I CONFREQ [REQsent] id 14 len 29 *Mar 2 02:25:27.729: Se0/0 LCP: MagicNumber 0xBFAE7481 (0x0506BFAE7481) *Mar 2 02:25:27.729: Se0/0 LCP: MRRU 1524 (0x110405F4) *Mar 2 02:25:27.729: Se0/0 LCP: EndpointDisc 1 Local (0x130F01696F7377616ED3 23630 3063) *Mar 2 02:25:27.729: Se0/0 LCP: O CONFREJ [REQsent] id 14 len 23 *Mar 2 02:25:27.729: Se0/0 LCP: MRRU 1524 (0x110405F4) *Mar 2 02:25:27.733: Se0/0 LCP: EndpointDisc 1 Local (0x130F01696F7377616ED3 23630 3063) *Mar 2 02:25:27.733: Se0/0 LCP: O CONFACK [REQsent] id 15 len 10 *Mar 2 02:25:27.733: Se0/0 LCP: MagicNumber 0xBFAE7481 (0x0506BFAE7481) *Mar 2 02:25:27.733: Se0/0 LCP: State is Open *Mar 2 02:25:27.733: Se0/0 PPP: Phase is UP *Mar 2 02:25:27.737: Se0/0 IPCP: O CONFREQ [Closed] id 10 len 16 *Mar 2 02:25:27.737: Se0/0 IPCP: CompressType VJ 15 slots (0x0206002D0F00) *Mar 2 02:25:27.737: Se0/0 IPCP: Address 10.1.30.200 (0x03060A011EC8) *Mar 2 02:25:27.745: Se0/0 LCP: I CONFACK [Open] id 11 len 10 *Mar 2 02:25:27.745: Se0/0 LCP: MagicNumber 0x35C4DB07 (0x050635C4DB07) *Mar 2 02:25:27.777: Se0/0 LCP: I CONFREQ [Open] id 15 len 10 *Mar 2 02:25:27.781: Se0/0 LCP: MagicNumber 0xBFAE7481 (0x0506BFAE7481) *Mar 2 02:25:27.781: Se0/0 LCP: Dropping packet, state is Open *Mar 2 02:25:27.813: Se0/0 IPCP: I CONFREQ [REQsent] id 105 len 28 *Mar 2 02:25:27.813: Se0/0 IPCP: CompressType VJ 15 slots (0x0206002D0F00) *Mar 2 02:25:27.813: Se0/0 IPCP: Address 0.0.0.0 (0x030600000000) *Mar 2 02:25:27.813: Se0/0 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *Mar 2 02:25:27.813: Se0/0 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *Mar 2 02:25:27.813: Se0/0 IPCP: Pool returned 10.1.30.109 *Mar 2 02:25:27.817: Se0/0 IPCP: O CONFREJ [REQsent] id 105 len 16 *Mar 2 02:25:27.817: Se0/0 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *Mar 2 02:25:27.817: Se0/0 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *Mar 2 02:25:27.817: Se0/0 IPCP: O CONFNAK [REQsent] id 106 len 10 *Mar 2 02:25:27.817: Se0/0 IPCP: Address 10.1.30.109 (0x03060A011E6D) *Mar 2 02:25:27.817: Se0/0 IPCP: O CONFACK [REQsent] id 107 len 16 *Mar 2 02:25:27.817: Se0/0 IPCP: CompressType VJ 15 slots (0x0206002D0F00) *Mar 2 02:25:27.821: Se0/0 IPCP: Address 10.1.30.109 (0x03060A011E6D) *Mar 2 02:25:27.833: Se0/0 IPCP: I CONFACK [ACKsent] id 10 len 16 *Mar 2 02:25:27.833: Se0/0 IPCP: CompressType VJ 15 slots (0x0206002D0F00) *Mar 2 02:25:27.833: Se0/0 IPCP: Address 10.1.30.200 (0x03060A011EC8) *Mar 2 02:25:27.833: Se0/0 IPCP: State is Open *Mar 2 02:25:27.837: Se0/0 IPCP: Install route to 10.1.30.109 *Mar 2 02:25:27.837: Se0/0 IPCP: Add link info for cef entry 10.1.30.109 *Mar 2 02:25:27.861: Se0/0 IPCP: I CONFREQ [Open] id 106 len 16 *Mar 2 02:25:27.865: Se0/0 IPCP: CompressType VJ 15 slots (0x0206002D0F00) *Mar 2 02:25:27.865: Se0/0 IPCP: Address 0.0.0.0 (0x030600000000) *Mar 2 02:25:27.865: Se0/0 IPCP: Dropping packet, state is Open *Mar 2 02:25:27.881: Se0/0 IPCP: I CONFREQ [Open] id 107 len 16 *Mar 2 02:25:27.885: Se0/0 IPCP: CompressType VJ 15 slots (0x0206002D0F00) *Mar 2 02:25:27.885: Se0/0 IPCP: Address 10.1.30.109 (0x03060A011E6D) *Mar 2 02:25:27.885: Se0/0 IPCP: Dropping packet, state is Open *Mar 2 02:25:28.733: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async65/, changed state to up R1# debug ppp authentication May 15 22:05:31.868: %LINK-3-UPDOWN: Interface Async65, changed state to up *May 15 22:05:31.892: %ISDN-6-CONNECT: Interface Async65 is now connected to 5551212 *May 15 22:05:31.900: ASYNC65 PPP: Treating connection as a callout *May 15 22:05:31.900: ASYNC65 CHAP: Using alternate hostname cisco *May 15 22:05:31.984: ASYNC65 CHAP: I CHALLENGE id 50 len 27 from "r8" *May 15 22:05:31.988: ASYNC65 CHAP: Using alternate hostname cisco *May 15 22:05:31.992: ASYNC65 CHAP: Username r8 found *May 15 22:05:31.992: ASYNC65 CHAP: Using default password *May 15 22:05:31.996: ASYNC65 CHAP: O RESPONSE id 50 len 26 from "cisco" R1# debug ppp error PPP Async65(i): rlqr receive failure. successes = 15 PPP: myrcvdiffp = 159 peerxmitdiffp = 41091 PPP: myrcvdiffo = 2183 peerxmitdiffo = 1714439 PPP: threshold = 25 PPP Async65(i): rlqr transmit failure. successes = 15 PPP: myxmitdiffp = 41091 peerrcvdiffp = 159 PPP: myxmitdiffo = 1714439 peerrcvdiffo = 2183 PPP: l->OutLQRs = 1 LastOutLQRs = 1 PPP: threshold = 25 PPP Async65(i): lqr_protrej() Stop sending LQRs. PPP Async65(i): The link appears to be looped back.
Next, you can test your configuration by following up with pings to appropriate addresses, as shown in Example 5-14.
Example 5-14. ICMP Testing
R1#ping 10.10.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.2, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 112/114/120 ms
R1#
If you want to check the results of all the scenarios in R1 configuration, take a look at Example 5-15, which displays R1's show running-config output.
Example 5-15. show running-config Output from R1
version 12.2 service timestamps debug datetime localtime service timestamps log datetime localtime no service password-encryption ! hostname R1 ! interface Async65 no ip address encapsulation ppp no ip route-cache no ip mroute-cache dialer in-band dialer fast-idle 122 dialer string 5551212 dialer hold-queue 100 dialer-group 1 async default routing async dynamic address async dynamic routing async mode interactive ppp reliable-link ppp encrypt mppe auto ppp authentication chap pap ms-chap optional ppp direction callin ppp link reorders ! dialer-list 1 protocol ip permit ! line aux 0 autobaud modem InOut modem autoconfigure discovery transport input all autoselect during-login flowcontrol hardware
| [ LiB ] | |