The Point-to-Point Protocol (PPP) specifies a standard method for transporting different network layer or routed protocols, such as IP, IPX, and SNA, across a physical point-to-point link. This chapter highlights the Cisco PPP over Frame Relay feature, a Cisco Frame Relay solution that allows an end-to-end PPP session to be established over a Frame Relay permanent virtual circuit (PVC). IP traffic can be transported over the PPP link using RFC 1973 compliant Frame Relay framing and encapsulation specifications. The RFC 1973 document is available at http://www.faqs.org/rfcs/rfc1973.html. This chapter features examples that use IOS configuration and debug commands for monitoring PPP over Frame Relay sessions.
The topics and questions that this chapter addresses include the following:
Overview of PPP over Frame Relay
PPP over Frame Relay frame format
Configuring PPP over Frame Relay on a Cisco router
Monitoring and maintaining PPP over Frame Relay configurations on a Cisco router
After completing this chapter, readers will understand how PPP over Frame Relay works and how it is related to PPP as defined by RFC 1661. Readers will become familiar with the tasks and Cisco IOS commands required to configure PPP over Frame Relay on a Cisco router. Furthermore, readers will learn the Cisco IOS show and debug commands for monitoring and maintaining PPP over Frame Relay configurations on a Cisco router.
The Request for Comments (RFC) document number 1661 (known as RFC 1661) outlines PPP as an industry standard protocol that supports router-to-router or host-to-network connections between point-to-point links. As a successor to the Serial Line Internet Protocol (SLIP), PPP was designed to work with several different network layer protocols, such as IP, IPX, and SNA. Unlike PPP, the legacy SLIP only supports IP.
PPP has added security features, such as Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP), that provide a secured connection via authentication of peers during the establishment phase of the link. To transport the different network layer protocols over PPP, PPP uses the Link Control Protocol (LCP) and Network Control Protocol (NCP) groups of protocols to manage the specified needs of each supported network layer protocol.
PPP is vast, and providing a comprehensive technical coverage of PPP is out of the scope of this book. RFC 1661 outlines the original PPP specifications. The RFC 1661 document is available at http://www.faqs.org/rfcs/rfc1661.html.
With the emergence of fast and affordable access technology such as xDSL, it is important to provide PPP support over Frame Relay virtual circuits (VCs) with PPP in Frame Relay encapsulation. The PPP over Frame Relay feature is required to allow an end-to-end PPP connection to be established over a Frame Relay network. This feature enables remote users using PPP protocol to access their corporate network over a Frame Relay connection.
RFC 1661 defines the standard PPP specifications, whereas a separate RFC document, RFC 1973, describes a standard method for transporting PPP over a Frame Relay VC connection. Cisco's implementation of the PPP over Frame Relay feature is based on the RFC 1973 specifications. A Cisco router supporting the PPP over Frame Relay feature is able to establish an end-to-end PPP session over an active Frame Relay PVC.
NOTE
Note that Cisco's implementation of RFC 1973 to support PPP over Frame Relay is essential to its support of other PPP-related advanced Frame Relay features, such as Link Fragmentation and Interleaving (LFI). For example, LFI depends on the setup of PPP multilink bundles. LFI is discussed and explained in Chapter 20, “Link Fragmentation and Interleaving (LFI) for Frame Relay Virtual Circuits.”
In 1998, Cisco developed the PPP over Frame Relay feature to supplement its ISDN Digital Subscriber Line (IDSL) solutions for the emerging xDSL (any DSL) market. DSL is a key access technology that offers affordable and high-speed “last mile” access over a low bandwidth line (such as a telephone line) to connect remote customer premises to the service provider network. In turn, the service provider network is connected to the customer's corporate office over a Frame Relay network. The PPP protocol is used to transport the customers' IP traffic between the remote premises and the corporate network. PPP over Frame Relay allows an end-to-end PPP connection to be established between the customer premises equipment (CPE) and the corporate gateway router.
Examples of typical applications that use the PPP over Frame Relay feature are illustrated in Figure 10-1. The next section covers a brief introduction to the IDSL access technology and the Cisco 90i Channel Unit card for transporting IDSL and PPP over Frame Relay.
The Cisco 90i IDSL Channel Unit is a circuit card that is commonly installed in a standard D4 channel bank to provide ISDN access to subscribers. The PPP over Frame Relay feature was developed initially to complement the Cisco 90i product by enabling a Cisco router to act as a home gateway router in the service provider's network. Using the Cisco 90i installations, the service provider routers can handle PPP connections over a Frame Relay PVC, thereby allowing the remote end users to access the corporate office network.
NOTE
IDSL is a cross between ISDN and xDSL. IDSL uses a single wire pair to transmit full-duplex data at the rate of 128 kbps for a maximum distance range of 15,000 to 18,000 feet. IDSL uses the ISDN 2B1Q line code to enable transparent operation through the ISDN “U” interface. Essentially, IDSL is a leased-line ISDN Basic Rate Interface (BRI). In the ISDN 2B1Q definition, 2B1Q represents “2 Binary 1 Quaternary,” which is an encoding scheme providing 2 bits per baud, 80k baud per second, and 160 kbps transfer rate. 2B1Q is the most common signaling method for ISDN U interfaces. “B” refers to an ISDN Bearer or B channel and it transports user data. Each B channel is typically 56 kbps or 64 kbps and normally two B channels are available on an ISDN BRI interface.
The “D” in ISDN 2B1D refers to the Signaling D channel, which is used to carry signaling information between a router and an ISDN switch. The D channel usually has a capacity of 16 kbps. Therefore, the aggregate bandwidth of ISDN 2B1D can be up to 144 kbps. Both IDSL and ISDN BRI use the same 2B1Q line modulation.
The Cisco 90i IDSL Channel Unit is part of Cisco's xDSL solutions. The Cisco 90i uses a D4 channel unit that is compatible with existing D4 channel banks with standard common equipment. The Cisco 90i Channel Unit can be used to convert the D4 channel bank digital group from a time-division multiplexing (TDM) unit into a high-performance Frame Relay multiplexer that can support up to four IDSL users running at speeds between 56 and 144 kbps. Each of the four users has access to the full bandwidth on a statistically multiplexed basis, and each user interface supports a standard twisted-pair 2B1Q loop up to a distance of 18,000 feet (5486.4 m).
The Cisco 90i requires a dedicated leased-line ISDN because it does not support switched or dialup ISDN connections. The subscribers' CPE devices, such as the Cisco 700 series routers, can be configured to connect to the Cisco 90i Channel Unit using PPP over IDSL. The PPP packets received by the Cisco 90i are in turn encapsulated in Frame Relay frames and transported over the Frame Relay network to the destination gateway router compliant with RFC 1973. An end-to-end PPP session carrying the users' IP traffic is established between the CPE and the gateway router.
Figure 10-2 shows the use of PPP over Frame Relay with IDSL together with the Cisco 90i Channel Unit card.
As illustrated in Figure 10-2, the Cisco 90i Channel Unit uses PPP over Frame Relay encapsulation to place PPP traffic from the subscriber into a Frame Relay frame and, similarly, extract PPP traffic from the Frame Relay network that is destined for the subscriber. An end-to-end PPP session is maintained between the subscriber and the corporate gateway router.
Information on the Cisco 90i and the Cisco 700 series CPE routers can be found on Cisco Connection Online (CCO): http://www.cisco.com/en/US/products/hw/iad/ps397/ps399/index.html.
RFC 1973 (PPP in Frame Relay) defines a Frame Relay frame format to encapsulate a PPP encapsulated packet in a Frame Relay frame. Based on RFC 1973, PPP uses Frame Relay as a framing mechanism. The Frame Relay frame format outlined in RFC 1973 closely resembles the Frame Relay frame format defined in RFC 1490 and RFC 2427 (Multiprotocol Interconnect over Frame Relay). Figure 10-3 shows a close comparison between the RFC 1973 PPP over Frame Relay frame format and the RFC 1490/RFC 2427 Frame Relay frame format. RFC 1490 can be found at http://www.faqs.org/rfcs/rfc1490.html, and RFC 2427 can be found at http://www.faqs.org/rfcs/rfc2427.html.
NOTE
The Cisco implementation of the PPP over Frame Relay feature is based closely on the specifications outlined in RFC 1973. The full specifications of RFC 1973 can be found at http://www.faqs.org/rfcs/rfc1973.html.
Table 10-1 explains the respective fields in the PPP over Frame Relay format in Figure 10-2.
Table 10-1. PPP over Frame Relay Fields
Flag | A 1-byte delimiter that identifies the beginning or end of a frame. |
Q.922 address | A 2-byte field that indicates the Frame Relay DLCI. |
Control | A 1-byte field that calls for transmission of user data. PPP over Frame Relay uses the value of 0x03. |
NLPID | A 1-byte field that identifies the network layer protocol ID the Frame is carrying. For PPP over Frame Relay, the value 0xCF uniquely identifies a PPP packet that follows after the Frame Relay header. |
PPP protocol header | This 2-byte field identifies the PPP packet type. |
The PPP over Frame Relay frame format consists of the 2-byte Q.922 DLCI address combined with a UI control byte (0x03) and a Network Layer Protocol ID (NLPID) byte. The value of 0xCF in the NLPID byte indicates that the PPP encapsulation follows inside the Frame Relay frame.
NOTE
The PPP over Frame Relay feature is supported on Cisco IOS release 11.3 for c7500, c7200, c4000, and c2500 platforms. The 12.0T Release added support for c1600, c2600, and c3600 platforms. PPP over Frame Relay is not supported on switched virtual circuit (SVC) on all Cisco platforms.
A Cisco router configured to set up a PPP session over a Frame Relay circuit verifies that the VC is in an ACTIVE state before establishing the connection. Once the PPP connection is established over a Frame Relay VC, the Frame Relay VC acts as the physical layer transport for PPP. IP information is carried sequentially by the PPP encapsulation over Frame Relay.
NOTE
A Frame Relay VC that is configured to transport PPP sessions can coexist with other Frame Relay VCs using different Frame Relay encapsulation methods, such as Cisco or RFC 1490/RFC 2427. In other words, it is possible to configure a serial interface on a Cisco router for normal IP data transport using Cisco or RFC 1490/RFC 2427 encapsulation on a Frame Relay DLCI, and then use the same interface for transporting PPP sessions using RFC 1973 on a different Frame Relay DLCI. A Frame Relay DLCI that is set up to use either Cisco or RFC 1490/RFC 2427 encapsulations is configured to transport IP over Frame Relay, whereas a Frame Relay DLCI using RFC 1973 encapsulation carries only PPP sessions. Multiple PPP-in-Frame Relay circuits can exist on the same Frame Relay link.
PPP over Frame Relay is configured on a Cisco router using virtual access interfaces cloned from a virtual template interface.
A virtual template interface is a logical interface or entity that can exist on a Cisco router. The virtual template interface involves configuration for a serial interface, but it is not tied to any physical interface. The virtual template is applied dynamically only as needed.
Virtual access interfaces are not directly configurable, but they are cloned from virtual template interfaces. Virtual access interfaces are created, configured dynamically, and then freed from the memory when they are no longer needed. Each virtual access interface requires the same amount of memory as a serial interface. Virtual template interfaces are associated with the virtual access interfaces using the virtual-template keyword.
NOTE
The maximum number of virtual interfaces supported on a Cisco router is platform dependent. Typically, a Cisco router can support up to 25 virtual template interfaces and a maximum of 300 virtual interfaces. Consult your Cisco router platform configuration guide for the maximum number of virtual templates and interfaces supported.
To configure a virtual template interface on a Cisco router, perform the following configuration tasks, beginning in the global configuration mode:
In the global configuration mode, create a virtual template interface using the interface virtual-template number global configuration command. This creates the virtual template interface with the specified number.
Enter the interface configuration mode of the virtual template interface and enable PPP encapsulation using encapsulation ppp.
Enable IP addressing on the virtual template interface without assigning a specific IP address using the ip unnumbered interface-type/number interface configuration command. Using ip unnumbered saves IP addresses.
Alternatively, an IP address pool can be used to assign IP addresses, or an IP address can be assigned directly to the virtual template interface.
(optional) You can enable other PPP configuration commands on the virtual template interface. An example is PPP authentication.
Example 10-1 shows a configuration example of creating a virtual template interface on a Cisco router. In this example, the ip unnumbered interface command is used to enable IP processing on the virtual template interface without assigning it an explicit IP address. Using ip unnumbered allows conservation of network and address space. The no ip directed-broadcast command is enabled by default. It drops all directed broadcast packets sent to the subnet broadcast address.
Example 10-1. Configuration Example of a Virtual Template Interface
interface loopback0
ip address 172.16.1.1 255.255.255.252
!
interface Virtual-Template1
ip unnumbered Loopback0
no ip directed-broadcast
ppp authentication chap
To apply the virtual template interface and configure PPP over Frame Relay on a Cisco router, perform the following configuration tasks, beginning in the global configuration mode:
Go into the interface configuration mode of the main interface on which you want to configure PPP over Frame Relay. Frame Relay encapsulation must be enabled on the specified main interface with the encapsulation frame-relay interface configuration command.
Configure the Frame Relay physical interface with the PVC. Apply a virtual template with PPP encapsulation to the DLCI to which it will apply. This is achieved using the frame-relay interface-dlci dlci [ppp virtual-template-name-string] command.
The sample in Example 10-2 demonstrates a PPP over Frame Relay configuration whereby DLCI 101 over subinterface serial 3/0.1 is associated with virtual template 1.
Example 10-2. Configuration Example of PPP over Frame Relay Applied to DLCI 101
interface serial 3/0
no ip address
encapsulation frame-relay
!
interface serial 3/0.1 point-to-point
frame-relay interface-dlci 101 ppp virtual-template1
!
interface Virtual-Template1
ip unnumbered loopback0
ppp authentication chap
!
interface loopback 0
ip address 172.16.1.1 255.255.255.252
The PPP over Frame Relay feature is configured between two Cisco routers, as shown in Figure 10-4. This figure is used to explain the show and debug commands for PPP over Frame Relay.
Example 10-3 shows the configuration files of routers R1 and R2.
Example 10-3. Running Configuration of R1 and R2
! R1
<output omitted>
interface Virtual-Template1
ip address 192.168.1.2 255.255.255.0
!
interface Serial1
no ip address
encapsulation frame-relay
!
interface Serial1.1 point-to-point
frame-relay interface-dlci 101 ppp Virtual-Template1
! R2
<output omitted>
frame-relay switching
!
interface Virtual-Template1
ip address 192.168.1.1 255.255.255.0
!
interface Serial1
no ip address
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
!
interface Serial1.1 point-to-point
frame-relay interface-dlci 101 ppp Virtual-Template1
The show frame-relay pvc global EXEC command can be used to display statistics of the Frame Relay PVC on the configured Frame Relay interfaces. Example 10-4 shows the status of the Frame Relay DLCI 101 under the point-to-point subinterface configured in Example 10-3. The output in Example 10-4 indicates that the Frame Relay PVC is bound to virtual access interface 1, cloned from the virtual template interface 1.
Example 10-4. Sample Output of show frame-relay pvc Command of DLCI 101
R1#show frame-relay pvc 101 PVC Statistics for interface Serial1 (Frame Relay DTE) DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.1 input pkts 50 output pkts 46 in bytes 2067 out bytes 1387 dropped pkts 0 in pkts dropped 0 out pkts dropped 0 out bytes dropped 0 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 2 out bcast bytes 582 pvc create time 00:03:37, last time pvc status changed 00:03:37Bound to Virtual-Access1(up, cloned from Virtual-Template1)
The debug ppp negotiation command can be used to observe the PPP negotiation process between the PPP peers when the routers attempt to set up a PPP session. An example is shown in Example 10-5.
Example 10-5. Sample Output of debug ppp negotiation Command on R1
PPP: PPP protocol negotiation debugging is on csidtw8# *Mar 2 00:20:23.669: Vi1 LCP: I CONFREQ [Open] id 34 len 10 *Mar 2 00:20:23.673: Vi1 LCP: MagicNumber 0x054CD717 (0x0506054CD717) *Mar 2 00:20:23.677: Vi1 IPCP: State is Closed *Mar 2 00:20:23.677: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load] *Mar 2 00:20:23.681: Vi1 PPP: Phase is ESTABLISHING [0 sess, 0 load] *Mar 2 00:20:23.685: Vi1 LCP: O CONFREQ [Open] id 6 len 10 *Mar 2 00:20:23.689: Vi1 LCP: MagicNumber 0xE55765B9 (0x0506E55765B9) *Mar 2 00:20:23.693: Vi1 LCP: O CONFACK [Open] id 34 len 10 *Mar 2 00:20:23.697: Vi1 LCP: MagicNumber 0x054CD717 (0x0506054CD717) *Mar 2 00:20:23.701: Vi1 LCP: I CONFACK [ACKsent] id 6 len 10 *Mar 2 00:20:23.705: Vi1 LCP: MagicNumber 0xE55765B9 (0x0506E55765B9) *Mar 2 00:20:23.705: Vi1 LCP: State is Open *Mar 2 00:20:23.709: Vi1 PPP: Phase is UP [0 sess, 0 load] *Mar 2 00:20:23.713: Vi1 IPCP: O CONFREQ [Closed] id 6 len 10 *Mar 2 00:20:23.717: Vi1 IPCP: Address 192.168.1.2 (0x0306C0A80102) *Mar 2 00:20:23.721: Vi1 IPCP: Remove route to 192.168.1.1 *Mar 2 00:20:23.729: Vi1 IPCP: I CONFREQ [REQsent] id 3 len 10 *Mar 2 00:20:23.733: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101) *Mar 2 00:20:23.737: Vi1 IPCP: O CONFACK [REQsent] id 3 len 10 *Mar 2 00:20:23.741: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101) *Mar 2 00:20:23.745: Vi1 IPCP: I CONFACK [ACKsent] id 6 len 10 *Mar 2 00:20:23.749: Vi1 IPCP: Address 192.168.1.2 (0x0306C0A80102) *Mar 2 00:20:23.749: Vi1 IPCP: State is Open *Mar 2 00:20:23.757: Vi1 IPCP: Install route to 192.168.1.1
In the debug ppp negotiation output in Example 10-5, observe PPP session negotiation messages being exchanged between the peer routers. Both the LCP and the NCP must be negotiated properly before a PPP session can be set up. In the debug output, the phases “LCP: State is Open” and “PPP: Phase is UP” indicate that the physical layer is working and LCP is properly establishing a connection between the peers. The NCP uses IP Control Protocol (IPCP) to set up and manage IP over the PPP session. The PPP negotiation process on R1 completes by installing a route to R2's virtual access interface (192.168.1.1 is cloned from virtual template interface 1 on R2).
The PPP authentication features are added to the R1 and R2 configurations in Example 10-3. The username/password and ppp authentication chap commands are set up on both R1 and R2, as shown in Example 10-6. Note that both username and password are case-sensitive.
Example 10-6. Adding CHAP Authentication to PPP over Frame Relay
! R1 <output omitted> username R2 password 0 cisco ! interface Virtual-Template1 ip address 192.168.1.2 255.255.255.0 ppp authentication chap ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point frame-relay interface-dlci 101 ppp Virtual-Template1 ! R2 <output omitted> username R1 password 0 cisco ! frame-relay switching ! interface Virtual-Template1 ip address 192.168.1.1 255.255.255.0 no peer default ip address ppp authentication chap ! interface Serial1 no ip address encapsulation frame-relay clockrate 64000 frame-relay intf-type dce ! interface Serial1.1 point-to-point frame-relay interface-dlci 101 ppp Virtual-Template1
The debug ppp authentication command can be used to display or troubleshoot the PPP CHAP or PAP authentication process between the peer routers, as shown in Example 10-7.
Example 10-7. Sample Output of debug ppp authentication at Router R1
*May 29 11:44:22.889: Vi1 PPP: Treating connection as a dedicated line *May 29 11:44:22.909: Vi1 CHAP: O CHALLENGE id 6 len 28 from "R1" *May 29 11:44:22.945: Vi1 CHAP: I CHALLENGE id 6 len 28 from "R2" *May 29 11:44:22.949: Vi1 CHAP: O RESPONSE id 6 len 28 from "R1" *May 29 11:44:22.953: Vi1 CHAP: I RESPONSE id 6 len 28 from "R2" *May 29 11:44:22.957: Vi1 CHAP: O SUCCESS id 6 len 4 *May 29 11:44:22.993: Vi1 CHAP: I SUCCESS id 6 len 4
PPP CHAP implements a three-way handshake process between two authenticating routers. Each side sends out a hash of its username and password instead of transmitting them across insecurely in clear text, as in the PAP case. Referring to the debug ppp authentication output displayed at router R1 in Example 10-7, routers R1 and R2 are involved in a two-way authentication. Both the calling (R2) and the called (R1) parties send out a CHALLENGE message to authenticate each other. Each party replies with a response containing a value calculated using a one-way hash function. Then each router checks the response against its own calculation of the expected hash value. If the response received matches the calculated hash value, the authentication is successful.
The debug frame-relay ppp command can be used to display error messages for link states and LMI status changes for PPP over Frame Relay sessions. Two examples are given in Example 10-8 and 10-9.
Example 10-8. Sample Output of debug frame-relay ppp When PPP over Frame Relay Is Working Properly
*May 29 11:48:17.509: FR-PPP: process on Virtual-Access1, #out-pkts=497 *May 29 11:48:19.509: FR-PPP: process on Virtual-Access1, #out-pkts=498 *May 29 11:48:21.509: FR-PPP: process on Virtual-Access1, #out-pkts=499 *May 29 11:48:23.509: FR-PPP: process on Virtual-Access1, #out-pkts=500 *May 29 11:48:25.509: FR-PPP: process on Virtual-Access1, #out-pkts=501 *May 29 11:48:27.509: FR-PPP: process on Virtual-Access1, #out-pkts=502 *May 29 11:48:28.917: FR-PPP: process on Virtual-Access1, #out-pkts=503
This chapter introduced readers to Cisco's implementation of the PPP over Frame Relay feature, based on the specifications defined in RFC 1973 (PPP in Frame Relay). Establishing a PPP session over a Frame Relay VC allows an end-to-end PPP session to be set up and maintained between two Frame Relay peers using RFC 1973. IP information is carried inside PPP packets, which are encapsulated in Frame Relay frames for transport over a Frame Relay VC. The PPP over Frame Relay feature is configured and maintained on Cisco routers with a virtual interface known as virtual access interface, which is cloned from a user-configured virtual template interface.
This chapter covered the configuration tasks and Cisco IOS commands necessary to establish a PPP session between two routers over a Frame Relay VC. Furthermore, this chapter explained the Cisco IOS show and debug commands for maintaining and troubleshooting PPP over Frame Relay on a Cisco router.
This chapter highlighted several optional PPP features, such as authentication and multilink PPP. Both PPP authentication and multilink PPP are supported with PPP over Frame Relay. The Multilink PPP over Frame Relay feature is explained separately in Chapter 14, “Multilink Frame Relay (FRF.16).”
The next chapter covers the use of the Frame Relay SVC feature on Cisco devices.
Cisco 90i IDSL Customer Premises Equipment: http://www.cisco.com/en/US/products/hw/iad/ps397/ps399/index.html
RFC 1490 –. Multiprotocol Interconnect over Frame Relay: http://www.faqs.org/rfcs/rfc1490.html
RFC 1661 –. The Point-to-Point Protocol: http://www.faqs.org/rfcs/rfc1661.html
RFC 1973 –. PPP in Frame Relay: http://www.faqs.org/rfcs/rfc1973.html
RFC 2427 –. Multiprotocol Interconnect over Frame Relay: http://www.faqs.org/rfcs/rfc2427.html
The network diagram in Figure 10-5 is used to verify the PPP over Frame Relay feature by establishing multiple Frame Relay PVC connections that mix normal Frame Relay circuits with PPP over Frame Relay. In this setup, R2 acts as a router that connects a local LAN segment to the corporate gateway router (R3) via PPP over Frame Relay. R3 allocates an IP address to R1 from a local pool that is configured. The use of the Cisco 90i Channel Unit is not demonstrated here.
A client computer is used to simulate a remote subscriber attempting to connect into the corporate gateway router (R3). The router R1 is used to send routing protocol updates over the Frame Relay network to R3 on a different DLCI but configured under the same Frame Relay physical interface. This verifies that PPP over Frame Relay can coexist with other Frame Relay encapsulations.
The configuration files of R1, R2, and R3 are shown in Example 10-10.
Example 10-10. The show running of R1, R2, and R3 in Figure 10-5
! R1 <output omitted> interface Ethernet0 ip address 172.16.1.1 255.255.255.0 ! router rip passive-interface Ethernet0 network 172.16.0.0 neighbor 172.16.1.2 ! R2 <output omitted> username R2 password 0 cisco username R3 password 0 cisco ! interface Ethernet0 ip address 172.16.1.2 255.255.255.0 ! interface Virtual-Template1 ip address negotiated ppp authentication chap ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point frame-relay interface-dlci 101 ppp Virtual-Template1 ! interface Serial1.2 point-to-point ip address 192.168.1.1 255.255.255.252 frame-relay interface-dlci 100 ! router rip passive-interface Ethernet0 network 172.16.0.0 network 192.168.1.0 neighbor 172.16.1.1 ! R3 <output omitted> username R1 password 0 cisco username R2 password 0 cisco ! frame-relay switching ! ! interface Loopback0 ip address 200.200.200.1 255.255.255.0 ! interface Virtual-Template1 ip unnumbered Loopback0 peer default ip address pool local_pool ppp authentication chap ! interface Serial1 no ip address encapsulation frame-relay clockrate 64000 frame-relay intf-type dce ! interface Serial1.1 point-to-point frame-relay interface-dlci 101 ppp Virtual-Template1 ! interface Serial1.2 point-to-point ip address 192.168.1.2 255.255.255.252 frame-relay interface-dlci 100 ! router rip network 192.168.1.0 ! ip local pool local_pool 200.200.200.2 200.200.200.200
The show frame-relay pvc command is used at R2 and R3 to verify both Frame Relay PVC connections are active, as shown in Example 10-11.
Example 10-11. show frame-relay pvc Output of R2 and R3 in Figure 10-5
R1#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.2
input pkts 87 output pkts 90 in bytes 14522
out bytes 10971 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
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 65 out bcast bytes 8575
pvc create time 00:37:54, last time pvc status changed 00:17:11
DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.1
input pkts 515 output pkts 694 in bytes 19846
out bytes 23924 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
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 41 out bcast bytes 11668
pvc create time 00:37:56, last time pvc status changed 00:17:13
Bound to Virtual-Access1 (up, cloned from Virtual-Template1)
R2#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DCE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.2
input pkts 135 output pkts 126 in bytes 21052
out bytes 23967 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
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 88 out bcast bytes 20592
pvc create time 01:05:46, last time pvc status changed 00:15:02
DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.1
input pkts 1405 output pkts 2039 in bytes 59575
out bytes 69286 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
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 104 out bcast bytes 31622
pvc create time 01:47:21, last time pvc status changed 00:15:04
Bound to Virtual-Access1 (up, cloned from Virtual-Template1)
As shown in Example 10-11, both DLCI 100 and DLCI 101 (bound to PPP over Frame Relay) are now in the ACTIVE state. Both Frame Relay PVC connections are configured under the same physical interface. This verifies that PPP over Frame Relay can coexist with Cisco or RFC 1490 encapsulations.
Example 10-12 displays the output of the debug ppp authentication command at router R2, which indicates a successful authentication between routers R2 and R3.
Example 10-12. The debug ppp authentication at Router R1 Indicates that PPP CHAP Authentication Is Successful
3d18h: Vi1 CHAP: O CHALLENGE id 24 len 28 from "R2" 3d18h: Vi1 CHAP: I CHALLENGE id 24 len 28 from "R3" 3d18h: Vi1 CHAP: O RESPONSE id 24 len 28 from "R2" 3d18h: Vi1 CHAP: I RESPONSE id 24 len 28 from "R3" 3d18h: Vi1 CHAP: O SUCCESS id 24 len 4 3d18h: Vi1 CHAP: I SUCCESS id 24 len 4
In the next example, the password on router R2 is deliberately changed to simulate a negative password authentication process between routers R2 and R3. The output of the debug ppp authentication command illustrated in Example 10-13 reveals the failed authentication and errors.
Example 10-13. The debug ppp authentication at Router R1 Indicates PPP CHAP Authentication Failure
3d18h: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up 3d18h: Vi1 PPP: Treating connection as a dedicated line 3d18h: Vi1 CHAP: O CHALLENGE id 25 len 28 from "R2" 3d18h: Vi1 CHAP: I CHALLENGE id 25 len 28 from "R3" 3d18h: Vi1 CHAP: O RESPONSE id 25 len 28 from "R2" 3d18h: Vi1 CHAP: I RESPONSE id 25 len 28 from "R3" 3d18h: Vi1 CHAP: O FAILURE id 25 len 25 msg is "MD/DES compare failed"
After restoring the correct password on router R2, the PPP session is reestablished over the Frame Relay connection. This can be verified by sending traffic across Frame Relay DLCI 100 and 101 from R2, as illustrated in Example 10-14.
Example 10-14. The Ping from R2 to R3 over DLCI 100 and DLCI 101 Is Successful
R2#ping 192.168.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms R2#ping 200.200.200.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.200.200.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/31/32 ms
In Example 10-14, take notice that on the 192.168.1.0/30 subnet, IP traffic is transported directly over Frame Relay DLCI 100 using Cisco or RFC 1490/RFC 2427 encapsulation. On the other hand, IP traffic is carried inside PPP packets, which are transported over Frame Relay DLCI 101 by encapsulating the PPP packets within Frame Relay frames.
Example 10-14 shows that router R2 has established network layer connectivity to the loopback interface (200.200.200.1/24) on router R3. After the PPP session is established between routers R2 and R3, R2 is allocated an IP address from the local_pool address pool configured on router R3. Example 10-15 shows the show interface virtual-access number privileged EXEC command is used to verify the IP address allocated to R2's virtual access interface from the local_pool address pool that is set up on router R1. In addition, the show interface virtual-access number command can be used to display the virtual access interface configurations to confirm a good clone of the virtual template.
In this setup, the routers are configured to perform PPP CHAP authentication using a locally configured username and password. On a production network, an AAA Radius server can be added to the network to perform remote Radius PPP authentication. The Radius user files on the Radius server can be set up to allocate an IP address to the PPP peer after a successful authentication.
Example 10-15. The show interface Output of the Virtual Access Interface on R2
R2#sh inter virtual-access 1
Virtual-Access1 is up, line protocol is up
Hardware is Virtual Access interface
Internet address is 200.200.200.2/32
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 Serial1.1 DLCI 101, Cloned from Virtual-Template1
Last input 00:00:44, output never, output hang never
Last clearing of "show interface" counters 00:42:51
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
515 packets input, 9174 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
517 packets output, 8474 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
RIP is configured on all three routers to verify that routing protocol updates can be propagated over the Frame Relay PVC connections. After DLCI 101 is brought up, the network statement 200.200.200.0 is added to the RIP routing process on R2 and R3. Example 10-16 shows that R3 can reach the Ethernet segment on R1 via two equal cost paths: one via DLCI 100 running conventional Frame Relay PVC, and the second via DLCI 101 running PPP over Frame Relay.
Example 10-16. The IP Routing Tables of R1, R2, and R3
R1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
R 200.200.200.0/24 [120/1] via 172.16.1.2, 00:00:13, Ethernet0
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Ethernet0
R 192.168.1.0/24 [120/1] via 172.16.1.2, 00:00:13, Ethernet0
R2##show ip route
1d01h: %SYS-5-CONFIG_I: Configured from console by console
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
200.200.200.0/32 is subnetted, 2 subnets
C 200.200.200.1 is directly connected, Virtual-Access1
C 200.200.200.2 is directly connected, Virtual-Access1
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Ethernet0
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, Serial1.2
R3#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
200.200.200.0/24 is variably subnetted, 2 subnets, 2 masks
C 200.200.200.0/24 is directly connected, Loopback0
C 200.200.200.2/32 is directly connected, Virtual-Access1
R 172.16.0.0/16 [120/1] via 192.168.1.1, 00:00:08, Serial1.2
[120/1] via 200.200.200.2, 00:00:08, Virtual-Access1
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, Serial1.2
150.1.0.0/24 is subnetted, 1 subnets
C 150.1.28.0 is directly connected, Ethernet1
The client PC on the Ethernet segment is configured with a default route to R1. A ping from the PC to the loopback address on R3 is successful, as shown in Example 10-17.
Example 10-17. A Standard Ping from the Client PC to R3 Is Successful
Microsoft Windows 2000 [Version 5.00.2195]
Copyright 1985-2000 Microsoft Corp.
C:>ping 200.200.200.1
Pinging 200.200.200.1 with 32 bytes of data:
Reply from 200.200.200.1: bytes=32 time=180ms TTL=254
Reply from 200.200.200.1: bytes=32 time=170ms TTL=254
Reply from 200.200.200.1: bytes=32 time=170ms TTL=254
Reply from 200.200.200.1: bytes=32 time=171ms TTL=254
Ping statistics for 200.200.200.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 170ms, Maximum = 180ms, Average = 172ms
NOTE
The return path traffic from R3 is load-balanced between the two equal cost paths to 172.16.1.0/24.
The case study in this section shows the successful establishment of a PPP session over a Frame Relay network between two Cisco routers. Moreover, a PPP over Frame Relay session between two routers can be configured to optionally support authentication. The case study also verified that a Frame Relay VC configured to support PPP over Frame Relay can coexist with other Frame Relay VCs using the Cisco or RFC 1490/RFC 2427 encapsulations.