Frame-relay finished

So this weekend is kind of hectic – July 4th and then a friend’s wedding. I covered Frame-Relay in detail and went over the UniverCD looking up all the frame-relay material. As of right now my frame-relay appears pretty solid. I know the different types of configurations and also when not to use certain configurations. As they say, it takes practice so I am hoping to make a second pass through Frame-relay later on. As of right now I will move on to RIPv2 and EIGRP.

Frame-relay Multipoint

In a multipoint frame-relay configuration, two issues must be resolved before an IP address can be reached

• The destination IP address must be in the routing table with a valid next hop
• There must be a frame-relay mapping to that destination

Broadcast Keyword

In a hub-spoke network, when you configure frame-relay mapping from one spoke to another spoke, make sure to leave out the “broadcast” keyword. Technically you should only use the “broadcast” keyword when connecting to the hub. If you use “broadcast” keyword for spoke-to-spoke mappings, your hub router will receive redundant routing traffic.

Frame-relay LMI

Frame-relay routers send their LMI status inquiries every 10 seconds and a full status inquiry every 6th cycle. This default behavior can be changed by using the “keepalive” command for status inquiries and “Frame-relay lmi-n391dte” command for the complete interval status.

Frame-relay Point-to-Point

Frame-relay point-to-point configuration has the following to characterstics

• There is no need to disable sending inverse-arp packets because inverse-arp is disabled by default on point-to-point configurations
• There is no need for frame-relay map statments since there is only one other router on the same line. Since by default all DLCIs are assigned to the main serial interface, you can use the “frame-relay interface-dlci” command to assign that particular dlci to the sub-interface.

 Frame-relay End to End Keepalives (FREEK)

Routers depend on the LMIs to maintain the status of an active connection. Since the intermediate switches in the cloud may or may not support NNI LMIs, FREEKs can be used to provide the local router with the status of the remote end. FREEK provides an end-to-end keepalive that runs on data DLCI (16-997) and not the LMI DLCI (Cisco 1023, q933a and ANSI 0).

FREEK maintains two internal keepalives:

• The first one is used to send out keepalive requests and to handle responses to the requests aka the send side.
• The second one handles and replies to the requests aka receive side.

At the send side when the timer expires, the send side transmits a keepalive and waits for a reply. When the send side receives a reply before the timer expires, a frame-relay keepalive is recorded. If the timer expires and no keepalives are received, an error event is recorded.

If a sufficient number of error events are recorded, the pvc will transition into a down state. The number of events necessary to change the status from up to down is known as an event window.

Frame-relay UniverCD