The Neighbor State Changes (Database Exchange)
The following is a brief description of the possible OSPF neighbor state changes:
It is important to note that there is no DR/BDR election on a point-to-multipoint interface and that you can confirm that with the appropriate show command.
If you do not see full adjacencies, then the packet negotiation sequence that occurs can be seen through the use of a debug ip ospf events command. This can be essential in identifying problems with the OSPF process by looking at the packets with the debug command as follows:
HUB_ROUTER1#term monitor HUB_ROUTER1#debug ip ospf events %FR-5-DLCICHANGE: Interface Serial0 - DLCI 100 state changed to ACTIVE OSPF: rcv. v:2 t:1 l:44 rid:10.0.1.2 Field definitions: aid:0.0.0.0 chk:EE35 aut:0 auk: from Serial0 rcv - received packet v:2 - OSPF v2 1:44 rid: - Router ID aid: - Area ID chk: - aut: - Authentication auk: - physical interface packet was received through OSPF: rcv. v:2 t:2 l:32 rid:10.0.1.2 aid:0.0.0.0 chk:D363 aut:0 auk: from Serial0 OSPF: Receive dbd from 10.0.1.2 seq 0x1A6E - begin of database exchange OSPF: 2 Way Communication to neighbor 10.0.1.2 - building of adjacency OSPF: send DBD packet to 10.0.1.2 seq 0x995 OSPF: rcv. v:2 t:2 l:72 rid:10.0.1.2 aid:0.0.0.0 chk:36C4 aut:0 auk: from Serial0 OSPF: Receive dbd from 10.0.1.2 seq 0x995 OSPF: NBR Negotiation Done We are the MASTER - neighbor negotiation OSPF: send DBD packet to 10.0.1.2 seq 0x996 OSPF: Database request to 10.0.1.2 OSPF: sent LS REQ packet to 10.0.1.2, length 12 - we are sending a request to 10.0.1.2 for link state data. OSPF: rcv. v:2 t:2 l:32 rid:10.0.1.2 aid:0.0.0.0 chk:E442 aut:0 auk: from Serial0 OSPF: Receive dbd from 10.0.1.2 seq 0x996 OSPF: send DBD packet to 10.0.1.2 seq 0x997 OSPF: rcv. v:2 t:3 l:48 rid:10.0.1.2 aid:0.0.0.0 chk:5E71 aut:0 auk: from Serial0 OSPF: rcv. v:2 t:4 l:64 rid:10.0.1.2 aid:0.0.0.0 chk:98D8 aut:0 auk: from Serial0 OSPF: rcv. v:2 t:2 l:32 rid:10.0.1.2 aid:0.0.0.0 chk:E441 aut:0 auk: from Serial0 OSPF: Receive dbd from 10.0.1.2 seq 0x997 OSPF: Exchange Done with neighbor 10.0.1.2 OSPF: Synchronized with neighbor 10.0.1.2, state:FULL - completion of the adjacency process
Explanation of the fields is included with the first packet, and they are also shown in Table 5-6:
This sequence shows the distribution of the LSA packets and the building of the database. It also shows the building of the OSPF adjacency. The debug ip ospf events command is very useful in discovering the problems that might be causing an OSPF adjacency problem on the network.
The output from a debug ip ospf events command shows both the received and transmitted packets, the building of the OSPF adjacency, and the exchange of database information. If you are having a problem with building the OSPF adjacency or there are OSPF database problems, then this debug command can help you identify whether the packets are being received or sent.
The following example illustrates a nonbroadcast point-to-multipoint network using the frame relay map statement for clarification of the PVCs. This enables you to identify both ends of the PVC and if you need to define multiple DLCIs for a split DLCI one PVC for receiving and one PVC for transmitting. This enables you to work with your provider in setting the committed information rate (CIR) for each of the PVCs. As customers need to shape their user and application traffic across their frame relay circuits, the use of this kind of mapping is necessary.
HUB_ROUTER1# interface Serial0 ip address 10.0.1.1 255.255.255.0 ip ospf network point-to-multipoint non-broadcast encapsulation frame-relay frame-relay local-dlci 100 frame-relay map ip 10.0.1.2 102 frame-relay map ip 10.0.1.3 103 frame-relay map ip 10.0.1.4 104 no shut ! router ospf 1 network 10.0.1.0 0.0.0.255 area 0 neighbor 10.0.1.3 neighbor 10.0.1.4 neighbor 10.0.1.5
The preceding code also illustrates the use of the neighbor command to force the configured OSPF routers interconnecting to nonbroadcast networks. The neighbor statements are used to form OSPF adjacency. This also enables the user to dictate upon which connections the router will attempt to form an OSPF adjacency.
Without the neighbor command, the OSPF adjacency might have problems being attained. With the command, you know which routers you should make an OSPF adjacency with and, therefore, know what to look for if there are problems.
Because OSPF performs an election process for a DR and BDR, which acts as a central distribution point for routing information, the setting up of neighbors can be important. Also, OSPF routers will only form a full adjacency to the DR and BDR. Therefore, OSPF can efficiently support a full mesh of neighboring routers per interface. This will enable the point-to-multipoint feature to provide the connectivity that is needed for a non-fully-meshed network.