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 CallbackCallback 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:
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.
Compressed PPPYou can configure a router interface to compress the data that passes through it. PPP supports four main types of compression:
The following list provides examples of when you use each method, and Table 4.5 illustrates the commands used:
Multilink PPPMultilink 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 BannersWith 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.
Link Quality MonitoringDevices 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. |