Frame Relay was
originally developed as an extension of ISDN. It was designed to enable the
circuit-switched technology to be transported on a packet-switched network. The
technology has become a stand-alone and cost-effective means of creating a WAN.
Frame Relay
switches create virtual circuits to connect remote LANs to a WAN. The Frame
Relay network exists between a LAN border device, usually a router, and the
carrier switch. The technology used by the carrier to transport the data
between the switches is not important to Frame Relay.
The
sophistication of the technology requires a thorough understanding of the terms
used to describe how Frame Relay works. Without a firm understanding of Frame
Relay, it is difficult to troubleshoot its performance.
Frame Relay has
become one of the most extensively used WAN protocols. One reason for its
popularity is that it is inexpensive compared to leased lines. Another reason
Frame Relay is popular is that configuration of user equipment in a Frame Relay
network is very simple.
This module
explains how to configure Frame Relay on a Cisco router. Frame Relay
connections are created by configuring routers or other devices to communicate
with a Frame Relay switch. The service provider usually configures the Frame
Relay switch. This helps keep end-user configuration tasks to a minimum.
Students
completing this module should be able to:
- Explain the scope and purpose
of Frame Relay
- Discuss the technology of Frame
Relay
- Compare point-to-point and
point-to-multipoint topologies
- Examine the topology of a Frame
Relay network
- Configure a Frame Relay
Permanent Virtual Circuit (PVC)
- Create a Frame Relay Map on a
remote network
- Explain the issues of a
non-broadcast multi-access network
- Describe the need for
subinterfaces and how to configure them
- Verify and troubleshoot a Frame
Relay connection
36.1
Frame Relay Concepts
36.1.1 Introducing Frame Relay
Frame Relay is an
International Telecommunication Union Telecommunications Standardization Sector
(ITU-T) and American National Standards Institute (ANSI) standard. Frame Relay
is a packet-switched, connection-oriented, WAN service. It operates at the data
link layer of the OSI reference model. Frame Relay uses a subset of the
high-level data-link control (HDLC) protocol called Link Access Procedure for
Frame Relay (LAPF). Frames carry data between user devices called data terminal
equipment (DTE), and the data communications equipment (DCE) at the edge of the
WAN.
Originally Frame Relay was designed to allow ISDN
equipment to have access to a packet-switched service on a B channel. However,
Frame Relay is now a stand-alone technology.
A Frame Relay
network may be privately owned, but it is more commonly provided as a service
by a public carrier. It typically consists of many geographically scattered
Frame Relay switches interconnected by trunk lines.
Frame Relay is
often used to interconnect LANs. When this is the case, a router on each LAN
will be the DTE. A serial connection, such as a T1/E1 leased line, will connect
the router to a Frame Relay switch of the carrier at the nearest
point-of-presence for the carrier. The Frame Relay switch is a DCE device.
Frames from one DTE will be moved across the network and delivered to other
DTEs by way of DCEs.
Computing
equipment that is not on a LAN may also send data across a Frame Relay network.
The computing equipment will use a Frame Relay access device (FRAD) as the DTE.
36.1 Frame Relay Concepts
36.1.2 Frame Relay terminology
The connection
through the Frame Relay network between two DTEs is called a virtual circuit
(VC). Virtual circuits may be established dynamically by sending signaling
messages to the network. In this case they are called switched virtual circuits
(SVCs). However, SVCs are not very common. Generally permanent virtual circuits
(PVCs) that have been preconfigured by the carrier are used. A VC is created by
storing input-port to output-port mapping in the memory of each switch and thus
linking one switch to another until a continuous path from one end of the
circuit to the other is identified.
Because it was
designed to operate on high-quality digital lines, Frame Relay provides no
error recovery mechanism. If there is an error in a frame, as detected by any
node, it is discarded without notification.
The FRAD or
router connected to the Frame Relay network may have multiple virtual circuits
connecting it to various end points. This makes it a very cost-effective
replacement for a mesh of access lines. With this configuration, each end point
needs only a single access line and interface. More savings arise as the
capacity of the access line is based on the average bandwidth requirement of
the virtual circuits, rather than on the maximum bandwidth requirement.
The various
virtual circuits on a single access line can be distinguished because each VC
has its own Data Link Connection Identifier (DLCI). The DLCI is stored in the address field of
every frame transmitted. The DLCI usually has only local significance and may
be different at each end of a VC.
36.1 Frame Relay Concepts
36.1.3 Frame Relay stack layered support
Frame Relay
functions by doing the following:
- Takes data packets from a
network layer protocol, such as IP or IPX
- Encapsulates them as the data
portion of a Frame Relay frame
- Passes them to the physical
layer for delivery on the wire
The physical layer is typically EIA/TIA-232, 449 or 530,
V.35, or X.21. The Frame Relay frame is a subset of the HDLC frame type.
Therefore it is delimited with flag fields. The 1-byte flag uses the bit
pattern 01111110. The Frame Check Sequence (FCS) is used to determine if any
errors in the layer 2 address field occurred during transmission. The FCS is
calculated prior to transmission and the result is inserted in the FCS field.
At the distance end, a second FCS value is calculated and compared to the FCS
in the frame. If the results are the same, the frame is processed. If there is
a difference, the frame is discarded. No notification is sent to the source
when a frame is discarded. Error control left to the upper layers of the OSI
model.
36.1 Frame Relay Concepts
36.1.4 Frame Relay bandwidth and flow control
The serial
connection or access link to the Frame Relay network is normally a leased line.
The speed of the line is the access speed or port speed. Port speeds are
typically between 64 kbps and 4 Mbps. Some providers offer speeds up to 45
Mbps.
Usually there are
several PVCs operating on the access link with each VC having dedicated
bandwidth availability. This is called the committed information rate (CIR).
The CIR is the rate at which the service provider agrees to accept bits on the
VC.
Individual CIRs
are normally less than the port speed. However, the sum of the CIRs will
normally be greater than the port speed. Sometimes this is a factor of 2 or 3.
Statistical multiplexing accommodates the bursty nature of computer
communications since channels are unlikely to be at their maximum data rate
simultaneously.
While a frame is
being transmitted, each bit will be sent at the port speed. For this reason,
there must be a gap between frames on a VC if the average bit rate is to be the
CIR.
The switch will
accept frames from the DTE at rates in excess of the CIR. This effectively
provides each channel with bandwidth on demand up to a maximum of the port
speed. Some service providers impose a VC maximum that is less than the port
speed. The difference between the CIR and the maximum, whether the maximum is
port speed or lower, is called the Excess Information Rate (EIR).
The time interval over which the rates are calculated is
called the committed time (Tc). The number of committed bits in Tc is the
committed burst (Bc). The extra number of bits above the committed burst, up to
the maximum speed of the access link, is the excess burst (Be).
Although the
switch accepts frames in excess of the CIR, each excess frame is marked at the
switch by setting the Discard Eligible (DE) bit to "1" in the address
field.
The switch
maintains a bit counter for each VC. An incoming frame is marked DE if it puts
the counter over Bc. An incoming frame is discarded if it pushes the counter
over Bc + Be. At the end of each Tc seconds the counter is reset. The counter
may not be negative, so idle time cannot be saved up.
Frames arriving
at a switch are queued or buffered prior to forwarding. As in any queuing
system, it is possible that there will be an excessive buildup of frames at a
switch. This causes delays. Delays lead to unnecessary retransmissions that
occur when higher-level protocols receive no acknowledgment within a set time.
In severe cases this can cause a serious drop in network throughput.
To avoid this
problem, Frame Relay switches incorporate a policy of dropping frames from a
queue to keep the queues short. Frames with their DE bit set will be dropped
first.
When a switch
sees its queue increasing, it tries to reduce the flow of frames to it. It does
this by notifying DTEs of the problem by setting the Explicit Congestion
Notification (ECN) bits in the frame address field.
The Forward ECN
(FECN) bit is set on every frame that the switch receives on the congested
link. The Backward ECN (BECN) bit is set on every frame that the switch places
onto the congested link. DTEs receiving frames with the ECN bits set are
expected to try to reduce the flow of frames until the congestion clears.
If the congestion
occurs on an internal trunk, DTEs may receive notification even though they are
not the cause of the congestion.
The DE, FECN and
BECN bits are part of the address field in the LAPF frame.
36.1
Frame Relay Concepts
36.1.5 Frame Relay address mapping and topology
When more than
two sites are to be connected, consideration must be given to the topology of
the connections between them.
Frame Relay is
unlikely to be cost-effective when only two sites are interconnected with a
point-to-point connection. Frame Relay is more cost-effective where multiple
sites must be interconnected.
WANs are often
interconnected as a star topology. A central site hosts the primary services
and is connected to each of the remote sites needing access to the
services. In a hub and spoke topology
the location of the hub is chosen to give the lowest leased line cost. When
implementing a star topology with Frame Relay, each remote site has an access link
to the frame relay cloud with a single VC. The hub has an access link with
multiple VCs, one for each remote site.
Because Frame Relay tariffs are not distance related, the hub does not
need to be in the geographical center of the network.
A full mesh
topology is chosen when services to be accessed are geographically dispersed
and highly reliable access to them is required. With full mesh, every site is
connected to every other site. Unlike with leased line interconnections, this
can be achieved in Frame Relay without additional hardware. It is necessary to configure additional VCs
on the existing links to upgrade from star to full mesh topology. Multiple VCs
on an access link will generally make better use of Frame Relay than single
VCs. This is because they take advantage of the built-in statistical
multiplexing.
For large
networks, full mesh topology is seldom affordable. This is because the number
of links required for a full mesh topology grows at almost the square of the
number of sites. While there is no equipment issue for Frame Relay, there is a
limit of less than 1000 VCs per link. In practice, the limit will be less than
that, and larger networks will generally be partial mesh topology. With partial
mesh, there are more interconnections than required for a star arrangement, but
not as many as for a full mesh. The actual pattern is very dependant on the
data flow requirements.
In any Frame
Relay topology, when a single interface is used to interconnect multiple sites,
there may be reachability issues. This is due to the nonbroadcast multiaccess
(NBMA) nature of Frame Relay. Split horizon is a technique used by routing
protocols to prevent routing loops. Split horizon does not allow routing
updates to be sent out the same interface that was the source of the route
information. This can cause problems with routing updates in a Frame Relay
environment where multiple PVCs are on a single physical interface.
Whatever the
underlying topology of the physical network, a mapping is needed in each FRAD
or router between a data link layer Frame Relay address and a network layer
address, such as an IP address. Essentially, the router needs to know what
networks are reachable beyond a particular interface. The same problem exists
if an ordinary leased line is connected to an interface. The difference is that
the remote end of a leased line is connected directly to a single router.
Frames from the DTE travel down a leased line as far as a network switch, where
they may fan out to as many as 1000 routers. The DLCI for each VC must be
associated with the network address of its remote router. This information can
be configured manually by using map commands. The DLCI can also be configured
automatically using Inverse ARP.
36.1
Frame Relay Concepts
36.1.6 Frame Relay LMI
Frame Relay was
designed to provide packet-switched data transfer with minimal end-to-end
delays. Anything that might contribute to delays was omitted. When vendors
implemented Frame Relay as a separate technology rather than as one component
of ISDN, they decided that there was a need for DTEs to dynamically acquire
information about the status of the network. This feature was omitted in the
original design. The extensions for this status transfer are called the Local
Management Interface (LMI).
The 10-bit DLCI
field allows VC identifiers 0 through 1023. The LMI extensions reserve some of
these identifiers. This reduces the number of permitted VCs. LMI messages are
exchanged between the DTE and DCE using these reserved DLCIs.
The LMI
extensions include the following:
- The keepalive mechanism, which
verifies that a VC is operational
- The multicast mechanism
- The flow control
- The ability to give DLCIs
global significance
- The VC status mechanism
There are several
LMI types, each of which is incompatible with the others. The LMI type
configured on the router must match the type used by the service provider.
Three types of LMIs are supported by Cisco routers:
- Cisco - The original LMI
extensions
- Ansi - Corresponding to the
ANSI standard T1.617 Annex D
- q933a - Corresponding to the
ITU standard Q933 Annex A
LMI messages are
carried in a variant of LAPF frames. This variant includes four extra fields in
the header so that they will be compatible with the LAPD frames used in ISDN. The
address field carries one of the reserved DLCIs. Following this are the
control, protocol discriminator, and call reference fields that do not change.
The fourth field indicates the LMI message type.
There are one or
more information elements (IE) that follow the header. Each IE consists of the
following:
- A one byte IE identifier
- An IE length field
- One or more bytes containing
actual data that typically includes the status of a DLCI
Status messages
help verify the integrity of logical and physical links. This information is
critical in a routing environment because routing protocols make decisions
based on link integrity.
36.1 Frame Relay Concepts
36.1.7 Stages of Inverse ARP and LMI operation
LMI status
messages combined with Inverse ARP messages allow a router to associate network
layer and data link layer addresses.
When a router
that is connected to a Frame Relay network is started, it sends an LMI status
inquiry message to the network. The network replies with an LMI status message
containing details of every VC configured on the access link.
Periodically the
router repeats the status inquiry, but subsequent responses include only status
changes. After a set number of these abbreviated responses, the network will
send a full status message.
If the router
needs to map the VCs to network layer addresses, it will send an Inverse ARP
message on each VC. The Inverse ARP message includes the network layer address
of the router, so the remote DTE, or router, can also perform the mapping. The
Inverse ARP reply allows the router to make the necessary mapping entries in
its address to DLCI map table. If several network layer protocols are supported
on the link, Inverse ARP messages will be sent for each.
36.2
Configuring Frame Relay
36.2.1 Configuring basic Frame Relay
This section
explains how to configure a basic Frame Relay PVC. Frame Relay is configured on a serial
interface. The default encapsulation type is the Cisco proprietary version of
HDLC. To change the encapsulation to Frame Relay use the encapsulation
frame-relay[cisco | ietf] command.
cisco
Uses the Cisco proprietary Frame Relay
encapsulation. Use this option if connecting to another Cisco router. Many
non-Cisco devices also support this encapsulation type. This is the default.
ietf
Sets the encapsulation method to comply with
the Internet Engineering Task Force (IETF) standard RFC 1490. Select this if
connecting to a non-Cisco router.
Cisco's
proprietary Frame Relay encapsulation uses a 4-byte header, with 2 bytes to
identify the data-link connection identifier (DLCI) and 2 bytes to identify the
packet type.
Set an IP address
on the interface using the ip address command. Set the bandwidth of the serial
interface using the bandwidth command. Bandwidth is specified in kilobits per
second (kbps). This command is used to notify the routing protocol that
bandwidth is statically configured on the link. The bandwidth value is used by
Interior Gateway Routing Protocol (IGRP), Enhanced Interior Gateway Routing
Protocol (EIGRP), and Open Shortest Path First (OSPF) to determine the metric
of the link.
The LMI
connection is established and configured by the frame-relay lmi-type [ansi |
cisco | q933a] command. This command is only needed if using Cisco IOS Release
11.1 or earlier. With IOS Release 11.2 or later, the LMI-type is autosensed and
no configuration is needed. The default LMI type is cisco. The LMI type is set
on a per-interface basis and is shown in the output of the show interfaces
command.
These
configuration steps are the same, regardless of the network layer protocols
operating across the network.
36.2 Configuring Frame Relay
36.2.2 Configuring a static Frame Relay map
The local DLCI
must be statically mapped to the network layer address of the remote router
when the remote router does not support Inverse ARP. This is also true when
broadcast traffic and multicast traffic over the PVC must be controlled. These
static Frame Relay map entries are referred to as static maps.
Use the frame-relay
map protocol protocol-address dlci [broadcast] command to statically map the
remote network layer address to the local DLCI.
36.2 Configuring Frame Relay
36.2.3 Reachability issues with routing updates in
NBMA
By default, a Frame Relay network provides non-broadcast
multi-access (NBMA) connectivity between remote sites. An NBMA environment is
viewed like other multiaccess media environments, such as Ethernet, where all
the routers are on the same subnet. However, to reduce cost, NBMA clouds are
usually built in a hub-and-spoke topology. With a hub-and-spoke topology, the
physical topology does not provide the multi-access capabilities that Ethernet
does. The physical topology consists of
multiple PVCs.
A Frame Relay
NBMA topology may cause two problems:
- Reachability issues regarding
routing updates
- The need to replicate
broadcasts on each PVC when a physical interface contains more than one
PVC
Split-horizon
updates reduce routing loops by not allowing a routing update received on one
interface to be forwarded out the same interface. If Router B, a spoke router,
sends a broadcast routing update to Router A, the hub router, and Router A has
multiple PVCs over a single physical interface, then Router A cannot forward
that routing update through the same physical interface to other remote spoke
routers. If split-horizon is disabled, then the routing update can be forwarded
out the same physical interface from which it came. Split-horizon is not a
problem when there is a single PVC on a physical interface. This would be a
point-to-point Frame Relay connection.
Routers that
support multiple connections over a single physical interface have many PVCs
that terminate in a single router. This router must replicate broadcast packets
such as routing update broadcasts, on each PVC, to the remote routers. The
replicated broadcast packets can consume bandwidth and cause significant
latency to user traffic. It might seem logical to turn off split-horizon to
resolve the reachability issues caused by split-horizon. However, not all
network layer protocols allow split-horizon to be disabled and disabling
split-horizon increases the chances of routing loops in any network.
One way to solve
the split-horizon problem is to use a fully meshed topology. However, this will
increase the cost because more PVCs are required. The preferred solution is to
use subinterfaces.
36.2 Configuring Frame Relay
36.2.4 Frame Relay subinterfaces
To enable the
forwarding of broadcast routing updates in a hub-and-spoke Frame Relay
topology, configure the hub router with logically assigned interfaces. These
interfaces are called subinterfaces. Subinterfaces are logical subdivisions of
a physical interface.
In split-horizon routing environments, routing updates
received on one subinterface can be sent out another subinterface. In a
subinterface configuration, each virtual circuit can be configured as a
point-to-point connection. This allows each subinterface to act similarly to a
leased line. Using a Frame Relay point-to-point subinterface, each pair of the
point-to-point routers is on its own subnet.
Frame Relay
subinterfaces can be configured in either point-to-point or multipoint mode:
- Point-to-point
- A single point-to-point subinterface is used to establish one PVC
connection to another physical interface or subinterface on a remote
router. In this case, each pair of the point-to-point routers is on its
own subnet and each point-to-point subinterface would have a single DLCI.
In a point-to-point environment, each subinterface is acting like a
point-to-point interface. Therefore, routing update traffic is not subject
to the split-horizon rule.
- Multipoint -
A single multipoint subinterface is used to establish multiple PVC
connections to multiple physical interfaces or subinterfaces on remote
routers. All the participating interfaces would be in the same subnet. The
subinterface acts like an NBMA Frame Relay interface so routing update
traffic is subject to the split-horizon rule.
The encapsulation
frame-relay command is assigned to the physical interface. All other
configuration items, such as the network layer address and DLCIs, are assigned
to the subinterface.
Multipoint
configurations can be used to conserve addresses that can be especially helpful
if Variable Length Subnet Masking (VLSM) is not being used. However, multipoint
configurations may not work properly given the broadcast traffic and
split-horizon considerations. The point-to-point subinterface option was
created to avoid these issues.
36.2 Configuring Frame Relay
36.2.5 Configuring Frame Relay subinterfaces
The Frame Relay
service provider will assign the DLCI numbers. These numbers range from 16 to
992, and usually have only local significance. This number range will vary
depending on the LMI used. DLCIs can have global significance in certain
circumstances.
In the figure,
Router A has two point-to-point subinterfaces. The s0/0.110 subinterface
connects to router B and the s0/0.120 subinterface connects to router C. Each
subinterface is on a different subnet. To configure subinterfaces on a physical
interface, the following steps are required:
- Configure Frame Relay
encapsulation on the physical interface using the encapsulation
frame-relay command
- For each of the defined PVCs, create
a logical subinterface
router(config-if)#interface
serialnumber.subinterface-number [multipoint | point-to-point]
To create a
subinterface, use the interface serial command. Specify the port number,
followed by a period (.), and then by the subinterface number. Usually, the
subinterface number is chosen to be that of the DLCI. This makes
troubleshooting easier. The final required parameter is stating whether the
subinterface is a point-to-point or point-to-multipoint interface. Either the
multipoint or point-to-point keyword is required. There is no default. The
following commands create the subinterface for the PVC to router B:
routerA(config-if)#interface
serial 0/0.110 point-to-point
If the
subinterface is configured as point-to-point, then the local DLCI for the
subinterface must also be configured in order to distinguish it from the
physical interface. The DLCI is also required for multipoint subinterfaces for
which Inverse ARP is enabled. It is not required for multipoint subinterfaces
configured with static route maps. The frame-relay interface-dlci command is
used to configure the local DLCI on the subinterface
router(config-subif)#frame-relay
interface-dlci dlci-number
36.2
Configuring Frame Relay
36.2.6 Verifying the Frame Relay configuration
The show
interfaces command displays information regarding the encapsulation and Layer 1
and Layer 2 status. It also displays information about the following:
- The LMI type
- The LMI DLCI
- The Frame Relay data terminal
equipment/data circuit-terminating equipment (DTE/DCE) type
Normally, the
router is considered a data terminal equipment (DTE) device. However, a Cisco
router can be configured as a Frame Relay switch. The router becomes a data
circuit-terminating equipment (DCE) device when it is configured as a Frame
Relay switch.
Use the show
frame-relay lmi command to display LMI traffic statistics. For example, this command demonstrates the
number of status messages exchanged between the local router and the local
Frame Relay switch.
Use the show
frame-relay pvc [interface interface] [dlci] command to display the status of
each configured PVC as well as traffic statistics. This command is also useful for viewing the
number of BECN and FECN packets received by the router. The PVC status can be
active, inactive, or deleted.
The show
frame-relay pvc command displays the status of all the PVCs configured on the
router. Specifying a PVC will show the status of only that PVC. In Figure , the
show frame-relay pvc 100 command displays the status of only PVC 100.
Use the show
frame-relay map command to display the current map entries and information
about the connections. The following information interprets the show
frame-relay map output that appears in Figure :
- 10.140.1.1 is the IP address of
the remote router, dynamically learned via the Inverse ARP process
- 100 is the decimal value of the
local DLCI number
- 0x64 is the hex conversion of
the DLCI number, 0x64 = 100 decimal
- 0x1840 is the value as it would
appear on the wire because of the way the DLCI bits are spread out in the
address field of the Frame Relay frame
- Broadcast/multicast is enabled
on the PVC
- PVC status is active
To clear
dynamically created Frame Relay maps, which are created using Inverse ARP, use
the clear frame-relay-inarp command.
36.2 Configuring Frame Relay
36.2.7
Troubleshooting the Frame Relay configuration
Use the debug
frame-relay lmi command to determine whether the router and the Frame Relay
switch are sending and receiving LMI packets properly. The "out" is an LMI status message
sent by the router. The "in" is a message received from the Frame
Relay switch. A full LMI status message is a "type 0". An LMI
exchange is a "type 1". The "dlci 100, status 0x2" means
that the status of DLCI 100 is active. The possible values of the status field
are as follows:
- 0x0
- Added/inactive means that the switch has this DLCI programmed but for
some reason it is not usable. The reason could possibly be the other end
of the PVC is down.
- 0x2
- Added/active means the Frame Relay switch has the DLCI and everything is
operational.
- 0x4
- Deleted means that the Frame Relay switch does not have this DLCI
programmed for the router, but that it was programmed at some point in the
past. This could also be caused by the DLCIs being reversed on the router,
or by the PVC being deleted by the service provider in the Frame Relay
cloud.
Summary
An understanding
of the following key points should have been achieved:
- The scope and purpose of Frame
Relay
- The technology of Frame Relay
- Point-to-point and
point-to-multipoint topologies
- The topology of a Frame Relay
network
- How to configure a Frame Relay
Permanent Virtual Circuit (PVC)
- How to create a Frame Relay Map
on a remote network
- Potential problems with routing
in a non-broadcast multi-access network
- Why subinterfaces are needed
and how they are configured
- How to verify and troubleshoot
a Frame Relay connection
No comments:
Post a Comment