The first step in configuring Frame Relay is to select the interface and then enable the Frame
Relay encapsulation on the serial interface. You do this with the
encapsulation frame-relay
command. As you will notice in the following router configuration commands, there are two
options:
cisco
and
ietf
.
Router#
config t
Router(config)#interface serial 0
Router(config-if)#encapsulation frame-relay [cisco or ietf]
Cisco is the default encapsulation, which means that you have another Cisco router on the
remote end with which your router will communicate. You will use the IETF encapsulation
when communicating with a remote router that is not a Cisco device.
After you configure the encapsulation to the serial interface, you then need to add the Network
layer address, DLCI number, and LMI type. Cisco’s capability to autosense the LMI type has
greatly simplified configuration. The following router configuration shows the process of specifying
the IP address and DLCI number, but not the LMI type because it is automatically detected:
Router(config-if)#ip address 172.16.10.1 255.255.255.0
Router(config-if)#frame-relay interface-dlci 16
Router(config-if)#no shutdown
IT Certification CCIE,CCNP,CCIP,CCNA,CCSP,Cisco Network Optimization and Security Tips
Frame Relay Local Management Interface (LMI)
In 1990, the Group of Four developed extensions to the Frame Relay standard to help ease the
management and configuration burden. One of these extensions was the
Local Management
Interface (LMI)
. LMI provides for virtual circuit status messages and multicasting.
Cisco routers support three versions of the LMI standard: Cisco, ANSI, and ITU-T (Q.933a).
LMI autosense, the automatic detection of the LMI type, was introduced in IOS version 11.2. LMI
autosense determines the LMI type by rapidly trying each of them in order: ANSI, ITU-T (Q.933a),
and then Cisco. If it cannot determine the LMI type within 60 seconds, it will terminate the
autosense process and revert to the Cisco LMI type.
After LMI is established between the router and the switch, the next stage is DLCI determination
and IARP. The router will query the switch, asking what the DLCI(s) is/are for this
circuit. The router will configure itself with that DLCI(s) and query the switch to determine
the status of the circuit.
This query is the first stage of discovery. The query that is sent includes the local router’s network
information. The remote router will record the network information and reply in kind.
The local router will map the DLCI it learned from static or dynamic addressing to other network
addresses it discovered from queries.
When an IARP is made, the router updates its map table with one of three possible LMI connection
states:
Active
The connection is active, and the routers can exchange data through the PVC.
Inactive
The local connection to the Frame Relay switch is working, but the remote end of the
PVC is not communicating to the Frame Relay switch.
Deleted
No LMI keepalive information from the switch to the router is being received for this
PVC. This could be because no LMI is actually being exchanged or because the DLCI is not configured
on the ingress switch.
Figure 29.4 shows that the Chicago office PVC to Miami is deleted because the Miami office
is not receiving keepalives from the Frame Relay switch. Neither this inactive state nor this deleted
state affect the other connections (PVCs) that Chicago might have to other locations.
FIGURE 2 9 . 4
LMI connection states
PVC
DLCI = 16
LMI = inactive
Keepalive
PVC
DLCI = 17
LMI = deleted
No keepalive
management and configuration burden. One of these extensions was the
Local Management
Interface (LMI)
. LMI provides for virtual circuit status messages and multicasting.
Cisco routers support three versions of the LMI standard: Cisco, ANSI, and ITU-T (Q.933a).
LMI autosense, the automatic detection of the LMI type, was introduced in IOS version 11.2. LMI
autosense determines the LMI type by rapidly trying each of them in order: ANSI, ITU-T (Q.933a),
and then Cisco. If it cannot determine the LMI type within 60 seconds, it will terminate the
autosense process and revert to the Cisco LMI type.
After LMI is established between the router and the switch, the next stage is DLCI determination
and IARP. The router will query the switch, asking what the DLCI(s) is/are for this
circuit. The router will configure itself with that DLCI(s) and query the switch to determine
the status of the circuit.
This query is the first stage of discovery. The query that is sent includes the local router’s network
information. The remote router will record the network information and reply in kind.
The local router will map the DLCI it learned from static or dynamic addressing to other network
addresses it discovered from queries.
When an IARP is made, the router updates its map table with one of three possible LMI connection
states:
Active
The connection is active, and the routers can exchange data through the PVC.
Inactive
The local connection to the Frame Relay switch is working, but the remote end of the
PVC is not communicating to the Frame Relay switch.
Deleted
No LMI keepalive information from the switch to the router is being received for this
PVC. This could be because no LMI is actually being exchanged or because the DLCI is not configured
on the ingress switch.
Figure 29.4 shows that the Chicago office PVC to Miami is deleted because the Miami office
is not receiving keepalives from the Frame Relay switch. Neither this inactive state nor this deleted
state affect the other connections (PVCs) that Chicago might have to other locations.
FIGURE 2 9 . 4
LMI connection states
PVC
DLCI = 16
LMI = inactive
Keepalive
PVC
DLCI = 17
LMI = deleted
No keepalive
Subscribe to:
Posts (Atom)