Frame Relay

Frame Relay is still one of the most popular WAN services deployed over the past decade, and there’s a good reason for this cost. And it’s a rare network design or designer that has the privilege to ignore that all-important cost factor!

By default, Frame Relay is classified as a non-broadcast multi-access (NBMA) network, meaning it doesn’t send any broadcasts like RIP updates across the network. No worries I’m not going leave you hanging. We’ll get into this more soon.

Frame Relay has at its roots a technology called X.25, and it essentially incorporates the components of X.25 that are still relevant to today’s reliable and relatively “clean” telecommunications networks while leaving out the no-longer-needed error-correction components.

It’s substantially more complex than the simple leased-line networks you learned about when I discussed the HDLC and PPP protocols. The leased-line networks are easy to conceptualize but not so much when it comes to Frame Relay. It can be significantly more complex and versatile, which is why it’s often represented as a “cloud” in networking graphics. I’ll get to that in a minute—for right now, I’m going to introduce Frame Relay in concept and show you how it differs from simpler leased-line technologies.

Along with your introduction to this technology, you’ll get a virtual dictionary of all the new terminology you’ll need to solidly grasp the basics of Frame Relay. After that, I’ll guide you through some simple Frame Relay implementations.

PPPoE Configuration

If you have a router with an interface that supports PPPoE and the router is connected to a DSL modem, you can configure the router to be a PPPoE client—well, assuming your ISP has provided you with the authentication information, that is.

Let’s take a look at configuring a PPPoE client on a router. Here’s what it looks like under the physical interface:

R1(config)#int f0/0
R1(config-if)#p?
pppoe pppoe-client priority-group
R1(config-if)#pppoe ?
enable Enable pppoe
max-sessions Maximum PPPOE sessions
R1(config-if)#pppoe enable ?
group attach a BBA group
<cr>
R1(config-if)#pppoe enable group ?
WORD BBA Group name
global Attach global PPPoE group
R1(config-if)#pppoe enable group global
R1(config-if)#pppoe-client dial-pool-number ?
<1-255> Dialer pool number
R1(config-if)#pppoe-client dial-pool-number 1

!
interface FastEthernet4
description $ETH-WAN$
no ip address
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
!

After all that, there really are only two commands needed under the physical interface the pppoe enable command and the pppoe-client command. And both of them reference the logical interface we haven’t created yet.

In order to add a PPPoE connection to your router, you need to also create a dialer interface.

This is a logical interface, and under it, I’m going to add the ip address negotiated command so a DHCP address can be received and configured on the interface. And by the way, if you’re using private IP addresses between the DSL modem and your router, you can easily add a static IP address on this interface. Take a look:

!
interface Dialer0
ip address negotiated
ip mtu 1452
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname Todd
ppp chap password 0 lammle
!

Take special notice of how the logical interface associates itself to the physical interface with both the dial pool 1 command and the dialer-group 1 command.

Last, under the dialer interface, the PPP authentication is set using the ppp authentication and ppp chap commands. Using the CLI, I provided these commands at global configuration mode, but in this setup, I’ll configure the command directly under the logical interface instead.

Although this is a pretty simple configuration, it works really well! Still, I’ll show you how to configure PPPoE using the SDM in a bit.

Mismatched IP Addresses

A tricky problem to spot is if you have HDLC or PPP configured on your serial interface but your IP addresses are wrong. Things seem to be just fine because the interfaces will show that they are up. Take a look at Figure 1 and see if you can see what I mean—the two routers are connected with different subnets—router Pod1R1 with 10.0.1.1/24 and router Pod1R2 with 10.2.1.2/24.

FIGURE 1 Mismatched IP addresses

This will never work. But as I said, take a look at the output:

Pod1R1#sh int s0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Internet address is 10.0.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
LCP Open
Open: IPCP, CDPCP

See that? The IP addresses between the routers are wrong but the link looks like it’s working fine. This is because PPP, like HDLC and Frame Relay, is a layer 2 WAN encapsulation and doesn’t care about IP addresses at all. So yes, the link is up, but you can’t use IP across this link since it’s misconfigured.

To find and fix this problem, you can use the show running-config or the show interfaces command on each router, or you can use what you learned in Chapter 5—the show cdp neighbors detail command:

Pod1R1#sh cdp neighbors detail
-------------------------
Device ID: Pod1R2
Entry address(es):
IP address: 10.2.1.2

You can view and verify the directly connected neighbor’s IP address and then solve your problem.

Mismatched WAN Encapsulations

If you have a point-to-point link but the encapsulations aren’t the same, the link will never
come up. Figure 1 shows one link with PPP and one with HDLC.

FIGURE 1 Mismatched WAN encapsulations

Look at router Pod1R1 in this output:

Pod1R1#sh int s0/0
Serial0/0 is up, line protocol is down
Hardware is PowerQUICC Serial
Internet address is 10.0.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 254/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
LCP REQsent
Closed: IPCP, CDPCP

The serial interface is down and LCP is sending requests but will never receive any responses because router Pod1R2 is using the HDLC encapsulation. To fix this problem, you would have to go to router Pod1R2 and configure the PPP encapsulation on the serial interface. One more thing even though the usernames are configured and they’re wrong, it doesn’t matter because the command ppp authentication chap isn’t used under the serial interface configuration and the username command isn’t relevant in this example.

Debugging PPP Authentication

To display the CHAP authentication process as it occurs between two routers in the network, just use the command debug ppp authentication.

If your PPP encapsulation and authentication are set up correctly on both routers, and your usernames and passwords are all good, then the debug ppp authentication command will display an output that looks like this:

d16h: Se0/0 PPP: Using default call direction
1d16h: Se0/0 PPP: Treating connection as a dedicated line

1d16h: Se0/0 CHAP: O CHALLENGE id 219 len 27 from "Pod1R1"
1d16h: Se0/0 CHAP: I CHALLENGE id 208 len 27 from "Pod1R2"
1d16h: Se0/0 CHAP: O RESPONSE id 208 len 27 from "Pod1R1"
1d16h: Se0/0 CHAP: I RESPONSE id 219 len 27 from "Pod1R2"
1d16h: Se0/0 CHAP: O SUCCESS id 219 len 4
1d16h: Se0/0 CHAP: I SUCCESS id 208 len 4

But if you have the username wrong, as we did previously in the PPP authentication failure example back in Figure 1, the output would look something like this:

1d16h: Se0/0 PPP: Using default call direction
1d16h: Se0/0 PPP: Treating connection as a dedicated line
1d16h: %SYS-5-CONFIG_I: Configured from console by console
1d16h: Se0/0 CHAP: O CHALLENGE id 220 len 27 from "Pod1R1"
1d16h: Se0/0 CHAP: I CHALLENGE id 209 len 27 from "Pod1R2"
1d16h: Se0/0 CHAP: O RESPONSE id 209 len 27 from "Pod1R1"
1d16h: Se0/0 CHAP: I RESPONSE id 220 len 27 from "Pod1R2"
1d16h: Se0/0 CHAP: O FAILURE id 220 len 25 msg is "MD/DES compare failed"

PPP with CHAP authentication is a three-way authentication, and if the username and passwords are not configured exactly the way they should be, then the authentication will fail and the link will be down.

Verifying PPP Encapsulation

Okay—now that PPP encapsulation is enabled, let me show you how to verify that it’s up and running. First, let’s take a look at a figure of a sample network. Figure 1 shows two routers connected with either a point-to-point serial or ISDN connection.

FIGURE 1 PPP authentication example

You can start verifying the configuration with the show interface command:

Pod1R1#sh int s0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Internet address is 10.0.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 239/255, txload 1/255, rxload 1/255
Encapsulation PPP
loopback not set
Keepalive set (10 sec)
LCP Open
Open: IPCP, CDPCP
[output cut]

Notice that the sixth line lists encapsulation as PPP and the eighth line shows that the LCP is open. This means that it has negotiated the session establishment and all is good! The ninth line tells us that NCP is listening for the protocols IP and CDP.

But what will you see if everything isn’t perfect? I’m going to type in the configuration shown in Figure 1.1 and find out.

FIGURE 1.1 Failed PPP authentication

Okay—what’s wrong here? Take a look at the usernames and passwords. Do you see the problem now? That’s right, the C is capitalized on the Pod1R2 username command found in the configuration of router Pod1R1. This is wrong because the usernames and passwords are case sensitive, remember? Let’s take a look at the show interface command and see what happens:

Pod1R1#sh int s0/0
Serial0/0 is up, line protocol is down
Hardware is PowerQUICC Serial
Internet address is 10.0.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 243/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
LCP Closed
Closed: IPCP, CDPCP

First, notice in the first line of output that Serial0/0 is up, line protocol is down.This is because there are no keepalives coming from the remote router. Next, notice that the LCP is closed because the authentication failed.

Configuring PPP Authentication

After you configure your serial interface to support PPP encapsulation, you can configure authentication using PPP between routers. First, you need to set the hostname of the router, if it’s not already. Then you set the username and password for the remote router that will be connecting to your router:

Here’s an example:

Router#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#hostname RouterA
RouterA(config)#username RouterB password cisco

When using the hostname command, remember that the username is the hostname of the remote router that’s connecting to your router. And it’s case sensitive too. Also, the password on both routers must be the same. It’s a plain-text password that you can see with a show run command; you can encrypt the password by using the command service password-encryption. You must have a username and password configured for each remote system you plan to connect to. The remote routers must also be configured with usernames and passwords.

Now, after you’ve set the hostname, usernames, and passwords, choose the authentication type, either CHAP or PAP:

RouterA#config t
Enter configuration commands, one per line. End with CNTL/Z.
RouterA(config)#int s0
RouterA(config-if)#ppp authentication chap pap
RouterA(config-if)#^Z
RouterA#

If both methods are configured on the same line, as shown here, then only the first method will be used during link negotiation—the second acts as a backup just in case the first method fails.

Configuring PPP on Cisco Routers

Configuring PPP encapsulation on an interface is really pretty straightforward. To configure it from the CLI, follow these simple router commands:

Router#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int s0
Router(config-if)#encapsulation ppp
Router(config-if)#^Z
Router#

Of course, PPP encapsulation has to be enabled on both interfaces connected to a serial line in order to work, and there are several additional configuration options available to you via the help command.

PPP Authentication Methods

There are two methods of authentication that can be used with PPP links:

Password Authentication Protocol (PAP) The Password Authentication Protocol (PAP) is the less secure of the two methods. Passwords are sent in clear text, and PAP is only performed upon the initial link establishment. When the PPP link is first established, the remote node sends the username and password back to the originating router until authentication is acknowledged. Not exactly Fort Knox!

Challenge Handshake Authentication Protocol (CHAP) The Challenge Handshake Authentication Protocol (CHAP) is used at the initial startup of a link and at periodic checkups on the link to make sure the router is still communicating with the same host.

After PPP finishes its initial link-establishment phase, the local router sends a challenge request to the remote device. The remote device sends a value calculated using a one-way hash function called MD5. The local router checks this hash value to make sure it matches. If the values don’t match, the link is immediately terminated.

PPP Session Establishment

When PPP connections are started, the links go through three phases of session establishment,
as shown in Figure 1

FIGURE 1 PPP session establishment

Link-establishment phase LCP packets are sent by each PPP device to configure and test the
link. These packets contain a field called the Configuration Option that allows each device to
see the size of the data, compression, and authentication. If no Configuration Option field is
present, then the default configurations will be used.

Authentication phase If required, either CHAP or PAP can be used to authenticate a link.
Authentication takes place before Network layer protocol information is read. And it’s possible
that link-quality determination will occur simultaneously.

Network layer protocol phase PPP uses the Network Control Protocol (NCP) to allow multiple
Network layer protocols to be encapsulated and sent over a PPP data link. Each Network layer
protocol (e.g., IP, IPX, AppleTalk, which are routed protocols) establishes a service with NCP.

Link Control Protocol (LCP) Configuration Options

Link Control Protocol (LCP) offers different PPP encapsulation options, including the following:

Authentication This option tells the calling side of the link to send information that can identify the user. The two methods are PAP and CHAP.

Compression This is used to increase the throughput of PPP connections by compressing the data or payload prior to transmission. PPP decompresses the data frame on the receiving end.

Error detection PPP uses Quality and Magic Number options to ensure a reliable, loop-free data link.

Multilink Starting with IOS version 11.1, multilink is supported on PPP links with Cisco routers. This option makes several separate physical paths appear to be one logical path at layer 3. For example, two T1s running multilink PPP would show up as a single 3Mbps path to a layer 3 routing protocol.

PPP callback PPP can be configured to call back after successful authentication. PPP callback
can be a good thing for you because you can keep track of usage based upon access charges, for accounting records, and a bunch of other reasons. With callback enabled, a calling router (client) will contact a remote router (server) and authenticate as I described earlier. (Know that both routers have to be configured for the callback feature for this to work.) Once authentication is completed, the remote router will terminate the connection and then re-initiate a connection to the calling router from the remote router.