Frame Relay Overview n Frame Relay defines the interconnection process between the DTE and the DCE...

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

Frame RelayNetw ork

HeadquartersHub City

Satellite Office 1Spokane

172.16.1.1172.16.1.2

DLCI 101 DLCI 102

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!

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)

Frame RelayNetw ork



172.16.1.1172.16.1.2

DLCI 101 DLCI 102

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

Frame RelayNetwork



Satellite Office 2Spokomo

172.16.1.1 172.16.1.3

172.16.1.2

DLCI 101

DLCI 102

DLCI 112

DLCI 211

• This is known as a Hub and Spoke Topology, where the Hub router relays information between the Spoke routers.

• Limits the number of PVCs needed as in a full-mesh topology (coming).

Hub Router

Spoke Routers

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

Inverse ARP resolved the ip addresses for Spokane for HubCity

Inverse ARP resolved the ip 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 RelayNetw ork




172.16.1.1 172.16.1.3

172.16.1.2

DLCI 101

DLCI 102

DLCI 112

DLCI 211

HubCityinterface Serial0ip address 172.16.1.2 255.255.255.0encapsulation frame-relay(Inverse-ARP still works here)

Spokaneinterface Serial0ip address 172.16.1.1 255.255.255.0encapsulation frame-relayframe-relay map ip 172.16.1.3 102frame-relay map ip 172.16.1.2 102

Spokomointerface Serial0ip address 172.16.1.3 255.255.255.0encapsulation frame-relayframe-relay map ip 172.16.1.1 211frame-relay map ip 172.16.1.2 211

Frame-Relay Map Statements

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!

Frame RelayNetw ork




172.16.1.1 172.16.1.3

172.16.1.2

DLCI 101

DLCI 102

DLCI 112

DLCI 211

HubCityinterface Serial0ip address 172.16.1.2 255.255.255.0encapsulation frame-relay

Spokaneinterface Serial0ip address 172.16.1.1 255.255.255.0encapsulation frame-relayframe-relay map ip 172.16.1.3 102

Spokomointerface Serial0ip address 172.16.1.3 255.255.255.0encapsulation frame-relayframe-relay map ip 172.16.1.1 211






Serial0 (up): ip 172.16.1.3 dlci 102, static, CISCO, status defined, active (static = learned via fr map statement)



Serial0 (up): ip 172.16.1.1 dlci 211, static, CISCO, 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

Serial0 (up): ip 172.16.1.3 dlci 102, static, CISCO, 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 RelayNetw ork




172.16.1.1 172.16.1.3

172.16.1.2

DLCI 101

DLCI 102

DLCI 112

DLCI 211

HubCityinterface Serial0ip address 172.16.1.2 255.255.255.0encapsulation frame-relay(Inverse-ARP still works here)Spokaneinterface Serial0ip address 172.16.1.1 255.255.255.0encapsulation frame-relayframe-relay map ip 172.16.1.3 102frame-relay map ip 172.16.1.2 102Spokomointerface Serial0ip address 172.16.1.3 255.255.255.0encapsulation frame-relayframe-relay map ip 172.16.1.1 211frame-relay map ip 172.16.1.2 211

Frame-Relay Map Statements - Solution

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 ConfigurationThe following example shows a case in which most destinations use Cisco encapsulation, but one site requires IETF encapsulation:

Router(config-if)#encapsulation frame-relayRouter(config-if)#frame-relay map ip 131.108.123.2 48 broadcastRouter(config-if)#frame-relay map ip 131.108.123.3 49 broadcast ietfRouter(config-if)#frame-relay map ip 131.108.123.4 50 broadcast

Early Implementations of Frame RelayRequired that a router (DTE device) must have a WAN serial

interface for every permanent virtual circuit (PVC)

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.

Early Implementations of Frame Relay

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

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.

FR and Subinterfaces

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.

Point-to-point Subinterfaces

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

Point-to-point subinterfaces

172.30.1.0/24

172.30.2.0/24

172.30.3.0/24

Each subinterface is on a separate network or subnet with a single remote connection (I.e. point-to-point)

Point-to-point subinterfaces are equivalent to using multiple physical “point to point” interfaces

S0 S1 S2

Site A Site B Site C

172.30.1.1/24 172.30.2.1/24 172.30.3.1/24

172.30.1.2/24 172.30.2.2/24 172.30.3.2/24

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-dlciRouter(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 mapshow 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

Point-to-Point Subinterfaces at the Hub and Spokes Each subinterface on Hub router requires a separate subnet (or network)• Each subinterface on Hub router is treated like a regular physical point-to-point interface, so split horizon does not need to be disabled.Interface Serial0 (for all routers)encapsulation frame-relayno ip addressHubCityinterface Serial0.1 point-to-pointip address 172.16.1.1 255.255.255.0encapsulation frame-relayframe-relay interface dlci 301

interface Serial0.2 point-to-pointip address 172.16.2.1 255.255.255.0encapsulation frame-relayframe-relay interface dlci 302Spokaneinterface Serial0.1 point-to-pointip address 172.16.1.2 255.255.255.0frame-relay interface dlci 103Spokomointerface Serial0.1 point-to-pointip address 172.16.2.2 255.255.255.0frame-relay interface dlci 203

Frame RelayNetw ork




Serial 0.1172.16.1.2/24

Serial 0.1172.16.2.2/24

Serial 0.1172.16.1.1/24

DLCI 301

DLCI 103

DLCI 302

DLCI 203

Serial 0.2172.16.2.1/24

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

Multipoint subinterfaces

172.30.1.0/24

172.30.2.0/24

172.30.3.0/24

Each subinterface is on a separate network or subnet but may have multiple connections, with a different DLCI for each connection.

Split horizon still an issue on each Multipoint subinterface.

Multipoint subinterfaces are equivalent to using multiple physical “hub to spoke” interfaces.

S0 S1 S2

Site A1

Site B1

Site C2

172.30.1.1/24 172.30.2.1/24 172.30.3.1/24

172.30.1.2/24

172.30.2.2/24

172.30.3.3/24

Site A2

172.30.1.3/24

Site B2

172.30.2.3/24

Site C1

172.30.3.2/24

Frame RelayNetw ork




Serial 0172.16.3.1

Serial 0172.16.3.2

Serial 0172.16.3.3

DLCI 301

DLCI 103

DLCI 302

DLCI 203

Notes• Highly scalable solution• Disable Split Horizon on Hub router when running a distance vector routing protocolInterface Serial0 (for all routers)encapsulation frame-relayno ip addressHubCityinterface Serial0.1 mulitpointip address 172.16.3.3 255.255.255.0frame-relay interface-dlci 301frame-relay interface-dlci 302no ip split-horizonSpokaneinterface Serial0.1 point-to-pointip address 172.16.3.1 255.255.255.0frame-relay interface-dlci 103Spokomointerface Serial0.1 point-to-pointip address 172.16.3.2 255.255.255.0frame-relay interface-dlci 203

Multipoint subinterface at the Hub and Point-to-Point Subinterfaces at the Spokes

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 serialSerial 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 lmiLMI 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 100PVC 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 mapSerial 1 (up): ip 131.108.177.177dlci 177 (0xB1,0x2C10), static, broadcast, CISCO

The debug frame-relay Command

#debug frame-relaySerial0(i): dlci 500(0x7C41), pkt type 0x0800, datagramsize 24Serial0(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13Serial0(i): dlci 500(0x7C41), pkt type 0x0800, datagramsize 24Serial0(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 Overview n Frame Relay defines the interconnection process between the DTE and the DCE...

Documents

Transcript of Frame Relay Overview n Frame Relay defines the interconnection process between the DTE and the DCE...