Configuring Frame Relay
Objective:
- Configure and verify Frame Relay on Cisco routers
Configuring Frame Relay can be very simple or slightly complex, depending on your network requirements and design. I’d like to walk you through three configuration scenarios, explaining step-by-step how each piece is configured. By the time you’re finished here, you’ll be a Frame Relay expert. The three configuration scenarios are as follows:
- Configuring Frame Relay for a single neighbor
- Configuring Frame Relay that uses a multipoint interface
- Configuring Frame Relay that uses a point-to-point interface
Configuring Frame Relay for a Single Neighbor
This configuration is the simplest one to set up for Frame Relay. Because the router does most of the work for you in this configuration, many people call this a Frame Relay auto-configuration. It is helpful to walk through this configuration step-by-step, first looking at Figure 23.8.
FIGURE 23.8 Simple Frame Relay configuration.
There are two locations in this scenario: Alabama and Alaska. This configuration is really a point-to-point style connection, we’re just going through a Frame Relay cloud to accomplish it. Alabama uses DLCI 503 to reach Alaska, and Alaska uses DLCI 305 to reach Alabama. You’ve already configured the necessary IP addresses for the network requirements; all that’s left to do is configure the Frame Relay connection. Let’s have at it!
Step 1: Turn on Frame Relay Encapsulation
Start on the Alabama router to get familiar with your surroundings:
Alabama#show ip interface brief Interface IP-Address OK? Method Status Protocol Serial0/0 192.168.5.1 YES manual administratively down down Serial0/1 unassigned YES unset administratively down down Serial0/2 unassigned YES unset administratively down down Serial0/3 unassigned YES unset administratively down down FastEthernet2/0 172.16.35.1 YES manual up up
It looks as though the Fast Ethernet interface is up and running, and the Serial 0/0 interface has an IP address, but needs a little work beyond. First turn on the Frame Relay encapsulation:
Alabama#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Alabama(config)#interface serial 0/0 Alabama(config-if)#encapsulation frame-relay ? ietf Use RFC1490/RFC2427 encapsulation <cr> Alabama(config-if)#encapsulation frame-relay Alabama(config-if)#
Take a look at this. When you access the Serial interface and type encapsulation framerelay ?, you are given the option of either hitting the Enter key or adding the ietf keyword after the command. If you just press the Enter key, the router uses Cisco proprietary Frame Relay encapsulation. The Cisco proprietary version of encapsulation came out before the industry standard (ietf) Frame Relay encapsulation and uses a slightly different method for identifying the Layer 3 protocol (IP, IPX, and so on) that is being encapsulated.
This makes it incompatible with the industry standard Frame Relay encapsulation. What it boils down to is this: If you are connecting two Cisco routers over a Frame Relay network, use the command encapsulation frame-relay to configure each side. If you are connecting your Cisco router to a non-Cisco device, use the command encapsulation frame-relay ietf to use the industry standard Frame Relay encapsulation.
EXAM ALERT
Be sure to know how to configure Frame Relay encapsulation between Cisco and non-Cisco routers.
The example wants to connect two Cisco routers, so you can use the Cisco proprietary encapsulation. Watch what happens when the Serial 0/0 interface on the Alabama router is brought up:
Alabama(config-if)#no shutdown Alabama(config-if)# *Mar 1 00:23:40.571: %LINK-3-UPDOWN: Interface Serial0/0, 3changed state to up Alabama(config-if)# *Mar 1 00:23:51.571: %LINEPROTO-5-UPDOWN: Line protocol on Interface 3Serial0/0, changed state to up
It looks like the interface has come up, so now it’s time get out to privileged mode and verify that everything is working as expected. The first command you can use to check the connection is show frame-relay lmi. Remember, LMI (the Local Management Interface) is the language of love between you and your service provider. The service provider uses this language to send status messages, DLCI information, and line statistics to your local router. This is the lowest level of Frame Relay communication. If it is not working, nothing will be working.
Alabama#show frame-relay lmi LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO 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 36 Num Status msgs Rcvd 35 Num Update Status Rcvd 0 Num Status Timeouts 1
Focus on the key information here, which has been conveniently bolded for you. You can see that you have sent 36 status messages and received 35 messages. This is good. These numbers should be relatively equal and increasing on a steady basis. If the connection is failing, you will see the Num Status Timeouts field increment steadily.
You can think of these messages as keepalives for your Frame Relay connection. Your router is saying “Hello” to the service provider (Num Status Enq. Sent) and the service provider is saying “Hello back” (Num Status msgs Rcvd). Now let’s move up to the next level.
Alabama#show frame-relay pvc PVC Statistics for interface Serial0/0 (Frame Relay DTE) Active Inactive Deleted Static Local 0 0 0 0 Switched 0 0 0 0 Unused 0 1 0 0 DLCI = 503, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = ÂSerial0/0 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in pkts dropped 0 out pkts dropped 0 out bytes dropped 0 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 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec switched pkts 0 Detailed packet drop counters: no out intf 0 out intf down 0 no out PVC 0 in PVC down 0 out PVC down 0 pkt too big 0 shaping Q full 0 pkt above DE 0 policing drop 0 pvc create time 00:09:59, last time pvc status changed 00:09:34
By using the show frame-relay pvc command, you can see all your virtual circuit connections over the Frame Relay cloud. Notice that none of this has been configured. The service provider actually sent the usable DLCI information to you with the LMI signaling! Your router (Alabama) received DLCI 503 from the service provider. Referring back to the network diagram in Figure 23.8, you can see that this is exactly the DLCI information you want to receive. But there seems to be a problem: The DLCI is marked as INACTIVE. This is where understanding the four PVC states can come in very handy:
- Active—A PVC marked as ACTIVE is successfully connected through between the two endpoints (routers). This is the normal state if everything is working properly.
- Inactive—A PVC marked as INACTIVE is working properly on your end of the connection (the local side); however, the other side of the connection is either not configured or offline.
- Deleted—A PVC marked as DELETED is having problems at your side (local side) of the connection. Most likely, you are attempting to use a DLCI number that the service provider has not configured.
- Static—A PVC marked as STATIC has been manually entered by you (the administrator) rather than dynamically discovered from the service provider.
EXAM ALERT
Understanding the states of a PVC can be quite useful in both the real world and the testing environment.
Whew! Quite a bit of information there applies directly to what you are seeing right now. Because the PVC is marked as INACTIVE, it means that your side (Alabama) is working just fine; it’s the remote side (Alaska) that is having the problem. This is where you suddenly realize that you are not just the administrator in Alabama, but also the administrator for Alaska as well. You need to jump on a plane (or use a telnet connection) to reach the Alaska router and configure that side of the connection.
Alaska#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 172.16.20.1 YES NVRAM up up Ethernet1 unassigned YES unset administratively down down Serial0 192.168.5.2 YES NVRAM administratively down down Serial1 unassigned YES unset administratively down down
It looks as if Alaska is in the same state as Alabama was when you first got involved in the configuration. Turn on Frame Relay encapsulation and power on the interface:
Alaska#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Alaska(config)#interface serial 0 Alaska(config-if)#encapsulation frame-relay Alaska(config-if)#no shutdown Alaska(config-if)# 00:26:42: %LINK-3-UPDOWN: Interface Serial0, changed state to up 00:26:53: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, 3changed state to up 00:28:42: %FR-5-DLCICHANGE: Interface Serial0 - DLCI 305 state 3changed to ACTIVE
Take a look at that—the Line Protocol (data link connectivity) on the Serial interface came up and the DLCI 305 went ACTIVE. Now do the same verification commands you did on Alabama to see what things look like:
Alaska(config-if)#^Z Alaska#show frame lmi LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO 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 53 Num Status msgs Rcvd 54 Num Update Status Rcvd 0 Num Status Timeouts 0 Alaska#show frame pvc PVC Statistics for interface Serial0 (Frame Relay DTE) DLCI = 305, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0 input pkts 1 output pkts 1 in bytes 30 out bytes 30 dropped pkts 0 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 1 out bcast bytes 30 pvc create time 00:00:59, last time pvc status changed 00:01:00
Right on! The PVC status is now viewed as ACTIVE from the perspective of Alaska, which implicitly implies that Alabama is working as well (because ACTIVE indicates both sides of the connection are working as they should). So, hold your breath—now it’s time to do the final test: to ping from Alaska to Alabama, which acts as an end-to-end test of Network layer (Layer 3)
connectivity:
Alaska#ping 192.168.5.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms YES!!! That’s exactly what you want to see. Five exclamation points indicating five successful, round-trip ping messages over the Frame Relay network. Isn’t this exciting?
So let me summarize what it took to get a point-to-point Frame Relay connection running:
1. Turn on Frame Relay encapsulation. That’s it! Of course, there are some prerequisite steps, such as assigning IP addresses and turning on the interface. It may have seemed like a bigger process because of the verification commands that were performed.
However, if you have just a single connection over the Frame Relay cloud, the service provider sends both sides of the connection their DLCI information through LMI signaling. The router then uses Inverse ARP messages to discover the IP address on the remote end of the connection. After the remote IP address is discovered, the router makes the connection between the local DLCI and remote IP address. Look at one more show command:
Alaska#show frame-relay map Serial0 (up): ip 192.168.5.1 dlci 305(0x131,0x4C10), dynamic, broadcast,, status defined, active From the Alaska router’s perspective, you can see from using the show frame-relay map command that the router has mapped the Alabama router’s IP address (192.168.5.1) to the local DLCI the Alaska router uses to reach that IP address (305). You can also see that this map was dynamically defined, which means that the Cisco router made this link between IP and DLCI numbers with Inverse ARP. So the key to allowing Cisco routers to configure the Frame Relay connection themselves is to ensure the LMI is working correctly between your router and the service provider, which brings us to the closing point of this section. If you are using an extremely old version of the IOS (any version earlier than 11.2), the router is unable to auto-detect what LMI language the service provider is using. This means you must manually configure it with the following syntax: Router(config-if)#frame-relay lmi-type ? cisco ansi q933a To determine which LMI signaling you should use, you need to contact your service provider.
EXAM ALERT
Be sure to know the LMI types and be able to pick them out of a line-up. It is also key to remember that “ietf” is a Frame Relay encapsulation type. IETF is not an LMI type.
Configuring Frame Relay That Uses a Multipoint Interface
Now, the scenario has expanded with the addition of another office to the mix. This change is reflected in Figure 23.9.
FIGURE 23.9 Frame Relay configuration with multiple locations.
The Arizona office has entered the picture and moved this story to a hub and spoke design. Alabama is the hub of the network, having PVC connections to both Alaska and Arizona. To save on cost, Alaska and Arizona are not directly connected and must use their PVC to Alabama anytime they would like to reach each other.
Notice the IP addressing in this figure as well: All routers are configured on the same subnet (192.168.5.0/24) for their WAN connections. This IP addressing tells you that you are using a point-to-multipoint design. The routers think the WAN operates just like an ethernet network where all points connected to the network are able to reach all other points in the network.
If you were using a point-topoint design (a much better design, in my humble opinion), each PVC would be on its own subnet, just as if you had point-to-point WAN links through the Frame Relay cloud. The point-to-point design is discussed a little bit later; for now, it’s time to focus on making the point-to-multipoint design work successfully.
Configuring a multipoint interface can be done in two ways: You can either place the configuration under the physical interface itself or use a subinterface. Let me demonstrate. You’ve already done plenty of configuration on the physical interface, just by placing commands directly under the Serial interface. If you want to configure a subinterface, this is how the process looks:
Alaska#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Alaska(config)#interface serial 0.? <0-4294967295> Serial interface number Alaska(config)#interface serial 0.10 ? multipoint Treat as a multipoint link point-to-point Treat as a point-to-point link Alaska(config)#interface serial 0.10 multipoint Alaska(config-subif)#
In this case, the multipoint subinterface Serial 0.10 has been created. The subinterface number you choose is completely up to you. As you can see, you can use numbers from zero up to slightly more than 4 billion (Cisco is all about flexibility). In this case, I chose 10. If you were using this for your Frame Relay configuration, you could remove all commands from the physical interface (Serial 0) except for the encapsulation frame-relay command and place them under the subinterface.
At this point, there’s no real advantage to configuring Frame Relay with subinterfaces because you are using a multipoint configuration. After you get to point-topoint, you’ll see the many advantages of this configuration. For now, you can save a little complexity and just configure everything under the physical interface.
If you had a full mesh Frame Relay design where every location had a PVC to every other location, this setup would take care of itself just like the previous configuration you saw. Each location would send an Inverse ARP message out on its PVCs and figure out how to connect to everyone else. However, if you look at the figure, you can see that there is no full mesh of virtual circuits. Alabama will work just fine in this design because it has PVCs to each location.
Alaska and Arizona are going to have some problems if you just leave everything in its default configuration. The Inverse ARP message will be able to discover Alabama because it is directly at the end of the PVC; however, the Inverse ARP message does not “bounce through.” Alaska does not discover Arizona and vice versa.
This is where Frame Relay maps come in handy. You can manually configure each site by defining static maps dictating which DLCIs connect to each remote IP address. Even though it is not necessary to manually configure Alabama, it is a good practice not to mix dynamic and static configurations. If you want to use dynamic, it should be in use everywhere. Likewise, if you want to use static, use it everywhere. So the first thing to do is to configure the hub of the network, Alabama:
Alabama#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Alabama(config)#interface serial 0/0 Alabama(config-if)#frame-relay map ? bridge Bridging ip IP llc2 llc2 Alabama(config-if)#frame-relay map ip ? A.B.C.D Protocol specific address Alabama(config-if)#frame-relay map ip 192.168.5.2 ? <16-1007> DLCI Alabama(config-if)#frame-relay map ip 192.168.5.2 503 ? broadcast Broadcasts should be forwarded to this address cisco Use CISCO Encapsulation compress Enable TCP/IP and RTP/IP header compression ietf Use RFC1490/RFC2427 Encapsulation nocompress Do not compress TCP/IP headers payload-compression Use payload compression rtp RTP header compression parameters tcp TCP header compression parameters <cr> Alabama(config-if)#frame-relay map ip 192.168.5.2 503 broadcast Alabama(config-if)#frame-relay map ip 192.168.5.3 504 broadcast
You’ve now statically mapped the DLCI numbers to the remote IP addresses. Remember, after you do this, you’ve overruled the Inverse ARP process; you are now taking the role of Inverse ARP under your belt. Look at the first static map: It tells the router, “If you would like to reach the remote IP address 192.168.5.2, use the local DLCI number 503.” Likewise, the second line says, “To reach the remote IP address 192.168.5.3, use the local DLCI number 504.” It’s also important to talk about the last option added to the syntax, broadcast. By default, your router treats the Frame Relay cloud just like the type of network it is: NBMA. Therefore, your routing protocols (which use multicast and broadcast traffic) will not work over a Frame Relay network. If you would like the router to forward broadcasts over the Frame Relay cloud, attach the broadcast keyword onto the end of the Frame Relay map.
You can also see from the context-sensitive help that you have many other options in addition to the broadcast keyword that you can add to the end of the Frame Relay map. Most of these options deal with the various flavors of compression that you can enable over the Frame Relay network if you wish. However, the other two highlighted options are of key importance.
The keywords cisco and ietf define whether the remote router is a Cisco router or some other brand that uses the IETF industry-standard Frame Relay encapsulation. You might have noticed that neither command was entered under the map statement. The Cisco router uses the Cisco Frame Relay encapsulation by default. If you are connecting to non-Cisco routers, be sure to add the ietf keyword to the each map. Now you can move on to the Alaska and Arizona routers:
Alaska#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Alaska(config)#interface serial 0 Alaska(config-if)#frame map ip 192.168.5.1 305 broadcast Alaska(config-if)#frame map ip 192.168.5.3 305 broadcast Arizona#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Arizona(config)#interface serial 0/0 Arizona(config-if)#frame map ip 192.168.5.1 405 broadcast Arizona(config-if)#frame map ip 192.168.5.2 405 broadcast
Take a look at this: On the Arizona and Alaska routers, both remote IP addresses have been mapped to the same DLCI number. This is why you could not use Inverse ARP to solve this whole scenario: It would have detected only the directly connected neighbor—Alabama, in this case. Because I’m still sitting on the Arizona router, I perform the verification from there:
Arizona#show frame-relay lmi LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO 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 1336 Num Status msgs Rcvd 1337 Num Update Status Rcvd 0 Num Status Timeouts 2 Last Full Status Req 00:00:23 Last Full Status Rcvd 00:00:23
It looks like the LMI information is being received successfully. Now examine the PVC status and mappings:
Arizona#show frame-relay pvc PVC Statistics for interface Serial0/0 (Frame Relay DTE) Active Inactive Deleted Static Local 1 0 0 0 Switched 0 0 0 0 Unused 0 0 0 0 DLCI = 405, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in pkts dropped 0 out pkts dropped 0 out bytes dropped 0 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 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 00:15:57, last time pvc status changed 00:00:20 Arizona#show frame-relay map Serial0/0 (up): ip 192.168.5.1 dlci 405(0x195,0x6450), static, broadcast, CISCO, status defined, active Serial0/0 (up): ip 192.168.5.2 dlci 405(0x195,0x6450), static, broadcast, CISCO, status defined, active
Based on the output from the show frame-relay pvc and show frame-relay map commands, it looks like DLCI 405 is ACTIVE and statically mapped to both the remote IP addresses it is able to reach. Because it tests round-trip connectivity, the final ping test verifies that the rest of the locations are configured correctly as well:
Arizona#ping 192.168.5.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms Arizona#ping 192.168.5.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.2, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 116/117/124 ms Take a look at that—successful pings everywhere! However, things are not as peachy as they may seem initially. Compare those round trip times for the two destinations. When the first ping was performed from Arizona to Alabama, the average round-trip response time was 58ms. The second ping went from Arizona to Alaska, and the round-trip response time effectively doubled, moving up to 117ms! Although the hub and spoke topologies are very cost effective, they can have devastating effects on delay-sensitive traffic, such as Citrix, Voice over IP, or Video over IP. Now that the Frame Relay network is working correctly, it may be tempting to walk away cheering and feeling quite fantastic about the general state of your life.
However, one more thing needs to be checked. Take a look again at Figure 23.8. Each location has a LAN connection, representing the offices in those locations. Although the Frame Relay network may be humming along, you still need to check the routing tables to ensure each one of these locations is able to reach the other. Behind the scenes, I’ve configured EIGRP for Autonomous System 100 on each router, sending and receiving advertisements on all interfaces. Look at the routing table on Alabama first:
Alabama#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 3 subnets C 172.16.35.0 is directly connected, FastEthernet2/0 D 172.16.20.0 [90/20537600] via 192.168.5.2, 00:00:35, Serial0/0 D 172.16.15.0 [90/20537600] via 192.168.5.3, 00:00:03, Serial0/0 C 192.168.5.0/24 is directly connected, Serial0/0
Whew! Everything looks good. As you can see, the highlighted output shows the Alabama router has learned about the networks in Alaska and Arizona just fine. Just to be certain of things, jump over to Arizona and verify the routing table over there.
Arizona#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 2 subnets D 172.16.35.0 [90/2172416] via 192.168.5.1, 00:02:12, Serial0/0 C 172.16.15.0 is directly connected, Ethernet0/0 C 192.168.5.0/24 is directly connected, Serial0/0
Uh-oh. That warm, fuzzy feeling is slipping away. It appears that Arizona has learned about only the Alabama network, and is not showing Alaska in the routing table. It’s a good idea to verify the Alaska routing table as well.
Alaska#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - default U - per-user static route, o - ODR Gateway of last resort is not set 172.16.0.0/24 is subnetted, 2 subnets D 172.16.35.0 [90/2172416] via 192.168.5.1, 00:03:22, Serial0 C 172.16.20.0 is directly connected, Ethernet0 C 192.168.5.0/24 is directly connected, Serial0
Sure enough, Alaska is not learning about the Arizona network either. You have just experienced the split-horizon routing rule taking effect. The Alabama router is acting as the hub of the network. As it receives incoming routing updates on its Serial 0 interface from the Alaska and Arizona routers, the split-horizon rule jumps in and restricts the Alabama router’s capability to send those updates back out of the interface on which it was received.
There are two ways to solve this problem. First, you could move from a multipoint configuration to a pointto-point configuration (the safer, more preferred method), or disable the split-horizon routing rule completely (opening yourself up to the potential of routing loops). Remember, these routing rules have been put in place for a reason. Disabling them is like skydiving without a backup parachute. Most of the time, you should be fine, but just wait until that unusual situation. There may be very little chance of a safe landing.
Because this is a multipoint configuration, you can go ahead and disable the split-horizon features for now. The point-to-point solution is explained in just a moment. You need to be careful to disable split-horizon only at the key points of a network. If you disable it everywhere, you will most certainly end up with routing loops. In this case, you need to disable it at the network hub: Alabama. If you turn it off on this router, the routing updates will be received on the Serial 0 interface and sent right back out the same interface, allowing Arizona and Alaska to hear about each other. Here’s how it’s done:
Alabama#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Alabama(config)#interface serial 0/0 Alabama(config-if)#no ip split-horizon ? eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) <cr> Alabama(config-if)#no ip split-horizon eigrp ? <1-65535> Autonomous system number Alabama(config-if)#no ip split-horizon eigrp 100 *Mar 1 00:45:29.507: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor Â192.168.5.3 (Serial0/0) is down: split horizon changed *Mar 1 00:45:29.507: destroy peer: 192.168.5.3 *Mar 1 00:45:29.507: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor Â192.168.5.2 (Serial0/0) is down: split horizon changed *Mar 1 00:45:29.507: destroy peer: 192.168.5.2 Alabama(config-if)# *Mar 1 00:46:19.647: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor Â192.168.5.2 (Serial0/0) is up: new adjacency *Mar 1 00:46:38.111: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor Â192.168.5.3 (Serial0/0) is up: new adjacency
You can see that turning off split-horizon for the EIGRP routing system caused the neighbors to reset themselves because of the configuration change. Now that they’ve come back up, you can verify the Alaska and Arizona routing tables:
Alaska#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - default U - per-user static route, o - ODR Gateway of last resort is not set 172.16.0.0/24 is subnetted, 3 subnets D 172.16.35.0 [90/2172416] via 192.168.5.1, 00:02:12, Serial0 C 172.16.20.0 is directly connected, Ethernet0 D 172.16.15.0 [90/21049600] via 192.168.5.1, 00:02:12, Serial0 C 192.168.5.0/24 is directly connected, Serial0 Arizona#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 3 subnets D 172.16.35.0 [90/2172416] via 192.168.5.1, 00:02:57, Serial0/0 D 172.16.20.0 [90/21049600] via 192.168.5.1, 00:02:33, Serial0/0 C 172.16.15.0 is directly connected, Ethernet0/0 C 192.168.5.0/24 is directly connected, Serial0/0
Excellent! The remote sites are now seeing each other’s LAN connections in the routing table. The multipoint Frame Relay configuration is complete.
Configuring Frame Relay That Uses Point-to-Point Interfaces
I’m so excited! All this configuration has led up to this point: my highly suggested and preferred Frame Relay configuration, point-to-point subinterfaces. As you just saw, configuring Frame Relay using multipoint connections can be confusing because you have multiple, non–directly connected sites tied together through a single physical interface. In addition, it can cause some technical problems, primarily with routing protocols. Now, enter point-topoint subinterfaces into the configuration and these problems slowly melt away.
The configuration of point-to-point subinterfaces does require a little more work than multipoint because it requires you to create a logical subinterface for each PVC coming out of your locations. To explain this, let me introduce the next scenario to be configured. It involves setting up a network very similar to the previous, multipoint configuration. This time, a router known as Salmon will be the hub. BlueGill and Trout will act as the spokes. Take a look at the logical diagram in Figure 23.10.
FIGURE 23.10 Point-to-point Frame Relay configuration.
Can you see the difference between the point-to-point and multipoint configurations at the hub router? Instead of having a single IP address and interface connected to the Frame Relay cloud, you now have two logical subinterfaces connected to the Frame Relay cloud: Serial0/0.503 and Serial0/0.504. Each one of these subinterfaces is on its own subnet. Now, the split-horizon problems from before are automatically solved through the creation of these subinterfaces.
When the router receives a routing update on Serial0/0.503, it has no problem sending it out Serial0/0.504, and vice versa. Now you may argue that it is still sending it out the same physical interface, which is true. However, the router doesn’t see it this way. After you create the two subinterfaces, the router sees them as two completely independent connections.
The only disadvantage of a point-to-point configuration is that you must configure a separate subnet for each PVC, whereas the multipoint allowed all routers to share a common subnet. With that foundation in place, let’s jump straight into the configuration and fill in the gaps as you go. I’m going to begin with the hub of the network: the great Salmon router. First, familiarize yourself with the surroundings:
Salmon#show ip interface brief Interface IP-Address OK? Method Status Protocol Serial0/0 unassigned YES manual up up Serial0/1 unassigned YES NVRAM administratively down down Serial0/2 unassigned YES NVRAM administratively down down Serial0/3 unassigned YES NVRAM administratively down down Ethernet1/0 unassigned YES NVRAM administratively down down FastEthernet2/0 172.16.35.1 YES NVRAM up up Good—the Serial0/0 interface has no IP configuration. Let’s begin: Salmon#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Salmon(config)#interface serial 0/0 Salmon(config-if)#encapsulation frame-relay Salmon(config-if)#exit Salmon(config)# *Mar 1 02:06:37.787: %LINEPROTO-5-UPDOWN: Line protocol on 3Interface Serial0/0, changed state to up The first move is to enable Frame Relay encapsulation on the physical interface. Notice that the line protocol immediately comes online. At this point, you are finished with the physical interface configuration. Now you can move to the subinterfaces. Salmon(config)#interface serial 0/0.? <0-4294967295> Serial interface number Salmon(config)#interface serial 0/0.503 ? multipoint Treat as a multipoint link point-to-point Treat as a point-to-point link Salmon(config)#interface serial 0/0.503 point-to-point Salmon(config-subif)#
We’ve just created the subinterface Serial0/0.503 in a point-to-point configuration, as shown in Figure 23.10. The fact that the subinterface number matches the local DLCI used for the connection holds no functional significance whatsoever. It is just a common practice to have your subinterface number match the DLCI number for administrative identification purposes. Now that you are in the subinterface configuration mode, you can set up the logical parameters. This will take just two settings:
Salmon(config-subif)#ip address 10.5.5.1 255.255.255.0 Salmon(config-subif)#frame-relay interface-dlci 503 Salmon(config-fr-dlci)#exit Salmon(config-subif)#exit Salmon(config)#
The two commands necessary assigned the IP address and the local DLCI number to the subinterface. No complex mappings. No broadcast keywords. Just an IP address and DLCI number. Simple is good. Now add the second subinterface to the configuration and verify how everything looks:
Salmon(config)#interface serial 0/0.504 point-to-point Salmon(config-subif)#ip address 10.6.6.1 255.255.255.0 Salmon(config-subif)#frame-relay interface-dlci 504 Salmon(config-fr-dlci)#end Salmon# *Mar 1 02:14:31.287: %SYS-5-CONFIG_I: Configured from console by console Salmon#show ip interface brief Interface IP-Address OK? Method Status Protocol Serial0/0 unassigned YES manual up up Serial0/0.503 10.5.5.1 YES manual up up Serial0/0.504 10.6.6.1 YES manual up up Serial0/1 unassigned YES NVRAM administratively down down Serial0/2 unassigned YES NVRAM administratively down down Serial0/3 unassigned YES NVRAM administratively down down Ethernet1/0 unassigned YES NVRAM administratively down down FastEthernet2/0 172.16.35.1 YES NVRAM up up
Have you ever had a fresh chocolate chip cookie, pulled right out of the oven, cooked to a golden crisp that literally melts in your mouth? That’s the only thing that might be better than a configuration like this. Look at that!!! You have two logical subinterfaces configured perfectly on their own subnets. The router also knows what DLCI number it is able to use to reach the other side of the connection. One quick note: Have you been noticing how the router moves you into a DLCI configuration mode after you enter the frame-relay interface-dlci command? When you get into the advanced Frame Relay configurations, you will be able to assign certain traffic shaping parameters to each one of those connections that tell the router how fast it should send to each site, among many other things. That’s for the CCNP certification. For now, go ahead and bring up the two spoke routers:
BlueGill#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 172.16.20.1 YES NVRAM up up Ethernet1 unassigned YES unset administratively down down Serial0 unassigned YES NVRAM up down Serial1 unassigned YES unset administratively down down BlueGill#configure terminal Enter configuration commands, one per line. End with CNTL/Z. BlueGill(config)#interface serial 0 BlueGill(config-if)#encapsulation frame-relay *Mar 1 02:19:32.011: %LINEPROTO-5-UPDOWN: Line protocol on ÂInterface Serial0, changed state to up BlueGill(config-if)#exit BlueGill(config)#interface serial 0.305 point-to-point BlueGill(config-subif)#ip address 10.5.5.2 255.255.255.0 BlueGill(config-subif)#frame-relay interface-dlci 305 02:20:18: %FR-5-DLCICHANGE: Interface Serial0 - DLCI 305 state Âchanged to ACTIVE BlueGill(config-fr-dlci)#^Z BlueGill# Trout#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 172.16.15.1 YES NVRAM up up Serial0/0 unassigned YES NVRAM up down Trout#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Trout(config)#interface serial 0/0 Trout(config-if)#encapsulation frame-relay *Mar 1 02:29:36.081: %LINEPROTO-5-UPDOWN: Line protocol on Interface ÂSerial0/0, changed state to up Trout(config-if)#exit Trout(config)#interface serial 0/0.405 point-to-point Trout(config-subif)#ip address 10.6.6.2 255.255.255.0 Trout(config-subif)#frame-relay interface-dlci 405 02:33:18: %FR-5-DLCICHANGE: Interface Serial0/0 - DLCI 405 state Âchanged to ACTIVE Trout(config-fr-dlci)#^Z Trout#
Did you see those DLCIs go ACTIVE? That’s a really good sign that things are working just fine. Behind the scenes, I also configured the EIGRP process on all three routers to include all attached interfaces. Because I’m currently connected to the Trout router, I’ll verify everything is working okay from here:
Trout#ping 10.6.6.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.6.6.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms Trout#ping 10.5.5.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.5.5.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/116/117 ms Trout#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 3 subnets D 172.16.35.0 [90/2172416] via 10.6.6.1, 00:05:21, Serial0/0.405 D 172.16.20.0 [90/21049600] via 10.6.6.1, 00:05:21, Serial0/0.405 C 172.16.15.0 is directly connected, Ethernet0/0 10.0.0.0/24 is subnetted, 2 subnets C 10.6.6.0 is directly connected, Serial0/0.405 D 10.5.5.0 [90/21024000] via 10.6.6.1, 00:05:21, Serial0/0.405
Sweet! The first ping tested connectivity from the Trout router to the Salmon router. The second ping tested connectivity from the Trout router to the BlueGill router. Finally, by examining the routing table, you can see that the Trout router has already learned about the LANs behind Trout and BlueGill, and has even learned about the PVC between Salmon and BlueGill (this is the last bolded entry in the routing table). This is a key feature of the point-to-point configuration. Because every PVC is seen as its own subnet, routing protocols enable your routers to learn about those connections without requiring the messy maps of multipoint configurations. Just like that, you have a point-to-point Frame Relay configuration.