1 / 71

Frame Relay Overview

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?.

jesse
Download Presentation

Frame Relay Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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.

  2. What Is Frame Relay? Frame Relay defines the interconnection process between a router and the service provider’s local access switching equipment.

  3. 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.

  4. 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.

  5. 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 .

  6. Frame Relay Operation

  7. 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.

  8. 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.

  9. 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.

  10. 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

  11. 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

  12. 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!

  13. Inverse ARP 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)

  14. Inverse ARP Limitations Limitation of Inverse ARP Inverse ARP only resolves network addresses of remote Frame-Relay connections that are directly connected.

  15. NBMA Topologies

  16. Hub Router • 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). A Frame-Relay Configuration Supporting Multiple Sites Spoke Routers

  17. 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 encapsulation frame-relay Spokomo interface Serial0 ip address 172.16.1.3 255.255.255.0 encapsulation frame-relay

  18. HubCity# show frame-relay map Serial0 (up): ip 172.16.1.1 dlci 101, dynamic, broadcast, status defined, active Serial0 (up): ip 172.16.1.3 dlci 112, dynamic, broadcast, status defined, active Spokane# show frame-relay map Serial0 (up): ip 172.16.1.2 dlci 102, dynamic, broadcast, status defined, active Spokomo# show frame-relay map Serial0 (up): ip 172.16.1.2 dlci 211, dynamic, broadcast, status defined, active

  19. 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

  20. 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.

  21. 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

  22. 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

  23. 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

  24. Frame-Relay Map Statements HubCity interface Serial0 ip address 172.16.1.2 255.255.255.0 encapsulation frame-relay (Inverse-ARP still works here) Spokane interface Serial0 ip address 172.16.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 172.16.1.3 102 frame-relay map ip 172.16.1.2 102 Spokomo interface Serial0 ip address 172.16.1.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 172.16.1.1 211 frame-relay map ip 172.16.1.2 211

  25. 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!

  26. 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 encapsulation frame-relay frame-relay map ip 172.16.1.3 102 Spokomo interface Serial0 ip address 172.16.1.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 172.16.1.1 211

  27. HubCity#show frame-relay map Serial0 (up): ip 172.16.1.1 dlci 101, dynamic, broadcast, status defined, active Serial0 (up): ip 172.16.1.3 dlci 112, dynamic, broadcast, status defined, active Spokane#show frame-relay map 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 (static = learned via fr map statement) Spokomo#show frame-relay map Serial0 (up): ip 172.16.1.2 dlci 211, dynamic, broadcast, status defined, active Serial0 (up): ip 172.16.1.1 dlci 211, static, CISCO, status defined, active (static = learned via fr map statement)

  28. 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...

  29. 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.

  30. 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.

  31. HubCity#show frame-relay map (after reload) Serial0 (up): ip 172.16.1.1 dlci 101, dynamic, broadcast, status defined, active Serial0 (up): ip 172.16.1.3 dlci 112, dynamic, broadcast, status defined, active Spokane#show frame-relay map 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 Spokomo#show frame-relay map NOW MISSING: Serial0 (up): ip 172.16.1.2 dlci 211, dynamic, broadcast, status defined, active Serial0 (up): ip 172.16.1.1 dlci 211, static, CISCO, status defined, active

  32. HubCity#show frame-relay map (after reload) Serial0 (up): ip 172.16.1.1 dlci 101, dynamic, broadcast, status defined, active Serial0 (up): ip 172.16.1.3 dlci 112, dynamic, broadcast, status defined, active Spokane#show frame-relay map Serial0 (up): ip 172.16.1.3 dlci 102, static, CISCO, status defined, active Spokomo#show frame-relay map Serial0 (up): ip 172.16.1.1 dlci 211, static, CISCO, status defined, active Spokane and Spokomo can no longer ping HubCity!

  33. Solution: Wherever there are Inverse-ARP statements, replace them with Frame-Relay map statements.

  34. Frame-Relay Map Statements - Solution HubCity interface Serial0 ip address 172.16.1.2 255.255.255.0 encapsulation frame-relay (Inverse-ARP still works here) Spokane interface Serial0 ip address 172.16.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 172.16.1.3 102 frame-relay map ip 172.16.1.2 102 Spokomo interface Serial0 ip address 172.16.1.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 172.16.1.1 211 frame-relay map ip 172.16.1.2 211

  35. Local Management Interface

  36. 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

  37. 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.

  38. 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.

  39. FR Configuration Example For routing metric information

  40. 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-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

  41. Early Implementations of Frame RelayRequired that a router (DTE device) must have a WAN serial interface for every permanent virtual circuit (PVC)

  42. 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.

  43. 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.

  44. Solution: No Split Horizon with Point-to-point Subinterfaces

  45. FR and Subinterfaces

  46. 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.

  47. 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.

  48. 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.

More Related