OSPF Process in detail...
3:07 AM | Author: Siddhartha Ghosh 
OSPF Header:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|   Version #   |       5       |         Packet length         |
-----------------------------------------------------------------
|                          Router ID                            |
-----------------------------------------------------------------
|                           Area ID                             |
-----------------------------------------------------------------
|           Checksum            |             AuType            |
-----------------------------------------------------------------
|                       Authentication                          |
-----------------------------------------------------------------
|                       Authentication                          |
-----------------------------------------------------------------
 

Hello Packet:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|                      Network Mask                             |    
-----------------------------------------------------------------
|         HelloInterval         |    Options    |    Rtr Pri    |
-----------------------------------------------------------------
|                     RouterDeadInterval                        |
-----------------------------------------------------------------
|                      Designated Router                        |
-----------------------------------------------------------------
|                   Backup Designated Router                    |
-----------------------------------------------------------------
|                          Neighbor                             |
-----------------------------------------------------------------
 
 
 
DBD Packet:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|         Interface MTU         |    Options    |0|0|0|0|0|I|M|MS
-----------------------------------------------------------------
|                     DD sequence number                        |
-----------------------------------------------------------------
|                                                               |
-                       An LSA Header                           -
|                                                               |
-----------------------------------------------------------------
|                              ...                              |
 
 
 
LS Request:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|                          LS type                              |
-----------------------------------------------------------------
|                       Link State ID                           |
-----------------------------------------------------------------
|                     Advertising Router                        |
-----------------------------------------------------------------
|                              ...                              |
 
 
 
LS Update:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|                            # LSAs                             |
-----------------------------------------------------------------
|                             LSAs                              |
|                              ...                              |
 
 
 
LS ACK:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|                                                               |
--                         An LSA Header                       --
|                                                               |
-----------------------------------------------------------------
|                              ...                              |
 
 

LSA Header:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|            LS age             |    Options    |    LS type    |
-----------------------------------------------------------------
|                        Link State ID                          |
-----------------------------------------------------------------
|                     Advertising Router                        |
-----------------------------------------------------------------
|                     LS sequence number                        |
-----------------------------------------------------------------
|         LS checksum           |             length            |
-----------------------------------------------------------------
 

Router-LSAs:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|    0    |V|E|B|        0      |            # links            |
-----------------------------------------------------------------
|                          Link ID                              |
-----------------------------------------------------------------
|                         Link Data                             |
-----------------------------------------------------------------
|     Type      |     # TOS     |            metric             |
-----------------------------------------------------------------
|                              ...                              |
-----------------------------------------------------------------
|      TOS      |        0      |          TOS  metric          |
-----------------------------------------------------------------
|                          Link ID                              |
-----------------------------------------------------------------
|                         Link Data                             |
-----------------------------------------------------------------
|                              ...                              |
 
 
 
Network-LSAs:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|                         Network Mask                          |
-----------------------------------------------------------------
|                        Attached Router                        |
-----------------------------------------------------------------
|                              ...                              |
 
 
 
Summary-LSAs:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|                         Network Mask                          |
-----------------------------------------------------------------
|      0        |                  metric                       |
-----------------------------------------------------------------
|     TOS       |                TOS  metric                    |
-----------------------------------------------------------------
|                              ...                              |
 

AS-external-LSAs:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-----------------------------------------------------------------
|                         Network Mask                          |
-----------------------------------------------------------------
|E|     0       |                  metric                       |
-----------------------------------------------------------------
|                      Forwarding address                       |
-----------------------------------------------------------------
|                      External Route Tag                       |
-----------------------------------------------------------------
|E|    TOS      |                TOS  metric                    |
-----------------------------------------------------------------
|                      Forwarding address                       |
-----------------------------------------------------------------
|                      External Route Tag                       |
-----------------------------------------------------------------
|                              ...                              |


PROCESS:
 
1.When a router comes up initially: it send first Hello packet to the multicast
address 224.0.0.5, setting its Neighbor field empty.
 
2.It then looks for the Hello packets to discover Neighbors.
 
3.If it receives a Hello packet from another Router, it processes it and checks
the Neighbor field to find out if its Router-ID is mentioned in that field.
In case it’s mentioned there, 2-WayReceived event is triggered and it forms
2-WAY adjacency with that router. If not, it checks other fields like Area-ID,
Network-Mask or IP-Address (In case of Broadcast or NBMA network),
Authentication-Type, Authentication-Key, Hello-interval, Dead-interval.
If these field matches with the one that is configured on its own interface,
then it sends (unicast) an immediate Hello packet. 
 
Receiving Hello packet triggers HelloReceived event. In this case, when
HelloReceived is triggered, Router changed its state from DOWN to INIT.
When the other Router received its immediate Hello packet, its state also
gets changed from DOWN to INIT.
 
4.In a Broadcast & Point-to-Point network Hello packets are multicast at every
10 seconds and Dead-interval is 10x4=40. In other networks, its 30 & 120
respectively. So, this time when it multicast the Hello packet, Neighbor field
contains the Router-ID of the newly discovered Neighbor. When the other router
checks and find out its own Router-ID in that Hello packet’s Neighbor field,
it changes its state from INIT to 2-WAY with that router.
 
   5.DR & BDR election takes place in Broadcast & NBMA networks. And it can only
  take place after 2-WAY state. 
 
   6.A router can change its state from INIT to 2-WAY, if it receives a Hello packet
  which contains its Router-ID in the Neighbor field OR if it receives a DBD
  packet. 
 
   7.After election, DR & BDR is selected. Election of DR & BDR is basically on
  Router-Priority field in Hello packet. If it’s same then Router-ID is the tie
  breaker.
 
   8.Once election is finished, Router changes its state to EXSTART. In networks
  where election is not required, routers can directly go to EXSTART state from
  INIT.
 
9.Negotiation is done in EXSTART state, which implies who will become MASTER to
initiate the EXCHANGE. Router with higher Router-ID becomes the MASTER. SLAVE
has to agree on the DD sequence no. set by MASTER. Only MASTER can increment
the DD sequence no. and retransmit DBD packets. Every time MASTER sends a DBD
packet it increments the DD sequence no. Every DBD packet sent by MASTER has
to be acknowledged by SLAVE through echoing with same DD sequence no. If a
reply is not received by SLAVE before RetransmissionInterval expires, DBD
packet is retransmitted my MASTER. If MASTER receives a DBD packet with
different DD sequence no. then SeqNumberMismatch  event is generated and
adjacency is started from EXSTART state once again.
 
        DR & BDR election is based on Router priority, however selection 
of MASTER & Slave is purely based on Router-ID & is per neighbor basis.
Therefore, a DR can also become a Slave
 
10.In EXSTART state both the routers sends each other the DBD packet with Flag
set to 0x7 (I bit=1, M bit=1, MS bit=1), means this is the first DBD packet
I am sending, there are more DBD packets to come and I am MASTER. These DBDs
don’t contain any LSA Headers. A router with higher Router-ID becomes MASTER.
And SLAVE sends a DBD packet with flag set to 0x2 turning off the I and MS bit.
This is the confirmation packet from the SLAVE. SLAVE changes its state to
EXCHANGE (triggering NegotiationDone event) after sending this packet. SLAVE
also starts sending LSA Headers in DBDs now (as it’s in EXCHANGE state now).
When the other router receives this packet, a NegotiationDone event is
triggered there too. This changes the state of the receiving end to EXCHANGE
too. The MASTER now sends a DBD packet with flag set to 0x3 (just turning off
the I bit) and this DBD packet also contains LSA Headers. Flags remains to be
0x2 (for SLAVE) and 0x3 (for MASTER) until there are more LSA Headers to send.
When SLAVE has no more LSA Headers to send along with DBD packets, it echoes
back with flag set to 0x0. Then if MASTER has no more LSA Headers to send along
with DBD packets, it set flag to 0x1. At this stage any router whose flag is
set to either 0x0 or 0x1 will start sending LSA Request packets. This LSA
Request packets are sent based on comparison of there LSDB with the LSA Headers
that they received during EXCHANGE state. Both the routers may also receive LS
Update packets in this EXCHANGE state.
 
11.However, MASTER will still be waiting for the reply on its last DBD that it
sent. This implies that the last DBD is always sent by SLAVE. ExchangeDone
event is triggered on SLAVE router as soon as SLAVE sends the last DBD packet.
Once MASTER receives this DBD packet, ExchangeDone event is triggered there
too.
 
12.Once ExchangeDone event is triggered, router changes state from EXCHANGE to
LOADING (in case there are more out-dated links in the database to request) or
EXCHANGE to FULL.
 
13.In LOADING state, routers send and receive LS Request and LS Update packets
for any out-dated links. Once LS Request and LS Update packet is empty,
LoadingDone event is triggered, indicating that the LSDB is now synchronized
throughout the area.
 
14.Once LSDB of all the routers in an area is synchronized, state is changed from
LOADING to FULL, indicating full adjacency. SFP algorithm is then calculated
and routing table is build.
 
15.All the routers keep on sending and receiving Hello packets in specific
interval to maintain and keep watch on NeighborState changes. 
 
 
 
The Neighbor Data Structure
 
State: The functional level of the neighbor conversation.
 
Inactivity Timer: A single shot timer whose firing indicates that no 
Hello Packet has been seen from this neighbor recently.  The length of the
timer is RouterDeadInterval seconds.
 
Master/Slave: 
When the two neighbors are exchanging databases, they form a master/slave
relationship. 
 
DD Sequence Number:
      The DD Sequence number of the Database Description packet that
      is currently being sent to the neighbor.
 
Last received Database Description packet:
      The initialize(I), more (M) and master(MS) bits, Options field,
and DD sequence number contained in the last Database Description packet
received from the neighbor. Used to determine whether the next Database
Description packet received from the neighbor is a duplicate.
 
Neighbor ID:
      The OSPF Router ID of the neighboring router.      

Neighbor Priority:
     The Router Priority of the neighboring router.
 
Neighbor IP address:
     The IP address of the neighboring router's interface to the
        attached network.  
 
Neighbor Options:
     The optional OSPF capabilities supported by the neighbor.
 
Neighbor's Designated Router:
     The neighbor's idea of the Designated Router.  
 
Neighbor's Backup Designated Router:
     The neighbor's idea of the Backup Designated Router.
 
 
Link state retransmission list:
     The list of LSAs that have been flooded but not acknowledged on
     this adjacency.  These will be retransmitted at intervals until
     they are acknowledged, or until the adjacency is destroyed.
 
Database summary list:
     The complete list of LSAs that make up the area link-state
     database, at the moment the neighbor goes into Database Exchange
     state. This list is sent to the neighbor in Database Description  
     packets.
 
Link state request list:
     The list of LSAs that need to be received from this neighbor in
     order to synchronize the two neighbors' link-state databases.
     This list is created as Database Description packets are
     received, and is then sent to the neighbor in Link State Request
     packets. The list is depleted as appropriate Link State Update
     packets are received.
 
 
Neighbor states
 
DOWN
ATTEMPT – In NBMA
INIT - In this state, an Hello packet has recently been seen from
       the neighbor.  However, bidirectional communication has not
       yet been established with the neighbor 
 
2-WAY: Router has seen either Hello packet consist of its own Router-ID 
       in the neighbors field OR received DBD packet. The (Backup)
       Designated Router is selected from the set of neighbors in
       state 2-Way or greater.
 
 
EXSTART: This is the first step in creating an adjacency between the
         two neighboring routers.  The goal of this step is to decide
         which router is the master, and to decide upon the initial
         DD sequence number.  Neighbor conversations in this state or
         greater are called adjacencies.
 
 
EXCHANGE: Database summaries are exchanged, LS Request & LS Updates are 
           also sent.
 
LOADING: In this state, Link State Request packets are sent to the     
neighbor asking for the more recent LSAs that have been discovered
(but not yet received) in the Exchange state.
 
FULL: In this state, the neighboring routers are fully adjacent. These 
        adjacencies will now appear in router-LSAs and network-LSAs.
 
 
Events
 
HelloReceived: An Hello packet has been received from the neighbor.
 
Start (NBMA): This is an indication that Hello Packets should now be 
        sent to the neighbor at intervals of HelloInterval seconds. 
 
2-WayReceived: Bidirectional communication has been realized between 
the two neighboring routers.  This is indicated by the router seeing itself
in the neighbor's Hello packet.
 
NegotiationDone: The Master/Slave relationship has been negotiated, and 
        DD sequence numbers have been exchanged.
 
ExchangeDone: Both routers have successfully transmitted a full 
        sequence of Database Description packets.  Each router now knows 
        what parts of its link state database are out of date.  
 
BadLSReq: A Link State Request has been received for an LSA not 
        contained in the database.  This indicates an error in the
        Database Exchange process.
 
LoadingDone: Link State Updates have been received for all out-of-date
            portions of the database.  This is indicated by the Link
            state request list becoming empty after the Database
            Exchange process has completed.
 
AdjOK?: A decision must be made as to whether an adjacency should be
        established/maintained with the neighbor.  This event will
        start some adjacencies forming, and destroy others.
 
 
The following events cause well developed neighbors to revert to lesser states.  
Unlike the above events, these events may occur when the neighbor conversation is
in any of a number of states.
 
SeqNumberMismatch: A Database Description packet has been received that 
either a) has an unexpected DD sequence number, b) unexpectedly has the Init
bit set or c) has an Options field differing from the last Options field
received in a Database Description packet.  Any of these conditions indicate
that some error has occurred during adjacency establishment.
 
1-Way: An Hello packet has been received from the neighbor, in which 
        the router is not mentioned. 
 
 KillNbr: This  is  an  indication that  all  communication  with  the
          neighbor  is now  impossible,  forcing  the  neighbor  to
          revert  to  Down  state.
 
 InactivityTimer: The inactivity Timer has fired. This means that no 
Hello packets have been seen recently from the neighbor. The neighbor reverts
to Down state.
 
 LLDown: This is an indication from the lower level protocols that the 
neighbor is now unreachable.
 
 
Event SeqNumberMismatch forces ExStart state,
Event BadLSReq forces ExStart state,
Event 1-Way forces Init state,
Event KillNbr always forces Down State,
Event InactivityTimer always forces Down State,
Event LLDown always forces Down State,
Event AdjOK? leads to adjacency forming/breaking

EVENTS: 
 
R3#debug ip ospf events
OSPF events debugging is on
R3 has just come up and sending Hello packets to multicast address 224.0.0.5 to all its interface. This Hello
packet’s Neighbor field is empty and DR/BDR field is set to 0.0.0.0
*Mar 1 00:00:29.635: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar 1 00:00:29.639: OSPF: Send hello to 224.0.0.5 area 1 on Serial0/0 from 192.168.10.1
*Mar 1 00:00:39.635: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
Dead Interval timer has expired (in this case it was 40 seconds) and InactivityTimer event is triggered, which in turn
triggered MAXAGE and deleted all LSAs from the database.
*Mar  1 00:00:42.347: OSPF: service_maxage: Trying to delete MAXAGE LSA
This is lead to the election of DR/BDR, electing itself to DR & BDR to none.
*Mar  1 00:00:49.635: OSPF: end of Wait on interface FastEthernet0/0
*Mar  1 00:00:49.635: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:00:49.635: OSPF: Elect BDR 0.0.0.255
*Mar  1 00:00:49.639: OSPF: Elect DR 0.0.0.255
*Mar  1 00:00:49.639: OSPF: Elect BDR 0.0.0.0
*Mar  1 00:00:49.639: OSPF: Elect DR 0.0.0.255
*Mar  1 00:00:49.643:        DR: 0.0.0.255 (Id)   BDR: none
Now it will keep sending hello packets until it discover any neighbors.
*Mar  1 00:00:49.643: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar  1 00:00:59.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar  1 00:01:09.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar  1 00:01:19.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar  1 00:01:29.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar  1 00:01:39.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar  1 00:01:49.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
It received first multicast Hello packet from R2. Now the state of R3 gets changed to INIT. However, this Hello
packet’s neighbor field is empty too. So, 2-WayReceived event won’t generate and it won’t form 2-WAY adjacency
as of now. But R3 will check other fields (Area-ID, Interface-IP, Auth-type, Auth-Key, Hello-Interval, Dead-Interval)
to find out if R2 is eligible to be its neighbor.
*Mar  1 00:01:52.655: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2
Eligibility criteria matched, thus R3 sent an Immediate Hello to R2. This unicast Hello will bring R2 to INIT state.
*Mar  1 00:01:52.659: OSPF: Send immediate hello to nbr 0.0.0.254, src address 172.16.1.2, on FastEthernet0/0
*Mar  1 00:01:52.663: OSPF: Send hello to 172.16.1.2 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar  1 00:01:52.667: OSPF: End of hello processing
Likewise, R3 also received Hello packet from R1 and processed it the same way as above.
*Mar  1 00:01:55.319: OSPF: Rcv hello from 0.0.0.1 area 0 from FastEthernet0/0 172.16.1.1
*Mar  1 00:01:55.323: OSPF: Send immediate hello to nbr 0.0.0.1, src address 172.16.1.1, on FastEthernet0/0
*Mar  1 00:01:55.327: OSPF: Send hello to 172.16.1.1 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar  1 00:01:55.327: OSPF: End of hello processing
Now, when both the Hello packets are processed and Hello-Interval is reached, it’s sending a multicast Hello
packet setting its neighbor field with Router-ID of both R2 & R1. This will trigger 2-WayReceived event on both
R2 & R1, because they will find there respective Router-ID in this Hello packet’s Neighbor field.
*Mar  1 00:01:59.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
After 2-WayReceived event triggered on both parties, both R2 & R1 are now in 2-WAY state and are allowed to
conduct election. As election is also finished on R2, it’s in EXSTART state by sending its first DBD packet, claiming
it as a Master setting flag to 0x7 and generating a DD sequence no.
*Mar  1 00:01:59.771: OSPF: Rcv DBD from 0.0.0.254 on FastEthernet0/0 seq 0x264 opt 0x52 flag 0x7 len 32  mtu
1500 state INIT
Once R3 received this DBD packet, it will change its state to 2-WAY and will conduct election.
*Mar  1 00:01:59.771: OSPF: 2 Way Communication to 0.0.0.254 on FastEthernet0/0, state 2WAY
*Mar  1 00:01:59.775: OSPF: Neighbor change Event on interface FastEthernet0/0
*Mar  1 00:01:59.775: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:01:59.775: OSPF: Elect BDR 0.0.0.254
*Mar  1 00:01:59.775: OSPF: Elect DR 0.0.0.255
*Mar  1 00:01:59.775:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)
DR & BDR is selected, which will appear in the next Hello packet that R3 will send.
Now, as elction is finished R3 will change its state to EXSTART sending the first DBD packet claiming it to be
Master.
*Mar  1 00:01:59.775: OSPF: Send DBD to 0.0.0.254 on FastEthernet0/0 seq 0xDAE opt 0x52 flag 0x7 len 32
*Mar  1 00:01:59.775: OSPF: First DBD and we are not SLAVE
Now, we can see R3 has received a multicast Hello packet from R2. This Hello packet contains R2’s discovery
of R1 in its Neighbor field. This triggered Neighbor change event on R3 and led to election again (one for each
neighbor).
*Mar  1 00:01:59.799: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2
*Mar  1 00:01:59.799: OSPF: Neighbor change Event on interface FastEthernet0/0
*Mar  1 00:01:59.799: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:01:59.799: OSPF: Elect BDR 0.0.0.254
*Mar  1 00:01:59.799: OSPF: Elect DR 0.0.0.255
*Mar  1 00:01:59.799:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)
*Mar  1 00:01:59.799: OSPF: Neighbor change Event on interface FastEthernet0/0
*Mar  1 00:01:59.799: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:01:59.799: OSPF: Elect BDR 0.0.0.254
*Mar  1 00:01:59.799: OSPF: Elect DR 0.0.0.255
*Mar  1 00:01:59.799:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)
*Mar  1 00:01:59.799: OSPF: End of hello processing
R3 now received DBD packet echoed by R2. This DBD packet contains same DD sequence no. that R3 has
set and flag is also set to 0x2, which tells that R2 has agreed itself to be a Slave. This packet also contains LSA
Header, therefore M bit is set to 1. This will trigger NegotiationDone event on R3 too.
*Mar  1 00:01:59.847: OSPF: Rcv DBD from 0.0.0.254 on FastEthernet0/0 seq 0xDAE opt 0x52 flag 0x2 len 52  mtu
1500 state EXSTART
*Mar  1 00:01:59.851: OSPF: NBR Negotiation Done. We are the MASTER
Now both R3 & R2 are in EXCHANGE state. R3 is sending its second DBD packet incrementing the DD sequence
no.. Flag 0x3 tells that this packet contains LSA Header.
*Mar  1 00:01:59.855: OSPF: Send DBD to 0.0.0.254 on FastEthernet0/0 seq 0xDAF opt 0x52 flag 0x3 len 52
R3 received echoed DBD packet from R2. Flag is set to 0x0, which means this packet don’t contain any LSA
Header. Thus M bit is cleared indicating it has no more data to send. Now, as R2 has no more LSA Headers to
send it can now compare its own LSDB against the LSA Headers that it received during EXCHANGE state and
can start sending LS Request packets if any. 
*Mar  1 00:02:00.063: OSPF: Rcv DBD from 0.0.0.254 on FastEthernet0/0 seq 0xDAF opt 0x52 flag 0x0 len 32  mtu
1500 state EXCHANGE
R3 sends its last DBD incrementing the DD sequence no. and with flag setting to 0x1, that indicates it has no more
data to send. However, it will still expect a DBD echoed reply packet from Slave. As R3 has no more LSA Headers
to send, it can also now send LS Request packets if any.
*Mar  1 00:02:00.063: OSPF: Send DBD to 0.0.0.254 on FastEthernet0/0 seq 0xDB0 opt 0x52 flag 0x1 len 32
*Mar  1 00:02:00.063: OSPF: Send LS REQ to 0.0.0.254 length 12 LSA count 1
R3 received DBD packet from R1. This is the first DBD packet from R1 changing the state of R3 to 2-WAY with R1.
Rest of the process will be same as described earlier.
*Mar  1 00:02:00.063: OSPF: Rcv DBD from 0.0.0.1 on FastEthernet0/0 seq 0x18BD opt 0x52 flag 0x7 len 32  mtu
1500 state INIT
*Mar  1 00:02:00.063: OSPF: 2 Way Communication to 0.0.0.1 on FastEthernet0/0, state 2WAY
*Mar  1 00:02:00.063: OSPF: Neighbor change Event on interface FastEthernet0/0
*Mar  1 00:02:00.063: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:02:00.063: OSPF: Elect BDR 0.0.0.254
*Mar  1 00:02:00.063: OSPF: Elect DR 0.0.0.255
*Mar  1 00:02:00.063:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)
*Mar  1 00:02:00.063: OSPF: Send DBD to 0.0.0.1 on FastEthernet0/0 seq 0x1B0 opt 0x52 flag 0x7 len 32
*Mar  1 00:02:00.063: OSPF: First DBD and we are not SLAVE
*Mar  1 00:02:00.063: OSPF: Rcv hello from 0.0.0.1 area 0 from FastEthernet0/0 172.16.1.1
*Mar  1 00:02:00.067: OSPF: Neighbor change Event on interface FastEthernet0/0
*Mar  1 00:02:00.067: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:02:00.071: OSPF: Elect BDR 0.0.0.254
*Mar  1 00:02:00.071: OSPF: Elect DR 0.0.0.255
*Mar  1 00:02:00.071:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)
*Mar  1 00:02:00.075: OSPF: Neighbor change Event on interface FastEthernet0/0
*Mar  1 00:02:00.075: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:02:00.079: OSPF: Elect BDR 0.0.0.254
*Mar  1 00:02:00.079: OSPF: Elect DR 0.0.0.255
*Mar  1 00:02:00.079:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)
*Mar  1 00:02:00.083: OSPF: End of hello processing
R3 received LS Request packet from R2 and sending LS Update packet thereafter.
*Mar  1 00:02:00.163: OSPF: Rcv LS REQ from 0.0.0.254 on FastEthernet0/0 length 36 LSA count 1
*Mar  1 00:02:00.167: OSPF: Send UPD to 172.16.1.2 on FastEthernet0/0 length 40 LSA count 1
R3 now received echoed DBD packet from R2 that it was expecting and that triggers ExchangeDone event. R2
changed its state to LOADING (triggering ExchangeDone event ) soon after sending this DBD packet.
*Mar  1 00:02:00.207: OSPF: Rcv DBD from 0.0.0.254 on FastEthernet0/0 seq 0xDB0 opt 0x52 flag 0x0 len 32  mtu
1500 state EXCHANGE
*Mar  1 00:02:00.207: OSPF: Exchange Done with 0.0.0.254 on FastEthernet0/0
R3’s EXSTART state continues with R1
*Mar  1 00:02:00.207: OSPF: Rcv DBD from 0.0.0.1 on FastEthernet0/0 seq 0x1B0 opt 0x52 flag 0x2 len 52  mtu 1500
state EXSTART
*Mar  1 00:02:00.207: OSPF: NBR Negotiation Done. We are the MASTER
R3’s EXCHANGE state continues with R1
*Mar  1 00:02:00.207: OSPF: Send DBD to 0.0.0.1 on FastEthernet0/0 seq 0x1B1 opt 0x52 flag 0x3 len 52
R3 in LOADING state received LS Update packet from R2 and sent LS Ack packet acknowledging the update.
*Mar  1 00:02:00.207: OSPF: Rcv LS UPD from 0.0.0.254 on FastEthernet0/0 length 64 LSA count 1
R3 expects no more LS Update packets. Thus, triggering the LoadingDone event. R3’s LSDB is now synchronized
with R2, changing the state of R3 to FULL with R2.
*Mar  1 00:02:00.207: OSPF: Synchronized with 0.0.0.254 on FastEthernet0/0, state FULL
*Mar  1 00:02:00.207: %OSPF-5-ADJCHG: Process 100, Nbr 0.0.0.254 on FastEthernet0/0 from LOADING to FULL,
Loading Done
R3’s EXCHANGE state continues with R1
*Mar  1 00:02:00.307: OSPF: Rcv DBD from 0.0.0.1 on FastEthernet0/0 seq 0x1B1 opt 0x52 flag 0x0 len 32  mtu 1500
state EXCHANGE
*Mar  1 00:02:00.311: OSPF: Send DBD to 0.0.0.1 on FastEthernet0/0 seq 0x1B2 opt 0x52 flag 0x1 len 32
*Mar  1 00:02:00.311: OSPF: Send LS REQ to 0.0.0.1 length 12 LSA count 1
*Mar  1 00:02:00.379: OSPF: Rcv DBD from 0.0.0.1 on FastEthernet0/0 seq 0x1B2 opt 0x52 flag 0x0 len 32  mtu 1500
state EXCHANGE
*Mar  1 00:02:00.379: OSPF: Exchange Done with 0.0.0.1 on FastEthernet0/0
R3’s LOADING state continues with R1
*Mar  1 00:02:00.383: OSPF: Rcv LS UPD from 0.0.0.1 on FastEthernet0/0 length 64 LSA count 1
R3’s state is FULL with R1
*Mar  1 00:02:00.387: OSPF: Synchronized with 0.0.0.1 on FastEthernet0/0, state FULL
*Mar  1 00:02:00.387: %OSPF-5-ADJCHG: Process 100, Nbr 0.0.0.1 on FastEthernet0/0 from LOADING to FULL,
Loading Done
Now, whenever there will be any update in the network, DR & BDR will multicast LS Update packets to 224.0.0.5 &
DROTHER will multicast at 224.0.0.6 (which will be received by only DR & BDR). LS Update packets will always be
acknowledged by LS Ack packet by the recipients.
*Mar  1 00:02:00.659: OSPF: Rcv LS UPD from 0.0.0.254 on FastEthernet0/0 length 64 LSA count 1
*Mar  1 00:02:00.755: OSPF: Rcv LS UPD from 0.0.0.1 on FastEthernet0/0 length 64 LSA count 1
Regular multicast Hello packets will be sent and received to keep track of any neighbor changes.
*Mar  1 00:02:00.919: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2
*Mar  1 00:02:00.923: OSPF: End of hello processing
*Mar  1 00:02:01.263: OSPF: Rcv hello from 0.0.0.1 area 0 from FastEthernet0/0 172.16.1.1
*Mar  1 00:02:01.263: OSPF: Neighbor change Event on interface FastEthernet0/0
*Mar  1 00:02:01.267: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:02:01.267: OSPF: Elect BDR 0.0.0.254
*Mar  1 00:02:01.267: OSPF: Elect DR 0.0.0.255
*Mar  1 00:02:01.271:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)
*Mar  1 00:02:01.271: OSPF: End of hello processing
*Mar  1 00:02:04.631: OSPF: Rcv LS UPD from 0.0.0.1 on FastEthernet0/0 length 64 LSA count 1
*Mar  1 00:02:04.711: OSPF: Rcv LS UPD from 0.0.0.254 on FastEthernet0/0 length 64 LSA count 1
*Mar  1 00:02:05.287: OSPF: Rcv LS UPD from 0.0.0.1 on FastEthernet0/0 length 64 LSA count 1
*Mar  1 00:02:09.507: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2
*Mar  1 00:02:09.511: OSPF: End of hello processing
*Mar  1 00:02:09.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar  1 00:02:09.975: OSPF: Rcv hello from 0.0.0.1 area 0 from FastEthernet0/0 172.16.1.1
*Mar  1 00:02:09.975: OSPF: End of hello processing
*Mar  1 00:02:18.895: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2
*Mar  1 00:02:18.899: OSPF: End of hello processing
*Mar  1 00:02:19.231: OSPF: Rcv hello from 0.0.0.1 area 0 from FastEthernet0/0 172.16.1.1
*Mar  1 00:02:19.231: OSPF: End of hello processing
*Mar  1 00:02:19.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3
*Mar  1 00:02:27.967: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2
*Mar  1 00:02:27.967: OSPF: End of hello processing
R3#u all
All possible debugging has been turned off
R3#
|
This entry was posted on 3:07 AM and is filed under . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

0 comments:

Post a Comment