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.
IT Certification CCIE,CCNP,CCIP,CCNA,CCSP,Cisco Network Optimization and Security Tips
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.
IP Address Design Inefficiencies
Network Class
Addresses Required
Addresses Available
Addresses Wasted
A
100
16,777,214
16,777,114
B
100
00,065,534
00,065,434
C
100
00,000,254
00,000,154
Now multiply each entry in Table 2-3 by the 50 networks that are required and you can easily see that regardless of which address class we choose, an enormous number of IP addresses will be wasted. Also, if we are to have connectivity to the Internet, then the network will have to advertise 50 networks to the Internet routers. Multiply that by the number of campuses in the world and you have a situation where the size of the Internet routing tables becomes unmanageable. How do we overcome these problems? In a word, subnetting.
Addresses Required
Addresses Available
Addresses Wasted
A
100
16,777,214
16,777,114
B
100
00,065,534
00,065,434
C
100
00,000,254
00,000,154
Now multiply each entry in Table 2-3 by the 50 networks that are required and you can easily see that regardless of which address class we choose, an enormous number of IP addresses will be wasted. Also, if we are to have connectivity to the Internet, then the network will have to advertise 50 networks to the Internet routers. Multiply that by the number of campuses in the world and you have a situation where the size of the Internet routing tables becomes unmanageable. How do we overcome these problems? In a word, subnetting.
Subscribe to:
Posts (Atom)