This section covers the basic Frame Relay configuration information including point-to-multipoint configurations, point-to-point configurations, minimum DLCI recommendations, and the Frame Relay broadcast queue. Point-to-Multipoint ConfigurationsThe basic Frame Relay configurations for point-to-multipoint include the configuration of both the core (hub) and the remote user's (spoke) side. Figure 16-1 shows an example of this configuration. Figure 16-1. Hub and Spoke in a Point-to-Multipoint ConfigurationPoint-to-Multipoint Configuration of the HubExample 16-1 shows a hub side configuration, including the FastEthernet interface and the serial interface of the core router. Example 16-1. Basic Hub Configuration in a Point-to-Multipoint Configuration 7206-frame#show running-config <output omitted> interface FastEthernet0/0 description FastEthernet connection to gateway1 ip address 181.70.192.22 255.255.255.224 ! interface Serial0 ip address 181.68.1.1 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 100 frame-relay interface-dlci 200 frame-relay interface-dlci 300 frame-relay interface-dlci 400 ! ! router eigrp 19 network 181.68.0.0 network 181.70.0.0 ! <output omitted> In this configuration, the hub side is configured on a Cisco 7206x router (7206-frame) and is connected to four spoke routers with DLCI 100, 200, 300 and 400. The configuration uses dynamic mapping based on Inverse ARP (InARP). InARP is enabled by default and no additional command is required on interface Serial0. The routers learn the DLCIs from the Frame Relay switch through Local Management Interface (LMI) updates. The routers then use InARP for the remote Internet Protocol (IP) address and create a map of local DLCIs and their associated remote IP addresses (see the section, "Inverse ARP" in Chapter 15). When Frame Relay InARP is enabled, broadcast IP traffic goes out over the connection by default. Using InARP is called dynamic mapping. The response from InARP is stored in an address-to-DLCI mapping table on the router that supplies the next hop protocol address for the outgoing interface. As discussed in Chapter 15, an alternative to using InARP is static mapping. You must use static mapping if the router at the other end either does not support InARP, or does not support InARP for a specific protocol. To establish static mapping according to your network needs, use the commands in Example 16-2. Pay attention to the mapping statements under the Serial0 interface. In this configuration, the Internet Engineering Task Force (IETF) encapsulation is set up on a per-DLCI Basis. If all DLCIs are using the same encapsulation type, you can use a shorter configuration by configuring the IETF encapsulation on a per-interface basis. Example 16-2. Static Mapping Configuration of the Hub Serial Interface 7206-frame#show running-config <output omitted> interface Serial0 ip address 181.68.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 181.68.1.2 100 broadcast ietf frame-relay map ip 181.68.1.3 200 broadcast ietf frame-relay map ip 181.68.1.4 300 broadcast ietf frame-relay map ip 181.68.1.5 400 broadcast ietf <output omitted> NOTE In the latter case, encapsulation frame-relay becomes encapsulation frame-relay ietf, and each static mapping statement changes. For example, frame-relay map ip 181.68.1.2 100 broadcast ietf becomes frame-relay map ip 181.68.1.2 100 broadcast, and so on. The protocol IP address 181.68.1.2 is bound to DLCI = 100. The command frame-relay map ip 181.68.1.2 100 broadcast ietf can be interpreted as saying, "If you want to reach IP 181.68.1.2, use DLCI 100," thus mapping a next hop protocol address to the DLCI that connects to the protocol address. InARP is enabled by default for all protocols that it supports, but it can be disabled for specific protocol-DLCI pairs. When you supply a static map, InARP is automatically disabled for the specified protocol on the specified DLCI. NOTE The keyword broadcast greatly simplifies the configuration for the Open Shortest Path First (OSPF) protocol. See Cisco IOS Wide-Area Networking Command Reference for more information about using the broadcast keyword. You can use dynamic mapping for some protocols and static mapping for other protocols on the same DLCI. You can disable InARP for a protocol-DLCI pair if you know that the protocol is not supported on the other end of the connection. Point-to-Multipoint Configuration of the SpokeThe configuration on the remote user's router (spoke) is similar to the configuration segment in Example 16-3. Example 16-3. Configuring the 2500-Frame Router as a Spoke in a Point-to-Multipoint Configuration 2500-frame#show running-config <output omitted> interface Ethernet0 ip address 10.0.1.1 255.255.255.248 ! interface Serial1 ip address 181.68.1.2 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 101 ! ! router eigrp 19 network 10.0.0.0 network 181.68.0.0 ! <output omitted> Similarly, this side can apply InARP or static mapping. If the following command is applied to Interface Serial1, the protocol IP address 181.68.1.2 is bound to DLCI = 101: frame-relay map ip 181.68.1.1 101 broadcast ietf This can be interpreted as saying, "If you want to reach IP 181.68.1.1, use DLCI 101," thus mapping a next-hop protocol address to the DLCI 101 to connect to the protocol address. Dynamic and static mapping is applicable to this configuration. With a point-to-point configuration, however, only the static mapping solution is applicable. Point-to-Point ConfigurationsConfiguring a physical interface with multiple subinterfaces or multiple virtual interfaces is another example of the virtuality used in Cisco routers. This approach is commonly used in point-to-point configurations. The benefits of this configuration are realized in partially meshed Frame Relay designs. The concept of subinterfaces was originally created to better handle issues caused by split horizon over nonbroadcast multiaccess (NBMA) networks (such as Frame Relay, Asynchronous Transfer Mode [ATM], Switched Multimegabit Digital Service [SMDS], or X.25), the distance vector-based routing protocols (such as Internetwork Packet Exchange [IPX] Routing Information Protocol/Service Advertisement Protocol [RIP/SAP], AppleTalk, and IP RIP), and transparent bridging. A virtual interface overcomes the rules imposed by split horizon. Because every virtual interface can be considered a separate interface, sending packets back to the same physical interface does not violate the rules of split horizon. The point-to-point configuration solution allows the transformation from a partially meshed to a de facto, fully meshed configuration. To the routed protocol, each subnetwork now appears to be located on separate interfaces. Routing updates that are received from one side on one logical point-to-point subinterface can be forwarded to another on a separate logical interface without violating split horizon. NOTE In the NBMA model, all routers are configured as one logical subnet. As such, NBMA resembles a local-area network (LAN) logical topology. NOTE The split horizon rule states the following: Never advertise a route out of the interface through which it was learned. The basic hub and spoke configuration in a point-to-point configuration is shown in Figure 16-2. Figure 16-2. Hub and Spoke in a Point-to-Point ConfigurationPoint-to-Point Configuration of the HubThe core side is configured according to Example 16-4. Here, the Serial4/2:0 interface, a T1/Channelized Primary Rate Interface (PRI), is configured with four subinterfaces: Serial4/2:0.100, Serial4/2:0.200, Serial4/2:0.300, and Serial4/2:0.400. It is good practice to have the circuit description under the T1/PRI, as in Example 16-4. When working with the service provider, one can reference the interface description for circuit information. Example 16-4. Configuration of 7206-Frame as a Hub Router in Point-to-Point Configurations 7206-frame#show running-config <output omitted> interface Serial4/2:0 description Home Frame Relay : NUA :5555555511 : HICAP CID XXXYYZZZ72HCR-001 no ip address encapsulation frame-relay no ip route-cache no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi frame-relay broadcast-queue 100 1200 120 ! interface Serial4/2:0.100 point-to-point description 2500-frame: 10.0.1.0/29 bandwidth 128 ip unnumbered Loopback0 no ip route-cache frame-relay class class-128-new frame-relay interface-dlci 100 ! interface Serial4/2:0.200 point-to-point description 1602-frame : 10.0.2.0/29 : 14716506 : 3842400259 bandwidth 128 ip unnumbered Loopback0 no ip route-cache frame-relay class class-128-new frame-relay interface-dlci 200 ! interface Serial4/2:0.300 point-to-point description 2500-frame1 : 10.0.3.0/29: : 3823600256 bandwidth 56 ip unnumbered Loopback0 no ip route-cache frame-relay class class-56-new frame-relay interface-dlci 300 ! interface Serial4/2:0.400 point-to-point description 1602-frame1 : 10.0.4.0/29 : 14787359 : 3872200079 bandwidth 56 ip unnumbered Loopback0 no ip route-cache frame-relay class class-56-new frame-relay interface-dlci 400 ! interface Loopback0 description monitoring loopback 0 interface ip address 192.3.25.75 255.255.255.255 <output omitted> It is good practice to have a description for every DLCI and user to make remote trouble-shooting easier. You can locate that particular interface quickly by using the different search/find features of IOS. The line description 2500-frame: 10.0.1.0/29 explains that this subinterface is configured for a spoke user, called 2500-frame. The rest of the subinterfaces are configured in a similar manner. Another recommended technique in this configuration is to use the description of the subinterface that is consistent with the DLCI number. It saves time in the troubleshooting process by matching the subinterface number with its associated DLCI. The configured loopback 0 interface allows any monitoring tool to monitor the status of the 7206-frame router. The IOS feature IP unnumbered is discussed in the advanced configuration section. An important part of the hub configuration in point-to-point configurations is to define how routing is performed. For the purposes of this example, dynamic EIGRP routing is used for the hub router, and static routing is used for the spoke routers. The important routing segments of the configuration are shown in Example 16-5 and Example 16-6. Example 16-5 shows how to prevent other routers on a local network from learning about routes dynamically. One approach here can be to keep routing update messages from being sent through a router interface. This feature applies to all IP-based routing protocols except the Border Gateway Protocol (BGP), and can be configured in the global configuration mode with the following command: Router(config-router)#passive-interface interface-type interface-number Example 16-5. Configuring the Passive Interfaces in the Hub Router<output omitted> router eigrp 19 redistribute static passive-interface Serial4/2:0.100 passive-interface Serial4/2:0.200 passive-interface Serial4/2:0.300 passive-interface Serial4/2:0.400 network 10.0.0.0 no auto-summary no eigrp log-neighbor-changes As usual, to configure the static routing statements, you must add the commands shown in Example 16-6. In this example, there is a next hop address for subinterfaces of 10.0.1.1, 10.0.2.1, 10.0.3.1, and 10.0.4.1. To define the next hop address of the routing statement, you must refer to the advanced configuration section, where it is explained how the subinterface Serial1.201 obtains its IP address from the Ethernet 0 interface of the spoke router. Example 16-6. Configuring the Routing Statements in the Hub Router<output omitted> ip classless ip route 10.0.1.0 255.255.255.248 Serial4/2:0.100 10.0.1.1 ip route 10.0.2.0 255.255.255.248 Serial4/2:0.200 10.0.2.1 ip route 10.0.3.0 255.255.255.248 Serial4/2:0.300 10.0.3.1 ip route 10.0.4.0 255.255.255.248 Serial4/2:0.400 10.0.4.1 <output omitted> Point-to-Point Configuration of the SpokeNext, you configure the spoke router to ensure consistency with the hub router. The Ethernet interface is configured with a static IP address and helper address. The Serial1 interface is configured for 128 kbps (service-module t1 timeslots 1-2) with no IP address. Subinterface Serial1.201 obtains an IP address through the IP unnumbered feature of IOS, which is explained in the advanced configuration section of this chapter. The default route statement points to the Loopback0 address of the hub router (192.3.25.75). The major elements of the configuration can be seen in Example 16-7. Example 16-7. The Major Elements of the Spoke Router Configuration 1602-frame#show running-config interface Ethernet0 ip address 10.0.2.1 255.255.255.248 ip helper-address 192.168.221.193 ! <output omitted> interface Serial1 no ip address encapsulation frame-relay no ip mroute-cache no fair-queue service-module t1 timeslots 1-2 frame-relay lmi-type ansi ! interface Serial1.201 point-to-point ip unnumbered Ethernet0 bandwidth 128 frame-relay interface-dlci 201 ! ip classless ip route 0.0.0.0 0.0.0.0 192.3.25.75 ip route 181.70.194.1 255.255.255.255 Serial0.201 ip route 10.0.2.0 255.255.255.248 Ethernet0 <output omitted> The other spoke routers from Figure 16-2 are configured in a similar manner. In each of the hub and spoke configurations, you must understand how the IP addressing scheme is defined. In the hub configuration, the serial subinterfaces obtain their IP address from the Loopback0 interface. In the spoke configuration, Serial1.201 obtains its IP address from the Ethernet0 interface. This IP preservation technique is only applicable to point-to-point configurations. You are not limited to one Loopback interface. NOTE You cannot change the subinterface configurations from point-to-point to point-to-multipoint or vice versa without reloading the router. When a subinterface is configured, IOS defines an interface descriptor block (IDB). The IDBs defined for subinterfaces cannot be changed without a reload. Also, using the no interface command shows the subinter-faces as deleted until the router is reloaded, when it disappears from the output. You can also change the encapsulation from Frame Relay to high-level data link control (HDLC) on the interface. This strips out all subinterfaces because HDLC does not support this feature, but you still need to reboot the router. Maximum Number of DLCIs Per InterfaceAs you already know from Chapter 14, "Frame Relay Technology Background," the default DLCI address space is 10 bits. Theoretically, 210 = 1024 DLCIs can be configured on a single physical link. In reality, certain DLCIs are reserved for management and signaling messages. The available DLCIs for permanent virtual circuits (PVCs) range from 16 to 1007 for Consortium and from 16 to 992 for American National Standards Institute/International Telecommunication Union Telecommunication Standardization Sector (ANSI/ITU-T) specifications. However, the LMI protocol requires that the full status report about all PVCs fit into a single packet. This generally limits the number of DLCIs to fewer than 800, and depends on the maximum transmission unit (MTU) size. If you have the output of a show frame-relay lmi command from your Cisco device, you might notice that the report type (RT) information element (IE) is one byte long and the keepalive (KA) IE is 2 bytes long. For the ANSI and Q933a LMIs, the PVC IE is 5 bytes long. For the Cisco LMI, it is 8 bytes long because of the additional bandwidth value. Detailed information from the debug frame-relay lmi command is given in Chapter 17. For the purposes of the calculation, consider that the MTU size is equal to the entire LMI packet, which is 1500 bytes. Then, you subtract 13 bytes from the entire LMI packet. 13 bytes = IEs (10 bytes) + RT (1 byte) + KA (2 bytes). Next, divide that number by the length of the PVC IE (5 bytes for ANSI and Q933a, 8 bytes for Cisco) to get the maximum theoretical number of DLCIs for the interface: For ANSI or Q933a, the formula is
For Cisco, the formula is
The calculation for the maximum number of DLCIs per router is available in the Cisco documentation. You can also refer to Appendix C of Cisco Internetwork Design by Matthew H. Birkner (Cisco Press, 2000). Routing Protocols and Frame Relay ConfigurationsIt is well known that every routing protocol adds overhead, which in some cases, can be considerable, and reduces the overall bandwidth. Distance vector protocols, such as RIP and the Interior Gateway Routing Protocol (IGRP), use periodic updates to exchange routing information. RIP updates are exchanged every 30 seconds. RIP IPX updates are exchanged every 60 seconds, which results in the bandwidth consumption reaching 18.7 percent of the access rate of a T1. Some size estimates of the various distance vector routing protocol updates are shown in Table 16-1.
Link-state protocols impose other requirements on the configuration. Examples of these protocols include EIGRP for IP, IPX, AppleTalk, OSPF for IP, and Integrated Intermediate System-to-Intermediate System (IS-IS) for IP. Because these protocols do not broadcast large updates regularly, and thereby less frequently affect performance of the normal user data, higher packet and byte rates are acceptable. The queues must be dimensioned properly for the periodic exchange of the full routing/topology tables. Hence, it is recommended that the queue sizes be dimensioned as if a periodic protocol were being used. If OSPF is chosen as a routing protocol, the broadcast command in the static mapping transforms the nonbroadcast Frame Relay to broadcast. This results in forwarding broadcasts when multicasting is not enabled for NBMA networks. This approach allows OSPF to run over Frame Relay as a broadcast network. In point-to-point configurations using EIGRP, the passive-interface command prevents all routing updates from being sent to or received from a network through a specific interface, thus reducing the bandwidth consumption for routing overhead. The passive-interface command is not applicable for link-state protocols. This command prevents the router from establishing a neighbor adjacency with other routers that are connected to the same link (see Cisco IOS 12.0 documentation for more detail). On most protocols, the passive-interface command stops the router from sending updates to a particular neighbor, but it continues to listen to and use its routing updates. In general, the following techniques reduce the update load: update-only routing protocols, routing and SAP filters, longer update timers, longer interval timers, multiple access lines, and higher-speed access lines. (For a detailed description on routing protocols and their requirements and configuration features, refer to Cisco documentation). Frame Relay Broadcast QueueRemote access designs are characterized by a large number of spoke routers that terminate into one or a couple of hub routers. The routing updates can create a large amount of traffic and thus seriously affect the overall performance of the entire architecture. One of the possible solutions is the use of a Frame Relay broadcast queue per interface. For Frame Relay, the broadcast queue is separate from the regular interface queue. It has its own buffers, size, rate and is configurable with the command frame-relay broadcast-queue size byte-rate packet-rate. The configuration line is as follows: frame-relay broadcast-queue size byte-rate packet-rate The simple configuration procedure for Interface Serial3/0:0 is shown in the following lines: 7206-frame#config terminal 7206-frame(config)#interface Serial3/0:0 7206-frame(config-if)#frame-relay broadcast-queue 100 1200 120 The default settings of this command are as follows:
The actual settings in the configuration can be viewed with the show interface Serial3/0:0 command. The broadcast queue has a guaranteed minimum bandwidth allocation. To set the queue size, Cisco recommends starting with 20 packets per DLCI and monitoring the number of drops. Cisco also recommends that the byte rate should be less than both of the following (assuming 250-byte packets):
|