| There are two possible Frame Relay
encapsulations. The Cisco encapsulation has a four-byte header, with
two bytes for the DLCI and two bytes to identify the packet type.
The IETF standard is in accordance with RFCs 1294 and 1490 and it
uses a two-byte header, as shown in the Figure. To configure Frame
Relay on a Cisco router to interoperate with another vendor's
equipment, IETF encapsulation and Frame Relay map entries (per
protocol) are used for more flexibility; if backward
compatibility and interoperability are required, then this is the
preferred method.
Regarding DLCI-to-Layer 3 mapping,
some administrators let inverse ARP discover the DLCIs, and then
manually map the Layer 3 addresses to DLCI numbers with the
frame-relay map command. This strategy makes it easier for support
staff to gain information on the Frame Relay network.
If the Cisco encapsulation is
configured on a serial interface, then that encapsulation applies to
all VCs on that serial interface, with the following caveat. If some
of the equipment at the destination is non-Cisco equipment and some
is Cisco equipment, the solution is to configure the Cisco
encapsulation on the interface and selectively configure IETF
encapsulation per DLCI (or vice versa). Because the default
encapsulation is Cisco, you would not have to reference it
explicitly in the encapsulation
frame-relay command:
router(config-if)#encapsulation
frame-relay
router(config-if)#frame-relay map
ip 192.1.1.7 73 ietf
If you use dynamic address mapping,
Frame Relay inverse ARP requests next-hop protocol addresses based
on a VC's DLCI address. The router then updates its mapping table
and uses the information in the table to route outgoing traffic.
Dynamic address mapping is enabled by default for all protocols
enabled on a physical interface. No additional commands are
necessary.
If you use static address mapping,
you must use the frame-relay map command to statically map
destination network protocol addresses to a designated DLCI. If your
Frame Relay environment supports LMI and inverse ARP, dynamic
address mapping will take place. Therefore, no static address
mapping is required.
Again, the encapsulation method can
be configured either on an interface or per-destination basis. The
following example represents a Frame Relay interface using IETF
frames to communicate to the two destinations shown:
Router(config-if)#encapsulation
frame-relay IETF
Router(config-if)#frame-relay map ip 131.108.123.2 48 broadcast
Router(config-if)#frame-relay map ip 131.108.123.3 49 broadcast
On the other hand, it is possible to
configure encapsulation strictly per destination. In the following
example, IETF encapsulation is configured on a per-DLCI basis. This
configuration has the same result as the configuration in the first
example.
Router(config-if)#encapsulation
frame-relay
Router(config-if)#frame-relay map ip 131.108.123.2 48 broadcast
ietf
Router(config-if)#frame-relay map ip 131.108.123.3 49 broadcast
ietf
The following example shows a case in
which most destinations use Cisco encapsulation, but one site
requires IETF encapsulation:
Router(config-if)#encapsulation
frame-relay
Router(config-if)#frame-relay map ip 131.108.123.2 48 broadcast
Router(config-if)#frame-relay map ip 131.108.123.3 49 broadcast
ietf
Router(config-if)#frame-relay map ip 131.108.123.4 50 broadcast
|