The Fundamentals of OSPF Routing Design

Previous Table of Contents Next

The Neighbor State Changes (Database Exchange)

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

  ExStart. This state indicates the first step in creating adjacency, the goal of which is to decide which router is the master and to decide upon the initial DD sequence number.
  Exchange. In this state, the router is describing its entire LSDB by sending Database Description packets to the neighbor.
  Loading. This state indicates that the LSR packets are sent to the neighbor asking for the more recent advertisements that are not yet received in the Exchange state.
  Full. This state indicates that the neighboring routers are fully adjacent.

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:        Field definitions:           aid: 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:          aid: chk:D363 aut:0 auk: from Serial0    OSPF: Receive dbd from seq 0x1A6E —- begin of database exchange    OSPF: 2 Way Communication to neighbor - building of adjacency    OSPF: send DBD packet to seq 0x995    OSPF: rcv. v:2 t:2 l:72 rid:          aid: chk:36C4 aut:0 auk: from Serial0    OSPF: Receive dbd from seq 0x995    OSPF: NBR Negotiation Done We are the MASTER - neighbor negotiation    OSPF: send DBD packet to seq 0x996    OSPF: Database request to    OSPF: sent LS REQ packet to, length 12 - we are sending a       request to for link state data.    OSPF: rcv. v:2 t:2 l:32 rid:          aid: chk:E442 aut:0 auk: from Serial0    OSPF: Receive dbd from seq 0x996    OSPF: send DBD packet to seq 0x997    OSPF: rcv. v:2 t:3 l:48 rid:          aid: chk:5E71 aut:0 auk: from Serial0    OSPF: rcv. v:2 t:4 l:64 rid:          aid: chk:98D8 aut:0 auk: from Serial0    OSPF: rcv. v:2 t:2 l:32 rid:          aid: chk:E441 aut:0 auk: from Serial0    OSPF: Receive dbd from seq 0x997    OSPF: Exchange Done with neighbor    OSPF: Synchronized with neighbor, 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:

Table 5-6 Fields in the debug ip ospf events command
Field Description

v ospf_version
t ospf_type
1 Hello To maintain neighbors
2 Database Exchange to bring up adjacency
3 Link State Request
4 Link State Update
5 Link State Ack.
l ospf_length
rid ospf_rtr_id
aid ospf_area_id
chk ospf_checksum
aut ospf_autype

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    ip ospf network point-to-multipoint non-broadcast    encapsulation frame-relay    frame-relay local-dlci 100    frame-relay map ip 102    frame-relay map ip 103    frame-relay map ip 104    no shut    !    router ospf 1    network area 0    neighbor    neighbor    neighbor 

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.

Previous Table of Contents Next

OSPF Network Design Solutions
OSPF Network Design Solutions
ISBN: 1578700469
EAN: 2147483647
Year: 1998
Pages: 200
Authors: Tom Thomas

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: