PPP over Frame Relay

Problem

You want to run use PPP encapsulation over a Frame Relay PVC.

Solution

To configure PPP over Frame Relay, you need to associate the DLCI with a Virtual Template, which will carry the Layer 3 information. Because PPP fundamentally involves a single connection between two devices, it is most natural to use this feature on point-to-point subinterfaces:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface Loopback1
Router1(config-if)#ip address 10.1.200.5 255.255.255.252
Router1(config-if)#exit
Router1(config)#interface Virtual-Template1
Router1(config-if)#ip unnumbered Loopback1
Router1(config-if)#encapsulation ppp
Router1(config-if)#exit
Router1(config)#interface Serial0
Router1(config-if)#no ip address
Router1(config-if)#encapsulation frame-relay
Router1(config-if)#exit
Router1(config)#interface Serial0.1 point-to-point
Router1(config-subif)#frame-relay interface-dlci 104 ppp Virtual-Template1
Router1(config-fr-dlci)#exit
Router1(config-subif)#exit
Router1(config)#end
Router1#

You can also use this feature directly on a physical interface:

Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#interface Loopback1
Router2(config-if)#ip address 10.1.200.6 255.255.255.252
Router2(config-if)#exit
Router2(config)#interface Virtual-Template1
Router2(config-if)#ip unnumbered Loopback1
Router2(config-if)#encapsulation ppp
Router2(config-if)#exit
Router2(config)#interface Serial0/0
Router2(config-if)#no ip address
Router2(config-if)#encapsulation frame-relay
Router2(config-if)#frame-relay interface-dlci 105 ppp Virtual-Template1
Router2(config-fr-dlci)#exit
Router2(config-if)#exit
Router2(config)#end
Router2#

 

Discussion

RFC 1973 defines the standard for running the Point-to-Point Protocol (PPP) standard over a Frame Relay PVC. Normally you wouldn't want to do this, as the default Frame Relay encapsulation standards discussed in Recipe 10.1 are more than adequate for most situations. However, a PVC that is delivered via a Frame Relay circuit at one location may be converted to an ATM VC inside the carrier's cloud, and could ultimately arrive at another location as a DSL circuit delivered through an Ethernet interface. The only Layer 2 frame format that supports all of these standards is PPP. It is for these types of situations that RFC 1973 was developed.

The router uses Virtual-Template interfaces in an interesting and unusual way. When trying to bring up the PPP link, the router will first clone the Virtual-Template interface to create a Virtual-Access interface. You can see all of these interfaces with the show ip interface brief command:

Router2#show ip interface brief
Interface IP-Address OK? Method Status Prot
ocol
FastEthernet0/0 141.200.5.5 YES NVRAM up up
Serial0/0 unassigned YES manual up up
BRI0/0 unassigned YES NVRAM administratively down down
BRI0/0:1 unassigned YES unset administratively down down
BRI0/0:2 unassigned YES unset administratively down down
Virtual-Access1 10.1.200.6 YES TFTP up up
Virtual-Template1 10.1.200.6 YES TFTP down down
Loopback1 10.1.200.6 YES manual up up
Router2#

You can see here that the Frame Relay interface or subinterface (interface, in this case) has no IP address. The Layer 3 information representing this Frame Relay PVC is held on the interface Virtual-Access1, which the router dynamically created from the Virtual-Template1 interface:

Router2#show interfaces Virtual-Access1
Virtual-Access1 is up, line protocol is up 
 Hardware is Virtual Access interface
 Interface is unnumbered. Using address of Loopback1 (10.1.200.6)
 MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec, 
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation PPP, loopback not set
 Keepalive set (10 sec)
 DTR is pulsed for 5 seconds on reset
 LCP Open
 Open: IPCP
 Bound to Serial0/0 DLCI 105, Cloned from Virtual-Template1
 Last input 00:00:01, output never, output hang never
 Last clearing of "show interface" counters 00:24:53
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue: 0/40 (size/max)
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 370 packets input, 7372 bytes, 0 no buffer
 Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
 401 packets output, 7240 bytes, 0 underruns
 0 output errors, 0 collisions, 0 interface resets
 0 output buffer failures, 0 output buffers swapped out
 0 carrier transitions
Router2#

One of the side benefits of using PPP encapsulation on a Frame Relay PVC like this is you can enforce an extra measure of security by requiring PPP CHAP authentication:

Router1(config)#username Router2 password cookbook
Router1(config)#interface Virtual-Template1
Router1(config-if)#ip unnumbered Loopback1
Router1(config-if)#encapsulation ppp
Router1(config-if)#ppp authentication chap

Naturally, the authentication method and password must match on the other router:

Router2(config)#username Router1 password cookbook
Router2(config)#interface Virtual-Template1
Router2(config-if)#ip unnumbered Loopback1
Router2(config-if)#encapsulation ppp
Router2(config-if)#ppp authentication chap

When you do this, the Virtual-Access interfaces remain in a down state until the routers pass PPP authentication. Since the IP address information is not exchanged until the PPP session is established, it is not possible to use Inverse ARP to deduce a good IP address and insert a rogue router into the network. We note, however, that this type of attack is only possible if you don't control the physical security of the router at the remote site.

Finally, we note in passing that we always create a Loopback interface to carry the IP addresses for Virtual-Template interfaces. In this particular example, because we must use separate IP addressing on every PVC, this is not actually necessary. We could have assigned the IP address directly to the Virtual-Template interface. However, we do it this way because Virtual-Template interfaces are also used for other purposes such as dial backup and PPP over ATM. In some cases, you may want to have more than one type of Virtual-Template configuration, but with the same IP addressing. So because of these situations, it is a good general practice to put the IP address on a Loopback interface, as we have done here.

See Also

RFC 1973; Recipe 10.1