Quick bit of a refresh on OSPF network types, these are specified on a per link basis and it changes the way OSPF behaves on that link specifying the wrong type can cause bad things to happen such as if you mix DR & Non DR types adjacencies wont form correctly.

There are 5 network types,

1. Point to Point – Should be used as the name implies on P2P links which support broadcast, nearly all OSPF traffic is sent to the ALLSPFRouters address which is 224.0.0.5, although retransmitted LSAs are sent to the unicast address as such these links should support broadcasting.
2. Broadcast – This is the default network type for Ethernet networks, as this network type is capable of having adjacencies with multiple routers. To prevent unnecessary meshing DR & BDR elections take place. Communications from the DR & BDR take place on the ALLDRRouters address 224.0.0.6 whilst all other communications on 224.0.0.5. As the name implies the layer 2 network must support broadcasting.
3. Non Broadcast Multiple Access (NBMA) – This is the default configuration on a serial interface, and is classified as a link which is able to send to multiple other routers via the single link but with no broadcasting, therefore neighbour statements must be manually set. A DR & BDR will still be elected but all communication is unicast, the hello and dead timers change from the defaults to 30 and 120 seconds.
4. Point to Multipoint networks – All communication is unicast and no DR or BDR election takes place an ideal placement for this would be in the hub in a hub and spoke topology.
5. Virtual Links – Packets sent over Virtual Links are unicast and perceived as unnumbered point to point connections

Its pretty simple to change the network type its all done under the interface like so.

Router(config-if)#ip ospf network ?
  broadcast            Specify OSPF broadcast multi-access network
  non-broadcast        Specify OSPF NBMA network
  point-to-multipoint  Specify OSPF point-to-multipoint network
  point-to-point       Specify OSPF point-to-point network

In a nutshell On-Demand Routing (ODR) is simply freaking awesome for hub and spoke environments.

In hub and spoke enviornemnts before ODR there was generally two choices to the deployment

1. Have default routes on the spokes pointing to the hub and static routes back. But frankly this was a pain as there was an administrative burden as you have to manually add/remove each spoke as needed.
2. Run a routing protocol on the spokes which communicates reachability information with the hub but this is unnecessary as the spokes are dead end streets they don’t need more topology information than a default route and generally the spoke routers aren’t the best in the network so it an unneeded overhead.

But this is were On-Demand Routing (ODR) comes to the rescue . Now ODR is not a routing protocol, the spoke routers send details of attached networks via CDP to neighbouring routers and when ODR is enabled the network information is simply installed into the IP routing table. Each of the spokes only needs to have a default route pointing to the hub and have CDP enabled which is on by default and thats it. The routes it collects have an AD of 160 with a metric of 1 (only 1 hop away), the routes that ODR collected can then be redistributed into your IGP of choice.

If you don’t believe me that its that simple check out the configuration below

Firstly we just enable it with the

router odr

command, this is a single command which only needs to be configured on the hub, the spokes dont need it.

R0(config)#router odr

There are not many options in the protocol itself the most common you might wish to change is the timers

R0(config-router)#?
Router configuration commands:
  default            Set a command to its defaults
  default-metric     Set metric of redistributed routes
  distance           Define an administrative distance
  distribute-list    Filter networks in routing updates
  exit               Exit from routing protocol configuration mode
  help               Description of the interactive help system
  maximum-paths      Forward packets over multiple paths
  neighbor           Specify a neighbor router
  network            Enable routing on an IP network
  no                 Negate a command or set its defaults
  passive-interface  Suppress routing updates on an interface
  redistribute       Redistribute information from another routing protocol
  timers             Adjust routing timers
  traffic-share      How to compute traffic share over alternate paths

We can validate that its running and see the routes it has collected.

R0#sh ip protocols
Routing Protocol is "odr"
  Sending updates every 60 seconds, next due in 47 seconds
  Invalid after 180 seconds, hold down 0, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Maximum path: 4
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.1.2.1             160      00:00:30
    10.1.1.1             160      00:00:47
  Distance: (default is 160)

And on the hub se should be able to see the routes installed into the IP routing table with the AD of 160 and metric of 1

R0#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 2 subnets
o       10.1.2.0 [160/1] via 10.1.2.1, 00:01:45, Serial0/1
                 [160/1] via 10.1.2.1, 00:00:45
o       10.1.1.0 [160/1] via 192.168.1.2, 00:00:02, Serial0/0
                 [160/1] via 10.1.1.1, 00:02:02, Serial0/0
                 [160/1] via 10.1.1.1, 00:01:02
     192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.1.0/24 is directly connected, Serial0/0
C       192.168.1.2/32 is directly connected, Serial0/0
     192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.2.2/32 is directly connected, Serial0/1
C       192.168.2.0/24 is directly connected, Serial0/1

Now to test it the view from R2 just shows the default route up to the hub

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

10.0.0.0/24 is subnetted, 1 subnets
C       10.1.2.0 is directly connected, Loopback0
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.2.0/24 is directly connected, Serial0/0
C       192.168.2.1/32 is directly connected, Serial0/0
S*   0.0.0.0/0 is directly connected, Serial0/0

Now to test if we can ping the other spoke router

R2#ping 10.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/39/60 ms

I am almost speechless at how simple it was to get spoke to spoke connectivity! Beautiful!