Additional PPP Settings

As mentioned earlier, PPP has a couple of other settings that can be useful in a corporate environment. This section discusses PPP callback, compression, and multilink, plus a couple of new options in link quality monitoring and login banners.

PPP Callback

Callback is designed by Cisco to aid in bill consolidation. Instead of having numerous telecommuting employees pay long-distance fees that they have to expense, the router calls them back after the person is authenticated. Although Cisco does not officially market callback as a security feature, many organizations use it as such. It allows the organization to control the phone numbers that the router will connect with.

When a user dials in, PPP still communicates and sets up the connection, the user authenticates, but then the call is disconnected. The remote device calls the user back and the connection proceeds normally.

The following list outlines the PPP callback steps:

1. The user/callback client calls the remote router/callback server. If the user is configured to request callback, callback may occur. This request is sent during the LCP negotiation phase.

2. The callback server checks its own configuration to verify it can perform callback services.

3. Authentication takes place as normal with PPP.

4. Once the callback client is authenticated, the callback server checks its configuration to find the callback string for this specific client. The router uses the username of the client to find this information.

5. The call is disconnected.

6. The callback server uses the specified client dial string to call the client back. Only one attempt is made, so if something interferes with the callback process, the client needs to call the server again.

7. Once a connection is made when the server calls back the client, another round of authentication happens. If successful, there is an active connection.

What can prevent the second phase of callback from completing? Anything that can interrupt a phone line can disrupt the process. Such an interruption would be someone else calling or a household member picking up the phone; on the callback-server side, traffic using the last modem can prevent the return connection from happening. You can configure callback for both plain old telephone system (POTS) and ISDN lines.

Table 4.4 lists the commands necessary to configure callback.

Table 4.4. Callback Configuration Commands

Callback Command	Explanation
Router(config-if)#ppp callback request	This command tells the client to request callback from the callback server it is dialing. This command is placed in the dialing interface.
Router(config-if)#dialer hold-queue timeout seconds	This command tells the client to wait the specified number of seconds for callback to take place. The router holds packets going to the destination for this period. This command is optional and can also be used on the callback server.
Router(config-if)#dialer hold-queue packets	This command indicates how many packets the hold queue may contain. The range is 0 through 100. This command is helpful if the dialer hold-queue timeout command has been configured, because otherwise, the router drops packets while it waits for callback.
Router(config-if)#ppp callback accept	This command tells the router to accept callback requests that arrive on this interface. It is a callback server command.
Router(config-if)#ppp callback initiate	This command is another callback server command. (The rest of the commands are too.) It allows the router to start a callback session to a remote device capable of auto-answering.
Router(config-line)#callback forced-wait <seconds>	Used on a line, this command tells the router to wait so many seconds before beginning callback.
Router(config-line)#script callback script-name	This command gives specific AT commands the modem should use for this callback session.
Router(config)#username <password password> <callback-dialstring phone-number> <callback-line line-number> <callback-rotary rotary-group>	Options to the usual username name password password configuration for CHAP authentication include options for callback. They are defined individually next.
Callback-dialstring phone-number	This line indicates what phone number the callback server dials to reach this device.
Callback-line line-number	Use this line to specify a line to be used when calling this device.
Callback-rotary rotary-group	Rather than specify a particular line, you can specify a group of dial-out devices by using the callback-rotary command.

Compressed PPP

You can configure a router interface to compress the data that passes through it. PPP supports four main types of compression:

• Stacker Stacker compression uses a Lempel-Ziv (LZ) compression algorithm to compress data. Stacker maps where data appears in a stream and only sends each type once. Stacker is more CPU intensive than Predictor because it compresses everything, including traffic that is already compressed.

• Predictor Predictor examines data to see whether it is already compressed. If the data is not compressed, Predictor compresses and then forwards the data. If it is compressed, Predictor does not compress the data. Predictor is more memory intensive, due to all the checking it does, than either Stacker or Microsoft Point-to-Point Compression (MPPC) protocol. Predictor is the preferred method if your router has a lot of CPU-intensive tasks but not many memory-intensive ones.

• MPPC MPPC enables a user with a Microsoft workstation to connect to a Cisco router and compress the data that flows between them. MPPC is also an LZ algorithm. MPPC is more CPU intensive than Predictor for the same reason that Stacker is.

• TCP Header TCP Header compression does not do any compression on the data portion of the packet; instead, it compresses only the TCP headers.

The following list provides examples of when you use each method, and Table 4.5 illustrates the commands used:

• Stacker You use Stacker compression when you know the majority of your data is not already compressed. Compressing already compressed data can lead to an increase in file size, but always results in wasted CPU cycles.

• Predictor You use Predictor compression in the opposite scenario given for Stacker: when you have quite a bit of compressed data crossing a WAN link and you don't want to use the processing cycles needed to compress already compressed data.

• MPPC This one is easy. Just remember what the M is for, Microsoft. Use this type of compression when connecting Microsoft operating-system clients to a routed interface. It operates under the same assumption that the Stacker version does: that most of the traffic can be compressed.

• TCP Header You always want to compress the largest part of a packet that you can, so if you are sending packets where the TCP headers take up more bandwidth on average than the data portion, you use this type of compression. An example of appropriate use is if an organization has a lot of Telnet traffic crossing a WAN link.

Table 4.5. PPP Compression Commands

PPP Compression Option	Explanation
Router(config-if)#compress stac	Use this command at the appropriate interface to enable Stacker compression.
Router(config-if)#compress predictor	This command enables Predictor compression.
Router(config-if)#compress mppc	This command enables MPPC compression.
Router(config-if)#ip tcp header-compression <passive>	This command enables TCP Header compression on an interface. The passive command is optional and tells the interface to compress only if it receives compressed headers from the other side of the WAN.

Multilink PPP

Multilink allows for bundling data circuits into a larger virtual pipe. For example, ISDN has two data channels that each support up to 64Kbps. You can use each channel separately, or you can bind them together to form a virtual 128Kbps pipe. Multilink accomplishes it by load-balancing across the circuits. Multilink ensures that packets do not arrive out of order by fragmenting the packets and then shooting the fragments across the multilinked bundle. Figure 4.2 shows two routers connected via a two-channel Basic Rate Interface (BRI) circuit. The circuits are logically bundled together to give the appearance of a single link, and like other PPP options, Multilink is negotiated during the LCP phase.

Figure 4.2. Channel bundling.

In addition to the normal commands that you need to make a remote connection possible, Multilink needs two other commands. You issue both commands in interface configuration mode. The first command, ppp multilink, establishes an interface as a member of a Multilink bundle with other interfaces that have been configured with the command. The other command indicates when circuits should be brought up in support of the bundle. It might not be desirable to dial all multilink circuits at the beginning of a connection if the bandwidth isn't needed and charges are made based on the number of calls or on the length of a call. You can use the dialer-load threshold command to activate additional circuits. This command and its options are explained in more detail in Chapter 8, "Dial-on-Demand Routing."

Multilink PPP (MLP) is supported by multiple vendors under RFC 1990, an update to RFC 1717. You do not have to have Cisco equipment on both sides of the WAN to multilink. A router uses the Maximum Received Reconstructed Unit (MRRU) during LCP negotiation to tell the device on the far side that it is capable of forming a multilink bundle. Multilink is best used in environments where bandwidth requirements are dynamic. Cisco targets Multilink usage to telecommuters and the small office/home office (SOHO) market.

Multilink adds headers to the packet fragments so that the fragments can be reconstructed. These headers may be 2, 4 or 8 bytes, and they are used for sequencing. The Cisco 700 series ISDN devices use 2-byte headers, whereas Cisco IOS uses 4-byte headers.

Cisco routers also support a feature called multilink fragment interleaving. This feature is desired when there are both large data frames and small time-sensitive packets, such as those carrying voice traffic. Interleaving, shown in Figure 4.3, allows the voice to get mixed in with the fragmented data, allowing the voice to arrive at the far side quicker than it might have otherwise.

Figure 4.3. Interleaving fragments.

Figure 4.3 shows that traffic can enter the router from two different interfaces, and even though the streams are both headed across the WAN, prioritization can be given to one type over another. More on prioritization appears in Chapter 12, "Traffic Management."

Although the full topic is beyond the scope of this book, no discussion of MLP would be complete without taking the design to the extreme. Regular Multilink works well when all the connections terminate at a single access server, but environments that might have several hundred or more circuits coming in probably won't terminate them all at the same device (if for no other reason than redundancy). It's possible for your load threshold command to bring a secondary circuit up in support of the primary and for both to be attached to different devices! Needless to say, you end up with two separate connections rather than a single logical connection.

Multichassis multilink fixes this problem. All access server devices are placed into a pool called a stack group. When the user calls up, a member of the pool is assigned to the connection based on a process called bidding. Bidding can take into account processing capabilities, but it's usually based on which device has the most lines free. If the user calls up with a second connection utilizing a multilink process, the device handling the initial connection gets a bonus to its bid. Typically, as long as the device handling the original connection can handle the additional load, it gets the new connection, even if it would have lost the bid otherwise. In this fashion, we can ensure that the same device terminates both circuits.

Login Banners

With the emphasis on security and making sure that a company is legally covered, it often is a good idea to provide a means of letting intruders know that they aren't welcome into the system. A strongly worded warning against unauthorized access is difficult to defend against in a court of law, but a weak notice might be considered ambiguous or even inviting! A banner is available on all of the major login/authentication systems on the market today, and Cisco provides one with an IOS router, such as an AS5300 as a remote access server.

The format of the banner operates the same way as a message-of-the-day banner does in the IOS. You enter global configuration mode and use the command banner slip-ppp ? <message> ?. The question marks are delimiting characters. When you use the same character in each space, they indicate the beginning and end of the message.

You're the administrator of a Cisco remote access router and you want to provide a login banner that says "Authorized Access Only, Press "Enter" and Then Log In to Proceed." It's important to ensure that users take a positive action, reducing the chance someone can claim he got into the network "by mistake." Let's take a look at two examples of how you can configure this command.

In the first example, you enter the command banner slip-ppp "Authorized Access Only, Press "Enter" and Then Log In to Proceed.". The intent is to use a quote mark (") to indicate the beginning and end of the text. The router displays all text after the first delimiting character until it sees that character a second time. It's normally a bad idea to use any letter as a delimiting character, and you have to be careful with symbols as well. In the preceding example, the output is "Authorized Access Only, Press" because it's at that point where the second quote, the one that ends the banner, appears.

A better example of the same banner is banner slip-ppp ^Authorized Access Only, Press "Enter" and Then Log In to Proceed.^. The first carat starts the banner, and the router displays all text until it encounters the second carat. Symbols make better delimiting characters because most aren't used very often.

Be careful: That @ symbol is fine until you list an email address in the banner.

Link Quality Monitoring

Devices using PPP send keepalive packets to each other to ensure both sides stay awake. If one side stops receiving keepalives, it is assumed that something has happened to the circuit and the link is normally terminated. One exception to this rule is when link quality monitoring (LQM) is used. LQM uses link quality reports (LQRs) instead of keepalives. On one level, the purpose is the same: to show that both sides exist on an active link. But an LQR is also a report of how many packets and bytes have been sent out by the device in question. If a router is configured for LQM, then it is configured to shut down the link if the circuit degrades past a certain point.

If router A and router B are attached via a dialup link and each is configured with an LQM level of 75%, each wants to see 75% of the sent packets and bytes arrive at the router on the far side. If more than 25% of the traffic gets lost, the detecting side shuts down the circuit. It is assumed that the circuit would be reestablished through normal means and that there is a good chance that the new connection would not suffer from the problems the old one did.

You configure LQM in interface configuration mode with the ppp quality % command. Enter a numerical value for the LQM percentage and if that percentage is not maintained, the link is disconnected. Don't set the level too high or you risk never having a stable link due to disconnects, but setting it too low avoids fixing any problems you're having. This command normally requires monitoring and tweaking to find the best value.

LQM is defined in RFC 1989 but is typically used only on network hardware, as opposed to client PCs.