Cisco CCNA / CCNP Certification Tutorial: Frame Relay End-To-End Keepalives

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.

Reply mode enables only the receive process. The router will respond to requests from other routers but will initiate no requests of its own.

Finally, passive reply mode allows the router to respond to requests, but no timers are set and no events are tracked.

Frame Relay End-To-End Keepalive defaults:

Two send or receive errors must be registered in order for the VC to be considered down.

The event window size is three. The event window is the number of events considered by the router when determining the status of the VC. Therefore, using the defaults, two send or receive errors would have to be received within the event window of three events for the VC to be considered down.

The timer mentioned earlier - the amount of time a router waits for a response - is set to 10 seconds

Working with Frame Relay end-to-end keepalives is just one Frame skill you’ll need to pass the CCNP exams – and I wouldn’t be surprised to see them on a CCIE exam. Know the details and you’re on your way to Cisco certification exam success!

Cisco CCNA / CCNP Certification Exam: Frame Relay Encapsulation Types

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(0x7B,0x1CB0), static

broadcast, CISCO, status defined, active

Serial0 (up): ip 172.12.123.2 dlci 122(0x7B,0x1CB0), 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!