The Fundamentals of OSPF Routing Design | OSPF Network Design Solutions

Table of Contents

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

Notes:
Note that no static frame relay map statements were configured. This is because Inverse ARP will take care of the DLCI to IP resolution and mapping.
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.

Notes:
Typically you will see OSPF go from 2-Way to full; however, when a full state is reached, this reflects that the LSDBs (that is, all database exchanges) have been completely exchanged between the two routers in question. This process differs from the Hello protocol and is the subtle difference between the two.

Table of Contents