Routing Protocols over On-Demand circuits

By | June 10, 2015

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 recap

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.

 on-demand circuits

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:

 Read more:

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 neighbor

     or, in more recent “named configuration mode”:

  •  set the Hello Interval as high as possible

    Is this really such a good idea?

     in named configuration mode:

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).

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:

429466 seconds is 7157 minutes = 119.29 hours = 4.97 days

Yes, RIP can be mostly silent on a link for days.

But there’s more!There is more!

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:

 And that is not all! You can also specify a neighbor statement and combine it with passive-interface:

 Passive interface prevents broadcasts. The neighbor statement allows for a unicast neighbor.

 

Denis Borchev
Follow me

Denis Borchev

Engineer at Netcube LLC
I am a networking engineer, a geek and a generally nice person=)
Computer Networking Engineer with some experience; MSc Applied CS, CCIE #53271
Denis Borchev
Follow me

Latest posts by Denis Borchev (see all)