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!