Narbik’s Soup-to-Nuts Workbook Frame-relay Lab 6

Frame Relay, Narbik WB — By CCIETalk on June 8, 2008 at 5:11 pm

Lab 6 - "Frame-relay end-to-end Keepalive - FREEK" requires us to configure a frame-relay cloud with a hub and spoke topology using point-to-point sub-interfaces. This part was similar to the other frame-relay labs I have done in this workbook. To be honest, I have never configured end-to-end keepalives before so I had no choice but to look through the DOCCD. As always, this was a great exercise that helped me get familiar with the DOCCD Configuring Frame-relay end-to-end keepalives is documented under Cisco IOS Wide-Area Networking Configuration Guide, Release 12.4. Task 2 asks you to configure end-to-end keepalives using bidirectional mode. Using the command reference listed in the table, use the mode option to configure this. Task 3 requires that we configure request mode on R1 and reply mode on R3. Once again use the mode option to change the modes on the routers. These two tasks were a good starting point for me to understand keepalives. I read through the DOCCD explaination and tried a few other combinations to really master this concept.

To configure Frame Relay end-to-end keepalives, use the following commands beginning in global configuration mode:


	Command	Purpose
Step 1	Router(config)# map-class frame-relay map-class-name	Specifies a map class for the VC.
Step 2	Router(config-map-class)# frame-relay end-to-end keepalive mode {bidirectional \| request \| reply \| passive-reply}	Specifies Frame Relay end-to-end keepalive mode.

The four modes determine the type of keepalive traffic each device sends and responds to:

In bidirectional mode, the device will send keepalive requests to the other end of the VC and will respond to keepalive requests from the other end of the VC.
In request mode, the device will send keepalive requests to the other end of the VC.
In reply mode, the device will respond to keepalive requests from the other end of the VC.
In passive-reply mode, the device will respond to keepalive requests from the other end of the VC, but will not track errors or successes.