PPP over Frame Relay

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

Compressing Frame Relay Data with Maps

Compressing Frame Relay Data with Maps

Problem

You want to configure your router to do Frame Relay compression with map statements.

Solution

The same Frame Relay compression options that we discussed for subinterfaces are also available with map statements. You can turn on FRF.9 compression by simply adding a few additional keywords to the frame-relay map statement as follows:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#description Frame Relay to branches
Central(config-if)#ip address 192.168.1.1 255.255.255.0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay map ip 192.168.1.10 101 payload-compression frf9 stac
Central(config-if)#exit
Central(config)#end
Central#

Or you can opt to use Cisco's proprietary packet-by-packet compression instead:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#description Frame Relay to branches
Central(config-if)#ip address 192.168.1.1 255.255.255.0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay map ip 192.168.1.10 101 payload-compression packet-by-packet
Central(config-if)#exit
Central(config)#end
Central#

The map configuration also supports TCP header compression:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#description Frame Relay to branches
Central(config-if)#ip address 192.168.1.1 255.255.255.0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay map ip 192.168.1.10 101 compress
Central(config-if)#exit
Central(config)#end
Central#

Discussion

As we discussed in Recipe 10.7, Cisco routers are able to compress the data payload of packets before sending them through Frame Relay circuits. This recipe simply shows how to do the same thing using map statements instead of subinterfaces. Note that the header compression example shown in Recipe 10.7 applies to the physical interface. So the configuration for header compression is identical, whether you are using maps or subinterfaces.

You can combine the payload compression option with the other options we discussed in Recipe 10.3 by specifying all of the required options on the same command line:

Central(config)#interface Serial0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay map ip 192.168.1.10 101 ietf broadcast payload-compression frf9 stac
Central(config-if)#end

Note that you can specify these keywords in any order, as long as the compression options are last. However, you cannot combine the different compression options with one another.

See Also

Compressing Frame Relay Data on a Subinterface

Compressing Frame Relay Data on a Subinterface

Problem

You want to configure your router to do Frame Relay compression on a subinterface.

Solution

Cisco offers several different types of compression with Frame Relay. You can opt to compress only the TCP headers as follows:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay ip tcp header-compression passive
Central(config-if)#exit
Central(config)#end
Central#

This command also works at the subinterface level:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0.1 point-to-point
Central(config-subif)#frame-relay ip tcp header-compression passive
Central(config-subif)#exit
Central(config)#end
Central#

There are also two different payload compression options. The first uses the FRF.9 Frame Relay compression standard:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0.1 point-to-point
Central(config-if)#frame-relay payload-compression frf9 stac
Central(config-if)#exit
Central(config)#end
Central#

And the second uses Cisco's proprietary packet-by-packet compression:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0.1 point-to-point
Central(config-if)#frame-relay payload-compression packet-by-packet
Central(config-if)#exit
Central(config)#end
Central#

Discussion

The nice thing about the first example in this recipe is that with the passive keyword, the router sends packets with compressed TCP headers only if it receives packets with compressed headers. So if you have a variety of remote sites, some of which have routers that don't support header compression, this can be a useful configuration option. You need to configure the device on at least one end without the passive keyword:

Branch1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Branch1(config)#interface Serial0
Branch1(config-if)#encapsulation frame-relay
Branch1(config-if)#frame-relay ip tcp header-compression
Branch1(config-if)#exit
Branch1(config)#end
Branch1#

Note that Cisco recommends shutting down the interface before changing this feature. It is not dangerous, but with some routers you need to reset the interface to ensure that it picks up the new configuration. The cleanest way to do this is to shut it down before making the change, and then bring it back up when you are done.

For the payload compression examples, it is critical to configure the same compression on both ends. This is a subinterface level command, so you can configure each PVC to use compression or not, according to what the device on the other end supports.

In both cases, by default the router will do the compression in a Compression Service Adapter (CSA), if one exists. If the router doesn't have a CSA, then it will use a Versatile Interface Processor (VIP-2) card instead. And, if it doesn't have either of these hardware options, then it will do the compression in software using the router's CPU. Some external Frame Relay Access Devices (FRAD) also include FRF.9 compression, but it is unlikely that you will find a FRAD the supports Cisco's packet-by-packet compression.

The FRF.9 compression command can also take several different options that allow you to force different hardware options. For example, you can force the router to use a particular CSA as follows:

Central(config-if)#frame-relay payload-compression frf9 stac csa 1

Or, if you want to force the router to do the compression in its CPU, you can use the software keyword:

Central(config-if)#frame-relay payload-compression frf9 stac software

The stac keyword in all of these FRF.9 examples specifies the standard Stacker algorithm. In fact, this is the only option available for FRF.9 compression.

In general, we recommend using FRF.9 rather than packet-by-packet compression because it is an open standard, while packet-by-packet will only work with Cisco equipment. There is no noticeable performance difference between the two compression types. Cisco introduced its own packet-by-packet compression method before the FRF.9 standard was available, and continues to support it primarily for backward compatibility.

You can see statistics on the header compression with the following command:

Router#show frame-relay ip tcp header-compression
DLCI 100 Link/Destination info: point-to-point dlci
Interface Serial1:
Rcvd: 220 total, 219 compressed, 0 errors
0 dropped, 0 buffer copies, 0 buffer failures
Sent: 482 total, 481 compressed,
17001 bytes saved, 229749 bytes sent
1.7 efficiency improvement factor
Connect: 16 rx slots, 16 tx slots, 1 long searches, 1 misses
99% hit ratio, five minute miss rate 0 misses/sec, 0 max

Router#

See Also

Simulating a Frame Relay Cloud

Simulating a Frame Relay Cloud

Problem

You want to use a router to simulate a Frame Relay cloud in the lab.

Solution

A Cisco router can function as a Frame Relay switch. This is mostly useful when you are trying to simulate a Frame Relay cloud in a lab to test your router configurations:

Cloud#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Cloud(config)#frame-relay switching
Cloud(config)#interface Serial0
Cloud(config-if)#description Frame-relay connection to Central - DLCI 50
Cloud(config-if)#encapsulation frame-relay
Cloud(config-if)#clock rate 125000
Cloud(config-if)#frame-relay lmi-type cisco
Cloud(config-if)#frame-relay intf-type dce
Cloud(config-if)#frame-relay route 101 interface Serial1 50
Cloud(config-if)#frame-relay route 102 interface Serial2 50
Cloud(config-if)#exit
Cloud(config)#interface Serial1
Cloud(config-if)#description Frame-relay connection to Branch1 - DLCI 101
Cloud(config-if)#encapsulation frame-relay
Cloud(config-if)#clock rate 125000
Cloud(config-if)#frame-relay lmi-type cisco
Cloud(config-if)#frame-relay intf-type dce
Cloud(config-if)#frame-relay route 50 interface Serial0 101
Cloud(config-if)#exit
Cloud(config)#interface Serial2
Cloud(config-if)#description Frame-relay connection to Branch2 - DLCI 102
Cloud(config-if)#encapsulation frame-relay
Cloud(config-if)#clock rate 125000
Cloud(config-if)#frame-relay lmi-type cisco
Cloud(config-if)#frame-relay intf-type dce
Cloud(config-if)#frame-relay route 50 interface Serial0 102
Cloud(config-if)#exit
Cloud(config)#end
Cloud#

Discussion

This type of configuration can be extremely useful when you need to test basic Frame Relay functionality in a lab, and you don't happen to have a real Frame Relay switch available. However it's extremely important to remember that a router is not a Frame Relay switch, and it doesn't emulate all of the functionality of the switch. In particular, the router will not support switching of SVCs. Also, although Cisco has introduced the frame-relay congestion-management command, you can still only generate FECN and BECN notifications on a limited set of router hardware and software configurations. So if you are using this type of configuration to test adaptive traffic shaping or any other feature that relies on BECN notifications, it will not give you a reliable simulation of a real cloud.

To use the router as a Frame Relay switch, you must first enable the frame-relay switching option. Then you must configure each interface as DCE with the frame-relay intf-type command, and supply a clock signal with the clock rate command. Cisco routers will not allow you to configure this command unless you use a DCE cable on the interface. And, finally, you need to map the PVCs. In this case, we have configured a central hub router and two branch routers, as in Recipe 10.1. The central router can see both of the branch routers, one with DLCI 101, and the other with DLCI 102. Both of the branch routers see the central router with DLCI 50. The two branch routers cannot see one another directly.

In this example, all three of the Frame Relay connections are to DTE devices such as routers, so all of the interfaces are configured for DCE signaling. However, you can also configure connections to other switching devices. This might be useful if you were interested in constructing your own private Frame Relay cloud. In this case, you would still need to designate one of the devices to be the physical DCE and supply the clock. Then you would configure the interface type on both devices as nni:

Cloud#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Cloud(config)#interface Serial2
Cloud(config-if)#description Frame-relay connection to next switch
Cloud(config-if)#encapsulation frame-relay
Cloud(config-if)#clock rate 125000
Cloud(config-if)#frame-relay lmi-type cisco
Cloud(config-if)#frame-relay intf-type nni
Cloud(config-if)#exit
Cloud(config)#end
Cloud#

You would also use frame-relay route statements to configure one or more PVCs to be served by this neighboring switch. The PVC routing commands in this case are identical to those for DCE interfaces.

You can look at the routing of the virtual circuits on a router that is configured for Frame Relay switching with the show frame-relay route command:

Cloud#show frame-relay route
Input Intf Input Dlci Output Intf Output Dlci Status
Serial0 101 Serial1 50 active
Serial0 102 Serial2 50 inactive
Serial0 103 Serial3 50 inactive
Serial1 50 Serial0 101 active
Serial1 102 Serial2 101 inactive
Serial1 103 Serial3 101 inactive
Serial2 50 Serial0 102 inactive
Serial2 101 Serial1 102 inactive
Serial2 103 Serial3 102 inactive
Serial3 50 Serial0 103 inactive
Serial3 101 Serial1 103 inactive
Serial3 102 Serial2 103 inactive
Cloud#

This output shows, for example, that traffic received on DLCI number 101 through interface Serial0 is forwarded to DLCI number 50 on Serial1. And a few lines lower, you can see the reverse path as well. The status for both of these lines is active, so this virtual circuit is working properly.

Another extremely useful option for creating private Frame Relay networks is the ability to specify a GRE tunnel as the destination of a Frame Relay route command:

Cloud(config)#interface Loopback1
Cloud(config-if)#ip address 192.168.2.1 255.255.255.255
Cloud(config-if)#exit
Cloud(config)#interface Tunnel1
Cloud(config-if)#ip address 192.168.1.5 255.255.255.252
Cloud(config-if)#tunnel source 192.168.2.1
Cloud(config-if)#tunnel destination 192.168.2.2
Cloud(config-if)#exit
Cloud(config)#interface Serial1
Cloud(config-if)#frame-relay route 201 interface Tunnel1 101
Cloud(config-if)#exit

In this case, we have created a GRE tunnel interface called Tunnel1, which terminates on another router somewhere else in the network. Then we route Frame Relay DLCI 201 to this tunnel interface. On the other router, you would need to create a similar GRE tunnel interface. Then, on a Serial interface on that other router, you would put a matching frame-relay route statement:

Cloud9(config)#interface Loopback1
Cloud9(config-if)#ip address 192.168.2.2 255.255.255.255
Cloud9(config-if)#exit
Cloud9(config)#interface Tunnel1
Cloud9(config-if)#ip address 192.168.1.6 255.255.255.252
Cloud9(config-if)#tunnel source 192.168.2.2
Cloud9(config-if)#tunnel destination 192.168.2.1
Cloud9(config-if)#exit
Cloud9(config)#interface Serial1
Cloud9(config-if)#frame-relay route 301 interface Tunnel1 101
Cloud9(config-if)#exit

This is an extremely efficient way of creating a virtual Frame Relay cloud layered on top of an existing IP network.

See Also

Configuring Frame Relay SVCs

Configuring Frame Relay SVCs

Problem

You want to configure the router to support Frame Relay SVCs.

Solution

Frame Relay SVCs are not extremely common, but some carrier networks support them. The advantage to using SVCs is that the router can add and remove inactive virtual circuits dynamically in a lightly used network. Because of the extra complexity and the management problems associated with dynamic network topologies, most network engineers will use this feature only if it offers significant cost advantages.

You can configure SVCs to use subinterfaces, as in Recipe 10.1:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay lmi-type q933a
Central(config-if)#frame-relay svc
Central(config-if)#exit
Central(config)#interface Serial0.10 point-to-point
Central(config-subif)#ip address 192.168.1.129 255.255.255.252
Central(config-subif)#frame-relay interface-dlci 100
Central(config-subif)#map-group SVCMAP
Central(config-fr-dlci)#class SVCclass
Central(config-fr-dlci)#exit
Central(config-subif)# exit
Central(config)#map-list SVCMAP source-addr X121 1234 dest-addr X121 4321
Central(config-map-list)#ip 192.168.55.6 class SVCclass ietf
Central(config-map-list)#exit
Central(config)#map-class frame-relay SVCclass
Central(config-map-class)#frame-relay traffic-rate 56000 128000
Central(config-map-class)#exit
Central(config)#end
Central#

And you can also configure Frame Relay SVCs without subinterfaces, similar to the map configuration for PVCs, which we discussed in Recipe 10.3:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#ip address 192.168.55.1 255.255.255.0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay lmi-type q933a
Central(config-if)#frame-relay svc
Central(config-if)#map-group SVCMAP
Central(config-if)#frame-relay interface-dlci 50
Central(config-fr-dlci)#class SVCclass
Central(config-fr-dlci)#exit
Central(config-if)#exit
Central(config)#map-list SVCMAP source-addr X121 1234 dest-addr X121 4321
Central(config-map-list)#ip 192.168.55.6 class SVCclass ietf
Central(config-map-list)#exit
Central(config)#map-class frame-relay SVCclass
Central(config-map-class)#frame-relay traffic-rate 56000 128000
Central(config-map-class)#exit
Central(config)#end
Central#

Discussion

You can enable Frame Relay SVCs on an interface simply by including the frame-relay svc command. This is required whether you use maps or subinterfaces:

Central(config-if)#frame-relay svc

However, this doesn't tell the network how to actually build the virtual circuits. To do that, you need to define a map-list and a map-class as follows:

Central(config)#map-list SVCMAP source-addr X121 1234 dest-addr X121 4321
Central(config-map-list)#ip 192.168.55.6 class SVCclass ietf
Central(config-map-list)#exit
Central(config)#map-class frame-relay SVCclass
Central(config-map-class)#frame-relay traffic-rate 56000 128000
Central(config-map-class)#end

The map-list associates an IP address with either X.121 or E.164 source and destination addresses. In the example, we have used X.121 addresses, but if your carrier's network uses E.164 addressing instead, you would simply replace the keyword X121 with E164, and specify the appropriate E.164 addresses:

Central(config)#map-list  SVCMAP  source-addr E164  1234  dest-addr E164  4321 

The map-class command tells the router about the actual SVC parameters such as CIR and EIR. In this example, we want the network to create SVCs with CIR of 56000 and total burst rate (CIR+EIR) of 128000 bits per second.

By default the router will keep an idle SVC for 120 seconds before tearing it down. You can change this period using the frame-relay idle-timer command. There are three ways to specify an idle time. You can have the router tear down an idle PVC if there is no traffic in either direction for a specified time period like this:

Central(config)#map-class frame-relay  SVCclass 
Central(config-map-class)#frame-relay idle-timer 60

Or you can specify the inbound and outbound directions separately:

Central(config)#map-class frame-relay SVCclass
Central(config-map-class)#frame-relay idle-timer in 20
Central(config-map-class)#frame-relay idle-timer out 30

In each case, the argument is the time period specified in seconds.

You can view the SVC map information on a router with the show frame-relay svc command:

Central#show frame-relay svc maplist SVCMAP
Map List : SVCMAP
Address : Source X121 1234 <----> Destination X121 4321

Protocol : ip 192.168.55.6 Encapsulation : IETF

FMIF (Frame Mode Information Field Size), bytes
Configured : In = 1500, Out = 1500

CIR (Committed Information Rate), bits/sec
Configured : In = 56000, Out = 56000,

Minimum Acceptable CIR, bits/sec
Configured : In = 56000, Out = 56000,

Bc (Committed Burst Size), bits
Configured : In = 56000, Out = 56000,

Be (Excess Burst Size), bits
Configured : In = 56000, Out = 56000,

Central#

It is useful to remember that whether you use maps or subinterfaces, you can combine SVCs and PVCs on the same physical interface.

See Also