Frame Relay Configuration Basics
Two of the most important details regarding Frame Relay configuration are the association of DLCIs with the correct interface or subinterface, and the mapping of L3 addresses to those DLCIs. Interesting, both features can be configured using the same two commands—the frame-relay map and frame-relay interface-dlci commands. Chapter 7 already covered the details of mapping L3 addresses to DLCIs using InARP and static mapping. (If you have not reviewed those
Table 18-3 Frame Relay FECN, BECN, and DE Summary
|
Bit |
Meaning When Set |
Where Set |
|
FECN |
Congestion in the same direction as this frame |
By FR switches in user frames |
|
BECN |
Congestion in the opposite direction of this frame |
By FR switches or routers in user or Q.922 test frames |
|
DE |
This frame should be discarded before non-DE frames |
By routers or switches in user frames |
details since starting this chapter, it is probably a good time to do so.) This section focuses more on the association of DLCIs with a particular subinterface.
Although a router can learn each DLCI on the access link via LMI Status messages, these messages do not imply with which subinterface each DLCI should be used. To configure Frame Relay using subinterfaces, the DLCIs must be associated with the subinterface. Any DLCIs learned with LMI that are not associated with a subinterface are assumed to be used by the physical interface.
The more common method to make this association is to use the frame-relay interface-dlci subinterface subcommand. On point-to-point subinterfaces, only a single frame-relay interface-dlci command is allowed, whereas multipoint interfaces support multiple commands. The alternative method is to use the frame-relay map command. This command still maps Layer 3 addresses to DLCIs, but also implies an association of the configured DLCI with the subinterface under which the command is issued. And similar to frame-relay interface-dlci commands, only one frame-relay map command is allowed per point-to-point subinterface, per Layer 3 protocol. On multipoint subinterfaces, multiple commands are allowed per Layer 3 protocol.
Example 18-1 depicts a wide variety of Frame Relay configuration options, using frame-relay interface-dlci commands, and the related show commands. Based on Figure 18-4, this example implements the following requirements:
■ R1 uses a multipoint subinterface to connect to R2 and R3.
■ R1 uses a point-to-point subinterface to connect to R4.
■ The VC between R1 and R4 uses IETF encapsulation.
Figure 18-4 Sample FR Network for Configuration Examples
Network 10.0.0.0
Figure 18-4 Sample FR Network for Configuration Examples
Network 10.0.0.0
- Subnet 10.1.14.0/24, Point-to-Point Subinterfaces
IETF
Encapsulation
! R1 configuration begins the example. Subint .14 shows the IETF option used on ! the frame-relay interface-dlci command. Subint .123 has two DLCIs associated ! with it, for the VCs to R2 and R3. interface Serial0/0/0 encapsulation frame-relay
interface Serial0/0/0.14 point-to-point ip address 10.1.14.1 255.255.255.0 frame-relay interface-dlci 104 IETF
interface Serial0/0/0.123 multipoint ip address 10.1.123.1 255.255.255.0 frame-relay interface-dlci 102 frame-relay interface-dlci 103
! R2 configuration comes next. R2 assigns the DLCI for the VC to R1 and R3 to the ! .123 subinterface. Note the routers' subint numbers do not have to match. interface Serial0/0/0 encapsulation frame-relay
interface Serial0/0/0.123 multipoint ip address 10.1.123.2 255.255.255.0 frame-relay interface-dlci 101 frame-relay interface-dlci 103
! R3 configuration follows the same conventions as does R2's and is not shown. ! R4's configuration follows next, with the encapsulation frame-relay ietf command ! setting the encapsulation for all the VCs on interface s0/0/0. Also note that ! the frequency of LMI enquiries was changed from the default (10) to 8 with the ! keepalive 8 command. interface Serial0/0/0 encapsulation frame-relay IETF keepalive 8
interface Serial0/0/0.1 point-to-point ip address 10.1.14.4 255.255.255.0 frame-relay interface-dlci 101
|
DLCI |
= 100, |
DLCI |
USAGE = |
UNUSED |
PVC |
STATUS |
= INACTIVE, INTERFACE |
= Serial0/0/0 |
|
|
DLCI |
= 102, |
DLCI |
USAGE = |
LOCAL, |
PVC |
STATUS = |
ACTIVE, |
INTERFACE = |
Serial0/0/0.123 |
|
DLCI |
= 103, |
DLCI |
USAGE = |
LOCAL, |
PVC |
STATUS = |
ACTIVE, |
INTERFACE = |
Serial0/0/0.123 |
|
DLCI |
= 104, |
DLCI |
USAGE = |
LOCAL, |
PVC |
STATUS = |
ACTIVE, |
INTERFACE = |
Serial0/0/0.14 |
|
DLCI |
= 105, |
DLCI |
USAGE = |
UNUSED, |
PVC |
STATUS |
= ACTIVE |
INTERFACE = |
Serial0/0/0 |
|
DLCI |
= 106, |
DLCI |
USAGE = |
UNUSED, |
PVC |
STATUS |
= INACTIVE, INTERFACE |
= Serial0/0/0 |
|
|
DLCI |
= 107, |
DLCI |
USAGE = |
UNUSED, |
PVC |
STATUS |
= ACTIVE |
INTERFACE = |
Serial0/0/0 |
|
DLCI |
= 108, |
DLCI |
USAGE = |
UNUSED, |
PVC |
STATUS |
= ACTIVE |
INTERFACE = |
Serial0/0/0 |
|
DLCI |
= 109, |
DLCI |
USAGE = |
UNUSED, |
PVC |
STATUS |
= INACTIVE, INTERFACE |
= Serial0/0/0 |
|
DLCI = 110, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0/0 ! The next command lists stats for a single VC on R1, with DLCI 102, which is the ! VC to R2. Note the counters for FECN, BECN, and DE, as well as the in and out ! bit rates just for this VC. R1# show frame-relay pvc 102
PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0.123
input pkts 41 out bytes 5491 out pkts dropped 0 in FECN pkts 0 out BECN pkts 0 out bcast pkts 27
in bytes 4615 in pkts dropped 0
out FECN pkts 0 out DE pkts 0
output pkts 54 dropped pkts 0 out bytes dropped 0 in BECN pkts 0 in DE pkts 0 out bcast bytes 1587 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 00:29:37, last time pvc status changed 00:13:47
The following output confirms that R1s link is using the Cisco LMI standard. Full LMI Status messages occur about every minute, with the Last Full Status message listed last. Note that the router sends Status Enquiries to the switch, with the switch sending Status messages; those counters should increment together. R1# show frame-relay lmi
LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid dummy Call Ref 0 Invalid Status Message 0 Invalid Information ID 0 Invalid Report Request 0 Num Status Enq. Sent 183 Num Update Status Rcvd 0 Last Full Status Req 00:00:35
Invalid Prot Disc 0 Invalid Msg Type 0 Invalid Lock Shift 0 Invalid Report IE Len 0 Invalid Keep IE Len 0 Num Status msgs Rcvd 183 Num Status Timeouts 0 Last Full Status Rcvd 00:0
The show interface command lists several details as well, including the interval for LMI messages (keepalive), LMI stats, LMI DLCI (1023), and stats for the FR broadcast queue. The broadcast queue holds FR broadcasts that must be replicated and sent over this VC, for example, OSPF LSAs. R1# show int s 0/0/0
Serial0/0/0 is up, line protocol is up ! lines omitted for brevity Encapsulation FRAME-RELAY, loopback not set Keepalive set (10 sec)
LMI enq sent 185, LMI stat recvd 185, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE FR SVC disabled, LAPF state down
Broadcast queue 0/64, broadcasts sent/dropped 274/0, interface broadcasts 228 ! Lines omitted for brevity
! R3 is using ANSI LMI, which uses DLCI 0, as confirmed next.
R3# sh frame lmi | include LMI TYPE
LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = ANSI
LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE
At the end of Example 18-1, note that R3 is using the ANSI LMI type. R3 could have configured the LMI type statically using the frame-relay lmi-type {ansi | cisco | q933a} command, under the physical interface. However, R3 omitted the command, causing R3 to take the default action of autosensing the LMI type.
Continue reading here: Do I Know This Already Quiz Rli
Was this article helpful?