OSPF Network Design Solutions

Router Configuration Examples

The following are examples of the configurations contained within the routers shown in Figure 5-21:

Hub_Router1# interface Serial 0 ip address 10.0.1.1 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint non-broadcast frame-relay local-dlci 100 ! router ospf 1 network 10.0.1.0 0.0.0.255 area 0 neighbor 10.0.1.2 10 neighbor 10.0.1.3 10 neighbor 10.0.1.4 10 Spoke_Router2# interface Serial 0 ip address 10.0.1.2 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint non-broadcast frame-relay local dlci 101 ! router ospf 1 network 10.0.1.0 0.0.0.255 area 0 network 10.2.0.0 0.0.255.255 area 2 neighbor 10.0.1.1 10 Spoke_Router3# interface Serial 0 ip address 10.0.1.3 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint non-broadcast frame-relay local-dlci 103 ! router ospf 1 network 10.0.1.0 0.0.0.255 area 0 network 10.3.0.0 0.0.255.255 area 3 neighbor 10.0.1.1 10 Spoke_Router4# interface Serial 0 ip address 10.0.1.4 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint non-broadcast frame-relay local-dlci 104 ! router ospf 1 network 10.0.1.0 0.0.0.255 area 0 network 10.4.0.0 0.0.255.255 area 4 neighbor 10.0.1.1 10

You will not be able to ping your own IP address on a multipoint Frame Relay interface. This is because FR multipoint (sub)interfaces are nonbroadcast (unlike Ethernet and point-to-point interfaces (HDLC) and Frame Relay point-to-point sub-interfaces). Furthermore, you will not be able to ping from one spoke router to another spoke router in a hub and spoke configuration. This is because there is no mapping for your own IP address (and none was learned via inverse-arp). However, if you configure a static map (frame-relay map) for your own IP address (or one for the remote spoke) to use the local DLCI, you can ping yourself to your heart’s content.

The following capture from a router occurred before the circuit went active. Check the State. The following example highlights the important fields that you would use in troubleshooting an OSPF link-state problem:

Hub_router1#show ip ospf interface serial 0 Serial0 is up, line protocol is up Internet Address 10.0.1.1/24, Area 0 Process ID 10, Router ID 10.0.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64 DoNotAge LSA allowed. Transmit Delay is 1 sec, State DOWN, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

After the OSPF state goes active, the capture from the router is as follows:

Hub_router1#show ip ospf interface serial 0 Serial0 is up, line protocol is up Internet Address 10.0.1.1/24, Area 0 Process ID 10, Router ID 10.0.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64 DoNotAge LSA allowed. 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:01 Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 10.0.1.2 Suppress hello for 0 neighbor(s)

Taking a look at the show ip ospf neighbor command for each of the routers will show the following:

Hub_Router1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.1.2 1 FULL/ - 00:01:30 10.0.1.1 Serial0 10.0.1.3 1 FULL/ - 00:01:30 10.0.1.1 Serial0 10.0.1.4 1 FULL/ - 00:01:30 10.0.1.1 Serial0

The preceding command shows that the state is a full adjacency. Notice that there is no DR or ADR, which is normal and expected behavior for a NBMA media. If the state is anything but FULL, then the adjacencies have not been completely built and there might be a problem with the multicast LSA packets being passed through the interface. Perform the following command to check the state:

Spoke_Router2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.1.1 1 FULL/ - 00:01:52 10.0.1.2 Serial0 Spoke_Router3#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.1.1 1 FULL/ - 00:01:52 10.0.1.3 Serial0 Spoke_Router4#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.1.1 1 FULL/ - 00:01:52 10.0.1.4 Serial0

The following sections provide a definition of the different OSPF states.

The Neighbor State Changes (Hello Protocol)

The following is a brief description of the possible OSPF neighbor state changes:

•  Down. This is the initial state of a neighbor conversation.

•  Attempt. This is valid only for neighbors attached to nonbroadcast networks.

•  Init. Hello packet has been seen, but bi-directional communication has not yet been established with the neighbor.

•  2-Way. Communication between the two routers is bi-directional. On Cisco routers, you see the router, in this state, when you give a priority of 0 for that interface.