This is the second post about Demand in Routing. In the first post I covered some common demand-related points and Cisco On-Demand Routing. In today’s post I write a little about Routing Protocols and their behavior over on-demand circuits.
On-demand circuits remain down most of the time and are brought up when there is some data to send over them. They are used in cases of rare periodic communications (for example, some non real time industrial automation might employ such circuit), or for backup in case of main channel failure.
It is obvious that routing protocols MUST behave differently on this type of datalines, and at the same time perform their functions correctly.
Routing protocol behavior over on-demand circuits
OSPF and On-Demand circuits
For OSPF, a link-state routing protocol, it seems natural to be able to understand and support different kinds of inter-router links. Although On-Demand circuits is not a link type, but a special property of a link for OSPF, a link of any type (multiaccess, p2p etc) can have this property.
Default Hello timer for OSPF is 10 seconds, LSAs are re-flooded every 30 minutes (half-LSAMaxAge). This behavior is wasteful for On-Demand circuits, so a solution has been devised.
The demand circuit feature suppresses Hellos and periodic floods on point-to-point (and, as a result, on point-to-multipoint) interfaces. It suppresses periodic floods only on other link types.
It works by setting up a special DNA (Do Not Age) bit in LS Age, which prevents the LSA from aging. For this to work, both routers across the link MUST support (on initial negotiation) the DC bit.
Configuration is performed under the interface:
ip ospf demand-circuit
EIGRP over On-Demand Circuits
Though EIGRP uses a lot of link characteristics in its operation, the protocol makes little distinction between links of different topologies.
As far as I understand, EIGRP does not have any special means to work correctly (i.e. silently) over an on-demand link. But it is possible to make it use the link very rarely.
To do that, several configuration actions are required:
It also might be a good idea to configure the router as a stub, as Stub routers are left undisturbed during Query (Active) events. But an EIGRP router cannot be a Stub on a single link: it is either all or nothing. That kind of limits possibilities.
- statically specify the far-end neighbor12router eigrp 123neighbor 172.22.1.23 interface cellular0
or, in more recent “named configuration mode”:123router eigrp cheburashkaaddress-family ipv4 autonomous-system 31337neighbor 172.16.1.23 cellular 0
- set the Hello Interval as high as possible
Is this really such a good idea?12interface cellular 0ip hello-interval eigrp 123 65535
in named configuration mode:1234router eigrp cheburashkaaddress-family ipv4 autonomous-system 31337af-interface cellular 0hello-interval 65535
Note: 65535 seconds = 1092.25 minutes = 18.2 hours. Not so much. Also, check that Dead Interval is adjusted properly.
So, that’s a tad more complicated and less reliable. It might be that it is better to leave EIGRP alone and use floating static on that link with ip sla & tracking providing necessary automation.
IS-IS Routing Protocol over On-Demand Circuits
There seems to be no special support for demand circuits in IS-IS Routing Protocol. The best that can be done, perhaps, is flooding reduction and maximizing the Hello timer (dead timer is 3 times more due to hello-multiplier=3 by default).
interface cellular 0
isis hello-interval 65535 [level-1|level-2]
Again, it might be a better idea to use floating static with ip sla or other backup routing mechanism.
RIP over On-Demand Circuits
Because “Routing Information Protocol Routing Protocol over…” is tautology too much.
Honestly, I don’t even expect RIP to have anything to be nice to demand links. On the other hand, it is a protocol from the wild times of unreliable links and dial-up, so it might surprise me. Let’s go.
OK, so, obviously there is no special link type, but it is possible to make updates on a single link as rare as possible:
interface cellular 0
ip rip advertise 429466
429466 seconds is 7157 minutes = 119.29 hours = 4.97 days
Yes, RIP can be mostly silent on a link for days.
Yes, that’s right. There is a special adaptation to make RIP more efficient over demand links, let us call it “triggered behavior”.
It makes the router send updates only when these events happen (directly from config guide):
- The router receives a specific request for a routing update. (Full database is sent.)
- Information from another interface modifies the routing database. (Only latest changes are sent.)
- The interface comes up or goes down. (Partial database is sent.)
- The router is first powered on, to ensure that at least one update is sent. (Full database is sent.)
It is nice that the updates learned through triggered updates do not age out.
To make it so, use this configuration:
interface cellular 0
ip rip triggered
And that is not all! You can also specify a neighbor statement and combine it with passive-interface:
passive-interface cellular 0
Passive interface prevents broadcasts. The neighbor statement allows for a unicast neighbor.