- "Do I Know This Already?" Quiz
- Foundation Topics
- Frame Relay Configuration
- Foundation Summary
- Q&A
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
){kind=link}
){kind=link}
){kind=link}
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
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 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
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
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
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.