Mahmoud,
You are exactly right. The default network type of a DMVPN tunnel is Point-to-Point.
One of the rules of a P2P interface is there can be at most 1 OSPF neighbor. With the Hub’s tunnel interface, however, the OSPF process hears Hello messages from numerous different neighbors’ OSPF processes. This causes the Hub’s OSPF process to churn over and over, throwing out the previously formed Exstart relationship to form a new neighborship with the most recently received Hello. When this happens, you will see these messages on the Hub over and over again for each Spoke it has:
OSPF-5-ADJCHG: Process 1, Nbr 150.1.2.2 on Tunnel0 from EXSTART to DOWN, Neighbor Down: Adjacency forced to reset
To fix this, you MUST change the network type of the tunnel. You have two choices here, Point-to-Multipoint or Broadcast. Which should you choose? If you pick the P2MP network type, DMVPN will not be able to function any more efficiently than at Phase 1. The reason for this is because the P2MP network type changes the next hop value of all traffic to be the hub. This means that all traffic flows through the hub, and you are no better off than Phase 1.
Therefore, you should change the network type of the tunnel to be Broadcast. Even this, however, has its pitfalls. You must ensure that each spoke is configured so that it will never be elected as the DR or BDR via the “ip ospf priority 0” command.
Can you see why it is generally recommended NOT to run OSPF via DMPVN? 