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 ActiveAfter 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. 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 RoutersFinally, 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)
|