Apparently, there are several very distinct topics in routing which have the word “demand” in them. First, there is Cisco On-Demand Routing quasi-protocol, and then there are on-demand circuits which routing protocols must treat differently. Last but not least, the on-demand circuits are used for Routing Backup.
What’s that “demand”?
Most generally, a “demand” is a request for service. In IP routing that would be an incoming packet which must be routed towards its destination.
So, for on-demand circuit, that means that the circuit is up if and only if there is a packet to be sent through it
Or we are expecting more packets soon after the first one – there is no reason in wasting time to setup a channel and bring it down right away, that would be too slow.
Backup routing uses on-demand circuits for, well, backup – the router sets up the channel when the main route fails for some reason.
Then there is a requirement for routing protocols to treat an on-demand circuit in a special way. First, a neighbor relationship must be created over the circuit, and perhaps some routing information exchange is in order. But after convergence, the on-demand circuit must be brought down.
This is often due to monetary cost. The on-demand circuit is likely to be a dial-up line or even ADSL. For example, several years ago I saw an ad from local phone company, selling ADSL to SOHO users marketed as “backup for your main ISP” with pay-per-day of actual link activity.
But routing protocols are a chatty bunch, they like to exchange Updates and Hellos. Of course we do not want to set up our pricey on-demand circuit just for the routers to be friends with each other. Thus, after relationship establishment, the link becomes silent and only activated by real demands (see above) or some major routing protocol events.
And finally, of all demand things in routing, there is Cisco On-Demand Routing “protocol”. This is not exactly a protocol, though it might be considered as such from a high level perspective (because it makes routes for prefixes appear in the routing table by way of data exchange), but an enhancement to Cisco Discovery Protocol. It is the shortest one, let’s get to it first, and get to full-blown routing protocols and backup routing next time.
General information about Cisco ON-Demand Routing
I think that the name is rather confusing, but so is the “VLAN Trunking Protocol”‘s name (which does no “trunking”, only database sync).
On-Demand Routing (ODR) is a way to exchange information on connected prefixes between two routers. ODR “runs” on top of Cisco Discovery Protocol (CDP) in the form of special TLV. This TLV has type 0x0007 and length of number of prefixes times 5 bytes (4 bytes IPv4 prefix, 1 byte IPv4 mask) .
This protocol is supposed to be used with Hub-and-Spoke topologies, and setup is required only on the Hub. The Hub sends only one prefix to its spokes: the next hop for a default route to be used by spokes. There might be several hubs in the topology, in that case hubs MUST be interconnected and share information via some real Routing Protocol.
Configuring Cisco On-Demand Routing
The only requirement for ODR to work is that CDP must be enabled globally and on the interface in question. The only special command to issue is:
The command is used on hub only. ODR will install the routes with default AD = 160, route metric is 1. Only connected prefixes are propagated from spokes to the hub – no static, no redistribution into ODR. Protocol timers are completely dependent on CDP timers, so convergence takes 180-240 seconds.
Note: it is possible to change timers with
1 timers basic [update] [invalid] [holddown (not used)] [flush] [sleeptime]
the defaults are:
- update: 60
- invalid: 180
- holddown: 0
- flush: 240
- sleeptime: 0
But they do not matter much, as real work is done in sync with CDP anyway.