|
|
The PPP over Frame Relay feature allows a router to establish end-to-end Point-to-Point Protocol (PPP) sessions over Frame Relay. IP datagrams are transported over the PPP link using RFC 1973 compliant Frame Relay framing. This feature is useful for remote users running PPP to access their Frame Relay corporate networks as shown in Figure 1. Figure 2 shows a connectivity scenario using the Cisco 90i D4 channel card, which is capable of supporting Integrated Services Digital Network (ISDN) Digital Service Loop (DSL), PPP, or Frame Relay, which connects to an Internet Service Provider (ISP) or corporate network.

PPP over Frame Relay provides the following benefits:
data-link connection identifier (DLCI)--- A value that specifies a PVC or SVC in a Frame Relay network. In the basic Frame Relay specification, DLCIs are locally significant (connected devices might use different values to specify the same connection). In the LMI extended specification, DLCIs are globally significant (DLCIs specify individual end devices).
Integrated Services Digital Network (ISDN)---Communication protocols offered by telephone companies that permit telephone networks to carry data, voice, and other source traffic.
Link Control Protocol (LCP)---A protocol that establishes, configures, and tests data link connections used by PPP.
permanent virtual circuit (PVC)---Virtual circuit that is permanently established. PVCs save bandwidth associated with circuit establishment and tear down in situations where certain virtual circuits must exist all the time.
Point-to-Point Protocol (PPP)---A protocol that encapsulates network layer protocol information over point-to-point links. The RFC for PPP is RFC 1661.
virtual circuit (VC)---A logical circuit created to ensure reliable communication between two network devices. A virtual circuit can be either permanent (a PVC) or switched (an SVC). Virtual circuits are used in Frame Relay and X.25.
The following restrictions apply when using PPP over Frame Relay:
This feature is supported on these platforms:
Before you can configure PPP over Frame Relay, Frame Relay must be enabled on the router using the encapsulation frame-relay command.
This feature supports the RFC 1973.
No new MIBs are supported by this feature.
PPP over Frame Relay is compliant to the functionality and encapsulation specifications as outlined in RFC 1973. The frame format is shown in Figure 3.
A PPP connection is established over the Frame Relay permanent virtual circuit (PVC). The PPP session does not occur unless the associated Frame Relay PVC is in an "active" state. The Frame Relay VC can coexist with other circuits using different Frame Relay encapsulation methods, such as RFC 1490 and Cisco proprietary, over the same Frame Relay link. There can be multiple PPP-in-Frame Relay circuits existing on one Frame Relay link.
One PPP connection resides on one virtual access interface, which is internally created from a virtual template interface. A virtual access interface is cloned from a virtual template interface. The virtual access interfaces is coexistent with the creation of the Frame Relay circuit when the corresponding DLCI is configured. One virtual template interface, containing all the necessary PPP and network protocol information is shared by multiple virtual access interfaces. Hardware compression and fancy queuing algorithms, such as weighted fair queuing, custom queuing, and priority queuing, are not applied to virtual access interfaces. Once a Frame Relay circuit is established using PPP over Frame Relay, all incoming and outgoing packets on this circuit are under RFC 1973 PPP-in-Frame-Relay encapsulation compliance until this DLCI is removed from the configuration. Refer to the Cisco IOS Release 11.3 Wide Area Configuration Guide and Command Reference documents for information about Frame Relay configuration options.

The breakdown of the Frame Relay frame format components is listed in Table 1.
| Field | Description |
|---|---|
Flag | A single byte that indicates the beginning or end of a frame. |
Address | A two byte field that indicates the logical connection that maps to the physical channel; the DLCI. |
Control | A single byte that calls for transmission of user data. PPP over Frame Relay uses a value of 0X03, which indicates the frame is an unnumbered information (UI) frame. |
NLPID | Network layer protocol ID, which is a single byte that uniquely identifies a PPP packet to Frame Relay. |
PPP protocol | Identifies the PPP packet type. |
The only task required to implement PPP over Frame Relay is to configure the interface with the locally terminated PVC and the associated virtual template for PPP and IP, as described in the following section.
After you configure the Cisco router or access server for Frame Relay encapsulation, you must configure the physical interface with the PVC and apply a virtual template with PPP encapsulation to the DLCI that it applies to. To configure the physical interface that will carry the PPP session and link it to the appropriate virtual template interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Define the PVC and map it to the virtual template. | frame-relay interface-dlci dlci [ppp virtual-template-name-string] |
This section provides the following examples:
The following example configures a router as a data terminating equipment (DTE) device for PPP over Frame Relay. Subinterface 2.1 contains the necessary DLCI and virtual template information. The virtual template interface (interface virtual-template 1) contains the PPP information that is applied to the PPP session associated with DLCI 32 on serial subinterface 2.1. Refer to the Cisco IOS Release 11.3 Wide-Area Configuration Guide and Wide-Area Networking Command Reference for information about Frame Relay configuration options.
interface serial 2 no ip address encapsulation frame-relay frame-relay lmi-type ansi ! interface serial 2.1 point-to-point frame-relay interface-dlci 32 ppp virtual-template1 ! interface Virtual-Template1 ip unnumbered ethernet 0 ppp authentication chap pap
The following example configures a router to act as a data communications equipment (DCE) device. Typically, a router is configured for a DCE if connecting directly to another router or if connected to a 90i D4 channel unit, which is connected to a telco channel bank. The three commands required for this type of configuration are the frame-relay switching, frame-relay intf-type dce, and frame-relay route commands. In this configuration
frame-relay switching ! interface Serial2/0:0 no ip address encapsulation frame-relay IETF frame-relay lmi-type ansi frame-relay intf-type dce frame-relay route 31 interface Serial1/2 100 frame-relay interface-dlci 32 ppp Virtual-Template1 ! interface Serial2/0:0.2 point-to-point no ip address frame-relay interface-dlci 40 ppp Virtual-Template2 ! interface Virtual-Template1 ip unnumbered Ethernet0/0 peer default ip address pool default ppp authentication chap pap ! interface Virtual-Template2 ip address 100.1.1.2 255.255.255.0 ppp authentication chap pap
This section documents the frame-relay interface-dlci command, which is revised to add the ppp keyword and virtual-template-name-string argument for PPP over Frame Relay. Only the revised keywords, which are used to configure PPP over Frame Relay are included. The show interfaces and show frame-relay pvc commands are modified to display configuration, status, and statistical information as related to Frame Relay interfaces configured for PPP.
To define a specific PVC to a DLCI and apply a virtual template configuration to a PPP session, use this form of the frame-relay interface-dlci interface configuration command. To remove this assignment, use the no form of this command.
frame-relay interface-dlci dlci [ppp virtual-template-name-string]
dlci | DLCI number to be used on the specified subinterface. |
ppp | Enables the circuit to use the PPP in Frame Relay encapsulation. |
virtual-template-name-string | Specifies which virtual template interface to apply the PPP connection to. |
PPP-in-Frame Relay encapsulation type is disabled.
Interface and subinterface configuration
This command first appeared in Cisco IOS Release 10.0.
The ppp keyword and virtual-template-name-string argument first appeared in Cisco IOS Release 11.3 T.
The following example specifies DLCI 26 over subinterface serial 1.1 and assigns the characteristics under virtual-template 2 to this PPP connection:
interface serial1.1 point-to-point frame-relay interface-dlci 26 ppp virtual-template2
show frame-relay pvc
show interface
To display statistics about PVCs for Frame Relay interfaces, use the show frame-relay pvc EXEC command.
show frame-relay pvc [type number [dlci]]
type | (Optional) Interface type. |
number | (Optional) Interface number. |
dlci | (Optional) One of the specific DLCI numbers used on the interface. Statistics for the specified PVC display when a DLCI is also specified. |
EXEC
This command first appeared in Cisco IOS Release 10.0.
This command was modified to display statistics about virtual access interfaces used for PPP connections over Frame Relay in Cisco IOS Release 11.3 T.
Use this command to monitor the PPP link control protocol (LCP) state as being open with an "up" state, or closed with a "down" state.
The following is sample output from the show frame-relay pvc command that shows the PVC statistics for serial interface 5, slot 1 and DLCI 55 is up. Refer to the Cisco IOS Release 11.3 Wide-Area Configuration Guide and Wide-Area Networking Command Reference for field description information.
Router# show frame-relay pvc 55
PVC Statistics for interface Serial5/1 (Frame Relay DTE)
DLCI = 55, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial5/1.1
input pkts 9 output pkts 16 in bytes 154
out bytes 338 dropped pkts 6 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
pvc create time 00:35:11, last time pvc status changed 00:00:22
Bound to Virtual-Access1 (up, cloned from Virtual-Template5)
The debug frame-relay ppp command is added to debug PPP sessions over Frame Relay.
Use the debug frame-relay ppp EXEC command to display debugging information. To disable debugging output, use the no form of this command.
[no] debug frame-relay pppDisplays error messages for link states and LMI status changes for PPP over Frame Relay sessions.
To debug process-switched packets, use the debug frame-relay packet and/or debug ppp packet commands. To analyze the packets that have been sent on a Frame Relay interface, use the debug frame-relay packet command.
The debug frame-relay ppp command is generated from process level switching only and is not CPU intensive.
Figure 4 shows output from the debug frame-relay ppp command where the encapsulation failed for VC 100.
Router# debug frame-relay ppp FR-PPP: encaps failed for FR VC 100 on Serial0 down FR-PPP: input- Serial0 vc or va down, pak dropped
Figure 5 shows the output from the debug frame relay ppp and debug frame-relay packet commands. This example shows a virtual interface (virtual interface 1) successfully establishing a PPP connection over PPP.
Router# debug frame-relay ppp Router# debug frame-relay packet Vi1 LCP: O CONFREQ [Closed] id 1 len 10 Vi1 LCP: MagicNumber 0xE0638565 (0x0506E0638565) Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16 Vi1 PPP: I pkt type 0xC021, datagramsize 14 Vi1 LCP: I CONFACK [REQsent] id 1 len 10 Vi1 LCP: MagicNumber 0xE0638565 (0x0506E0638565) Vi1 PPP: I pkt type 0xC021, datagramsize 14 Vi1 LCP: I CONFREQ [ACKrcvd] id 6 len 10 Vi1 LCP: MagicNumber 0x000EAD99 (0x0506000EAD99) Vi1 LCP: O CONFACK [ACKrcvd] id 6 len 10 Vi1 LCP: MagicNumber 0x000EAD99 (0x0506000EAD99) Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16 Vi1 IPCP: O CONFREQ [Closed] id 1 len 10 Vi1 IPCP: Address 170.100.9.10 (0x0306AA64090A) Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16 Vi1 PPP: I pkt type 0x8021, datagramsize 14 Vi1 IPCP: I CONFREQ [REQsent] id 1 len 10 Vi1 IPCP: Address 170.100.9.20 (0x0306AA640914) Vi1 IPCP: O CONFACK [REQsent] id 1 len 10 Vi1 IPCP: Address 170.100.9.20 (0x0306AA640914) Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16 Vi1 PPP: I pkt type 0x8021, datagramsize 14 Vi1 IPCP: I CONFACK [ACKsent] id 1 len 10 Vi1 IPCP: Address 170.100.9.10 (0x0306AA64090A) Vi1 PPP: I pkt type 0xC021, datagramsize 16 Vi1 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x000EAD99 Vi1 LCP: O ECHOREP [Open] id 1 len 12 magic 0xE0638565 Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 18 Vi1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0xE0638565 Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 18 Vi1 LCP: echo_cnt 4, sent id 1, line up
Figure 6 shows the output for the debug frame-relay ppp and debug frame-relay packet commands which report a failed PPP over Frame Relay session. The problem is due to a challenge handshake authentication protocol (CHAP) failure.
Router# debug frame-relay ppp Router# debug frame-relay packet Vi1 LCP: O CONFREQ [Listen] id 24 len 10 Vi1 LCP: MagicNumber 0xE068EC78 (0x0506E068EC78) Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 16 Vi1 PPP: I pkt type 0xC021, datagramsize 19 Vi1 LCP: I CONFREQ [REQsent] id 18 len 15 Vi1 LCP: AuthProto CHAP (0x0305C22305) Vi1 LCP: MagicNumber 0x0014387E (0x05060014387E) Vi1 LCP: O CONFACK [REQsent] id 18 len 15 Vi1 LCP: AuthProto CHAP (0x0305C22305) Vi1 LCP: MagicNumber 0x0014387E (0x05060014387E) Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 21 Vi1 PPP: I pkt type 0xC021, datagramsize 14 Vi1 LCP: I CONFACK [ACKsent] id 24 len 10 Vi1 LCP: MagicNumber 0xE068EC78 (0x0506E068EC78) Vi1 PPP: I pkt type 0xC223, datagramsize 32 Vi1 CHAP: I CHALLENGE id 12 len 28 from "krishna" Vi1 LCP: O TERMREQ [Open] id 25 len 4 Serial2/1(o): dlci 201(0x3091), NLPID 0x3CF(PPP), datagramsize 10 Vi1 PPP: I pkt type 0xC021, datagramsize 8 Vi1 LCP: I TERMACK [TERMsent] id 25 len 4 Serial2/1(i): dlci 201(0x3091), pkt type 0x2000, datagramsize 303 %SYS-5-CONFIG_I: Configured from console by console Vi1 LCP: TIMEout: Time 0x199580 State Listen
![]()
![]()
![]()
![]()
![]()
![]()
![]()
Posted: Tue Sep 14 19:05:26 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.