Hello Salman
If you take a look at the routing table of your spoke, you will find that you have two equal cost paths to both hubs. You should see something similar to this:
Spoke1#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA 1.1.1.1 [110/1002] via 172.16.1.2, 00:01:50, Tunnel0
[110/1002] via 172.16.1.1, 00:05:01, Tunnel0
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/1001] via 172.16.1.4, 00:04:51, Tunnel0
O IA 10.10.10.0/24 [110/1001] via 172.16.1.2, 00:01:50, Tunnel0
[110/1001] via 172.16.1.1, 00:05:01, Tunnel0
Note that 1.1.1.1 has two equal-cost paths via 172.16.1.1 and 176.16.1.2, the two hubs. When this occurs, you will find that OSPF will attempt to load balance traffic between equal-cost routes, and it will do this by alternating between the two available routes. This is why you see the behavior you are describing.
Now there are a couple of solutions that you can use to resolve this: use a distribute-list or use summarization. Neither is ideal as stated and explained in the lesson.
As stated at the very end of the lesson:
As we have seen, adding a second hub using a single cloud is very easy to configure but routing can be challenging. Since we use a single multipoint GRE interface, it’s difficult to prefer one hub router over another. Because of this, it’s unlikely to see this setup in production.
It is always preferable to use the dual hub dual cloud solution if you want to introduce redundancy at the hub.
I hope this has been helpful!
Laz