Networking Routing Fundamentals | OSPF Network Design Solutions

Table of Contents

If none of the three preceding troubleshooting operations work, it could be that the telco has yet to turn on the Frame Relay circuit. Use the debug frame-relay lmi command to display whether the router is receiving LMI responses from the Frame Relay switch or not. Double-check with the Frame Relay provider to make sure that the circuit has been activated.

Verifying That the PVC Status Is Active

After the interface is up and the line protocol is up, the next step is to verify that the PVC status is active. To view the status of PVCs on the router, use the show frame-relay pvc command. Figure 2-14 displays a sample output of the show frame-relay pvc command.

Figure 2-14 The show frame-relay pvc output.

The show frame-relay pvc command indicates that the PVC is in one of three different states (see field “B” in Figure 3-9). The sections that follow outline the possible PVC states and offer some suggested actions to correct PVC problems.

PVC Status: Active

If the PVC status is active, a permanent virtual circuit (PVC) has been created. The Frame Relay link between the two sites is up. You can proceed to Step 4 and verify that the Frame Relay encapsulation matches on both routers.

PVC Status: Inactive

If the PVC status is inactive, the PVC associated with the corresponding DLCI number (see Field A in Figure 2-14) is being offered by the Frame Relay provider but not being used by the router.

To correct this problem, you should begin by verifying DLCI numbering. Double-check the DLCI numbering with the Frame Relay provider and make certain that the router is configured with the DLCI numbering that the Frame Relay provider has supplied. The DLCI numbers are configured with either the frame-relay map command for multipoint interfaces or the frame-relay interface-dlci command for point-to-point subinterfaces. A common mistake is the accidental reversal of DLCI numbering between sites. For instance, if the DLCI number that is supposedly assigned to the remote site shows up as “inactive” at the local site, there is a good chance that the DLCI numbers are reversed.

PVC Status: Deleted

If the PVC status is “deleted,” the router has been configured with a DLCI number that is not offered by the Frame Relay provider. As a result, the PVC cannot be created and therefore is “deleted.”

To correct this problem, you should begin by double-checking the DLCI numbering with the Frame Relay provider and making certain that the router is configured with the DLCI numbering that the Frame Relay provider has supplied. The DLCI numbers are configured with either the frame-relay map command for multipoint interfaces or the frame-relay interface-dlci command for point-to-point subinterfaces. A common mistake is the accidental reversal of DLCI numbering between sites. Check to see if there are any other DLCI numbers showing up as inactive. If inactive entries exist, there is a good chance that the correct DLCI number should be the DLCI number that is showing up as inactive. Check with the Frame Relay provider to be certain!

Another tactic to employ is to verify that the Frame Relay provider has activated the PVC. There is a possibility that the Frame Relay provider has not yet activated the PVC. Check with the Frame Relay provider to verify that the PVC has been activated.

Verifying That the Frame Relay Encapsulation Matches on Both Routers

Finally, if all three of the previous steps have not solved the Frame Relay problem, the problem might be related to Frame Relay encapsulation. Cisco routers default to “cisco” Frame Relay encapsulation. “cisco” Frame Relay encapsulation is only valid between other Cisco routers that are using “cisco” Frame Relay encapsulation. If connecting to a third-party router, the Frame Relay encapsulation must be changed from “cisco” to “IETF”. To configure IETF Frame Relay encapsulation, replace the “encapsulation frame-relay” command with “encapsulation frame-relay IETF”. Most Frame Relay problems can be solved by following the steps outlined in this case study.

Frequently Asked Questions (FAQs)

Q—What is the difference between classful and classless routing protocols?

A—Classful protocols, such as RIP and IGRP, consider the IP network class (A, B, C . . . and their default masks) when doing route summarization. Whereas, with classless protocols, such as OSPF, several networks can appear as a single larger network to those outside the network in question when using aggregation.

Q—Are routing updates sent out on links that are defined only by static routes?

A—No routing updates are sent. The thought behind this routing characteristic is as follows: Because this route has been manually configured by the user, updates are not needed, so you can conserve bandwidth by not sending updates out the link. Dynamic and static routing can be used together; they are mutually exclusive.
For example, with OSPF, you can learn the route:

    O 171.69.0.0/16 interface e 0 via 1.1.1.1

You can also add a static route with various administrative distances applied to them—for example:

    ip route 123.0.0.0 255.0.0.0 e 0 1.1.1.1    ip route 171.69.0.0 255.255.0.0 bri 0 200

Then you will have the following entries in your routing table:

    O 171.69.0.0/16 interface e 0 via 1.1.1.1    S 123.0.0.0/8 interface e 0 via 1.1.1.1

In this case, you will still have an OSPF update going out interface e 0, which is not affected by the static route configured. However, if then you lose the OSPF route for 171.69.0.0, the static route will come into play:

    S 171.69.0.0/16 interface bri 0    S 123.0.0.0/8 interface e 0 via 1.1.1.1

And so you and have bri 0 as our backup to 171.69.0.0.

Q—Will static routes be sent out to other routers?

A—No, they are considered local routes only and are sent out to other routers only if you specifically tell the router to do so through the use of a redistribute static command.

Table of Contents