The Fundamentals of OSPF Routing Design | OSPF Network Design Solutions

Table of Contents

Another command used to troubleshoot the connection is show frame-relay map. It can be used to confirm the Layer 1 and 2 connectivity between the routers. This enables you to eliminate this as a problem before you begin concentrating on the Layer 3 issues. This command is available for use and is shown in the following example:

    HUB_ROUTER1#show frame map    Serial0 (up): point-to-point dlci, dlci 101(0x12,0x420), broadcast    Serial0 (up): point-to-point dlci, dlci 102(0x10,0x400), broadcast    Serial0 (up): point-to-point dlci, dlci 103(0x12,0x420), broadcast

This shows the connection from serial 0 to three different DLCIs; it shows that they are enabled for broadcast; and it will also show if the mapping is dynamic or static.

If there is no mapping to the other end, then the PVC has not been fully made. Therefore, there is a problem with the Frame Relay circuit and any associated problems with routing or with the OSPF process are not important until the physical layer problem has been taken care of.

Also, show ip ospf interface serial 0 will show the following:

    Spoke_R2#show ip ospf interface serial 0    Serial0 is up, line protocol is up      Internet Address 10.0.1.2/24, Area 0      Process ID 1, Router ID 10.0.1.2, Network Type POINT_TO_MULTIPOINT,      Cost: 64      Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,      Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5        Hello due in 00:00:07      Neighbor Count is 1, Adjacent neighbor count is 1        Adjacent with neighbor 10.0.2.1

The preceding command shows the network type and state. It also lets you confirm that different timers that are set in OSPF. These should be identical between your routers. If these are not, or there is a problem with the subnet masks between the two routers, then a debug ip ospf events will show the following:

    OSPF: Mismatched hello parameters from 200.1.3.2    Dead R 40 C 40, Hello R 10 C 10 Mask R 255.255.255.248 C 255.255.255.0    OSPF: Mismatched hello parameters from 200.1.3.2    Dead R 40 C 40, Hello R 10 C 10 Mask R 255.255.255.248 C 255.255.255.0

What is happening in the preceding output?

• The mask is not matching.

• R indicates what you are receiving.

• C indicates what is configured.

If one end of a Frame Relay link is configured to be a multipoint link type and the other end point-to-point, the multipoint interface would advertise the link as a Nonbroadcast and the point-to-point would interface the link as a point-to-point, which creates a conflict in the LSDB. It might cause the router to learn none of the routes through that link.

One possible fix for this is to change the point-to-point interface to a multipoint interface or change the interface type to broadcast by using the command ip ospf network broadcast.

OSPF and multipoint can be dangerous. OSPF needs a DR and if you start missing PVCs, then some routers might loose connectivity and want to become the DR. This can become a serious problem even though other routers still see the old DR. So your OSPF process will go a little crazy. Overhead associated with OSPF is not as obvious and predictable as that with traditional distance vector-routing protocols. The unpredictability comes from whether or not the OSPF network links are stable. If all adjacencies to a Frame Relay router are stable, only neighbor hello packets (keepalives) will flow, which is comparatively much less overhead than that incurred with a distance vector protocol (RIP, IGRP). If, however, routes (adjacencies) are unstable, link-state flooding will occur, and bandwidth can quickly be consumed. OSPF also is very processor-intensive when running the Dijkstra algorithm, which is used for computing routes.

Case Study Conclusion

The objective of this case study was to demonstrate how to use, configure, and troubleshoot an OSPF point-to-multipoint link. You have an example and explanation for the configuration, which should help you in both design considerations and implementation. The different show commands and debug commands reviewed will assist you in troubleshooting the point-to-multipoint configuration and, by understanding the data, should be helpful in troubleshooting more general OSPF problems as well.

A summary of appropriate show and debug commands for OSPF point-to-multipoint use, configuration, and troubleshooting is as follows:

• show ip ospf neighbor

• show ip ospf interface

• show ip ospf virtual

• debug ip ospf packet

• debug ip ospf events

• show frame-relay map

• show frame-relay PVC

Frequently Asked Questions

Q—OSPF is an IP based protocol which means it runs directly over IP but what value is placed in the IP packet header to identify it as a OSPF packet?

A—Protocol 89

Q—OSPF uses the class D multicast addresses in the range 224.0.0.0 through 239.255.255.255. with specially reserved address as follows 224.0.0.5 for all OSPF routers and 224.0.0.6 for all DRs and BDRs. However, is the multicasting on the IP layer alone sufficient?

A—No, sometimes the link layer protocol might also require special multicast MAC addresses so as to route the info properly.

Table of Contents