Frame Relay for ICND Exam

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Aug 29, 2003.

Chapter Description

Wendell Odom tells you what you need to know to ace the Frame Relay portion of the ICND Exam. In this sample chapter, he concentrates on Frame Relay protocols and configuration.

Frame Relay Configuration

Basic configuration of Frame Relay in a Cisco router is relatively straightforward, partly because Cisco IOS software uses good default values. Of course, you still need to know the optional parameters that are described in this section and the methods of changing the default values. The configuration examples start with a configuration with all the default settings and then begin adding optional features.

There is no substitute for hands-on experience! However, in lieu of hands-on experience, this section lists commands, provides examples, and points out tricky features. Tables 11-9 and 11-10 summarize the more popular commands used for Frame Relay configuration and verification. Several configuration examples follow. If you are interested in other references as well, the Cisco IOS software documentation is an excellent reference for additional IP commands.

Table 11-9 Frame Relay Configuration Commands

Command

Description

encapsulation frame-relay [ietf | cisco]

Interface configuration mode command that defines the Frame Relay encapsulation that is used rather than HDLC, PPP, and so on.

frame-relay lmi-type {ansi | q933a | cisco}

Interface configuration mode command that defines the type of LMI messages sent to the switch.

bandwidth num

Interface configuration mode command that sets the router's perceived interface speed. Bandwidth is used by some routing protocols to influence the metric and is used in link utilization calculations seen with the show interfaces command.

Command

Description

frame-relay map {protocol protocol-address dlci} payload-compression frf9 stac caim [element-number] [broadcast] [ietf | cisco]

Interface configuration mode command that statically defines a mapping between a network layer address and a DLCI.

keepalive sec

Interface configuration mode command that defines whether and how often LMI status inquiry messages are sent and expected.

interface serial number.sub [point-to-point | multipoint]

Global configuration mode command that creates a subinterface or references a previously created subinterface.

frame-relay interface-dlci dlci [ietf | cisco] [voice-cir cir] [ppp virtual-template-name]

Subinterface configuration mode command that links or correlates a DLCI to the subinterface.


Table 11-10Å@Frame Relay-Related EXEC Commands

Command

Description

show interfaces [type number]

Shows the physical interface status.

show frame-relay pvc [interface interface][dlci]

Lists information about the PVC status.

show frame-relay lmi [type number]

Lists LMI status information.


A network engineer might plan the Frame Relay configuration based on several factors. When the service is ordered, the service provider specifies the LMI type that will be used. The engineer chooses the endpoints of the VCs, including whether to use a full mesh or partial mesh. Based on the location of the VCs, the engineer then decides which IP addressing option to use: single subnet, single subnet per VC, or a combination of the two. Finally, the encapsulation type is chosen—totally without input from the provider, because only the routers on the ends of each VC need to agree on the encapsulation type. Because Frame Relay switches do not care about the encapsulation type, nor do they care about IP addressing, the only details that have to be discussed with the carrier are the VCs and the LMI type, along with the CIR and burst sizes.

Three examples of Layer 3 addressing were given earlier in this chapter, with the networks diagrammed in Figures 11-11, 11-12, and 11-13. The configurations matching those networks and addresses are shown next.

A Fully-Meshed Network with One IP Subnet

In this first example, the configuration uses all default values, and it does not use subinterfaces. The Frame Relay configuration is listed under the physical interfaces. Examples 11-1, 11-2, and 11-3 show the configuration for the network shown in Figure 11-16.

Figure xxxFigure 11-16 Full Mesh with IP Addresses

Example 11-1 Mayberry Configuration

interface serial0
encapsulation frame-relay
ip address 199.1.1.1 255.255.255.0
!
interface ethernet 0
ip address 199.1.10.1 255.255.255.0
!
router igrp 1
network 199.1.1.0
network 199.1.10.0

Example 11-2 Mount Pilot Configuration

interface serial0
encapsulation frame-relay
ip address 199.1.1.2 255.255.255.0
!
interface ethernet 0
ip address 199.1.11.2  255.255.255.0
!
router igrp 1
network 199.1.1.0
network 199.1.11.0

Example 11-3 Raleigh Configuration

interface serial0
encapsulation frame-relay
ip address 199.1.1.3 255.255.255.0
!
interface ethernet 0
ip address 199.1.12.3  255.255.255.0
!
router igrp 1
network 199.1.1.0
network 199.1.12.0

The configuration is simple in comparison with the protocol concepts. The encapsulation frame-relay command tells the routers to use Frame Relay data-link protocols instead of the default, which is HDLC. Note that the IP addresses on the three routers' serial interfaces are all in the same subnet. When you configure Frame Relay on the physical interfaces, all three routers must be in the same subnet.

Yes, Frame Relay configuration can be that easy, because IOS uses some very good choices for default settings:

  • The LMI type is automatically sensed.

  • The encapsulation is Cisco instead of IETF.

  • PVC DLCIs are learned via LMI status messages.

  • Inverse ARP is enabled (by default) and is triggered when the status message declaring that the VCs are up is received. (Inverse ARP is covered in the next section.)

In some cases, the default values are inappropriate. For example, you must use IETF encapsulation if one router is not a Cisco router. For the purpose of showing an alternative configuration, suppose that the following requirements were added:

  • The Raleigh router requires IETF encapsulation on both VCs.

  • Mayberry's LMI type should be ANSI, and LMI autosense should not be used.

Examples 11-4 and 11-5 show the changes that would be made to Mayberry and Raleigh.

Example 11-4 Mayberry Configuration with New Requirements

interface serial0
 encapsulation frame-relay
 frame-relay lmi-type ansi
 frame-relay interface-dlci 53 ietf
 ip address 199.1.1.1 255.255.255.0
! rest of configuration unchanged from Example 11-1.

Example 11-5Raleigh Configuration with New Requirements

interface serial0
 encapsulation frame-relay ietf
 ip address 199.1.1.3 255.255.255.0
!
! rest of configuration unchanged from Example 11-3.

These configurations differ from the previous ones in two ways: Raleigh changed its encapsulation for both its PVCs with the ietf keyword on the encapsulation command. This keyword applies to all VCs on the interface. However, Mayberry cannot change its encapsulation in the same way, because only one of the two VCs terminating in Mayberry needs to use IETF encapsulation—the other needs to use Cisco encapsulation. So Mayberry is forced to code the frame-relay interface-dlci command, referencing the DLCI for the VC to Raleigh, with the ietf keyword. With that command, you can change the encapsulation setting per-VC, as opposed to the configuration on Raleigh, which changes the encapsulation for all VCs.

The LMI configuration in Mayberry would be fine without any changes, because autosense would recognize ANSI. However, by coding the frame-relay lmi-type ansi command, Mayberry must use ANSI, because this command not only sets the LMI type, it also disables autonegotiation of the LMI type.

Mount Pilot needs to configure a frame-relay interface-dlci command with the ietf keyword for its VC to Raleigh, just like Mayberry. This change is not shown in the examples.

Frame Relay Address Mapping

Figure 11-16 does not even bother listing the DLCIs used for the VCs. The configurations work as stated, and frankly, if you never knew the DLCIs, this network would work! However, for the exam, and for real networking jobs, you need to understand an important concept related to Frame Relay—namely, Frame Relay address mapping. Figure 11-17 shows the same network, this time with Global DLCI values shown.

Frame Relay "mapping" creates a correlation between a Layer 3 address and its corresponding Layer 2 address. For example, the IP Address Resolution Protocol (ARP) cache used on LANs is an example of Layer 3-to-Layer 2 address mapping. With IP ARP, you know the IP address of another device on the same LAN, but not the MAC address; when the ARP completes, you know another device's LAN (Layer 2) address. Similarly, routers that use Frame Relay need a mapping between a router's Layer 3 address and the DLCI used to reach that other router.Figure 17

Figure 11-17 Full Mesh with IP Addresses

This section discusses the basics of why mapping is needed for LAN connections and Frame Relay, with a focus on Frame Relay. Here's a more general definition of mapping:

The information that correlates to the next-hop router's Layer 3 address, and the Layer 2 address used to reach it, is called mapping. Mapping is needed on multiaccess networks.

Thinking about routing helps make the need for mapping more apparent. Imagine that a host on the Mayberry Ethernet sends an IP packet to a host on the Mount Pilot Ethernet. The packet arrives at the Mayberry router over the LAN, and Mayberry discards the Ethernet header and trailer. Mayberry looks at the routing table, which lists a route to 199.1.11.0, outgoing interface Serial0, and next-hop router 199.1.1.2, which is Mount Pilot's Frame Relay IP address.

The next decision that the router must make to complete the process points out the need for mapping: What DLCI should Mayberry put in the Frame Relay header? We configured no DLCIs. However, it would work as configured! To see the answer, consider Example 11-6, which shows some important commands that can be used to see how Mayberry makes the right choice for the DLCI.

Example 11-6 show Commands on Mayberry, Showing the Need for Mapping

Mayberry#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

I  199.1.11.0/24 [100/8576] via 199.1.1.2, 00:00:26, Serial0
C  199.1.10.0/24 is directly connected, Ethernet0
I  199.1.12.0/24 [100/8539] via 199.1.1.3, 00:01:04, Serial0
C  199.1.1.0/24 is directly connected, Serial0
C  192.68.1.0/24 is directly connected, Ethernet0
C  192.168.1.0/24 is directly connected, Ethernet0

Mayberry#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)

       Active   Inactive   Deleted    Static
 Local     2      0      0      0
 Switched    0      0      0      0
 Unused     0      0      0      0

DLCI = 52, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

 input pkts 46      output pkts 22      in bytes 2946
 out bytes 1794      dropped pkts 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 21    out bcast bytes 1730
 pvc create time 00:23:07, last time pvc status changed 00:21:38

DLCI = 53, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

 input pkts 39      output pkts 18      in bytes 2564
 out bytes 1584      dropped pkts 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 18    out bcast bytes 1584
 pvc create time 00:23:08, last time pvc status changed 00:21:20

Mayberry#show frame-relay map
Serial0 (up): ip 199.1.1.2 dlci 52(0x34,0xC40), dynamic,
       broadcast,, status defined, active
Serial0 (up): ip 199.1.1.3 dlci 53(0x35,0xC50), dynamic,
       broadcast,, status defined, active

All the information needed for Mayberry to pick DLCI 52 is in the command output. The route to 199.1.11.0 points out Serial0 to 199.1.1.2 as the next-hop address. The show frame-relay pvc command lists two DLCIs, 52 and 53, and both are active. How does Mayberry know the DLCIs? Well, the LMI status messages tell Mayberry about the VCs, the associated DLCIs, and the status (active).

Which DLCI should Mayberry use to forward the packet? The show frame-relay map command output holds the answer. Notice the highlighted phrase ip 199.1.1.2 dlci 52 in the output. Somehow, Mayberry has mapped 199.1.1.2, which is the next-hop address in the route, to the correct DLCI, which is 52. So, Mayberry knows to use DLCI 52 to reach next-hop IP address 199.1.1.2.

Mayberry can use two methods to build the mapping shown in Example 11-6. One uses a statically configured mapping, and the other uses a dynamic process called Inverse ARP.

Inverse ARP dynamically creates a mapping between the Layer 3 address (for example, the IP address) and the Layer 2 address (the DLCI). The end result of Inverse ARP is the same as IP ARP on a LAN: The router builds a mapping between a neighboring Layer 3 address and the corresponding Layer 2 address. However, the process used by Inverse ARP differs for ARP on a LAN. After the VC is up, each router announces its network layer address by sending an Inverse ARP message over that VC. This works as shown in Figure 11-18.

Figure 18Figure 11-18 Inverse ARP Process

As shown in Figure 11-18, Inverse ARP announces its Layer 3 addresses as soon as the LMI signals that the PVCs are up. Inverse ARP starts by learning the DLCI data link layer address (via LMI messages), and then it announces its own Layer 3 addresses that use that VC.

Inverse ARP is enabled by default in Cisco IOS software Release 11.2 and later.

In Example 11-6, Mayberry shows two different entries in the show frame-relay map command output. Mayberry uses Inverse ARP to learn that DLCI 52 is mapped to next-hop IP address 199.1.1.2 and that DLCI 53 is mapped to next-hop IP address 199.1.1.3. Interestingly, Mayberry learns this information by receiving an Inverse ARP from Mount Pilot and Raleigh, respectively—another case of learning by listening, a great lesson for real life!

Table 11-11 summarizes what occurs with Inverse ARP in the network shown in Figure 11-17.

Table 11-11 Inverse ARP Messages for Figure 11-17

Sending Router
DLCI When the Frame Is Sent
Receiving Router
DLCI When the Frame Is Received
Information in the Inverse ARP Message
Mayberry
52
Mount Pilot
51
I am 199.1.1.1.
Mayberry
53
Raleigh
51
I am 199.1.1.1.
Mount Pilot
51
Mayberry
52
I am 199.1.1.2.
Mount Pilot
53
Raleigh
52
I am 199.1.1.2.
Raleigh
51
Mayberry
53
I am 199.1.1.3.
Raleigh
52
Mount Pilot
53
I am 199.1.1.3.

To understand Inverse ARP, focus on the last two columns of Table 11-11. Each router receives some Inverse ARP "announcements." The Inverse ARP message contains the sender's Layer 3 address, and the Frame Relay header, of course, has a DLCI in it. These two values are placed in the Inverse ARP cache on the receiving router. For example, in the third row, Mayberry receives an Inverse ARP. The DLCI is 52, and the IP address is 199.1.1.2. This is added to the Frame Relay map table in Mayberry, which is shown in the highlighted part of the show frame-relay map command in Example 11-6.

You can statically configure the same mapping information instead of using Inverse ARP. In a production network, you probably would just go ahead and use Inverse ARP. For the exam, you need to know how to configure the static map commands. Example 11-7 lists the static Frame Relay map for the three routers shown in Figure 11-11, along with the configuration used to disable Inverse ARP.

Example 11-7Å@frame-relay map Commands

Mayberry
interface serial 0
no frame-relay inverse-arp
frame-relay map ip 199.1.1.2 52 broadcast
frame-relay map ip 199.1.1.3 53 broadcast
Mount Pilot
interface serial 0
no frame-relay inverse-arp
frame-relay map ip 199.1.1.1 51 broadcast
frame-relay map ip 199.1.1.3 53 broadcast
Raleigh
interface serial 0
no frame-relay inverse-arp
frame-relay map ip 199.1.1.1 51 broadcast
frame-relay map ip 199.1.1.2 52 broadcast

The frame-relay map command entry for Mayberry, referencing 199.1.1.2, is used for packets in Mayberry going to Mount Pilot. When Mayberry creates a Frame Relay header, expecting it to be delivered to Mount Pilot, Mayberry must use DLCI 52. Mayberry's map statement correlates Mount Pilot's IP address, 199.1.1.2, to the DLCI used to reach Mount Pilot—namely, DLCI 52. Likewise, a packet sent back from Mount Pilot to Mayberry causes Mount Pilot to use its map statement to refer to Mayberry's IP address of 199.1.1.1. Mapping is needed for each next-hop Layer 3 address for each Layer 3 protocol being routed. Even with a network this small, the configuration process can be laborious.

A Partially-Meshed Network with One IP Subnet Per VC

The second sample network, based on the environment shown in Figure 11-19, uses point-to-point subinterfaces. Examples 11-8 through 11-11 show the configuration for this network. The command prompts are included in the first example because they change when you configure subinterfaces.

Figure 19Figure 11-19 Partial Mesh with IP Addresses

Example 11-8 Atlanta Configuration

Atlanta(config)#interface serial0
Atlanta(config-if)#encapsulation frame-relay

Atlanta(config-if)#interface serial 0.1 point-to-point
Atlanta(config-subif)#ip address 140.1.1.1 255.255.255.0
Atlanta(config-subif)#frame-relay interface-dlci 52

Atlanta(config-fr-dlci)#interface serial 0.2 point-to-point
Atlanta(config-subif)#ip address 140.1.2.1 255.255.255.0
Atlanta(config-subif)#frame-relay interface-dlci 53

Atlanta(config-fr-dlci)#interface serial 0.3 point-to-point
Atlanta(config-subif)#ip address 140.1.3.1 255.255.255.0
Atlanta(config-subif)#frame-relay interface-dlci 54

Atlanta(config-fr-dlci)#interface ethernet 0
Atlanta(config-if)#ip address 140.1.11.1 255.255.255.0

Example 11-9 Charlotte Configuration

interface serial0
encapsulation frame-relay
!
interface serial 0.1 point-to-point
ip address 140.1.1.2 255.255.255.0
frame-relay interface-dlci 51
!
interface ethernet 0
ip address 140.1.12.2 255.255.255.0

Example 11-10 Nashville Configuration

interface serial0
encapsulation frame-relay
!
interface serial 0.2 point-to-point
ip address 140.1.2.3 255.255.255.0
frame-relay interface-dlci 51
!
interface ethernet 0
ip address 140.1.13.3 255.255.255.0

Example 11-11 Boston Configuration

interface serial0
encapsulation frame-relay
!
interface serial 0.3 point-to-point
ip address 140.1.3.4 255.255.255.0
frame-relay interface-dlci 51
!
interface ethernet 0
ip address 140.1.14.4 255.255.255.0

Again, defaults abound in this configuration, but some defaults are different than when you're configuring on the main interface, as in the preceding example. The LMI type is autosensed, and Cisco encapsulation is used, which is just like the fully-meshed example. However, Inverse ARP is disabled on each point-to-point subinterface by default. As you will see, Inverse ARP is not needed with point-to-point subinterfaces.

Two new commands create the configuration required with point-to-point subinterfaces. First, the interface serial 0.1 point-to-point command creates logical subinterface number 1 under physical interface Serial0. The frame-relay interface-dlci subinterface subcommand then tells the router which single DLCI is associated with that subinterface.

An example of how the interface-dlci command works can help. Consider router Atlanta in Figure 11-19. Atlanta receives LMI messages on Serial0 stating that three PVCs, with DLCIs 52, 53, and 54, are up. Which PVC goes with which subinterface? Cisco IOS software needs to associate the correct PVC with the correct subinterface. This is accomplished with the frame-relay interface-dlci command.

The subinterface numbers do not have to match on the router on the other end of the PVC, nor does the DLCI number. In this example, I just numbered them to be easier to remember! In real life, it is useful to encode some information about your network numbering scheme into the subinterface number. One client I worked with encoded part of the carrier's circuit ID in the subinterface number so that the operations staff could find the correct information to tell the Telco when troubleshooting the link. Many sites use the DLCI as the subinterface number. Of course, useful troubleshooting information, such as the DLCI, the name of the router on the other end of the VC, and so on, could be configured as text with the description command as well. In any case, there are no requirements for matching subinterface numbers. Here, all I did was match the subinterface number to the third octet of the IP address.

Example 11-12 shows the output from the most popular Cisco IOS software Frame Relay EXEC commands for monitoring Frame Relay, as issued on router Atlanta.

Example 11-12 Output from EXEC Commands on Atlanta

Atlanta#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

       Active   Inactive   Deleted    Static
 Local     3      0      0      0
 Switched    0      0      0      0
 Unused     0      0      0      0
DLCI = 52, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

 input pkts 843      output pkts 876     in bytes 122723
 out bytes 134431     dropped pkts 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 876    out bcast bytes 134431
 pvc create time 05:20:10, last time pvc status changed 05:19:31
 --More--
DLCI = 53, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.2

 input pkts 0       output pkts 875     in bytes 0
 out bytes 142417     dropped pkts 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 875    out bcast bytes 142417
 pvc create time 05:19:51, last time pvc status changed 04:55:41
 --More--
DLCI = 54, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.3

 input pkts 10      output pkts 877     in bytes 1274
 out bytes 142069     dropped pkts 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 877    out bcast bytes 142069
 pvc create time 05:19:52, last time pvc status changed 05:17:42

Atlanta#show frame-relay map
Serial0.3 (up): point-to-point dlci, dlci 54(0x36,0xC60), broadcast
     status defined, active
Serial0.2 (up): point-to-point dlci, dlci 53(0x35,0xC50), broadcast
     status defined, active
Serial0.1 (up): point-to-point dlci, dlci 52(0x34,0xC40), broadcast
     status defined, active

Atlanta#debug frame-relay lmi
Frame Relay LMI debugging is on
Displaying all Frame Relay LMI data

Serial0(out): StEnq, myseq 163, yourseen 161, DTE up
datagramstart = 0x45AED8, datagramsize = 13
FR encap = 0xFCF10309
00 75 01 01 01 03 02 A3 A1

Serial0(in): Status, myseq 163
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 162, myseq 163

The show frame-relay pvc command lists useful management information. For instance, the packet counters for each VC, plus the counters for FECN and BECN, can be particularly useful. Likewise, comparing the packets/bytes sent on one router versus the counters of what is received on the router on the other end of the VC is also quite useful, because it reflects the number of packets/bytes lost inside the Frame Relay cloud. Also, the PVC status is a great place to start when troubleshooting. In addition, an SNMP manager can better gather all this information with this command.

The show frame-relay map command lists mapping information. With the earlier example of a fully-meshed network, in which the configuration did not use any subinterfaces, a Layer 3 address was listed with each DLCI. In this example, a DLCI is listed in each entry, but no mention of corresponding Layer 3 addresses is made. The whole point of mapping is to correlate a Layer 3 address to a Layer 2 address, but there is no Layer 3 address in the show frame-relay map command output! The reason is that the information is stored somewhere else. Subinterfaces require the use of the frame-relay interface-dlci configuration command. Because these subinterfaces are point-to-point, when a route points out a single subinterface, the DLCI to use to send frames is implied by the configuration. Mapping via Inverse ARP or static frame-relay map statements is needed only when more than two VCs terminate on the interface or subinterface, because those are the only instances in which confusion about which DLCI to use might occur.

The debug frame-relay lmi output lists information for the sending and receiving LMI inquiries. The switch sends the status message, and the DTE (router) sends the status inquiry. The default setting with Cisco IOS software is to send, and to expect to receive, these status messages. The Cisco IOS software no keepalive command is used to disable the use of LMI status messages. Unlike other interfaces, Cisco keepalive messages do not flow from router to router over Frame Relay. Instead, they are simply used to detect whether the router has connectivity to its local Frame Relay switch.

A Partially-Meshed Network with Some Fully-Meshed Parts

You can also choose to use multipoint subinterfaces for a Frame Relay configuration. This last sample network, based on the network shown in Figure 11-20, uses both multipoint and point-to-point subinterfaces. Examples 11-13 through 11-17 show the configuration for this network. Table 11-12 summarizes the addresses and subinterfaces used.

Figure 20Figure 11-20 Hybrid of Full and Partial Mesh

Example 11-13 Router A Configuration

hostname RouterA
!
interface serial0
encapsulation frame-relay
!
interface serial 0.1 multipoint
ip address 140.1.1.1 255.255.255.0
frame-relay interface-dlci 502
frame-relay interface-dlci 503
!
interface serial 0.2 point-to-point
ip address 140.1.2.1 255.255.255.0
frame-relay interface-dlci 504
!
interface serial 0.3 point-to-point
ip address 140.1.3.1 255.255.255.0
frame-relay interface-dlci 505
!
interface ethernet 0
ip address 140.1.11.1 255.255.255.0

Example 11-14 Router B Configuration

hostname RouterB
!
interface serial0
encapsulation frame-relay
!
interface serial 0.1 multipoint
ip address 140.1.1.2 255.255.255.0
frame-relay interface-dlci 501
frame-relay interface-dlci 503
!
interface ethernet 0
ip address 140.1.12.2 255.255.255.0

Example 11-15 Router C Configuration

hostname RouterC
!
interface serial0
encapsulation frame-relay
!
interface serial 0.1 multipoint
ip address 140.1.1.3 255.255.255.0
frame-relay interface-dlci 501
frame-relay interface-dlci 502
!
interface ethernet 0
ip address 140.1.13.3 255.255.255.0

Example 11-16 Router D Configuration

hostname RouterD
!
interface serial0
encapsulation frame-relay
!
interface serial 0.1 point-to-point
ip address 140.1.2.4 255.255.255.0
frame-relay interface-dlci 501
!
interface ethernet 0
ip address 140.1.14.4 255.255.255.0

Example 11-17 Router E Configuration

hostname RouterE
!
interface serial0
encapsulation frame-relay
!
interface serial 0.1 point-to-point
ip address 140.1.3.5 255.255.255.0
frame-relay interface-dlci 501
!
interface ethernet 0
ip address 140.1.15.5 255.255.255.0

Table 11-12 IP Addresses with Point-to-Point and Multipoint Subinterfaces

Router

Subnet

IP Address

Subinterface Type

A

140.1.1.0/24

140.1.1.1

Multipoint

B

140.1.1.0/24

140.1.1.2

Multipoint

C

140.1.1.0/24

140.1.1.3

Multipoint

A

140.1.2.0/24

140.1.2.1

Point-to-point

D

140.1.2.0/24

140.1.2.4

Point-to-point

A

140.1.3.0/24

140.1.3.1

Point-to-point

E

140.1.3.0/24

140.1.3.5

Point-to-point


Multipoint subinterfaces work best when you have a full mesh between a set of routers. On Routers A, B, and C, a multipoint subinterface is used for the configuration referencing the other two routers, because you can think of these three routers as forming a fully meshed subset of the network.

The term multipoint simply means that there is more than one VC, so you can send and receive to and from more than one VC on the subinterface. Like point-to-point subinterfaces, multipoint subinterfaces use the frame-relay interface-dlci command. Notice that there are two commands for each multipoint subinterface in this case, because each of the two PVCs associated with this subinterface must be identified as being used with that subinterface.

Router A is the only router using both multipoint and point-to-point subinterfaces. On Router A's multipoint Serial0.1 interface, DLCIs for Router B and Router C are listed. On Router A's other two subinterfaces, which are point-to-point, only a single DLCI needs to be listed. In fact, only one frame-relay interface-dlci command is allowed on a point-to-point subinterface, because only one VC is allowed. Otherwise, the configurations between the two types are similar.

No mapping statements are required for the configurations shown in Examples 11-13 through 11-17 because Inverse ARP is enabled on the multipoint subinterfaces by default. No mapping is ever needed for the point-to-point subinterface, because the only DLCI associated with the interface is statically configured with the frame-relay interface-dlci command.

Example 11-18 lists another show frame-relay map command, showing the mapping information learned by Inverse ARP for the multipoint subinterface. Notice that the output now includes the Layer 3 addresses! The reason is that the routes might point out a multipoint interface, but because more than one DLCI is associated with the interface, the router needs mapping information to identify the correct DLCI.

Example 11-18 Frame Relay Maps and Inverse ARP on Router C

RouterC#show frame-relay map
Serial0.1 (up): ip 140.1.1.1 dlci 501(0x1F5,0x7C50), dynamic,
       broadcast,, status defined, active
Serial0.1 (up): ip 140.1.1.2 dlci 502(0x1F6,0x7C60), dynamic,
       broadcast,, status defined, active


RouterC#debug frame-relay events
Frame Relay events debugging is on

RouterC#configure terminal
Enter configuration commands, one per line. End with Ctrl-Z.
RouterC(config)#interface serial 0.1
RouterC(config-subif)#no shutdown
RouterC(config-subif)#^Z
RouterC#

Serial0.1: FR ARP input
Serial0.1: FR ARP input
Serial0.1: FR ARP input
datagramstart = 0xE42E58, datagramsize = 30
FR encap = 0x7C510300
80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00
8C 01 01 01 7C 51 8C 01 01 03

datagramstart = 0xE420E8, datagramsize = 30
FR encap = 0x7C610300
80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00
8C 01 01 02 7C 61 8C 01 01 03

The messages about Inverse ARP in the debug frame-relay events output are not so obvious. One easy exercise is to search for the hex version of the IP addresses in the output. These addresses are highlighted in Example 11-18. For example, the first 3 bytes of 140.1.1.0 are 8C 01 01 in hexadecimal. This field starts on the left side of the output, so it is easy to recognize.

4. Foundation Summary | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020