Microsoft considers optional functions to be advanced options. These options include settings
to control compression and authentication protocols.
Under Advanced Options, five choices can be made by the user or administrator.
Shows the default configuration for a PPP connection with the NetBEUI and IPX/SPX options
unselected.
847
IT Certification CCIE,CCNP,CCIP,CCNA,CCSP,Cisco Network Optimization and Security Tips
Windows for Workgroups and Windows NT 3.1
Windows for Workgroups and Windows NT 3.1
This server type supports only NetBEUI
and its upper layer protocol, NetBIOS. NetBEUI does not support routing, however. It is a
simple protocol and negates the need for addressing. NetBEUI might provide the best performance
for a single connection, but it cannot scale and, given the demands on the network, it’s
probably best to use PPP.
The remainder of this section focuses on the rest of the options on the Server Types tab for
a PPP server type.
This server type supports only NetBEUI
and its upper layer protocol, NetBIOS. NetBEUI does not support routing, however. It is a
simple protocol and negates the need for addressing. NetBEUI might provide the best performance
for a single connection, but it cannot scale and, given the demands on the network, it’s
probably best to use PPP.
The remainder of this section focuses on the rest of the options on the Server Types tab for
a PPP server type.
SLIP
SLIP: Unix Connection
As with CSLIP, SLIP supports only IP connections and does not provide
advanced features. Although PPP is both recommended and popular, a significant number of
installations support only SLIP. Migration from SLIP to PPP is highly recommended because
of PPP’s multiprotocol support.
As with CSLIP, SLIP supports only IP connections and does not provide
advanced features. Although PPP is both recommended and popular, a significant number of
installations support only SLIP. Migration from SLIP to PPP is highly recommended because
of PPP’s multiprotocol support.
PPP
PPP: Internet, Windows NT Server, Windows 98
PPP is not only the default dial-up
server type, it is also the most recommended. As shown in Figure 25.7, it supports all
protocols and features.
PPP is not only the default dial-up
server type, it is also the most recommended. As shown in Figure 25.7, it supports all
protocols and features.
NRN
NRN: NetWare Connection Version 1.0 and 1.1
Just as SLIP and CSLIP supports only IP,
the NRN connection supports only IPX/SPX. This option is provided for legacy installations of
NetWare, but most environments have migrated away from this platform.
Just as SLIP and CSLIP supports only IP,
the NRN connection supports only IPX/SPX. This option is provided for legacy installations of
NetWare, but most environments have migrated away from this platform.
CSLIP
CSLIP: Unix Connection with IP Header Compression
This server type is seldom used for the
reason indicated in Chapter 24: SLIP (Serial Line Internet Protocol) is rarely used due to its sole
support for IP. Legacy Unix servers, however, might still require this option. CSLIP stands for
Compressed Serial Line Internet Protocol. This option supports only IP and does not support
software compression, encrypted passwords, or data compression.
This server type is seldom used for the
reason indicated in Chapter 24: SLIP (Serial Line Internet Protocol) is rarely used due to its sole
support for IP. Legacy Unix servers, however, might still require this option. CSLIP stands for
Compressed Serial Line Internet Protocol. This option supports only IP and does not support
software compression, encrypted passwords, or data compression.
General Tab-Server Types Tab
General Tab
The General tab displays the initial configuration information, including the name, phone number,
country code, and modem that will be used.
Server Types Tab
You will find that the Server Types tab is the most important for remote access configuration.
This tab addresses protocols, encapsulations, addressing, compression, and encryption. You
need to match these settings to those on a Cisco remote access device in order to establish an efficient
connection.
As shown in the first option asks you to specify the type of dial-up server. There
are five options (although the drop-down list shown in this figure has room to show only four).
The types of servers are as follows:
CSLIP: Unix Connection with IP Header Compression
NRN: NetWare Connect Version 1.0 and 1.1
PPP: Internet, Windows NT Server, Windows 98
SLIP: Unix Connection
Windows for Workgroups and Windows NT 3.1
You will learn more about each of these server types next.
The General tab displays the initial configuration information, including the name, phone number,
country code, and modem that will be used.
Server Types Tab
You will find that the Server Types tab is the most important for remote access configuration.
This tab addresses protocols, encapsulations, addressing, compression, and encryption. You
need to match these settings to those on a Cisco remote access device in order to establish an efficient
connection.
As shown in the first option asks you to specify the type of dial-up server. There
are five options (although the drop-down list shown in this figure has room to show only four).
The types of servers are as follows:
CSLIP: Unix Connection with IP Header Compression
NRN: NetWare Connect Version 1.0 and 1.1
PPP: Internet, Windows NT Server, Windows 98
SLIP: Unix Connection
Windows for Workgroups and Windows NT 3.1
You will learn more about each of these server types next.
Connection Properties
After this initial phase is completed, you have the opportunity to select the icon and attempt a connection
with the defaults, or you can right-click the icon to select the properties of the connection.
Select the option you wish to edit, and the connection properties dialog box
opens. Note that there are four tabs: General, Server Types, Scripting, and Multilink.
with the defaults, or you can right-click the icon to select the properties of the connection.
Select the option you wish to edit, and the connection properties dialog box
opens. Note that there are four tabs: General, Server Types, Scripting, and Multilink.
Make New Connection Wizard
After you select the Make New Connection icon, Windows begins the Make New Connection
Wizard. The first dialog box of this wizard is shown in Figure 25.2.
In this dialog box, you type a name for the connection and set the kind of modem that you
will be using for the connection. If Windows did not detect and install a modem in the Select a
Device box, you need to correct this before continuing.
844
Wizard. The first dialog box of this wizard is shown in Figure 25.2.
In this dialog box, you type a name for the connection and set the kind of modem that you
will be using for the connection. If Windows did not detect and install a modem in the Select a
Device box, you need to correct this before continuing.
844
Configuring a Dial-Up Connection Client
The configuration of a Windows client for dial-up networking is a relatively painless process,
although many configuration options are available, and good planning will greatly simplify an
enterprise-level deployment.
By default, the Windows 95/98 installation includes the basic files for installing and configuring
a network connection. It’s always a good idea, though, to have the original installation
CD-ROM available because the setup program might need additional files to complete the
installation. In addition, the latest service packs and updates should be installed—service packs
contain many updates and problem fixes called
patches
. In general, the installation of patches
is a benign event; however, before performing the upgrade, it is best to back up critical files and
review the appropriateness of the patch. For multiple node upgrades, it’s best to test the patch
before you deploy it.
Check the Windows website at
www.microsoft.com
for the latest patches, service
packs, and tips for configuring dial-up networking.
Although many tools are available for installing and configuring dial-up networking, this
book focuses on the basic installation—PPP and TCP/IP protocols. However, multilink connections
and scripting are also presented.
The screen captures in this chapter, unless otherwise noted, are from Windows
98 Second Edition. The screens from other versions of Windows
might differ slightly.
although many configuration options are available, and good planning will greatly simplify an
enterprise-level deployment.
By default, the Windows 95/98 installation includes the basic files for installing and configuring
a network connection. It’s always a good idea, though, to have the original installation
CD-ROM available because the setup program might need additional files to complete the
installation. In addition, the latest service packs and updates should be installed—service packs
contain many updates and problem fixes called
patches
. In general, the installation of patches
is a benign event; however, before performing the upgrade, it is best to back up critical files and
review the appropriateness of the patch. For multiple node upgrades, it’s best to test the patch
before you deploy it.
Check the Windows website at
www.microsoft.com
for the latest patches, service
packs, and tips for configuring dial-up networking.
Although many tools are available for installing and configuring dial-up networking, this
book focuses on the basic installation—PPP and TCP/IP protocols. However, multilink connections
and scripting are also presented.
The screen captures in this chapter, unless otherwise noted, are from Windows
98 Second Edition. The screens from other versions of Windows
might differ slightly.
Configuring Dial-Up Networking with Windows 95/98
Dial-up networking in Windows 95/98 is still popular, perhaps for no other reason than
approximately 100 million clients worldwide have a Microsoft operating system installed.
From a client’s perspective, the cost and effort needed to connect to the office remotely requires
little more than a phone line and modem.
As you will see in this chapter, configuring and administering a single Windows workstation
for dial-up networking is very simple. Unfortunately, administering dial-up networking
for thousands of remote users is not as simple, and there are few existing tools that
make this task easier.
Microsoft Windows 95/98 supports remote dial-up networking with the protocols that provide
transport for NetBIOS:
NetBEUI
IPX
IP
Supporting these protocols is logical because of Windows networking’s historical dependency
upon the NetBIOS protocol and the name services that it provides. This changed in Windows 2000
and XP. It is possible to add other protocols with third-party transport, but most designers find
IP support to be sufficient, and they configure the client for PPP services.
approximately 100 million clients worldwide have a Microsoft operating system installed.
From a client’s perspective, the cost and effort needed to connect to the office remotely requires
little more than a phone line and modem.
As you will see in this chapter, configuring and administering a single Windows workstation
for dial-up networking is very simple. Unfortunately, administering dial-up networking
for thousands of remote users is not as simple, and there are few existing tools that
make this task easier.
Microsoft Windows 95/98 supports remote dial-up networking with the protocols that provide
transport for NetBIOS:
NetBEUI
IPX
IP
Supporting these protocols is logical because of Windows networking’s historical dependency
upon the NetBIOS protocol and the name services that it provides. This changed in Windows 2000
and XP. It is possible to add other protocols with third-party transport, but most designers find
IP support to be sufficient, and they configure the client for PPP services.
Dial-Up Networking Application
To start configuring a dial-up connection, choose Start
Programs
Accessories
Communications
Dial-Up Networking. This opens a dialog box similar to the one shown in Figure
25.1.
On the system shown here, this is the first dial-up connection, so Windows provides only a
Make New Connection icon. Clicking this icon brings up the Dial-Up Networking Wizard. If
other connections were available, the user or administrator could select them to initiate a call
or to go into an already established connection in order to reconfigure options.
Programs
Accessories
Communications
Dial-Up Networking. This opens a dialog box similar to the one shown in Figure
25.1.
On the system shown here, this is the first dial-up connection, so Windows provides only a
Make New Connection icon. Clicking this icon brings up the Dial-Up Networking Wizard. If
other connections were available, the user or administrator could select them to initiate a call
or to go into an already established connection in order to reconfigure options.
Reasons to Use Dial-Up Networking
Fortunately, not only is configuring and using dial-up networking in Windows 95/98 simple, but
it also provides a broad base of services for remote users. These services include the following:
Automatic connection to websites
Once configured, the operating system automatically
establishes a dial-up connection to connect with a remote web server. If a user simply types a
URL into Microsoft Internet Explorer, the modem will dial the Internet service provider (ISP)
and request the web page.
E-mail
Mobile clients can connect to Microsoft Exchange or another e-mail service in the office.
This provides an efficient way to communicate with colleagues.
File synchronization
Remote users can obtain file updates and post their files on a server in the
office for local users. Although Microsoft provides the My Briefcase application for this purpose,
Symantec’s pcAnywhere and other such programs might be desired by more demanding users.
Remote control
One alternative to high-bandwidth applications is remote control. Remote
control software does exactly what it sounds like it does: keystrokes and mouse movements are
sent to the host, and the host returns the image to the remote user, enabling the user to control
the host. This solution enables only the screen images to be transferred, which can greatly
reduce the required bandwidth for supporting the application.
Consider the following: A remote user on a dial-up connection needs to access a database, and
this access results in 10MB of data being transferred. When using remote control, only the
screen data will be sent for the session; with compression, this means that possibly less than
2MB of data will be sent. Clearly, this bandwidth savings can be substantial. Note that remote
control solutions must be connected to access data—unlike remote node solutions, which use
the remote user’s processor for local applications and data and use the modem as a slower network
link. Also, the bandwidth savings can differ significantly depending on the data demands
of the application. In this context, remote control utilizes remote node solutions for transport,
but the connection must be maintained for the duration of the remote control session. Windows XP
includes a terminal server option.
NOTE:Effectively, anything that a user can accomplish in the office is possible to
accomplish remotely with dial-up networking. Unfortunately, the significantly
lower bandwidth of dial-up connections can make this impractical, depending
on the application.
it also provides a broad base of services for remote users. These services include the following:
Automatic connection to websites
Once configured, the operating system automatically
establishes a dial-up connection to connect with a remote web server. If a user simply types a
URL into Microsoft Internet Explorer, the modem will dial the Internet service provider (ISP)
and request the web page.
Mobile clients can connect to Microsoft Exchange or another e-mail service in the office.
This provides an efficient way to communicate with colleagues.
File synchronization
Remote users can obtain file updates and post their files on a server in the
office for local users. Although Microsoft provides the My Briefcase application for this purpose,
Symantec’s pcAnywhere and other such programs might be desired by more demanding users.
Remote control
One alternative to high-bandwidth applications is remote control. Remote
control software does exactly what it sounds like it does: keystrokes and mouse movements are
sent to the host, and the host returns the image to the remote user, enabling the user to control
the host. This solution enables only the screen images to be transferred, which can greatly
reduce the required bandwidth for supporting the application.
Consider the following: A remote user on a dial-up connection needs to access a database, and
this access results in 10MB of data being transferred. When using remote control, only the
screen data will be sent for the session; with compression, this means that possibly less than
2MB of data will be sent. Clearly, this bandwidth savings can be substantial. Note that remote
control solutions must be connected to access data—unlike remote node solutions, which use
the remote user’s processor for local applications and data and use the modem as a slower network
link. Also, the bandwidth savings can differ significantly depending on the data demands
of the application. In this context, remote control utilizes remote node solutions for transport,
but the connection must be maintained for the duration of the remote control session. Windows XP
includes a terminal server option.
NOTE:Effectively, anything that a user can accomplish in the office is possible to
accomplish remotely with dial-up networking. Unfortunately, the significantly
lower bandwidth of dial-up connections can make this impractical, depending
on the application.
LCP and NCP
PPP is a versatile protocol that provides a designer with many options when deploying it in the
network. Through the use of interactive PPP, you can provide flexibility to dial-in users using
asynchronous interfaces. If you are looking for a more secure dial-in environment, you can configure
an asynchronous interface to run in dedicated PPP mode. Another option for the security
conscious is to utilize PPP callback for enhanced security.
Addressing can be configured by using static IP addresses, but for greater flexibility we suggest
using DHCP or address pools to automatically assign IP addressing. User authentication
can be accomplished by using Password Authentication Protocol (PAP) or its more secure
cousin, Challenge Handshake Authentication Protocol (CHAP).
Compression and multilink are two PPP options that a network designer can use to increase
traffic flow on a connection. They can be used separately or together for even greater throughput.
When trouble occurs with an asynchronous connection, Cisco IOS offers a variety of troubleshooting
commands to assist the administrator in narrowing down the problem. These commands
can be used to show the PPP negotiation process, PPP authentication process, or each
PPP packet as it traverses an interface.
Know how to set up PPP on an interface and know what LCP and NCP are used for. To
configure PPP encapsulation on an interface, use the encapsulation ppp command. LCP is
used for PPP link control, including circuit testing and authentication. NCP is used to negotiate
which upper layer protocols will run over a connection and negotiates their addressing.
Understand how to set up an interface to allow multiple protocols and how to restrict the
method of access to a single protocol. An interface can be set up with the command async
mode interactive to enable a user to choose between SLIP and PPP encapsulation. The
administrator can restrict the user from changing the encapsulation by using the async mode
dedicated command. By using the autoselect command to sense the desired protocol, the
router can automatically configure the interface.
Know the three methods to give an interface an IP address. You can use static IP addressing,
which requires more administrator overhead; IP unnumbered, which has troubleshooting problems;
or dynamic IP address allocation using DHCP or IP address pools.
Be able to give a general overview of how DHCP works. The DHCP client uses a broadcast
packet to communicate with a DHCP server. A negotiation process determines an IP address
lease. After half of the lease time has expired, the DHCP client will attempt to renew the lease.
Understand the differences between the two PPP authentication protocols and when to use them.
You should understand how the PAP and CHAP protocols work and why CHAP is the better protocol
to use. CHAP never sends the username and password over the link, whereas PAP sends both
in cleartext. Security can be compromised with PAP, but sometimes legacy systems require its use.
Know the commands to use when configuring compression and Multilink PPP (MPPP). Use the
compress [predictor | stac | mppc [ignore-pfc]] command to configure compression on
a link, making sure to use the same method on each end of a connection. You can bond multiple
channels into a single connection for greater speed by using the ppp multilink command. Compression
and multilink can be used together or separately to enhance connection throughput.
Know the PPP troubleshooting commands and how to spot a problem. You can use the
debug ppp authentication, debug ppp negotiation, and debug ppp packet commands to
determine the cause of a remote access problem.
network. Through the use of interactive PPP, you can provide flexibility to dial-in users using
asynchronous interfaces. If you are looking for a more secure dial-in environment, you can configure
an asynchronous interface to run in dedicated PPP mode. Another option for the security
conscious is to utilize PPP callback for enhanced security.
Addressing can be configured by using static IP addresses, but for greater flexibility we suggest
using DHCP or address pools to automatically assign IP addressing. User authentication
can be accomplished by using Password Authentication Protocol (PAP) or its more secure
cousin, Challenge Handshake Authentication Protocol (CHAP).
Compression and multilink are two PPP options that a network designer can use to increase
traffic flow on a connection. They can be used separately or together for even greater throughput.
When trouble occurs with an asynchronous connection, Cisco IOS offers a variety of troubleshooting
commands to assist the administrator in narrowing down the problem. These commands
can be used to show the PPP negotiation process, PPP authentication process, or each
PPP packet as it traverses an interface.
Know how to set up PPP on an interface and know what LCP and NCP are used for. To
configure PPP encapsulation on an interface, use the encapsulation ppp command. LCP is
used for PPP link control, including circuit testing and authentication. NCP is used to negotiate
which upper layer protocols will run over a connection and negotiates their addressing.
Understand how to set up an interface to allow multiple protocols and how to restrict the
method of access to a single protocol. An interface can be set up with the command async
mode interactive to enable a user to choose between SLIP and PPP encapsulation. The
administrator can restrict the user from changing the encapsulation by using the async mode
dedicated command. By using the autoselect command to sense the desired protocol, the
router can automatically configure the interface.
Know the three methods to give an interface an IP address. You can use static IP addressing,
which requires more administrator overhead; IP unnumbered, which has troubleshooting problems;
or dynamic IP address allocation using DHCP or IP address pools.
Be able to give a general overview of how DHCP works. The DHCP client uses a broadcast
packet to communicate with a DHCP server. A negotiation process determines an IP address
lease. After half of the lease time has expired, the DHCP client will attempt to renew the lease.
Understand the differences between the two PPP authentication protocols and when to use them.
You should understand how the PAP and CHAP protocols work and why CHAP is the better protocol
to use. CHAP never sends the username and password over the link, whereas PAP sends both
in cleartext. Security can be compromised with PAP, but sometimes legacy systems require its use.
Know the commands to use when configuring compression and Multilink PPP (MPPP). Use the
compress [predictor | stac | mppc [ignore-pfc]] command to configure compression on
a link, making sure to use the same method on each end of a connection. You can bond multiple
channels into a single connection for greater speed by using the ppp multilink command. Compression
and multilink can be used together or separately to enhance connection throughput.
Know the PPP troubleshooting commands and how to spot a problem. You can use the
debug ppp authentication, debug ppp negotiation, and debug ppp packet commands to
determine the cause of a remote access problem.
Connect to the central site with Microsoft Windows
We have elected to retain this chapter for this revision of
the text because the exam might incorporate questions
related to the material. Based on the most recent information,
this is admittedly unlikely. You should be confident
that cursory retention of the material in this chapter
is all that might be needed for real-world and examination
success. This chapter focuses on Windows 95/98
because of Cisco’s focus on these versions. Please note
that Windows 2000 and Windows XP incorporate processes
and protocols that are similar to these earlier
versions, and this chapter can provide benefit and
understanding in that context.
Any book on remote access would be remiss if it did not include
a section on the world’s most popular desktop operating system.
It would be difficult to find a remote access solution that does not
require support for Windows. You might question the dedication of an entire chapter in a
present-day remote access book to the consumer-oriented platforms of Windows 95 and 98,
especially when Microsoft no longer supports Windows 95 and retired Windows 98 in 2004.
However, Cisco still requires an understanding of Windows dial-up networking. Fortunately,
older versions parallel the modern versions of the operating system, and, as such, this chapter
also provides a foundation for using Windows XP and 2000.
This chapter focuses on the configuration and support issues that surround this popular client
software. Particular attention should be paid to the protocols that are supported and the configuration
steps that are required on the client.
the text because the exam might incorporate questions
related to the material. Based on the most recent information,
this is admittedly unlikely. You should be confident
that cursory retention of the material in this chapter
is all that might be needed for real-world and examination
success. This chapter focuses on Windows 95/98
because of Cisco’s focus on these versions. Please note
that Windows 2000 and Windows XP incorporate processes
and protocols that are similar to these earlier
versions, and this chapter can provide benefit and
understanding in that context.
Any book on remote access would be remiss if it did not include
a section on the world’s most popular desktop operating system.
It would be difficult to find a remote access solution that does not
require support for Windows. You might question the dedication of an entire chapter in a
present-day remote access book to the consumer-oriented platforms of Windows 95 and 98,
especially when Microsoft no longer supports Windows 95 and retired Windows 98 in 2004.
However, Cisco still requires an understanding of Windows dial-up networking. Fortunately,
older versions parallel the modern versions of the operating system, and, as such, this chapter
also provides a foundation for using Windows XP and 2000.
This chapter focuses on the configuration and support issues that surround this popular client
software. Particular attention should be paid to the protocols that are supported and the configuration
steps that are required on the client.
The debug ppp packet Command
The debug ppp packet command reports real-time PPP packet flow, including the type of
packet and the specific B channel used in the case of ISDN. Although this command generates
a significant amount of output and could slow the access server, it is quite useful for locating
errors that involve upper layer protocols.
As with other debug protocol packet commands, the debug ppp packet command
records each packet that moves through the router using PPP. As such, the administrator can
monitor traffic flows as if they had a protocol analyzer attached to the interface. This might be
useful for troubleshooting Application layer problems, but a formal protocol analyzer is highly
recommended. This output includes both CDP packets (shown with the CDPCP entries) and IP
packets (showing proper configuration of IP on the link):
Router#debug ppp packet
PPP packet display debugging is on
Router#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
00:24:49: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.
00:24:50: BR0:1 LCP: O CONFREQ [Closed] id 4 len 10
00:24:50: BR0:1 LCP: MagicNumber 0x5025BF23
(0x05065025BF23)
00:24:50: BR0:1 PPP: I pkt type 0xC021, datagramsize 14
00:24:50: BR0:1 PPP: I pkt type 0xC021, datagramsize 14
00:24:50: BR0:1 LCP: I CONFREQ [REQsent] id 14 len 10
00:24:50: BR0:1 LCP: MagicNumber 0x5025BF46
(0x05065025BF46)
00:24:50: BR0:1 LCP: O CONFACK [REQsent] id 14 len 10
00:24:50: BR0:1 LCP: MagicNumber 0x5025BF46
(0x05065025BF46)
00:24:50: BR0:1 LCP: I CONFACK [ACKsent] id 4 len 10
00:24:50: BR0:1 LCP: MagicNumber 0x5025BF23
(0x05065025BF23)
00:24:50: BR0:1 PPP: I pkt type 0x8207, datagramsize 8
00:24:50: BR0:1 PPP: I pkt type 0x8021, datagramsize 14
00:24:50: BR0:1 CDPCP: O CONFREQ [Closed] id 4 len 4
00:24:50: BR0:1 PPP: I pkt type 0x8207, datagramsize 8
00:24:50: BR0:1 IPCP: O CONFREQ [Closed] id 4 len 10
00:24:50: BR0:1 IPCP: Address 10.1.1.2 (0x03060A010102)
00:24:50: BR0:1 CDPCP: I CONFREQ [REQsent] id 4 len 4
00:24:50: BR0:1 CDPCP: O CONFACK [REQ.!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 36/41/52 ms
Router#sent] id 4 len 4
00:24:50: BR0:1 PPP: I pkt type 0x8021, datagramsize 14
00:24:50: BR0:1 IPCP: I CONFREQ [REQsent] id 4 len 10
00:24:50: BR0:1 IPCP: Address 10.1.1.1 (0x03060A010101)
00:24:50: BR0:1 IPCP: O CONFACK [REQsent] id 4 len 10
00:24:50: BR0:1 IPCP: Address 10.1.1.1 (0x03060A010101)
00:24:50: BR0:1 CDPCP: I CONFACK [ACKsent] id 4 len 4
00:24:50: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
00:24:50: BR0:1 IPCP: Address 10.1.1.2 (0x03060A010102)
00:24:51: BR0:1 PPP: O pkt type 0x0021, datagramsize 104
00:24:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
00:24:51: BR0:1 PPP: O pkt type 0x0207, datagramsize 323
00:24:51: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
00:24:51: BR0:2 PPP: I pkt type 0xC021, datagramsize 14
00:24:51: BR0:2 LCP: I CONFREQ [Listen] id 4 len 10
00:24:51: BR0:2 LCP: MagicNumber 0x5025C5EF
(0x05065025C5EF)
00:24:51: BR0:2 LCP: O CONFREQ [Listen] id 4 len 10 00:24:51:
➥BR0:2 LCP: MagicNumber 0x5025C605
(0x05065025C605)
00:24:51: BR0:2 LCP: O CONFACK [Listen] id 4 len 10
00:24:51: BR0:2 LCP: MagicNumber 0x5025C5EF
(0x05065025C5EF)
00:24:51: BR0:2 PPP: I pkt type 0xC021, datagramsize 14
00:24:51: BR0:2 LCP: I CONFACK [ACKsent] id 4 len 10
00:24:51: BR0:2 LCP: MagicNumber 0x5025C605
(0x05065025C605)
00:24:51: BR0:2 PPP: I pkt type 0x8207, datagramsize 8
00:24:51: BR0:2 PPP: I pkt type 0x8021, datagramsize 14
00:24:51: BR0:2 CDPCP: O CONFREQ [Closed] id 4 len 4
00:24:51: BR0:2 IPCP: O CONFREQ [Closed] id 4 len 10
00:24:51: BR0:2 IPCP: Address 10.1.1.2 (0x03060A010102)
00:24:51: BR0:2 CDPCP: I CONFREQ [REQsent] id 4 len 4
00:24:51: BR0:2 CDPCP: O CONFACK [REQsent] id 4 len 4
00:24:51: BR0:2 PPP: I pkt type 0x8207, datagramsize 8
00:24:51: BR0:2 IPCP: I CONFREQ [REQsent] id 4 len 10
00:24:51: BR0:2 IPCP: Address 10.1.1.1 (0x03060A010101)
00:24:51: BR0:2 PPP: I pkt type 0x8021, datagramsize 14
00:24:51: BR0:2 IPCP: O CONFACK [REQsent] id 4 len 10
00:24:51: BR0:2 IPCP: Address 10.1.1.1 (0x03060A010101)
00:24:51: BR0:2 CDPCP: I CONFACK [ACKsent] id 4 len 4
00:24:51: BR0:2 IPCP: I CONFACK [ACKsent] id 4 len 10
00:24:51: BR0:2 IPCP: Address 10.1.1.2 (0x03060A010102)
00:24:52: BR0:1 LCP: O ECHOREQ [Open] id 1 len 12 magic
0x5025BF23
00:24:52: BR0:1 LCP: echo_cnt 1, sent id 1, line up
00:24:52: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:24:52: BR0:1 LCP: I ECHOREP [Open] id 1 len 12 magic
0x5025BF46
00:24:52: BR0:1 LCP: Received id 1, sent id 1, line up
00:24:52: BR0:2 LCP: O ECHOREQ [Open] id 1 len 12 magic
0x5025C605
00:24:52: BR0:2 LCP: echo_cnt 1, sent id 1, line up
00:24:52: BR0:2 PPP: I pkt type 0xC021, datagramsize 16 00:24:52:
➥BR0:2 LCP: I ECHOREP [Open] id 1 len 12 magic
0x5025C5EF
00:24:52: BR0:2 LCP: Received id 1, sent id 1, line up
00:24:52: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:2, changed state to up
00:24:52: BR0:1 PPP: O pkt type 0x0207, datagramsize 323
00:24:52: BR0:2 PPP: I pkt type 0x0207, datagramsize 312
00:24:53: BR0:1 PPP: O pkt type 0x0021, datagramsize 104
00:24:53: BR0:2 PPP: I pkt type 0x0021, datagramsize 104
00:24:53: BR0:1 PPP: O pkt type 0x0021, datagramsize 104
00:24:53: BR0:2 PPP: I pkt type 0x0021, datagramsize 104
00:24:53: BR0:1 PPP: O pkt type 0x0021, datagramsize 104
00:24:53: BR0:2 PPP: I pkt type 0x0021, datagramsize 104
00:24:53: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:24:53: BR0:1 LCP: I ECHOREQ [Open] id 1 len 12 magic
0x5025BF46
00:24:53: BR0:1 LCP: O ECHOREP [Open] id 1 len 12 magic
0x5025BF23
00:24:53: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:24:53: BR0:2 LCP: I ECHOREQ [Open] id 1 len 12 magic
0x5025C5EF
00:24:53: BR0:2 LCP: O ECHOREP [Open] id 1 len 12 magic
0x5025C605
Router#
00:25:02: BR0:1 LCP: O ECHOREQ [Open] id 2 len 12 magic
0x5025BF23
00:25:02: BR0:1 LCP: echo_cnt 1, sent id 2, line up
00:25:02: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:25:02: BR0:1 LCP: I ECHOREP [Open] id 2 len 12 magic
0x5025BF46
00:25:02: BR0:1 LCP: Received id 2, sent id 2, line up
00:25:02: BR0:2 LCP: O ECHOREQ [Open] id 2 len 12 magic
0x5025C605
00:25:02: BR0:2 LCP: echo_cnt 1, sent id 2, line up
00:25:02: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:25:02: BR0:2 LCP: I ECHOREP [Open] id 2 len 12 magic
0x5025C5EF
00:25:02: BR0:2 LCP: Received id 2, sent id 2, line up
00:25:03: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:25:03: BR0:1 LCP: I ECHOREQ [Open] id 2 len 12 magic
0x5025BF46
00:25:03: BR0:1 LCP: O ECHOREP [Open] id 2 len 12 magic
0x5025BF23
00:25:03: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:25:03: BR0:2 LCP: I ECHOREQ [Open] id 2 len 12 magic
0x5025C5EF
00:25:03: BR0:2 LCP: O ECHOREP [Open] id 2 len 12 magic
0x5025C605
The debug ppp packet command is most helpful in locating upper layer protocol errors.
It filters out non-PPP output, resulting in a cleaner debug output than a regular debug ip
packet command. Note that the magic numbers referred to in the previous output are used to
thwart playback attacks by maintaining a form of state for the session.
packet and the specific B channel used in the case of ISDN. Although this command generates
a significant amount of output and could slow the access server, it is quite useful for locating
errors that involve upper layer protocols.
As with other debug protocol packet commands, the debug ppp packet command
records each packet that moves through the router using PPP. As such, the administrator can
monitor traffic flows as if they had a protocol analyzer attached to the interface. This might be
useful for troubleshooting Application layer problems, but a formal protocol analyzer is highly
recommended. This output includes both CDP packets (shown with the CDPCP entries) and IP
packets (showing proper configuration of IP on the link):
Router#debug ppp packet
PPP packet display debugging is on
Router#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
00:24:49: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.
00:24:50: BR0:1 LCP: O CONFREQ [Closed] id 4 len 10
00:24:50: BR0:1 LCP: MagicNumber 0x5025BF23
(0x05065025BF23)
00:24:50: BR0:1 PPP: I pkt type 0xC021, datagramsize 14
00:24:50: BR0:1 PPP: I pkt type 0xC021, datagramsize 14
00:24:50: BR0:1 LCP: I CONFREQ [REQsent] id 14 len 10
00:24:50: BR0:1 LCP: MagicNumber 0x5025BF46
(0x05065025BF46)
00:24:50: BR0:1 LCP: O CONFACK [REQsent] id 14 len 10
00:24:50: BR0:1 LCP: MagicNumber 0x5025BF46
(0x05065025BF46)
00:24:50: BR0:1 LCP: I CONFACK [ACKsent] id 4 len 10
00:24:50: BR0:1 LCP: MagicNumber 0x5025BF23
(0x05065025BF23)
00:24:50: BR0:1 PPP: I pkt type 0x8207, datagramsize 8
00:24:50: BR0:1 PPP: I pkt type 0x8021, datagramsize 14
00:24:50: BR0:1 CDPCP: O CONFREQ [Closed] id 4 len 4
00:24:50: BR0:1 PPP: I pkt type 0x8207, datagramsize 8
00:24:50: BR0:1 IPCP: O CONFREQ [Closed] id 4 len 10
00:24:50: BR0:1 IPCP: Address 10.1.1.2 (0x03060A010102)
00:24:50: BR0:1 CDPCP: I CONFREQ [REQsent] id 4 len 4
00:24:50: BR0:1 CDPCP: O CONFACK [REQ.!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 36/41/52 ms
Router#sent] id 4 len 4
00:24:50: BR0:1 PPP: I pkt type 0x8021, datagramsize 14
00:24:50: BR0:1 IPCP: I CONFREQ [REQsent] id 4 len 10
00:24:50: BR0:1 IPCP: Address 10.1.1.1 (0x03060A010101)
00:24:50: BR0:1 IPCP: O CONFACK [REQsent] id 4 len 10
00:24:50: BR0:1 IPCP: Address 10.1.1.1 (0x03060A010101)
00:24:50: BR0:1 CDPCP: I CONFACK [ACKsent] id 4 len 4
00:24:50: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
00:24:50: BR0:1 IPCP: Address 10.1.1.2 (0x03060A010102)
00:24:51: BR0:1 PPP: O pkt type 0x0021, datagramsize 104
00:24:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
00:24:51: BR0:1 PPP: O pkt type 0x0207, datagramsize 323
00:24:51: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
00:24:51: BR0:2 PPP: I pkt type 0xC021, datagramsize 14
00:24:51: BR0:2 LCP: I CONFREQ [Listen] id 4 len 10
00:24:51: BR0:2 LCP: MagicNumber 0x5025C5EF
(0x05065025C5EF)
00:24:51: BR0:2 LCP: O CONFREQ [Listen] id 4 len 10 00:24:51:
➥BR0:2 LCP: MagicNumber 0x5025C605
(0x05065025C605)
00:24:51: BR0:2 LCP: O CONFACK [Listen] id 4 len 10
00:24:51: BR0:2 LCP: MagicNumber 0x5025C5EF
(0x05065025C5EF)
00:24:51: BR0:2 PPP: I pkt type 0xC021, datagramsize 14
00:24:51: BR0:2 LCP: I CONFACK [ACKsent] id 4 len 10
00:24:51: BR0:2 LCP: MagicNumber 0x5025C605
(0x05065025C605)
00:24:51: BR0:2 PPP: I pkt type 0x8207, datagramsize 8
00:24:51: BR0:2 PPP: I pkt type 0x8021, datagramsize 14
00:24:51: BR0:2 CDPCP: O CONFREQ [Closed] id 4 len 4
00:24:51: BR0:2 IPCP: O CONFREQ [Closed] id 4 len 10
00:24:51: BR0:2 IPCP: Address 10.1.1.2 (0x03060A010102)
00:24:51: BR0:2 CDPCP: I CONFREQ [REQsent] id 4 len 4
00:24:51: BR0:2 CDPCP: O CONFACK [REQsent] id 4 len 4
00:24:51: BR0:2 PPP: I pkt type 0x8207, datagramsize 8
00:24:51: BR0:2 IPCP: I CONFREQ [REQsent] id 4 len 10
00:24:51: BR0:2 IPCP: Address 10.1.1.1 (0x03060A010101)
00:24:51: BR0:2 PPP: I pkt type 0x8021, datagramsize 14
00:24:51: BR0:2 IPCP: O CONFACK [REQsent] id 4 len 10
00:24:51: BR0:2 IPCP: Address 10.1.1.1 (0x03060A010101)
00:24:51: BR0:2 CDPCP: I CONFACK [ACKsent] id 4 len 4
00:24:51: BR0:2 IPCP: I CONFACK [ACKsent] id 4 len 10
00:24:51: BR0:2 IPCP: Address 10.1.1.2 (0x03060A010102)
00:24:52: BR0:1 LCP: O ECHOREQ [Open] id 1 len 12 magic
0x5025BF23
00:24:52: BR0:1 LCP: echo_cnt 1, sent id 1, line up
00:24:52: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:24:52: BR0:1 LCP: I ECHOREP [Open] id 1 len 12 magic
0x5025BF46
00:24:52: BR0:1 LCP: Received id 1, sent id 1, line up
00:24:52: BR0:2 LCP: O ECHOREQ [Open] id 1 len 12 magic
0x5025C605
00:24:52: BR0:2 LCP: echo_cnt 1, sent id 1, line up
00:24:52: BR0:2 PPP: I pkt type 0xC021, datagramsize 16 00:24:52:
➥BR0:2 LCP: I ECHOREP [Open] id 1 len 12 magic
0x5025C5EF
00:24:52: BR0:2 LCP: Received id 1, sent id 1, line up
00:24:52: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:2, changed state to up
00:24:52: BR0:1 PPP: O pkt type 0x0207, datagramsize 323
00:24:52: BR0:2 PPP: I pkt type 0x0207, datagramsize 312
00:24:53: BR0:1 PPP: O pkt type 0x0021, datagramsize 104
00:24:53: BR0:2 PPP: I pkt type 0x0021, datagramsize 104
00:24:53: BR0:1 PPP: O pkt type 0x0021, datagramsize 104
00:24:53: BR0:2 PPP: I pkt type 0x0021, datagramsize 104
00:24:53: BR0:1 PPP: O pkt type 0x0021, datagramsize 104
00:24:53: BR0:2 PPP: I pkt type 0x0021, datagramsize 104
00:24:53: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:24:53: BR0:1 LCP: I ECHOREQ [Open] id 1 len 12 magic
0x5025BF46
00:24:53: BR0:1 LCP: O ECHOREP [Open] id 1 len 12 magic
0x5025BF23
00:24:53: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:24:53: BR0:2 LCP: I ECHOREQ [Open] id 1 len 12 magic
0x5025C5EF
00:24:53: BR0:2 LCP: O ECHOREP [Open] id 1 len 12 magic
0x5025C605
Router#
00:25:02: BR0:1 LCP: O ECHOREQ [Open] id 2 len 12 magic
0x5025BF23
00:25:02: BR0:1 LCP: echo_cnt 1, sent id 2, line up
00:25:02: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:25:02: BR0:1 LCP: I ECHOREP [Open] id 2 len 12 magic
0x5025BF46
00:25:02: BR0:1 LCP: Received id 2, sent id 2, line up
00:25:02: BR0:2 LCP: O ECHOREQ [Open] id 2 len 12 magic
0x5025C605
00:25:02: BR0:2 LCP: echo_cnt 1, sent id 2, line up
00:25:02: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:25:02: BR0:2 LCP: I ECHOREP [Open] id 2 len 12 magic
0x5025C5EF
00:25:02: BR0:2 LCP: Received id 2, sent id 2, line up
00:25:03: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:25:03: BR0:1 LCP: I ECHOREQ [Open] id 2 len 12 magic
0x5025BF46
00:25:03: BR0:1 LCP: O ECHOREP [Open] id 2 len 12 magic
0x5025BF23
00:25:03: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:25:03: BR0:2 LCP: I ECHOREQ [Open] id 2 len 12 magic
0x5025C5EF
00:25:03: BR0:2 LCP: O ECHOREP [Open] id 2 len 12 magic
0x5025C605
The debug ppp packet command is most helpful in locating upper layer protocol errors.
It filters out non-PPP output, resulting in a cleaner debug output than a regular debug ip
packet command. Note that the magic numbers referred to in the previous output are used to
thwart playback attacks by maintaining a form of state for the session.
The debug ppp authentication Command
Authentication failures can make a perfectly functional link appear faulty, and given the ease
with which one can mis-enter a password or username, it is one of the most common issues. The
debug ppp authentication command is useful for resolving these problems.
Examine the following output from the debug session. The ISDN BRI attempted to connect,
but the challenge failed and the link was disconnected immediately. The second packet attempted
to restore the link (response id 8) and also failed. This type of output points to either a username
or password problem—in this case, the password was incorrect:
Router#debug ppp authentication
01:54:14: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.
01:54:14: BR0:1 PPP: Treating connection as a callout
01:54:14: BR0:1 PPP: Phase is AUTHENTICATING, by both
01:54:14: BR0:1 CHAP: O CHALLENGE id 7 len 27 from "Router"
01:54:14: BR0:1 CHAP: I CHALLENGE id 7 len 24 from "Top"
01:54:14: BR0:1 CHAP: O RESPONSE id 7 len 27 from "Router"
01:54:14: BR0:1 CHAP: I FAILURE id 7 len 25 msg is "MD/DES
compare failed"
01:54:15: %ISDN-6-DISCONNECT: Interface BRI0:1
disconnected from 18008358661 , call lasted 1 seconds
01:54:15: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down.
01:54:18: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.
01:54:18: BR0:1 PPP: Treating connection as a callout
01:54:18: BR0:1 PPP: Phase is AUTHENTICATING, by both
01:54:18: BR0:1 CHAP: O CHALLENGE id 8 len 27 from "Router"
01:54:18: BR0:1 CHAP: I CHALLENGE id 8 len 24 from "Top"
01:54:18: BR0:1 CHAP: O RESPONSE id 8 len 27 from "Router"
01:54:18: BR0:1 CHAP: I FAILURE id 8 len 25 msg is "MD/DES
compare failed"
01:54:19: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected
from 18008358661 , call lasted 1 seconds
01:54:19: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down.
01:54:22: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.
The debug ppp authentication command is most helpful in troubleshooting password
problems. As shown in the preceding example, the message I FAILURE id 8 len 25 msg
is "MD/DEScompare failed” is a clear indication that the administrator should look at the
password settings.
with which one can mis-enter a password or username, it is one of the most common issues. The
debug ppp authentication command is useful for resolving these problems.
Examine the following output from the debug session. The ISDN BRI attempted to connect,
but the challenge failed and the link was disconnected immediately. The second packet attempted
to restore the link (response id 8) and also failed. This type of output points to either a username
or password problem—in this case, the password was incorrect:
Router#debug ppp authentication
01:54:14: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.
01:54:14: BR0:1 PPP: Treating connection as a callout
01:54:14: BR0:1 PPP: Phase is AUTHENTICATING, by both
01:54:14: BR0:1 CHAP: O CHALLENGE id 7 len 27 from "Router"
01:54:14: BR0:1 CHAP: I CHALLENGE id 7 len 24 from "Top"
01:54:14: BR0:1 CHAP: O RESPONSE id 7 len 27 from "Router"
01:54:14: BR0:1 CHAP: I FAILURE id 7 len 25 msg is "MD/DES
compare failed"
01:54:15: %ISDN-6-DISCONNECT: Interface BRI0:1
disconnected from 18008358661 , call lasted 1 seconds
01:54:15: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down.
01:54:18: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.
01:54:18: BR0:1 PPP: Treating connection as a callout
01:54:18: BR0:1 PPP: Phase is AUTHENTICATING, by both
01:54:18: BR0:1 CHAP: O CHALLENGE id 8 len 27 from "Router"
01:54:18: BR0:1 CHAP: I CHALLENGE id 8 len 24 from "Top"
01:54:18: BR0:1 CHAP: O RESPONSE id 8 len 27 from "Router"
01:54:18: BR0:1 CHAP: I FAILURE id 8 len 25 msg is "MD/DES
compare failed"
01:54:19: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected
from 18008358661 , call lasted 1 seconds
01:54:19: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down.
01:54:22: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.
The debug ppp authentication command is most helpful in troubleshooting password
problems. As shown in the preceding example, the message I FAILURE id 8 len 25 msg
is "MD/DEScompare failed” is a clear indication that the administrator should look at the
password settings.
The debug ppp negotiation Command
The debug ppp negotiation command is useful for two reasons. First, it can enhance the
troubleshooting process on PPP links. Second, it provides a wonderful summary of how PPP
works, including LCP and the higher protocols. The higher protocols consist of IPCP (IP) and
CDPCP (CDP), among others.
The following output shows the messages that might appear when using the debug ppp
negotiation command:
Router#debug ppp negotiation
PPP protocol negotiation debugging is on
Router#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
00:22:28: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
00:22:28: BR0:1 PPP: Treating connection as a callout
00:22:28: BR0:1 PPP: Phase is ESTABLISHING, Active Open
00:22:28: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x50239604
(0x050650239604)
00:22:28: BR0:1 LCP: I CONFREQ [REQsent] id 13 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x5023961F
(0x05065023961F)
00:22:28: BR0:1 LCP: O CONFACK [REQsent] id 13 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x5.023961F
(0x05065023961F)
00:22:28: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x50239604
(0x050650239604)
00:22:28: BR0:1 LCP: State is Open
00:22:28: BR0:1 PPP: Phase is UP
00:22:28: BR0:1 CDPCP: O CONFREQ [Closed] id 3 len 4
00:22:28: BR0:1 IPCP: O CONFREQ [Closed] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:28: BR0:1 CDPCP: I CONFREQ [REQsent] id 3 len 4
00:22:28: BR0:1 CDPCP: O CONFACK [REQsent] id 3 len 4
00:22:28: BR0:1 IPCP: I CONFREQ [REQsent] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:28: BR0:1 IPCP: O CONFACK [REQsent] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:28: BR0:1 CDPCP: I CONFACK [ACKsent] id 3 len 4
00:22:28: BR0:1 CDPCP: State is Open
00:22:28: BR0:1 IPCP: I CONFACK [ACKsent] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:28: BR0:1 IPCP: State is Open
00:22:28: BR0 IPCP: Install route to 10.1.1.1
Router#.!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 32/38/48 ms
00:22:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
00:22:29: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
00:22:29: BR0:2 PPP: Treating connection as a callin
00:22:29: BR0:2 PPP: Phase is ESTABLISHING, Passive Open
00:22:29: BR0:2 LCP: State is Listen
00:22:30: BR0:2 LCP: I CONFREQ [Listen] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CC8
(0x050650239CC8)
00:22:30: BR0:2 LCP: O CONFREQ [Listen] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CDA
(0x050650239CDA)
00:22:30: BR0:2 LCP: O CONFACK [Listen] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CC8
(0x050650239CC8)
00:22:30: BR0:2 LCP: I CONFACK [ACKsent] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CDA
(0x050650239CDA) 00:22:30: BR0:2 LCP: State is Open
00:22:30: BR0:2 PPP: Phase is UP
00:22:30: BR0:2 CDPCP: O CONFREQ [Closed] id 3 len 4
00:22:30: BR0:2 IPCP: O CONFREQ [Closed] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:30: BR0:2 CDPCP: I CONFREQ [REQsent] id 3 len 4
00:22:30: BR0:2 CDPCP: O CONFACK [REQsent] id 3 len 4
00:22:30: BR0:2 IPCP: I CONFREQ [REQsent] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:30: BR0:2 IPCP: O CONFACK [REQsent] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:30: BR0:2 CDPCP: I CONFACK [ACKsent] id 3 len 4
00:22:30: BR0:2 CDPCP: State is Open
00:22:30: BR0:2 IPCP: I CONFACK [ACKsent] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:30: BR0:2 IPCP: State is Open
00:22:31: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state
to up
00:22:32: BR0:1 LCP: O ECHOREQ [Open] id 12 len 12 magic
0x5020C645
00:22:32: BR0:1 LCP: echo_cnt 1, sent id 12, line up
00:22:32: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:22:32: BR0:1 LCP: I ECHOREP [Open] id 12 len 12 magic
0x5020C654
00:22:32: BR0:1 LCP: Received id 12, sent id 12, line up
00:22:32: BR0:2 LCP: O ECHOREQ [Open] id 12 len 12 magic
0x5020CD1B
00:22:32: BR0:2 LCP: echo_cnt 1, sent id 12, line up
00:22:32: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:22:32: BR0:2 LCP: I ECHOREP [Open] id 12 len 12 magic
0x5020CD0D
00:22:32: BR0:2 LCP: Received id 12, sent id 12, line up
00:22:33: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:22:33: BR0:1 LCP: I ECHOREQ [Open] id 12 len 12 magic
0x5020C654
00:22:33: BR0:1 LCP: O ECHOREP [Open] id 12 len 12 magic
0x5020C64500:21:23: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:22:33: BR0:2 LCP: I ECHOREQ [Open] id 12 len 12 magic
0x5020CD0D
00:22:33: BR0:2 LCP: O ECHOREP [Open] id 12 len 12 magic
0x5020CD1B
00:22:34: BR0:2 PPP: I pkt type 0x0207, datagramsize 15
00:22:35: BR0:2 PPP: I pkt type 0x0207, datagramsize 312
00:24:28: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected
from 18008358661 To p, call lasted 120 seconds
00:24:28: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
00:24:10: %ISDN-6-DISCONNECT: Interface BRI0:2 disconnected from 8358663, call
lasted 120 seconds
00:24:28: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
00:24:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to down
00:24:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:2, changed state to down
Notice that in this output, the first two ICMP packets (pings) failed due to the delay in bringing
up the ISDN BRI. Although faster than asynchronous connections, ISDN still introduces connection
delay, which can impact user applications. In addition, the output from the debug ppp
negotiation command shows the process by which a PPP session is activated.
This output does not use CHAP, compression, or multilink. Instead, as you can see, PPP
starts and then LCP is activated. After this occurs, the NCP negotiations begin, starting with
CDPCP and followed by IPCP. Cisco Discovery Protocol (CDP) is a proprietary advertisement
protocol that sends router and switch information between Cisco devices. It operates over any
physical media that supports Subnetwork Access Protocol (SNAP) (except ATM) and is independent
of IP. The IP Control Protocol (IPCP) was started to transport the ICMP pings that
were sent from the router.
Remember that PPP sessions must undergo a negotiation process and that the debug ppp
negotiation command will display upper level protocols such as IPCP, along with LCP and PPP.
troubleshooting process on PPP links. Second, it provides a wonderful summary of how PPP
works, including LCP and the higher protocols. The higher protocols consist of IPCP (IP) and
CDPCP (CDP), among others.
The following output shows the messages that might appear when using the debug ppp
negotiation command:
Router#debug ppp negotiation
PPP protocol negotiation debugging is on
Router#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
00:22:28: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
00:22:28: BR0:1 PPP: Treating connection as a callout
00:22:28: BR0:1 PPP: Phase is ESTABLISHING, Active Open
00:22:28: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x50239604
(0x050650239604)
00:22:28: BR0:1 LCP: I CONFREQ [REQsent] id 13 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x5023961F
(0x05065023961F)
00:22:28: BR0:1 LCP: O CONFACK [REQsent] id 13 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x5.023961F
(0x05065023961F)
00:22:28: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x50239604
(0x050650239604)
00:22:28: BR0:1 LCP: State is Open
00:22:28: BR0:1 PPP: Phase is UP
00:22:28: BR0:1 CDPCP: O CONFREQ [Closed] id 3 len 4
00:22:28: BR0:1 IPCP: O CONFREQ [Closed] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:28: BR0:1 CDPCP: I CONFREQ [REQsent] id 3 len 4
00:22:28: BR0:1 CDPCP: O CONFACK [REQsent] id 3 len 4
00:22:28: BR0:1 IPCP: I CONFREQ [REQsent] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:28: BR0:1 IPCP: O CONFACK [REQsent] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:28: BR0:1 CDPCP: I CONFACK [ACKsent] id 3 len 4
00:22:28: BR0:1 CDPCP: State is Open
00:22:28: BR0:1 IPCP: I CONFACK [ACKsent] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:28: BR0:1 IPCP: State is Open
00:22:28: BR0 IPCP: Install route to 10.1.1.1
Router#.!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 32/38/48 ms
00:22:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
00:22:29: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
00:22:29: BR0:2 PPP: Treating connection as a callin
00:22:29: BR0:2 PPP: Phase is ESTABLISHING, Passive Open
00:22:29: BR0:2 LCP: State is Listen
00:22:30: BR0:2 LCP: I CONFREQ [Listen] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CC8
(0x050650239CC8)
00:22:30: BR0:2 LCP: O CONFREQ [Listen] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CDA
(0x050650239CDA)
00:22:30: BR0:2 LCP: O CONFACK [Listen] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CC8
(0x050650239CC8)
00:22:30: BR0:2 LCP: I CONFACK [ACKsent] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CDA
(0x050650239CDA) 00:22:30: BR0:2 LCP: State is Open
00:22:30: BR0:2 PPP: Phase is UP
00:22:30: BR0:2 CDPCP: O CONFREQ [Closed] id 3 len 4
00:22:30: BR0:2 IPCP: O CONFREQ [Closed] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:30: BR0:2 CDPCP: I CONFREQ [REQsent] id 3 len 4
00:22:30: BR0:2 CDPCP: O CONFACK [REQsent] id 3 len 4
00:22:30: BR0:2 IPCP: I CONFREQ [REQsent] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:30: BR0:2 IPCP: O CONFACK [REQsent] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:30: BR0:2 CDPCP: I CONFACK [ACKsent] id 3 len 4
00:22:30: BR0:2 CDPCP: State is Open
00:22:30: BR0:2 IPCP: I CONFACK [ACKsent] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:30: BR0:2 IPCP: State is Open
00:22:31: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state
to up
00:22:32: BR0:1 LCP: O ECHOREQ [Open] id 12 len 12 magic
0x5020C645
00:22:32: BR0:1 LCP: echo_cnt 1, sent id 12, line up
00:22:32: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:22:32: BR0:1 LCP: I ECHOREP [Open] id 12 len 12 magic
0x5020C654
00:22:32: BR0:1 LCP: Received id 12, sent id 12, line up
00:22:32: BR0:2 LCP: O ECHOREQ [Open] id 12 len 12 magic
0x5020CD1B
00:22:32: BR0:2 LCP: echo_cnt 1, sent id 12, line up
00:22:32: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:22:32: BR0:2 LCP: I ECHOREP [Open] id 12 len 12 magic
0x5020CD0D
00:22:32: BR0:2 LCP: Received id 12, sent id 12, line up
00:22:33: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:22:33: BR0:1 LCP: I ECHOREQ [Open] id 12 len 12 magic
0x5020C654
00:22:33: BR0:1 LCP: O ECHOREP [Open] id 12 len 12 magic
0x5020C64500:21:23: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:22:33: BR0:2 LCP: I ECHOREQ [Open] id 12 len 12 magic
0x5020CD0D
00:22:33: BR0:2 LCP: O ECHOREP [Open] id 12 len 12 magic
0x5020CD1B
00:22:34: BR0:2 PPP: I pkt type 0x0207, datagramsize 15
00:22:35: BR0:2 PPP: I pkt type 0x0207, datagramsize 312
00:24:28: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected
from 18008358661 To p, call lasted 120 seconds
00:24:28: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
00:24:10: %ISDN-6-DISCONNECT: Interface BRI0:2 disconnected from 8358663, call
lasted 120 seconds
00:24:28: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
00:24:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to down
00:24:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:2, changed state to down
Notice that in this output, the first two ICMP packets (pings) failed due to the delay in bringing
up the ISDN BRI. Although faster than asynchronous connections, ISDN still introduces connection
delay, which can impact user applications. In addition, the output from the debug ppp
negotiation command shows the process by which a PPP session is activated.
This output does not use CHAP, compression, or multilink. Instead, as you can see, PPP
starts and then LCP is activated. After this occurs, the NCP negotiations begin, starting with
CDPCP and followed by IPCP. Cisco Discovery Protocol (CDP) is a proprietary advertisement
protocol that sends router and switch information between Cisco devices. It operates over any
physical media that supports Subnetwork Access Protocol (SNAP) (except ATM) and is independent
of IP. The IP Control Protocol (IPCP) was started to transport the ICMP pings that
were sent from the router.
Remember that PPP sessions must undergo a negotiation process and that the debug ppp
negotiation command will display upper level protocols such as IPCP, along with LCP and PPP.
Multilink Configuration
Multilink Configuration
Like compression, multilink is fairly easy to configure. Figure 24.10 illustrates the desired configuration.
Users or administrators simply configure the modem to be used and the phone number
to be dialed. Multilink services require two or more modems and two or more phone lines
on the client side, which are bonded together into a single logical connection.
For further reference, the Multilink PPP (MPPP) RFC is 1990.
The commands for configuring asynchronous multilink or ISDN multilink differ little, and
the primary commands need to include only the following:
encapsulation ppp
ppp multilink
Like compression, multilink is fairly easy to configure. Figure 24.10 illustrates the desired configuration.
Users or administrators simply configure the modem to be used and the phone number
to be dialed. Multilink services require two or more modems and two or more phone lines
on the client side, which are bonded together into a single logical connection.
For further reference, the Multilink PPP (MPPP) RFC is 1990.
The commands for configuring asynchronous multilink or ISDN multilink differ little, and
the primary commands need to include only the following:
encapsulation ppp
ppp multilink
Compression Configuration
Compression is available in the IOS software on virtually every Cisco router. However, despite
its benefits, software-based compression places a significant load on the router’s processor.
Therefore, administrators must weigh the benefits of compression against the potential performance
degradation that could result. In addition, monitoring the router’s CPU is required, that
is, ensuring that the utilization of the CPU does not exceed 65 percent. You can determine the
CPU utilization by viewing it with the show process cpu command. This command will show
you a one-minute and five-minute CPU utilization trend, as shown next, where the router is running
consistently at three percent utilization:
Router1#show process cpu
CPU utilization for five seconds: 3%/3%; one minute: 3%; five minutes: 3%
To configure compression, use the following commands:
encapsulation ppp
compress [predictor | stac | mppc [ignore-pfc]]
Note that both sides of the serial link need to be configured for the same compression
method; different compression protocols are not compatible with each other. Designers should
also consider the type of data that will be used when configuring compression:
Predictor The predictor option provides a useful benefit in that compressed data will not be
recompressed—a process that typically increases the transmitted size and adds substantial delay.
This is a good choice for a mixture of compressed and uncompressed data that will traverse the
link. Predictor can be more memory-intensive than other choices, but it does not burden the
router’s CPU substantially.
Stac Most significantly, the stac compression option is the only supported algorithm for the
CBOS-based router platforms, including the Cisco 700 series. As with other compression mechanisms,
stac substitutes repetitive data sequences with brief, summarized values, which are decoded
on the other end. The specific compression algorithm is called LZW, or Lempel-Ziv-Welch, the
names of the creators.
MPPC Microsoft Point-to-Point Compression (MPPC) is used when receiving compressed
data from Windows clients. With this option, all data is compressed.
In addition, a fourth compression type is available to the designer: TCP header compression.
Invoked with the ip tcp header-compression command, TCP header compression does
exactly that—it compresses only the TCP header information (20 bytes). The specifics of TCP
header compression, which is not unique to PPP, are documented in RFC 1144. This type of
compression reduces the number of bytes required for each TCP packet and provides this reduction
with a minimum amount of overhead. TCP header compression does not impact UDP or
Internet Control Message Protocol (ICMP) packets.
Administrators wishing to offload the route processor from the burdens of compression
computations might wish to use the Cisco 7500 series router with the compression service
adapter. When this card is present, the router will use the hardware-based compression that is
running on this card. If the router contains VIP2 cards, the compression process can be distributed,
which will move the overhead of compression away from the central processor. Interface
functions on the card will be affected, however. Without VIP2 technology or the compression
service adapter, the router will default to software-based compression.
Other Cisco routers support the use of hardware-assisted compression. The 2600, 3700, and
3660 series routers support the use of a compression Advanced Integration Module (AIM) to
offload compression duties from the CPU. Also, the 3620/40 routers support a network module
that offloads PPP and Frame Relay (FRF.9) compression.
NOTE:Compression is generally avoided beyond the 2Mbps level, and ideally, it is
used only for links below 128Kbps. Review your requirements carefully before
selecting the type of compression. If traffic is truly that high, it might be a short
time before additional capacity is necessary anyway.
its benefits, software-based compression places a significant load on the router’s processor.
Therefore, administrators must weigh the benefits of compression against the potential performance
degradation that could result. In addition, monitoring the router’s CPU is required, that
is, ensuring that the utilization of the CPU does not exceed 65 percent. You can determine the
CPU utilization by viewing it with the show process cpu command. This command will show
you a one-minute and five-minute CPU utilization trend, as shown next, where the router is running
consistently at three percent utilization:
Router1#show process cpu
CPU utilization for five seconds: 3%/3%; one minute: 3%; five minutes: 3%
To configure compression, use the following commands:
encapsulation ppp
compress [predictor | stac | mppc [ignore-pfc]]
Note that both sides of the serial link need to be configured for the same compression
method; different compression protocols are not compatible with each other. Designers should
also consider the type of data that will be used when configuring compression:
Predictor The predictor option provides a useful benefit in that compressed data will not be
recompressed—a process that typically increases the transmitted size and adds substantial delay.
This is a good choice for a mixture of compressed and uncompressed data that will traverse the
link. Predictor can be more memory-intensive than other choices, but it does not burden the
router’s CPU substantially.
Stac Most significantly, the stac compression option is the only supported algorithm for the
CBOS-based router platforms, including the Cisco 700 series. As with other compression mechanisms,
stac substitutes repetitive data sequences with brief, summarized values, which are decoded
on the other end. The specific compression algorithm is called LZW, or Lempel-Ziv-Welch, the
names of the creators.
MPPC Microsoft Point-to-Point Compression (MPPC) is used when receiving compressed
data from Windows clients. With this option, all data is compressed.
In addition, a fourth compression type is available to the designer: TCP header compression.
Invoked with the ip tcp header-compression command, TCP header compression does
exactly that—it compresses only the TCP header information (20 bytes). The specifics of TCP
header compression, which is not unique to PPP, are documented in RFC 1144. This type of
compression reduces the number of bytes required for each TCP packet and provides this reduction
with a minimum amount of overhead. TCP header compression does not impact UDP or
Internet Control Message Protocol (ICMP) packets.
Administrators wishing to offload the route processor from the burdens of compression
computations might wish to use the Cisco 7500 series router with the compression service
adapter. When this card is present, the router will use the hardware-based compression that is
running on this card. If the router contains VIP2 cards, the compression process can be distributed,
which will move the overhead of compression away from the central processor. Interface
functions on the card will be affected, however. Without VIP2 technology or the compression
service adapter, the router will default to software-based compression.
Other Cisco routers support the use of hardware-assisted compression. The 2600, 3700, and
3660 series routers support the use of a compression Advanced Integration Module (AIM) to
offload compression duties from the CPU. Also, the 3620/40 routers support a network module
that offloads PPP and Frame Relay (FRF.9) compression.
NOTE:Compression is generally avoided beyond the 2Mbps level, and ideally, it is
used only for links below 128Kbps. Review your requirements carefully before
selecting the type of compression. If traffic is truly that high, it might be a short
time before additional capacity is necessary anyway.
Verifying and Troubleshooting PPP
As with most troubleshooting on Cisco routers, administrators have a wide range of show and
debug commands available to resolve problems that can occur with the Point-to-Point Protocol.
Using standard troubleshooting methodologies, the administrator should be able to isolate
physical problems quickly and then use these tools to locate and resolve logical issues.
Ideally, designers and administrators unfamiliar with PPP will need to implement a simple
configuration before adding additional features such as authentication and multilink bonding.
However, one or both of these services might be required as part of the initial installation. The
debug and show commands will quickly help isolate the various issues.
This section focuses on the three most common debug commands:
debug ppp authentication
debug ppp negotiation
debug ppp packet
debug commands available to resolve problems that can occur with the Point-to-Point Protocol.
Using standard troubleshooting methodologies, the administrator should be able to isolate
physical problems quickly and then use these tools to locate and resolve logical issues.
Ideally, designers and administrators unfamiliar with PPP will need to implement a simple
configuration before adding additional features such as authentication and multilink bonding.
However, one or both of these services might be required as part of the initial installation. The
debug and show commands will quickly help isolate the various issues.
This section focuses on the three most common debug commands:
debug ppp authentication
debug ppp negotiation
debug ppp packet
PPP Compression and Multilink
It seems that there is never enough bandwidth for current user demand. However, PPP compression
and multilink can provide different mechanisms for increasing the throughput between
different locations.
Compression uses representation to remove bytes from the data stream. For example, if
the word the is represented by an @ sign, the protocol could save two characters per instance.
Repeated hundreds of times for different strings, it is possible to save substantial amounts of
bandwidth, which will improve performance. The overhead incurred with most compression is
minor compared to the resultant savings.
Multilink takes a different approach from compression. Compression uses the current connection
and squeezes additional information across the link. Multilink takes the standard data
stream and bonds multiple connections to increase the amount of bandwidth available to the
application. With multilink, two or more circuits can be made to appear as a single large pipe.
This is more expensive than compression because each location requires two or more analog
phone lines or ISDN circuits. This option is better when more bandwidth is required, but higher
bandwidth technologies are not available. Multilink ultimately improves throughput and
reduces latency. Compression and multilink can be combined to further improve throughput.
and multilink can provide different mechanisms for increasing the throughput between
different locations.
Compression uses representation to remove bytes from the data stream. For example, if
the word the is represented by an @ sign, the protocol could save two characters per instance.
Repeated hundreds of times for different strings, it is possible to save substantial amounts of
bandwidth, which will improve performance. The overhead incurred with most compression is
minor compared to the resultant savings.
Multilink takes a different approach from compression. Compression uses the current connection
and squeezes additional information across the link. Multilink takes the standard data
stream and bonds multiple connections to increase the amount of bandwidth available to the
application. With multilink, two or more circuits can be made to appear as a single large pipe.
This is more expensive than compression because each location requires two or more analog
phone lines or ISDN circuits. This option is better when more bandwidth is required, but higher
bandwidth technologies are not available. Multilink ultimately improves throughput and
reduces latency. Compression and multilink can be combined to further improve throughput.
Challenge Handshake Authentication Protocol (CHAP)
The Challenge Handshake Authentication Protocol (CHAP) is significantly more secure than PAP.
This is because of the mechanism used to transfer the username and password: CHAP protects
against playback hacking (resending the packet as part of an attack) by using a hash value that is
valid only for that transaction. When the attacker captures the CHAP session and replays that dialog
in an attempt to access the network, the hash method will prevent the connection. The password is
also hidden from the attacker; it is never sent over the circuit.
The hash value used in CHAP is derived from the Message Digest type 5 (MD5) algorithm,
which takes a message of arbitrary length and produces as output a 128-bit message digest of
the input. The message digest’s strength comes from being nonreversible, and it is computationally
infeasible to produce two messages having the same message digest. The MD5 algorithm is
defined in RFC 1321.
The MD5 hash shown in Figure 24.8 is valid for a relatively brief time, and no unencrypted information
is sent over the link. This data might allow a hacker to impersonate the authentic user.
FIGURE 2 4 . 8 CHAP authentication
The commands to configure CHAP are similar to those for PAP. Instead of selecting pap in the
ppp authentication command, the administrator uses the chap keyword. Notice, from the following
configuration snippet, that two additional options are also available: chap pap and pap
chap. These keywords provide the administrator with a means of selecting both protocols, and they
are attempted in order; thus, chap pap tries to authenticate via the CHAP protocol first. Typically,
this configuration option is used only during a transition because security would be compromised
if PAP were permitted. The following commands are used to enable PPP, a requirement for CHAP,
and to configure the router for CHAP authentication:
encapsulation ppp
ppp authentication {chap | chap pap | pap chap |
pap} [if-needed] [list-name | default] [callin]
The additional commands that you see are used for external user authentication and one-way
authentication. These are beyond the scope of this book, but they are included for completeness.
Usernames and passwords are added to the router with the username name password
secret command.
In Windows networking, the administrator is given the choice of whether to require password
encryption, as shown in Figure 24.9. Note that this Require Encrypted Password check box is not
selected, meaning that the user or administrator has chosen not to require encrypted passwords.
This configuration will work so long as PAP is not the only selected authentication method
on the access server. The Windows client will attempt to connect with MS-CHAP, a Microsoft
proprietary version of the CHAP protocol. If the check box is selected—meaning the password
must be encrypted—either PAP or CHAP will be used, depending on the configuration
of the server; if the server is not set to require CHAP, the client can fall back to a PAP, nonencrypted
password.
This is because of the mechanism used to transfer the username and password: CHAP protects
against playback hacking (resending the packet as part of an attack) by using a hash value that is
valid only for that transaction. When the attacker captures the CHAP session and replays that dialog
in an attempt to access the network, the hash method will prevent the connection. The password is
also hidden from the attacker; it is never sent over the circuit.
The hash value used in CHAP is derived from the Message Digest type 5 (MD5) algorithm,
which takes a message of arbitrary length and produces as output a 128-bit message digest of
the input. The message digest’s strength comes from being nonreversible, and it is computationally
infeasible to produce two messages having the same message digest. The MD5 algorithm is
defined in RFC 1321.
The MD5 hash shown in Figure 24.8 is valid for a relatively brief time, and no unencrypted information
is sent over the link. This data might allow a hacker to impersonate the authentic user.
FIGURE 2 4 . 8 CHAP authentication
The commands to configure CHAP are similar to those for PAP. Instead of selecting pap in the
ppp authentication command, the administrator uses the chap keyword. Notice, from the following
configuration snippet, that two additional options are also available: chap pap and pap
chap. These keywords provide the administrator with a means of selecting both protocols, and they
are attempted in order; thus, chap pap tries to authenticate via the CHAP protocol first. Typically,
this configuration option is used only during a transition because security would be compromised
if PAP were permitted. The following commands are used to enable PPP, a requirement for CHAP,
and to configure the router for CHAP authentication:
encapsulation ppp
ppp authentication {chap | chap pap | pap chap |
pap} [if-needed] [list-name | default] [callin]
The additional commands that you see are used for external user authentication and one-way
authentication. These are beyond the scope of this book, but they are included for completeness.
Usernames and passwords are added to the router with the username name password
secret command.
In Windows networking, the administrator is given the choice of whether to require password
encryption, as shown in Figure 24.9. Note that this Require Encrypted Password check box is not
selected, meaning that the user or administrator has chosen not to require encrypted passwords.
This configuration will work so long as PAP is not the only selected authentication method
on the access server. The Windows client will attempt to connect with MS-CHAP, a Microsoft
proprietary version of the CHAP protocol. If the check box is selected—meaning the password
must be encrypted—either PAP or CHAP will be used, depending on the configuration
of the server; if the server is not set to require CHAP, the client can fall back to a PAP, nonencrypted
password.
Password Authentication Protocol (PAP)
Password Authentication Protocol (PAP) provides basic security authentication for connections.
The username and password information, however, are transmitted in cleartext, which can be
intercepted by a hacker to compromise the network. Unfortunately, a few older systems support
only PAP and not the more secure CHAP, which mandates PAP’s usage in those cases.
PAP is defined in RFC 1334.
PAP operates by establishing a connection and then checking the username and password information.
If the username and password information matches, an OK message is returned and the session
is allowed to proceed. This is illustrated in Figure 24.7. Note that the username and password
are transmitted in cleartext in PAP—a significant security risk.
PAP usernames and passwords are transmitted in cleartext, reducing the security
benefits of the protocol. Use CHAP whenever possible.
To configure PAP, the administrator needs to configure both the service and a database of
usernames and passwords. The commands used to do this are shown here:
encapsulation ppp
ppp authentication {chap | chap pap | pap chap |
pap} [if-needed] [list-name | default] [callin]
Usernames and passwords are added to the router with the username name password
secret command.
There isn’t much more to PAP—it works with a minimal amount of configuration, in large
part due to its lack of security. Readers should be familiar with the existence of this protocol and
understand that it should not be used in current designs.
The username and password information, however, are transmitted in cleartext, which can be
intercepted by a hacker to compromise the network. Unfortunately, a few older systems support
only PAP and not the more secure CHAP, which mandates PAP’s usage in those cases.
PAP is defined in RFC 1334.
PAP operates by establishing a connection and then checking the username and password information.
If the username and password information matches, an OK message is returned and the session
is allowed to proceed. This is illustrated in Figure 24.7. Note that the username and password
are transmitted in cleartext in PAP—a significant security risk.
PAP usernames and passwords are transmitted in cleartext, reducing the security
benefits of the protocol. Use CHAP whenever possible.
To configure PAP, the administrator needs to configure both the service and a database of
usernames and passwords. The commands used to do this are shown here:
encapsulation ppp
ppp authentication {chap | chap pap | pap chap |
pap} [if-needed] [list-name | default] [callin]
Usernames and passwords are added to the router with the username name password
secret command.
There isn’t much more to PAP—it works with a minimal amount of configuration, in large
part due to its lack of security. Readers should be familiar with the existence of this protocol and
understand that it should not be used in current designs.
PAP and CHAP Authentication
One of the key benefits of PPP is the ability to add authentication services, which are provided
by PAP or CHAP. Authentication adds substantially to the security of the network and should
be used. Even though PAP is explained in this section, its use is discouraged and administrators
should configure their networks for the more secure CHAP.
by PAP or CHAP. Authentication adds substantially to the security of the network and should
be used. Even though PAP is explained in this section, its use is discouraged and administrators
should configure their networks for the more secure CHAP.
Configuring PPP Callback
For the following scenario, we set up a spoke router that needs to call into a hub router. The
configuration must also allow the hub router to call the spoke router back on a predefined
phone number after authentication. This situation has two benefits: One is added security,
because the hub router calls Spoke1 back on a predefined number. The other benefit is that it
is cheaper for the hub router to call Spoke1 because of discounts negotiated by the company
for long-distance calls from the hub site.
As a backup, we configured a callback from a spoke router to the hub router, where each router
is a Cisco 2600 series router and has a USR (US Robotics) modem attached to the aux port.
We’ll allow the Spoke1 router to call into the hub router, authenticate, and let the hub router call
the Spoke1 router back on a predefined number.
Here are the relevant commands we used to get things started:
Hub#config title
Hub(config)#username Spoke1 password sybex
Hub(config)#chat script Dialout
➥ABORT ERROR ABORT BUSY "" "AT" OK "ATDT \T" TIMEOUT 45 CONNECT \c
Hub(config)#modemcap entry USR_MODEM:MSC=&F1S0=1
Hub(config)#dialer-list 1 protocol ip permit
Hub(config)#line aux 0
Hub(config-line)#modem inout
Hub(config-line)#modem autoconfigure type USR_MODEM
Hub(config-line)#script dialer Dialout
Hub(config-line)#speed 115200
Hub(config-line)#transport input all
Hub(config-line)#stopbits 1
Hub(config-line)#flowcontrol hardware
Hub(config-line)#exec-timeout 0 0
Hub(config-line)#exit
Hub(config)#interface async65
Hub(config-if)#ip address 192.168.190.1 255.255.255.0
Hub(config-if)#encapsulation ppp
Hub(config-if)#dialer in-band
Hub(config-if)#dialer-group 1
Hub(config-if)#async default routing
Hub(config-if)#async mode dedicated
Hub(config-if)#ppp authentication chap
Hub(config-if)#^Z
Hub#
Spoke1#config title
Spoke1(config)#username Hub password sybex
Spoke1(config)#chat script Dialout
➥ABORT ERROR ABORT BUSY "" "AT" OK "ATDT \T" TIMEOUT 45 CONNECT \c
Spoke1(config)#modemcap entry USR_MODEM:MSC=&F1S0=1
Spoke1(config)#dialer-list 1 protocol ip permit
Spoke1(config)#line aux 0
Spoke1(config-line)#modem inout
Spoke1(config-line)#modem autoconfigure type USR_MODEM
Spoke1(config-line)#script dialer Dialout
Spoke1(config-line)#speed 115200
Spoke1(config-line)#transport input all
Spoke1(config-line)#stopbits 1
Spoke1(config-line)#flowcontrol hardware
Spoke1(config-line)#exec-timeout 0 0
Spoke1(config-line)#exit
Spoke1(config)#interface async65
Spoke1(config-if)#ip address 192.168.190.2 255.255.255.0
Spoke1(config-if)#encapsulation ppp
Spoke1(config-if)#dialer in-band
Spoke1(config-if)#dialer-group 1
Spoke1(config-if)#async default routing
Spoke1(config-if)#async mode dedicated
Spoke1(config-if)#ppp authentication chap
Spoke1(config-if)#^Z
Spoke1#
There are some things we need to point out before continuing. We created a custom modemcap
entry for our USR modem instead of using the built-in modemcap entry. We also omitted
the dialer map statements, which we will discuss in greater detail later. Finally, because both
sides need to dial out, we configured a chat script required to successfully dial out.
Next, we configured the routers—one as the client and one as the server—for callback. The configuration
is slightly different between the client and server callback routers. The Spoke1 router
will be the callback client, and the Hub router will be the callback server. We will use the dialer
map command on the spoke router just as you might expect, but on the Hub router we need to
add a class parameter to the dialer map command for callback purposes.
Please note that map-class configurations are beyond the scope of the exam and this book, and
you need not be too concerned at this point about the minutia. However, the syntax is fairly
straightforward. We recommend that you focus on the material for the exam at this point, and,
after you’ve passed, refer to the Cisco website or practice in your lab environment with the following
commands. Here is the configuration for each router:
Spoke1#config t
Spoke1(config)#interface async65
Spoke1(config-if)#dialer map ip 192.168.190.1 name Hub broadcast 5551211
Spoke1(config-if)#ppp callback request
Spoke1(config-if)#^Z
Spoke1#
Hub#config t
Hub(config)#map-class dialer Spoke1_Auth
Hub(config-map-class)#dialer callback username
Hub(config-map-class)#exit
Hub(config)#interface async65
Hub(config-if)#dialer map ip 192.168.190.2
➥name Spoke1 broadcast 5551212 class Spoke1_Auth
Hub(config-if)#ppp callback accept
Hub(config-if)#^Z
Hub#
When the spoke initiates a call to the hub router, the hub router will authenticate the spoke
router, and the spoke router will tell the hub router it would like to use callback. Then, the hub
router will drop the line and call back the spoke router on the number specified in the dialer
map command. When the spoke router gets the call, it will authenticate again before starting the
PPP negotiation process.
Notice that we did not specify any dynamic routing protocols over this link. Doing so would
make this configuration complex and is beyond the scope of this Study Guide. As noted before,
map-class and chat scripts are also beyond the scope of this book, but we want to give you a
taste of the possibilities when configuring Cisco IOS.
configuration must also allow the hub router to call the spoke router back on a predefined
phone number after authentication. This situation has two benefits: One is added security,
because the hub router calls Spoke1 back on a predefined number. The other benefit is that it
is cheaper for the hub router to call Spoke1 because of discounts negotiated by the company
for long-distance calls from the hub site.
As a backup, we configured a callback from a spoke router to the hub router, where each router
is a Cisco 2600 series router and has a USR (US Robotics) modem attached to the aux port.
We’ll allow the Spoke1 router to call into the hub router, authenticate, and let the hub router call
the Spoke1 router back on a predefined number.
Here are the relevant commands we used to get things started:
Hub#config title
Hub(config)#username Spoke1 password sybex
Hub(config)#chat script Dialout
➥ABORT ERROR ABORT BUSY "" "AT" OK "ATDT \T" TIMEOUT 45 CONNECT \c
Hub(config)#modemcap entry USR_MODEM:MSC=&F1S0=1
Hub(config)#dialer-list 1 protocol ip permit
Hub(config)#line aux 0
Hub(config-line)#modem inout
Hub(config-line)#modem autoconfigure type USR_MODEM
Hub(config-line)#script dialer Dialout
Hub(config-line)#speed 115200
Hub(config-line)#transport input all
Hub(config-line)#stopbits 1
Hub(config-line)#flowcontrol hardware
Hub(config-line)#exec-timeout 0 0
Hub(config-line)#exit
Hub(config)#interface async65
Hub(config-if)#ip address 192.168.190.1 255.255.255.0
Hub(config-if)#encapsulation ppp
Hub(config-if)#dialer in-band
Hub(config-if)#dialer-group 1
Hub(config-if)#async default routing
Hub(config-if)#async mode dedicated
Hub(config-if)#ppp authentication chap
Hub(config-if)#^Z
Hub#
Spoke1#config title
Spoke1(config)#username Hub password sybex
Spoke1(config)#chat script Dialout
➥ABORT ERROR ABORT BUSY "" "AT" OK "ATDT \T" TIMEOUT 45 CONNECT \c
Spoke1(config)#modemcap entry USR_MODEM:MSC=&F1S0=1
Spoke1(config)#dialer-list 1 protocol ip permit
Spoke1(config)#line aux 0
Spoke1(config-line)#modem inout
Spoke1(config-line)#modem autoconfigure type USR_MODEM
Spoke1(config-line)#script dialer Dialout
Spoke1(config-line)#speed 115200
Spoke1(config-line)#transport input all
Spoke1(config-line)#stopbits 1
Spoke1(config-line)#flowcontrol hardware
Spoke1(config-line)#exec-timeout 0 0
Spoke1(config-line)#exit
Spoke1(config)#interface async65
Spoke1(config-if)#ip address 192.168.190.2 255.255.255.0
Spoke1(config-if)#encapsulation ppp
Spoke1(config-if)#dialer in-band
Spoke1(config-if)#dialer-group 1
Spoke1(config-if)#async default routing
Spoke1(config-if)#async mode dedicated
Spoke1(config-if)#ppp authentication chap
Spoke1(config-if)#^Z
Spoke1#
There are some things we need to point out before continuing. We created a custom modemcap
entry for our USR modem instead of using the built-in modemcap entry. We also omitted
the dialer map statements, which we will discuss in greater detail later. Finally, because both
sides need to dial out, we configured a chat script required to successfully dial out.
Next, we configured the routers—one as the client and one as the server—for callback. The configuration
is slightly different between the client and server callback routers. The Spoke1 router
will be the callback client, and the Hub router will be the callback server. We will use the dialer
map command on the spoke router just as you might expect, but on the Hub router we need to
add a class parameter to the dialer map command for callback purposes.
Please note that map-class configurations are beyond the scope of the exam and this book, and
you need not be too concerned at this point about the minutia. However, the syntax is fairly
straightforward. We recommend that you focus on the material for the exam at this point, and,
after you’ve passed, refer to the Cisco website or practice in your lab environment with the following
commands. Here is the configuration for each router:
Spoke1#config t
Spoke1(config)#interface async65
Spoke1(config-if)#dialer map ip 192.168.190.1 name Hub broadcast 5551211
Spoke1(config-if)#ppp callback request
Spoke1(config-if)#^Z
Spoke1#
Hub#config t
Hub(config)#map-class dialer Spoke1_Auth
Hub(config-map-class)#dialer callback username
Hub(config-map-class)#exit
Hub(config)#interface async65
Hub(config-if)#dialer map ip 192.168.190.2
➥name Spoke1 broadcast 5551212 class Spoke1_Auth
Hub(config-if)#ppp callback accept
Hub(config-if)#^Z
Hub#
When the spoke initiates a call to the hub router, the hub router will authenticate the spoke
router, and the spoke router will tell the hub router it would like to use callback. Then, the hub
router will drop the line and call back the spoke router on the number specified in the dialer
map command. When the spoke router gets the call, it will authenticate again before starting the
PPP negotiation process.
Notice that we did not specify any dynamic routing protocols over this link. Doing so would
make this configuration complex and is beyond the scope of this Study Guide. As noted before,
map-class and chat scripts are also beyond the scope of this book, but we want to give you a
taste of the possibilities when configuring Cisco IOS.
PPP Callback
Security in PPP can be further augmented with the use of PPP callback, which instructs
the access server to disconnect the incoming connection after successful authentication and
re-establish the connection via an outbound call. This security feature requires that the
caller be in a single physical location and diminishes the impact of a compromised username
and password. The service can also be used to control costs because all connections appear
to be from the remote access server—allowing volume-based discounts.
PPP callback is documented in RFC 1570.
Clearly, this solution is not well suited to mobile users; for example, callback to a hotel room
would require repeated configuration and a mechanism to deal with extensions. Some callback
solutions enable the remote user to enter the callback number—a solution that removes the
physical location restrictions and enhances mobility.
Cisco’s callback feature does not permit remote users to dynamically enter the
callback number.
Consider the security provided by a callback configuration:
The remote client (user) must connect into the remote access server.
By using an authentication protocol such as CHAP, the user must authenticate.
If authentication is successful, the session will terminate and the remote access server will
call the remote client back. If the authentication fails, the connection will terminate.
Upon callback, the client and server can again perform password verification.
Clearly, these extra steps could enhance security.
To configure callback, the administrator needs to use the ppp callback accept command
on the router interface that receives the initial inbound call and the ppp callback request
command on the interface that is making the initial outbound call.
PPP callback will not make repeated retries to establish a return connection.
This means that a busy signal or other impediment will require the client side
to re-request the session.
the access server to disconnect the incoming connection after successful authentication and
re-establish the connection via an outbound call. This security feature requires that the
caller be in a single physical location and diminishes the impact of a compromised username
and password. The service can also be used to control costs because all connections appear
to be from the remote access server—allowing volume-based discounts.
PPP callback is documented in RFC 1570.
Clearly, this solution is not well suited to mobile users; for example, callback to a hotel room
would require repeated configuration and a mechanism to deal with extensions. Some callback
solutions enable the remote user to enter the callback number—a solution that removes the
physical location restrictions and enhances mobility.
Cisco’s callback feature does not permit remote users to dynamically enter the
callback number.
Consider the security provided by a callback configuration:
The remote client (user) must connect into the remote access server.
By using an authentication protocol such as CHAP, the user must authenticate.
If authentication is successful, the session will terminate and the remote access server will
call the remote client back. If the authentication fails, the connection will terminate.
Upon callback, the client and server can again perform password verification.
Clearly, these extra steps could enhance security.
To configure callback, the administrator needs to use the ppp callback accept command
on the router interface that receives the initial inbound call and the ppp callback request
command on the interface that is making the initial outbound call.
PPP callback will not make repeated retries to establish a return connection.
This means that a busy signal or other impediment will require the client side
to re-request the session.
The DHCP process
DHCP operates in similar fashion when served from the router: as noted previously, only the
configuration process changes. While an interesting feature, the DHCP server on the router is
not practical in most installations. The need to maintain a separate FTP server for the database
usually leads the administrator to opt for a more scalable option that requires installing a dedicated
server.
configuration process changes. While an interesting feature, the DHCP server on the router is
not practical in most installations. The need to maintain a separate FTP server for the database
usually leads the administrator to opt for a more scalable option that requires installing a dedicated
server.
DHCP Lease Length
The length of the DHCP lease governs the amount of time a host “owns” the address. To continue
using the address, the host must renew with the server before the lease expires. Designers
must consider the overhead of this renewal traffic and the impact of failed or unavailable DHCP
servers. In general, long leases are appropriate for fixed environments, and short leases are
applicable in more dynamic installations.
Consider a fully functioning network with 100 workstations and a lease length of five minutes.
This is an extreme example (that no self-respecting engineer would install) because DHCP will
send a renewal request at an interval equal to one-half the lease period. The overhead for just IP
address leases would be 2,400 requests per hour, not including any DNS queries and the multiple
packets involved in each request (see Figure 24.6). This is a high amount of overhead for information
that should not change under normal circumstances.
In addition, when a lease expires, the host must release its IP address. Without a DHCP
server, it will be unable to communicate on the network because it has no IP address.
The alternative to a short lease is to make the lease very long. Consider the impact of a lease
equal to 60 days. Should the hosts remain on a local subnet with very few changes, this would
substantially reduce the volume of traffic.
However, this would not be appropriate for a hotelling installation. Hotelling is a concept
introduced years ago in which notebook users would check into a cubicle for a day or even a
week. DHCP is a great solution for such an installation because the MAC addresses are constantly
changing, but a long lease time would be inappropriate here. Consider a scenario in
which each visitor connects once per quarter, or every 90 days. And, for this example, presume
that there are 800 users of the service, and the pool is a standard Class C network of 254 host
addresses. If the lease were long—90 days for this example—only the first 254 users would be
able to obtain an address. Clearly, this is not appropriate for this type of installation, which is
an important consideration for the network designer.
As mentioned earlier, the default DHCP lease renewal interval (on Windows NT) is 72 hours.
DHCP attempts to renew the lease after one-half the lease duration, or 36 hours in the case of
default Windows NT.
The default lease on Cisco IOS-based DHCP servers is 24 hours.
For reference, the mechanism by which DHCP obtains an address is illustrated in
Figure 24.6. Note that DHCP uses a system of discovery to locate the DHCP server—a
phase that uses the helper function. After the DHCP server is found, the offer is returned
to the workstation, and the request is positively or negatively acknowledged. One way to
remember the DHCP process is with the mnemonic DORA, which stands for Discover,
Offer, Request, and Acknowledgment.
using the address, the host must renew with the server before the lease expires. Designers
must consider the overhead of this renewal traffic and the impact of failed or unavailable DHCP
servers. In general, long leases are appropriate for fixed environments, and short leases are
applicable in more dynamic installations.
Consider a fully functioning network with 100 workstations and a lease length of five minutes.
This is an extreme example (that no self-respecting engineer would install) because DHCP will
send a renewal request at an interval equal to one-half the lease period. The overhead for just IP
address leases would be 2,400 requests per hour, not including any DNS queries and the multiple
packets involved in each request (see Figure 24.6). This is a high amount of overhead for information
that should not change under normal circumstances.
In addition, when a lease expires, the host must release its IP address. Without a DHCP
server, it will be unable to communicate on the network because it has no IP address.
The alternative to a short lease is to make the lease very long. Consider the impact of a lease
equal to 60 days. Should the hosts remain on a local subnet with very few changes, this would
substantially reduce the volume of traffic.
However, this would not be appropriate for a hotelling installation. Hotelling is a concept
introduced years ago in which notebook users would check into a cubicle for a day or even a
week. DHCP is a great solution for such an installation because the MAC addresses are constantly
changing, but a long lease time would be inappropriate here. Consider a scenario in
which each visitor connects once per quarter, or every 90 days. And, for this example, presume
that there are 800 users of the service, and the pool is a standard Class C network of 254 host
addresses. If the lease were long—90 days for this example—only the first 254 users would be
able to obtain an address. Clearly, this is not appropriate for this type of installation, which is
an important consideration for the network designer.
As mentioned earlier, the default DHCP lease renewal interval (on Windows NT) is 72 hours.
DHCP attempts to renew the lease after one-half the lease duration, or 36 hours in the case of
default Windows NT.
The default lease on Cisco IOS-based DHCP servers is 24 hours.
For reference, the mechanism by which DHCP obtains an address is illustrated in
Figure 24.6. Note that DHCP uses a system of discovery to locate the DHCP server—a
phase that uses the helper function. After the DHCP server is found, the offer is returned
to the workstation, and the request is positively or negatively acknowledged. One way to
remember the DHCP process is with the mnemonic DORA, which stands for Discover,
Offer, Request, and Acknowledgment.
Subscribe to:
Posts (Atom)