One of the first things you learned about Frame is that the LMI also serves as a keepalive, or a heartbeat – and if three consecutive LMIs are missed, the line protocol goes down. There’s a limitation to LMI as a keepalive, though. The LMI is exchanged only between the DTE and the closest DCE. The LMI is therefore a local keepalive that does not reflect any possible issues on the remote end of the virtual circuit.

Taking the LMI concept to the next logical level, Frame Relay End-To-End Keepalives (FREEK, one of the least-heard Cisco acronyms for some reason) are used to verify that endpoint-to-endpoint communications are functioning properly.

What you have to keep in mind about FREEK is that each and every PVC needs two separate keepalive processes. Remember, with a PVC, there’s no guarantee that the path taking through the frame relay cloud to get from R1 to R2 is going to be the same path taken to go back from R2 to R1. One process will be used to send requests for information and handle the responses to these requests; this is the send side. When the send side transmits a keepalive request, a response is expected in a certain number of seconds. If one is not received, an error event is noted. If enough error events are recorded, the VC’s keepalive status is marked as down.

The process that responds to the other side’s requests is the receive side.

This being Cisco, we’ve got to have some modes, right? FREEK has four operational modes.

Bidirectional mode enables both the send and receive process enabled on the router, meaning that the router will send requests and process responses (send side) and will also respond to remote requests for information (receive side).

Request mode enables only the send process. The router will send requests and process responses to those requests, but will not answer requests from other routers.
Read the full story

Earning your Cisco CCNA and CCNP is a tough proposition, and part of that is the fact that you quickly learn that there’s usually more than one way to do things with Cisco routers – and while that’s generally a good thing, you better know the ins and outs of all options when it comes to test day and working on production networks. Working with Frame Relay subinterfaces and split horizon is just one such situation.

One reason for the use of subinterfaces is to circumvent the rule of split horizon. You recall from your CCNA studies that split horizon dictates that a route cannot be advertised out the same interface upon which it was learned in the first place. In the following example, R1 is the hub and R2 and R3 are the spokes. All three routers are using their physical interfaces for frame relay connectivity, and they are also running RIPv2 172.12.123.0 /24. Each router is also advertising a loopback interface, using the router number for each octet.

R1(config)#int s0

R1(config-if)#ip address 172.12.123.1 255.255.255.0

R1(config-if)#no frame inverse

R1(config-if)#frame map ip 172.12.123.2 122 broadcast

R1(config-if)#frame map ip 172.12.123.3 123 broadcast

R1(config-if)#no shut

R2(config)#int s0

R2(config-if)#encap frame

R2(config-if)#no frame inver

R2(config-if)#frame map ip 172.12.123.1 221 broadcast

R2(config-if)#frame map ip 172.12.123.3 221 broadcast

R2(config-if)#ip address 172.12.123.2 255.255.255.0

R3(config)#int s0

R3(config-if)#encap frame

R3(config-if)#no frame inver

R3(config-if)#frame map ip 172.12.123.1 321 broadcast

R3(config-if)#frame map ip 172.12.123.2 321 broadcast

R3(config-if)#ip address 172.12.123.3 255.255.255.0

R1#show ip route rip

2.0.0.0/32 is subnetted, 1 subnets

R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:20, Serial0

3.0.0.0/32 is subnetted, 1 subnets

R 3.3.3.3 [120/1] via 172.12.123.3, 00:00:22, Serial0

R2#show ip route rip

1.0.0.0/32 is subnetted, 1 subnets

R 1.1.1.1 [120/1] via 172.12.123.1, 00:00:06, Serial0

R3#show ip route rip

1.0.0.0/32 is subnetted, 1 subnets

R 1.1.1.1 [120/1] via 172.12.123.1, 00:00:04, Serial0

The hub router R1 has a route to both loopbacks, but neither spoke has a route to the other spoke’s loopback. That’s because split horizon prevents R1 from advertising a network via Serial0 if the route was learned on Serial0 to begin with.

We’ve got two options here, one of which is to disable spilt horizon on the interface. While doing so will have the desired effect in our little network, disabling split horizon is not a good idea and should be avoided whenever possible. We’re not going to do it in this lab, but here is the syntax to do so:

R1(config)#interface serial0

R1(config-if)#no ip split-horizon

A better solution is to configure subinterfaces on R1. The IP addressing will have to be revisited, but that’s no problem here. R1 and R2 will use 172.12.123.0 /24 to communicate, while R1 and R3 will use 172.12.13.0 /24. R3’s serial0 interface will need to be renumbered, so let’s look at all three router configurations:

R1(config)#interface serial0

R1(config-if)#encap frame

R1(config-if)#no frame inverse-arp

R1(config-if)#no ip address

R1(config-if)#interface serial0.12 multipoint

R1(config-subif)#ip address 172.12.123.1 255.255.255.0

R1(config-subif)#frame map ip 172.12.123.2 122 broadcast

R1(config-subif)#interface serial0.31 point-to-point

R1(config-subif)#ip address 172.12.13.1 255.255.255.0

R1(config-subif)#frame interface-dlci 123

R2(config)#int s0

R2(config-if)#ip address 172.12.123.2 255.255.255.0

R2(config-if)#encap frame

R2(config-if)#frame map ip 172.12.13.3 221 broadcast

R2(config-if)#frame map ip 172.12.123.1 221 broadcast

R3(config)#int s0

R3(config-if)#ip address 172.12.13.3 255.255.255.0

R3(config-if)#encap frame

R3(config-if)#frame map ip 172.12.13.1 321 broadcast

R3(config-if)#frame map ip 172.12.123.2 321 broadcast

A frame map statement always names the REMOTE IP address and the LOCAL DLCI. Don’t forget the broadcast option!

Show frame map shows us that all the static mappings on R1 are up and running. Note the “static” output, which indicates these mappings are a result of using the frame map command. Pings are not shown, but all three routers can ping each other at this point.

R1#show frame map

Serial0 (up): ip 172.12.123.2 dlci 122(0×7A,0×1CA0), static,

broadcast, CISCO, status defined, active

Serial0 (up): ip 172.12.13.3 dlci 123(0×7B,0×1CB0), static,

broadcast, CISCO, status defined, active

After the 172.12.13.0 /24 network is added to R1 and R3’s RIP configuration, R2 and R3 now have each other’s loopback network in their RIP routing tables.

R2#show ip route rip

1.0.0.0/32 is subnetted, 1 subnets

R 1.1.1.1 [120/1] via 172.12.123.1, 00:00:20, Serial0

3.0.0.0/32 is subnetted, 1 subnets

R 3.3.3.3 [120/1] via 172.12.123.1, 00:00:22, Serial0

R3#show ip route rip

1.0.0.0/32 is subnetted, 1 subnets

R 1.1.1.1 [120/1] via 172.12.13.1, 00:00:20, Serial0

2.0.0.0/32 is subnetted, 1 subnets

R 2.2.2.2 [120/1] via 172.12.13.1, 00:00:22, Serial0

While turning split horizon off is one way to achieve total IP connectivity, doing so can have other unintended results. The use of subinterfaces is a more effective way of allowing the spokes to see the hub’s loopback network.

BECNs and FECNs aren’t just important to know for your Cisco CCNA and CCNP certification exams – they’re an important part of detecting congestion on a Frame Relay network and allowing the network to dynamically adjust its transmission rate when congestion is encountered.

The Forward Explicit Congestion Notification (FECN, pronounced “feckon”) bit is set to zero by default, and will be set to 1 if congestion was experienced by the frame in the direction in which the frame was traveling. A DCE (frame relay switch) will set this bit, and a DTE (router) will receive it, and see that congestion was encountered along the frame’s path.

If network congestion exists in the opposite direction in which the frame was traveling, the Backward Explicit Congestion Notification (BECN, pronounced “beckon”) will be set to 1 by a DCE.

If this is your first time working with BECNs and FECNs, you might wonder why the BECN even exists – after all, why send a “backwards” notification? The BECN is actually the most important part of this entire process, since it’s the BECN bit that indicates to the sender that it needs to slow down!

For example, frames sent from Kansas City to Green Bay encounter congestion in the FR cloud. A Frame Switch sets the FECN bit to 1. In order to alert KC that it’s sending data too fast, GB will send return frames with the BECN bit set. When KC sees the BECN bit is set to 1, the KC router knows that the congestion occurred when frames were sent from KC to GB.

Frame Relay BECN Adaptive Shaping allows a router to dynamically throttle back on its transmission rate if it receives frames from the remote host with the BECN bit set. In this case, KC sees that the traffic it’s sending to GB is encountering congestion, because the traffic coming back from GB has the BECN bit set. If BECN Adaptive Shaping is running on KC, that router will adjust to this congestion by slowing its transmission rate. When the BECNs stop coming in from GB, KC will begin to send at a faster rate.

BECN Adaptive Shaping is configured as follows:

KC(config)#int s0

KC(config-if)#frame-relay adaptive-shaping becn

To see how many frames are coming in and going out with the BECN and FECN bits set, run show frame pvc.

R3#show frame pvc

< some output removed for clarity >

input pkts 306 output pkts 609 in bytes 45566

out bytes 79364 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 568 out bcast bytes 75128

pvc create time 01:26:27, last time pvc status changed 01:26:27

Just watch the “in”s and “out”s of BECN, FECN, and DE in both the exam room and your production networks!

When you’re studying to pass the Cisco CCNA and CCNP certification exams, you quickly learn that there’s always something else to learn. (You’ll really pick up on this in your CCIE studies, trust me!) Today we’ll take a look at an often-overlooked topic in Frame Relay, the encapsulation type. You don’t exactly change this on a daily basis in production networks (not if you want to stay employed, anyway!), but it’s an important exam topic that you must be familiar with.

The DCE and DTE must agree on the LMI type, but there’s another value that must be agreed upon by the two DTEs serving as the endpoints of the VC. The Frame encapsulation can be left at the default of Cisco (which is Cisco-proprietary), or it can be changed to the industry-standard IETF, as shown below. If a non-Cisco router is the remote endpoint, IETF encapsulation must be used. Note that the default of Cisco isn’t listed as an option by IOS Help, so you better know that one by heart!

R1(config)#int s0

R1(config-if)#encap frame ?

ietf Use RFC1490/RFC2427 encapsulation

R1(config-if)#encap frame ietf

What if a physical interface is in use and some remote hosts require Cisco encapsulation and others require IETF? The encapsulation type can be configured on a per-PVC basis as well. One encap type can be used on the interface, and any map statements that require a different encap type can have that specified in the appropriate map statement. In the following example, all PVCs will use the default Cisco encapsulation type except for PVC 115. The frame map statement using that PVC has ietf specified.

R1(config)#int s0/0

R1(config-if)#encap frame

R1(config-if)#frame map ip 172.12.123.3 123 broadcast

R1(config-if)#frame map ip 172.12.123.2 122 ietf broadcast

show frame map shows us that the mapping to DLCI 123 is using Cisco encapsulation, and DLCI 122 is using IETF.

R1#show frame map

Serial0 (up): ip 172.12.123.3 dlci 123(0×7B,0×1CB0), static

broadcast, CISCO, status defined, active

Serial0 (up): ip 172.12.123.2 dlci 122(0×7B,0×1CB0), static

broadcast, ietf, status defined, active

Just remember that Cisco is the default, and all PVCs will use Cisco unless you specify IETF in the frame map statement itself. You could also change the entire interface to use IETF for all mappings with the frame-relay encapsulation IETF command. For Cisco exams, as well as work on production networks, it’s always a good idea to know more than one way to do something!