Frame Relay Characteristics

Frame Relay Characteristics

This section explains several Frame Relay characteristics of which you should be aware.

IP Split Horizon Checking

IP split horizon checking is disabled by default for Frame Relay encapsulation so routing updates will come in and out the same interface. The routers learn the data-link connection identifiers (DLCIs) they need to use from the Frame Relay switch via Local Management Interface (LMI) updates. The routers then use Inverse ARP for the remote IP address and create a mapping of local DLCIs and their associated remote IP addresses. Additionally, certain protocols such as AppleTalk, transparent bridging, and IPX cannot be supported on partially meshed networks because they require "split horizon," in which a packet received on an interface cannot be transmitted out the same interface, even if the packet is received and transmitted on different virtual circuits. Configuring Frame Relay subinterfaces ensures that a single physical interface is treated as multiple virtual interfaces. This capability allows us to overcome split horizon rules. Packets received on one virtual interface can now be forwarded out another virtual interface, even if they are configured on the same physical interface.

Ping Your Own IP Address on a Multipoint Frame Relay

You are not able to ping your own IP address on a multipoint Frame Relay interface. This is because Frame Relay multipoint (sub)interfaces are non-broadcast, (unlike Ethernet and point-to-point interfaces High-Level Data Link Control [HDLC]), and Frame Relay point-to-point sub-interfaces.

Furthermore, you are not able to ping from one spoke to another spoke in a hub and spoke configuration. This is because there is no mapping for your own IP address (and none were learned via Inverse ARP). But if you configure a static map (using the frame-relay map command) for your own IP address (or one for the remote spoke) to use the local DLCI, you can then ping your devices.

aton#ping  3.1.3.3
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
   .....
   Success rate is 0 percent (0/5)

   aton#configure terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   aton(config)#interface serial 1
   aton(config-if)#frame-relay map ip 3.1.3.3 160
   aton(config-if)#

   aton#show frame-relay map
   Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
                    broadcast,, status defined, active
   Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,
                    CISCO, status defined, active
   Serial1 (up): ip 3.1.3.3 dlci 160(0xA0,0x2800), static,
                    CISCO, status defined, active
   aton#ping 3.1.3.3     
   
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 64/68/76 ms
   aton#
   aton#show running-config
   !
   interface Serial1
   ip address 3.1.3.3 255.255.255.0
   no ip directed-broadcast
   encapsulation frame-relay
   frame-relay map ip 3.1.3.2 160
   frame-relay map ip 3.1.3.3 160
   frame-relay interface-dlci 160
   !

The Keyword broadcast

The broadcast keyword provides two functions: it forwards broadcasts when multicasting is not enabled, and it simplifies the configuration of Open Shortest Path First (OSPF) for non-broadcast networks that use Frame Relay.

The broadcast keyword might also be required for some routing protocols -- for example, AppleTalk -- that depend on regular routing table updates, especially when the router at the remote end is waiting for a routing update packet to arrive before adding the route.

By requiring selection of a designated router, OSPF treats a non-broadcast, multi-access network such as Frame Relay in much the same way as it treats a broadcast network. In previous releases, this required manual assignment in the OSPF configuration using the neighbor interface router command. When the frame-relay map command is included in the configuration with the broadcast keyword, and the ip ospf network command (with the broadcast keyword) is configured, there is no need to configure any neighbors manually. OSPF now automatically runs over the Frame Relay network as a broadcast network. (See the ip ospf network interface command for more detail.)

Note: The OSPF broadcast mechanism assumes that IP class D addresses are never used for regular traffic over Frame Relay.

Example

The following example maps the destination IP address 172.16.123.1 to DLCI 100:

interface serial 0
 frame-relay map IP 172.16.123.1 100 broadcast 

OSPF uses DLCI 100 to broadcast updates.

Reconfiguring a Subinterface

Once you create a specific type of subinterface, you cannot change it without a reload. For example, you cannot create a multipoint subinterface serial0.2, then change it to point-to-point. To change it, you need to either reload the router or create another subinterface. This is the way the Frame Relay code works in Cisco IOS® software.

DLCI Limitations

DLCI Address Space

Approximately 1000 DLCIs can be configured on a single physical link, given a 10-bit address. Because certain DLCIs are reserved (vendor-implementation-dependent), the maximum is about 1000. The range for a Cisco LMI is 16-1007. The stated range for ANSI/ITU is 16-992. These are the DLCIs carrying user-data.

However, when configuring Frame Relay VCs on subinterfaces, you need to consider a practical limit known as the IDB limit. The total number of interfaces and subinterfaces per system is limited by the number of interface descriptor blocks (IDBs) that your version of Cisco IOS supports. An IDB is a portion of memory that holds information about the interface such as counters, status of the interface, and so on. IOS maintains an IDB for each interface present on a platform and maintains an IDB for each subinterface. Higher speed interfaces require more memory than lower speed interfaces. Each platform contains different amounts of maximum IDBs and these limits may change with each Cisco IOS release.

For more information, see Maximum Number of Interfaces and Subinterfaces for Cisco IOS Software Platforms: IDB Limits.

LMI Status Update

The LMI protocol requires that all permanent virtual circuit (PVC) status reports fit into a single packet and generally limits the number of DLCIs to less than 800, depending on the maximum transmission unit (MTU) size.

The default MTU on serial interfaces is 1500 bytes, yielding a maximum of 296 DLCIs per interface. You can increase the MTU to support a larger full status update message from the Frame Relay switch. If the full status update message is larger than the interface MTU, the packet is dropped, and the interface giant counter is incremented. When changing the MTU, ensure the same value is configured at the remote router and intervening network devices.

Please note that these numbers vary slightly, depending on the LMI type. The maximum DLCIs per router (not interface) platform guideline, based on extrapolation from empirical data established on a Cisco 7000 router platform, are listed below:

• Cisco 2500: 1 X T1/E1 link @ 60 DLCIs per interface = 60 total

• Cisco 4000: 1 X T1/E1 link @ 120 DLCIs per interface = 120 total

• Cisco 4500: 3 X T1/E1 links @ 120 DLCIs per interface = 360 total

• Cisco 4700: 4 X T1/E1 links @ 120 DLCIs per interface = 480 total

• Cisco 7000: 4 X T1/E1/T3/E3 links @ 120 DLCIs per interface = 480 total

• Cisco 7200: 5 X T1/E1/T3/E3 links @ 120 DLCIs per interface = 600 total

• Cisco 7500: 6 X T1/E1/T3/E3 links @ 120 DLCIs per interface = 720 total

Note: These numbers are guidelines only, and assume that all traffic is fast-switched.

Other Considerations

A practical DLCI limit also depends on whether the VCs are running a dynamic or static routing protocol. Dynamic routing protocols, and other protocols like IPX SAP that exchange database tables, send hellos and forwarding information messages which must be seen and processed by the CPU. As a general rule, using static routes will allow you to configure a larger number of VCs on a single Frame Relay interface.

IP/IPX/AT Address

If you are using subinterfaces, don't put an IP, IPX or AT address on the main interface. Assign DLCIs to their subinterfaces before you enable the main interface to ensure that frame-relay inverse-arp works properly. In case it does malfunction, follow the steps below:

1. Turn off Inverse Address Resolution Protocol (ARP) for that DLCI by using the no frame-relay inverse-arp ip 16 and the clear frame-relay-inarp commands.

2. Fix your configuration.

3. Turn the frame-relay inverse-arp command on again.

RIP and IGRP

Routing Information Protocol (RIP) updates flow every 30 seconds. Each RIP packet can contain up to 25 route entries, for a total of 536 bytes; 36 bytes of this total are header information, and each route entry is 20 bytes. Therefore, if you advertise 1000 routes over a Frame Relay link configured for 50 DLCIs, the result is 1 MB of routing update data every 30 seconds, or 285 kbps of bandwidth consumed. On a T1 link, this bandwidth represents 18.7 percent of the bandwidth, with each update duration being 5.6 seconds. This amount of overhead is considerable, and it is borderline acceptable, but the committed information rate (CIR) would have to be in the region of the access speed. Obviously, anything less than a T1 would incur too much overhead. For example:

• 1000/25 = 40 packets X 36 = 1440 header bytes

• 1000 X 20 bytes = 20,000 bytes of route entries

• Total 21,440 bytes X 50 DLCIs = 1072 MB of RIP updates every 30 seconds

• 1,072,000 bytes / 30 sec X 8 bits = 285 kbps

Interior Gateway Routing Protocol (IGRP) updates flow every 90 seconds (this interval is configurable). Each IGRP packet can contain 104 route entries, for a total of 1492 bytes, 38 of which are header information, and each route entry is 14 bytes. If you advertise 1000 routes over a Frame Relay link configured with 50 DLCIs, the request is approximately 720 KB of routing update data every 90 seconds, or 64 kbps of bandwidth consumed. On a T1 link, this bandwidth would represent 4.2 percent of the bandwidth, with each update duration being 3.7 seconds. This overhead is an acceptable amount:

• 1000/104 = 9 packets X 38 = 342 header bytes

• 1000 X 14 = 14,000 bytes of route entries

• Total = 14,342 bytes X 50 DLCIs = 717 KB of IGRP updates every 90 seconds

• 717,000 bytes / 90 X 8 bits = 63.7 kbps

Routing Table Maintenance Protocol (RTMP) routing updates occur every 10 seconds (this interval is configurable). Each RTMP packet can contain up to 94 extended route entries, for a total of 564 bytes, 23 bytes of header information, and each route entry is 6 bytes. If you advertise 1000 AppleTalk networks over a Frame Relay link configured for 50 DLCIs, the result is approximately 313 KB of RTMP updates every 10 seconds, or 250 kbps of bandwidth consumed. To remain within an acceptable level of overhead 15 percent or less), a T1 rate is required. For example:

• 1000/94 = 11 packets X 23 bytes = 253 header bytes

• 1000 X 6 = 6000 bytes of route entries

• Total = 6253 X 50 DLCIs = 313 KB of RTMP updates every 10 seconds

• 313,000 / 10 sec X 8 bits = 250 kbps

IPX RIP packet updates occur every 60 seconds (this interval is configurable). Each IPX RIP packet can contain up to 50 route entries for a total of 536 bytes, 38 bytes of header information, and each route entry is 8 bytes. If you advertise 1000 IPX routes over a Frame Relay link configured for 50 DLCIs, the result is 536 KB of IPX updates every 60 seconds, or 58.4 kbps of bandwidth consumed. To remain within an acceptable level of overhead (15 percent or less), a rate of 512 kbps is required. For example:

• 1000/50 = 20 packets X 38 bytes = 760 bytes of header

• 1000 X 8 = 8000 bytes of route entries

• Total = 8760 X 50 DLCIs = 438,000 bytes of IPX updates every 60 seconds

• 438,000 / 60 sec X 8 bits = 58.4 kbps

IPX service access point (SAP) packet updates occur every 60 seconds (this interval is configurable). Each IPX SAP packet can contain up to seven advertisement entries for a total of 536 bytes, 38 bytes of header information, and each advertisement entry is 64 bytes. If you broadcast 1000 IPX advertisements over a Frame Relay link configured for 50 DLCIs, you would end up with 536 KB of IPX updates every 60 seconds, or 58.4 kbps of bandwidth consumed. To remain within an acceptable level of overhead (15 percent or less), a rate of greater than 2 Mbps is required. Obviously, SAP filtering is required in this scenario. Compared to all other protocols mentioned in this section, IPX SAP updates require the most bandwidth:

• 1000/7 = 143 packets X 38 bytes = 5434 bytes of header

• 1000 X 64 = 64,000 bytes of route entries

• Total = 69,434 X 50 DLCIs = 3,471,700 bytes of IPX service advertisements every 60 seconds

• 3,471,700 / 60 sec X 8 bits = 462 kbps

Keepalive

In some cases, the keepalive on the Cisco device needs to be set slightly shorter (about 8 seconds) than the keepalive on the switch. You'll see the need for this if the interface keeps coming up and down.

Serial Interfaces

Serial interfaces, which are by default multipoint, are non-broadcast media, while point-to-point subinterfaces are broadcast. If you are using static routes, you can point to either the next hop or the serial subinterface. For multipoint, you need to point to the next hop. This concept is very important when doing OSPF over Frame Relay. The router needs to know that this is a broadcast interface for OSPF to work.

OSPF and Multipoint

OSPF and multipoint can be very troublesome. OSPF needs a Designated Router (DR). If you start losing PVCs, some routers may lose connectivity and try to become a DR even though other routers still see the old DR. This causes the OSPF process to malfunction.

Overhead associated with OSPF is not as obvious and predictable as that with traditional distance vector routing protocols. The unpredictability comes from whether or not the OSPF network links are stable. If all adjacencies to a Frame Relay router are stable, only neighbor hello packets (keepalives) will flow, which is comparatively much less overhead than that incurred with a distance vector protocol (such as RIP and IGRP). If, however, routes (adjacencies) are unstable, link-state flooding will occur, and bandwidth can quickly be consumed. OSPF also is very processor-intensive when running the Dijkstra algorithm, which is used for computing routes.

In earlier releases of Cisco IOS software, special care had to be taken when configuring OSPF over multiaccess nonbroadcast medias such as Frame Relay, X.25, and ATM. The OSPF protocol considers these media like any other broadcast media such as Ethernet. Nonbroadcast multiaccess (NBMA) clouds are typically built in a hub and spoke topology. PVCs or switched virtual circuits (SVCs) are laid out in a partial mesh and the physical topology does not provide the multiaccess that OSPF believes is there. For the case of point-to-point serial interfaces, OSPF always forms an adjacency between the neighbors. OSPF adjacencies exchange database information. In order to minimize the amount of information exchanged on a particular segment, OSPF elects one router to be a DR, and one router to be a backup designated router (BDR) on each multiaccess segment. The BDR is elected as a backup mechanism in case the DR goes down.

The idea behind this setup is that routers have a central point of contact for information exchange. The selection of the DR became an issue because the DR and BDR needed to have full physical connectivity with all routers that exist on the cloud. Also, because of the lack of broadcast capabilities, the DR and BDR needed to have a static list of all other routers attached to the cloud. This setup is achieved using the neighbor command:

neighbor ip-address [priority number] [poll-interval seconds]

In later releases of Cisco IOS software, different methods can be used to avoid the complications of configuring static neighbors and having specific routers becoming DRs or BDRs on the nonbroadcast cloud. Which method to use is influenced by whether the network is new or an existing design that needs modification.

A subinterface is a logical way of defining an interface. The same physical interface can be split into multiple logical interfaces, with each subinterface being defined as point-to-point. This scenario was originally created in order to better handle issues caused by split horizon over NBMA and vector based routing protocols.

A point-to-point subinterface has the properties of any physical point-to-point interface. As far as OSPF is concerned, an adjacency is always formed over a point-to-point subinterface with no DR or BDR election. OSPF considers the cloud a set of point-to-point links rather than one multiaccess network. The only drawback for the point-to-point is that each segment belongs to a different subnet. This scenario might not be acceptable because some administrators have already assigned one IP subnet for the whole cloud. Another workaround is to use IP unnumbered interfaces on the cloud. This scenario also might be a problem for some administrators who manage the WAN based on IP addresses of the serial lines.

Sources

1. International Telegraph and Telephone Consultative Committee, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", CCITT Recommendation Q.922, 19 April 1991.

2. American National Standard For Telecommunications - Integrated Services Digital Network - Core Aspects of Frame Protocol for Use with Frame Relay Bearer Service, ANSI T1.618-1991, 18 June 1991.

3. Information technology - Telecommunications and Information Exchange between systems - Protocol Identification in the Network Layer, ISO/IEC TR 9577: 1990 (E) 1990-10-15.

4. International Standard, Information Processing Systems - Local Area Networks - Logical Link Control, ISO 8802-2: 1989 (E), IEEE Std 802.2-1989, 1989-12-31.

5. Internetworking Technology Overview, October 1994, Cisco Systems

6. Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, Stanford University, June 1984.

7. Postel, J. and Reynolds, J., "Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information Sciences Institute, February 1988.

8. RFC 1490-Multiprotocol encapsulation

9. RFC 1315-Frame Relay MIB

10. RFC 1293-Frame Relay Inverse ARP

11. RFC 1144-TCP/IP header compression

12. Frame Relay Forum (FRF) 1.1-User-Network Interface (UNI)

13. FRF 2.1-Frame Relay Network-to-Network Interface (NNI)

14. FRF 3.1-Multiprotocol encapsulation

15. FRF 4-SVCs

16. FRF 6-Frame Relay service customer network management (MIB)

17. Gang of four LMI

18. Q.922 Annex A

19. ANSI T1.617 Annex D

20. ANSI T1.618, T1.606

21. ITU-T Q.933, Q.922

22. OSPF Design Guide

23. Configuration Notes for the Enhanced Implementation of Enhanced IGRP