Frame Relay

Frame Relay Overview
 Frame Relay defines the

interconnection process between the
DTE and the DCE (the Frame Relay
network switch, not the CSU/DSU).
– It does not define the way the data is
transmitted within the service provider’s
Frame Relay cloud.
What Is Frame Relay?
Frame Relay defines the interconnection process between a

router and the service provider’s local access switching equipment.
NBMA - Non-Broadcast Multiple Access
 Frame Relay networks are known as NBMA,
Nonbroadcast Multi-Access networks.
 NBMA networks allow a router to set up and
maintain several logical connections over a single
physical serial interface.
 The “cloud” is a single network to which multiple
devices are attached.
 Unlike Ethernet and Token Ring, which are
broadcast networks, non-broadcast networks
means a packet sent into the network might not
be seen by all other routers attached to the
network.
Frame Relay Terminology #1
 Local access rate (LAR)
– The maximum physical media speed of the link
used by the Frame Relay interface. Frame Relay may
or may not use this full bandwidth, but cannot exceed
it
• Common local access rates include T1 (1.544 Mbps) and
could be up to T3 (44.476 Mbps).
 Committed information rate (CIR)
– The transmission rate that the frame relay provider
guarantees without frame drops
• Any frames sent above this rate has the DE bit set to one
allowing them to be dropped if congestion occurs.
• Monthly service charge is based heavily on this rate.
Frame Relay Terminology #2
 Excess burst
– The maximum bits that the Frame Relay
switch will attempt to transfer beyond the CIR.
Can not exceed the local access rate .
Frame Relay Operation
DLCIs
 A data-link connection identifier (DLCI)
identifies the logical VC between the CPE
and the Frame Relay switch.
 The Frame Relay switch maps the DLCIs
between each pair of routers to create a PVC.
 DLCIs have local significance
 Your Frame Relay provider sets up the DLCI
numbers to be used by the routers for
establishing PVCs.
DLCI Mapping to Network
Address
 Manual
– Manual: Administrators use a frame relay map
statement.
 Dynamic:
– Inverse Address Resolution Protocol (I-ARP)
provides a given DLCI and requests next-hop
protocol addresses for a specific connection.
– The router then updates its mapping table and
uses the information in the table to forward
packets on the correct route.
Inverse ARP
– The Inverse ARP mechanism allows the
router to automatically build the Frame
Relay map.
– The router learns the DLCIs that are in use
from the switch during the initial LMI
exchange and then sends an Inverse ARP
request to each DLCI for each protocol
configured on the interface if the protocol is
supported.
– The return information, the remote
network address, from the Inverse ARP is
then used to build the Frame Relay map.
Minimum Frame Relay Configuration
HubCity(config)# interface serial 0
HubCity(config-if)# ip address 172.16.1.2 255.255.255.0
HubCity(config-if)# encapsulation frame-relay
Spokane(config)# interface serial 0

Spokane(config-if)# ip address 172.16.1.1 255.255.255.0
Spokane(config-if)# encapsulation frame-relay
172.16.1.2 172.16.1.1
Frame Relay
DLCI 101 Network DLCI 102
Headquarters Satellite Office 1
Hub City Spokane
Router(config-if)#encapsulation frame-
relay [cisco | ietf]
 cisco is the default. Use this if

connecting to another Cisco router.
 ietf—Select this if connecting to a non-
Cisco router. - RFC 1490
 Cisco Router is now ready to act as a
Frame-Relay DTE device.
The following process occurs:

1. The interface is enabled.
2. The Frame-Relay switch announces the
configured DLCI(s) to the router.
3. Inverse ARP is performed to map remote
network layer addresses to the local
DLCI(s).
The routers can now ping each other!

Inverse ARP
172.16.1.2 172.16.1.1
Frame Relay
DLCI 101 Network DLCI 102
Headquarters Satellite Office 1
Hub City Spokane
HubCity# show frame-relay map

Serial0 (up): ip 172.16.1.1 dlci 101, dynamic,
broadcast, status defined, active
(dynamic refers to the router learning the ip address via
Inverse ARP)
Inverse ARP Limitations
Limitation of Inverse ARP

Inverse ARP only resolves network
addresses of remote Frame-Relay
connections that are directly connected.
NBMA Topologies
A Frame-Relay Configuration Supporting Multiple
Sites Headquarters
Hub City
• This is known as Hub Router
a Hub and Spoke DLCI 101 DLCI 112
Topology, where
172.16.1.2
the Hub router
relays information
between the Spoke
routers.
Frame Relay
• Limits the Network
number of PVCs
needed as in a full-
mesh topology DLCI 102 DLCI 211
(coming).
172.16.1.1 172.16.1.3
Spoke
Satellite Office 1 Routers Satellite Office 2
Spokane
Spokomo
Configuration using Inverse ARP:
HubCity
interface Serial0
ip address 172.16.1.2 255.255.255.0
encapsulation frame-relay
Spokane
interface Serial0
ip address 172.16.1.1 255.255.255.0
Spokomo
interface Serial0
ip address 172.16.1.3 255.255.255.0
Spokane# show frame-relay map

Spokomo# show frame-relay map

Notice:
 Inverse ARP resolved the ip
addresses for HubCity for both
Spokane and Spokomo
addresses for Spokane for HubCity
addresses for Spokomo for HubCity
Inverse ARP Limitations
 Can HubCity ping both Spokane and Spokomo?
Yes!
 Can Spokane and Spokomo ping HubCity? Yes!
 Can Spokane and Spokomo ping each other? No!
The router’s serial interface (spoke routers) drops
the ICMP packet because there is no DLCI-to-IP
address mapping for the destination address.
Solutions to the limitations of Inverse ARP

1. Add an additional PVC between Spokane and
Spokomo (Full Mesh)
2. Configure Frame-Relay Map Statements
3. Configure Point-to-Point Subinterfaces.
Full Mesh Solution Does Not Scale Well
Full Mesh Topology (n*(n-1)) / 2

Number of Number of
Connections PVCs
----------------- --------------
2 1
4 6
6 15
8 28
10 45
Frame Relay Map Statements
Instead of using additional PVCs, Frame-Relay

map statements can be used to:
 Statically map local DLCIs to an unknown
remote network layer addresses.
 Also used when the remote router does
not support Inverse ARP
Router(config-if)# frame-relay map protocol
protocol-address dlci [broadcast] [ietf |
cisco | payload-compress packet-by-
packet]
 broadcast (Optional) Forwards broadcasts to this

address when multicast is not enabled. Use this if
you want the router to forward routing updates. If
not enabled, you must define static routes, and if
using IPX, static SAPs.
 ietf | cisco (Optional) Select the Frame Relay

encapsulation type for use. Use ietf only if the
remote router is a non-Cisco router. Otherwise, use
cisco
Frame-Relay Map Statements
HubCity
interface Serial0
ip address 172.16.1.2 255.255.255.0 Headquarters
encapsulation frame-relay Hub City
(Inverse-ARP still works here)
DLCI 101 DLCI 112
Spokane
interface Serial0 172.16.1.2
ip address 172.16.1.1 255.255.255.0
frame-relay map ip 172.16.1.3 102
frame-relay map ip 172.16.1.2 102 Frame Relay
Network
Spokomo
interface Serial0
ip address 172.16.1.3 255.255.255.0
DLCI 102 DLCI 211
172.16.1.1 172.16.1.3
Satellite Office 1 Satellite Office 2

Spokane Spokomo
Mixing Inverse ARP and Frame
Relay Map Statements
 What if we were to use I-ARP between
the spoke routers and the hub, and
frame relay map statements between
the two spokes?
 There would be a problem!
HubCity
interface Serial0 Headquarters
ip address 172.16.1.2 255.255.255.0 Hub City
DLCI 101 DLCI 112
Spokane
interface Serial0 172.16.1.2
ip address 172.16.1.1 255.255.255.0

Frame Relay
Spokomo Network
interface Serial0
ip address 172.16.1.3 255.255.255.0
encapsulation frame-relay DLCI 102 DLCI 211
172.16.1.1 172.16.1.3

Spokane Spokomo
Serial0 (up): ip 172.16.1.1 dlci 101, dynamic, broadcast,
status defined, active
Serial0 (up): ip 172.16.1.3 dlci 102, static, CISCO,
status defined, active (static = learned via fr map
statement)
status defined, active (static = learned via fr map
statement)
Good News:
 Everything looks fine!
 Now all routers can ping each other!
Bad News:
 Problem when using Frame-Relay
map statements AND Inverse ARP.
 This will only work until the router is
reloaded, here is why...
Frame-Relay Map Statement Rule:
When a Frame-Relay map statement is

configured for a particular protocol (IP,
IPX, …) Inverse-ARP will be disabled
for that specific protocol, only for the
DLCI referenced in the Frame-Relay
map statement.
 The previous solution worked only because the
Inverse ARP had taken place between Spokane and
HubCity, and between Spokomo and HubCity, before
the Frame-Relay map statements were added.
(The Frame-Relay map statement was added after
the Inverse ARP took place.)
 Both the Inverse-ARP and Frame-Relay map
statements are in effect.
 Once the router is reloaded (rebooted) the Inverse-
ARP will never occur because of the configured
Frame-Relay map statement. (assuming the running-
config is copied to the startup-config)
 Rule: Inverse-ARP will be disabled for that
specific protocol, for the DLCI referenced in the
Frame-Relay map statement.
HubCity# show frame-relay map (after reload)
NOW MISSING: Serial0 (up): ip 172.16.1.2 dlci 102,
dynamic, broadcast, status defined, active
NOW MISSING: Serial0 (up): ip 172.16.1.2 dlci 211,
dynamic, broadcast, status defined, active
HubCity# show frame-relay map (after reload)
Spokane and Spokomo can no longer ping HubCity!

Solution: Wherever there are Inverse-ARP
statements, replace them with Frame-Relay
map statements.
Frame-Relay Map Statements - Solution
HubCity
interface Serial0
ip address 172.16.1.2 255.255.255.0
encapsulation frame-relay Headquarters
(Inverse-ARP still works here) Hub City
Spokane
interface Serial0
DLCI 101 DLCI 112
ip address 172.16.1.1 255.255.255.0
encapsulation frame-relay 172.16.1.2
Spokomo
interface Serial0 Frame Relay
ip address 172.16.1.3 Network
255.255.255.0
frame-relay map ip 172.16.1.1 211 DLCI 102 DLCI 211
172.16.1.1 172.16.1.3

Spokane Spokomo
Local Management Interface
LMI
 LMI is a signaling standard between the
CPE device and the Frame Relay
switch that is responsible for managing
the connection and maintaining status
between the devices. LMI includes:
– A keepalive mechanism, which verifies that
data is flowing
– A multicast mechanism, which provides the
network server (router) with its local DLCI
– A status mechanism, which provides an
ongoing status on the DLCIs known to the
switch
The router must be programmed to choose
which LMI type encapsulation will be used.
If using Cisco IOS Release 11.1 or earlier,

specify the LMI-type used by the FR switch:
Router(config-if)#frame-relay lmi-type {ansi |
cisco | q933a}
 cisco is the default.
With IOS Release 11.2 or later, the LMI-type is

autosensed so no configuration is needed.
LMI Autosensing
 Beginning in Cisco IOS Release 11.2, the
router tries to autosense which LMI type the
Frame Relay switch is using by sending one
or more full status requests to the Frame
Relay switch.
 The Frame Relay switch responds with the
LMI type.
 The router configures itself with the LMI type
received.
FR Configuration Example
For routing metric

information
FR Configuration
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
Early Implementations of Frame Relay
Required that a router (DTE device) must have a WAN serial
interface for every permanent virtual circuit (PVC)

Early Implementations of Frame Relay
 Early implementation of Frame Relay

Technology required that a router (DTE
device) must have a WAN serial interface for
every permanent virtual circuit (PVC).
 This was effective but increased the cost
because of the increased number of
interfaces, WAN connections, at the hub
router.
Multipoint Physical Interface (and multipoint
subinterfaces) and Split Horizon
 A single physical interface works, but Split Horizon
prohibits distance vector routing updates from
propagating out the same physical interface that it
received the update.
Solution: No Split Horizon with
Point-to-point Subinterfaces
FR and Subinterfaces
FR and Subinterfaces
Two types of subinterfaces are available
on Cisco routers:
1. point-to-point subinterfaces
2. multipoint subinterfaces
 By using point-to-point subinterfaces,

Cisco routers can treat each PVC as if it
were a separate point-to-point interface
on the router.
Hub Router:
•Point-to-point subinterfaces: Each subinterface is on its own subnet. Broadcasts and
Split Horizon not a problem because each point-to-point connection is its own subnet.
•Multipoint subinterfaces: All participating subinterfaces would be in the same subnet.
Broadcasts and routing updates are also subject to the Split Horizon Rule and may pose
a problem.
Frame Relay and Split Horizon
 Physical interfaces: With a hub and spoke topology
Split Horizon will prevent the hub router from
propagating routes learned from one spoke router to
another spoke router.
 Point-to-point subinterfaces: Each subinterface is on
its own subnet. Broadcasts and Split Horizon not a
problem because each point-to-point connection is its
own subnet.
 Multipoint subinterfaces: All participating
subinterfaces would be in the same subnet.
Broadcasts and routing updates are also subject to the
Split Horizon Rule and may pose a problem.
Point-to-point subinterfaces are like conventional
point-to-point interfaces (PPP, …) and have no
concept of (do not need):
 Inverse-ARP
 mapping of local DLCI address to remote network

address (frame-relay map statements)
Frame-Relay service supplies multiple PVCs over a

single physical interface and point-to-point
subinterfaces subdivide each PVC as if it were a
physical point-to-point interface.
Point-to-point subinterfaces completely bypass
the local DLCI to remote network address
mapping issue.
With physical and multipoint subinterface you:
 can have multiple DLCIs assigned to it.
 can use frame-relay map & interface dlci statements
 can use Inverse-ARP
With point-to-point subinterfaces you:

 cannot have multiple DLCIs associated with a single
point-to-point subinterface
 cannot use frame-relay map statements
 cannot use Inverse-ARP
 (can use the frame-relay interface dlci statement

for both point-to-point and multipoint)
Point-to-point subinterfaces
Each subinterface is on a separate

network or subnet with a single remote
connection (I.e. point-to-point)
172.30.1.0/24
172.30.2.0/24
172.30.3.0/24
172.30.1.1/24 172.30.2.1/24 172.30.3.1/24
S0 S1 S2
172.30.1.2/24 172.30.2.2/24 172.30.3.2/24
Site A Site B Site C

 Point-to-point subinterfaces are equivalent to using
multiple physical “point to point” interfaces
Point-to-point subinterface
 A single subinterface is used to establish
one PVC connection to another physical or
subinterface on a remote router.
 In this case, the interfaces would be:
– in the same subnet and
– each interface would have a single DLCI
 Each point-to-point connection is its own
subnet.
 In this environment, broadcasts are not a
problem because the routers are point-to-
point and act like a leased line.
Point-to-point subinterface configuration,
minimum of two commands:
(config)# interface Serial0.1 point-to-point
(config-subif)# frame-relay interface-dlci dlci-number
Rules:
1. No Frame-Relay map statements can be used
with point-to-point subinterfaces.
2. One and only one DLCI can be associated with a
single point-to-point subinterface
By the way, encapsulation is done only at the physical

interface:
interface Serial0
no ip address
frame-relay interface-dlci
Router(config-if)#frame-relay interface-
dlci dlci-number
 Used to assign specific DLCIs to specific

subinterfaces.
 This command is required for all point-to-point
subinterfaces.
 It is also required for multipoint subinterfaces for
which inverse ARP is enabled.
 It is not required for multipoint subinterfaces that are
configured with static route maps.
 Do not use this command on physical interfaces.
frame-relay interface-dlci and the
show frame map
show frame map
 point-to-point subinterfaces: listed as a “point-to-point
dlci”
Serial0.1 (up): point-to-point dlci, dlci 301
(0xCB, 0x30B0), broadcast status defined,
active
 With multipoint subinterfaces, the it lists it an inverse
ARP entry, “dynamic”
Serial0 (up): ip 172.30.2.1 dlci, 301 (0x12D,
0x48D0), dynamic,, broadcast status defined,
active
Each subinterface on Hub router requires a
separate subnet (or network) Point-to-Point Subinterfaces at the
• Each subinterface on Hub router is treated Hub and Spokes
like a regular physical point-to-point
interface, so split horizon does not need to be Headquarters
disabled. Hub City
Interface Serial0 (for all routers)
encapsulation frame-relay DLCI 301 DLCI 302
no ip address
Serial 0.1 Serial 0.2
HubCity 172.16.1.1/24 172.16.2.1/24
interface Serial0.1 point-to-point
ip address 172.16.1.1 255.255.255.0
frame-relay interface dlci 301 Frame Relay
Network
ip address 172.16.2.1 255.255.255.0
DLCI 103 DLCI 203
frame-relay interface dlci 302
Spokane Serial 0.1 Serial 0.1
interface Serial0.1 point-to-point 172.16.1.2/24 172.16.2.2/24
ip address 172.16.1.2 255.255.255.0

frame-relay interface dlci 103 Satellite Office 1 Satellite Office 2
Spokomo Spokane Spokomo
ip address 172.16.2.2 255.255.255.0
frame-relay interface dlci 203
Multipoint Subinterfaces
Share many of the same characteristics as a physical
Frame-Relay interface
With multipoint subinterface you can have:
 can have multiple DLCIs assigned to it.
 can use frame-relay map & interface dlci statements
 can use Inverse-ARP
Remember, with point-to-point subinterfaces you:

 cannot have multiple DLCIs associated with a single
point-to-point subinterface
 cannot use frame-relay map statements
 cannot use Inverse-ARP
 (can use the frame-relay interface dlci statement

for both point-to-point and multipoint)
Multipoint subinterfaces
Each subinterface is on a separate
network or subnet but may have
multiple connections, with a different
DLCI for each connection.
172.30.1.0/24
172.30.2.0/24
172.30.3.0/24
Split horizon still an issue on each

Multipoint subinterface.
172.30.1.1/24 172.30.2.1/24 172.30.3.1/24
S0 S1 S2
172.30.1.2/24 172.30.3.3/24
Site A1 Site C2
172.30.3.2/24
172.30.1.3/24
172.30.2.2/24 172.30.2.3/24
Site C1
Site A2
Site B1 Site B2
 Multipoint subinterfaces are equivalent to using
multiple physical “hub to spoke” interfaces.
Multipoint subinterface at the Hub
and Point-to-Point Subinterfaces
Notes at the Spokes
• Highly scalable solution
• Disable Split Horizon on Hub Headquarters
router when running a distance Hub City
vector routing protocol
Interface Serial0 (for all routers)
DLCI 301 DLCI 302
Serial 0
no ip address 172.16.3.3
HubCity
interface Serial0.1 mulitpoint
ip address 172.16.3.3 255.255.255.0
frame-relay interface-dlci 301
frame-relay interface-dlci 302 Frame Relay
Network
no ip split-horizon
Spokane
ip address 172.16.3.1 255.255.255.0 DLCI 103 DLCI 203
frame-relay interface-dlci 103
Spokomo Serial 0 Serial 0
interface Serial0.1 point-to-point 172.16.3.1 172.16.3.2
ip address 172.16.3.2 255.255.255.0

frame-relay interface-dlci 203 Satellite Office 1 Satellite Office 2
Spokane Spokomo
BECN and FECN
A Frame Relay switch sends FECN and BECN packets to reduce congestion.
FECN packets are sent to the destination device, BECN packets are sent to
the source device.
Verifying and Troubleshooting
Frame Relay
 The show interface serial Command
 The show frame-relay lmi Command
 The show frame-relay pvc [interface
interface [dlci#]] Command
 The show frame-relay map Command
 The debug frame-relay Command
The show interfaces serial
Command
Lab-B#show interfaces serial
Serial 2 is up, line protocol is up
Hardware type is MCI Serial
Internet address is 131.18.79.1, subnet mask is 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255,load 1/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
multicast DLCI 1022, status defined, active
source DLCI 20, status defined, active
LMI DLCI 1023, LMI sent 10, LMI stat recvd 10, LMI upd recvd 2
Last input 7:21:29, output 0:00:37, output hang never
The show frame-relay lmi
Command
Router#show frame-relay lmi
LMI Statistics for interface Serial1 (Frame Relay DTE) LMI TYPE = ANSI
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 9 Num Status msgs Rcvd 0
Num Update Status Rcvd 0 Num Status Timeouts 9
The show frame-relay pvc
Command
Router#show frame-relay pvc 100
PVC Statistics for interface Serial5/1 (Frame Relay DTE)
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial0.1
input pkts 9 output pkts 16 in bytes 154
out bytes 338 dropped pkts 6 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 0 out bcast bytes 0
pvc create time 00:35:11, last time pvc status changed 00:00:22
Bound to Virtual-Access1 (up, cloned from Virtual-Template5)
The show frame-relay map
Command
Router#show frame-relay map
Serial 1 (up): ip 131.108.177.177
dlci 177 (0xB1,0x2C10), static, broadcast, CISCO
The debug frame-relay Command
#debug frame-relay
Serial0(i): dlci 500(0x7C41), pkt type 0x0800, datagramsize 24
Serial0(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13
Serial0(i): dlci 500(0x7C41), pkt type 0x0800, datagramsize 24
Serial0(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13
Labs
 Configuring Hub and Spoke Frame

Relay
 Configuring Full-Mesh Frame Relay
 Configuring Full-Mesh Frame Relay
With Sub Interfaces

Frame Relay

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Frame Relay

Caricato da

Copyright:

Formati disponibili

Frame Relay Overview

 Frame Relay defines the

Frame Relay defines the interconnection process between a

Spokane(config)# interface serial 0

 cisco is the default. Use this if

The following process occurs:

The routers can now ping each other!

HubCity# show frame-relay map

Limitation of Inverse ARP

Spokane# show frame-relay map

Spokomo# show frame-relay map

Solutions to the limitations of Inverse ARP

Full Mesh Topology (n*(n-1)) / 2

Instead of using additional PVCs, Frame-Relay

 broadcast (Optional) Forwards broadcasts to this

 ietf | cisco (Optional) Select the Frame Relay

Satellite Office 1 Satellite Office 2

ip address 172.16.1.1 255.255.255.0

Satellite Office 1 Satellite Office 2

 Now all routers can ping each other!

When a Frame-Relay map statement is

Spokane and Spokomo can no longer ping HubCity!

Satellite Office 1 Satellite Office 2

If using Cisco IOS Release 11.1 or earlier,

With IOS Release 11.2 or later, the LMI-type is

For routing metric

interface for every permanent virtual circuit (PVC)

 Early implementation of Frame Relay

 By using point-to-point subinterfaces,

 mapping of local DLCI address to remote network

Frame-Relay service supplies multiple PVCs over a

 can use frame-relay map & interface dlci statements

 can use Inverse-ARP

With point-to-point subinterfaces you:

 cannot use Inverse-ARP

 (can use the frame-relay interface dlci statement

Each subinterface is on a separate

172.30.1.2/24 172.30.2.2/24 172.30.3.2/24

Site A Site B Site C

By the way, encapsulation is done only at the physical

 Used to assign specific DLCIs to specific

ip address 172.16.1.2 255.255.255.0

 can use frame-relay map & interface dlci statements

 can use Inverse-ARP

Remember, with point-to-point subinterfaces you:

 cannot use Inverse-ARP

 (can use the frame-relay interface dlci statement

Split horizon still an issue on each

ip address 172.16.3.2 255.255.255.0

 Configuring Hub and Spoke Frame

Potrebbero piacerti anche