Dial-on-Demand Routing (DDR)

This document provides a list of Snapshot routing frequently asked questions.

A. Snapshot allows you to remove the constraints of building and maintaining static routes/services when having hub and spoke topology in a DDR environment. Dynamic routing protocols will update naturally the routing tables during active windows and snapshot will prevent them from aging for a configurable period of time (quiet period).

A. Snapshot is a timer-based mechanism. It controls "active periods" when routing information is exchanged (which can trigger DDR connections) and freezes the routing table entries the rest of the time.

A. The client site keeps monitoring the "quiet period" timer. Once this timer has expired, it tries to trigger a connection with the server. If it fails, it will re-try every eight minutes.

A. Snapshot allows the use of all "distance vector" routing protocols over DDR lines. They include:

• RIP and IGRP for IP
• RTMP for Appletalk
• RIP and SAP for IPX
• RTP for Vines

A. With snapshot routing, you define an active period during which routers update their routing tables. In order to secure the exchange of the full routing tables, the minimum active period is set to five minutes (three routing updates minimum).

A. By default, Snapshot routing takes advantage of each new connection to enter into an active window. Because some applications require short connection time (less than a minute), this option can be deactivated and then snapshot routing will trigger the link-up and start an active period at the expiration of the quiet period.

A. If you use the default configuration, this is exactly what happens. The parameter "suppress-statechange-updates" prevents the behavior you desire, but by default the behavior is there. Whenever the link goes from down to up, the Snapshot active period is restarted by default. Note that the active period retains its original length. For example, if it is set to five minutes, the updates are exchanged for the first five minutes, after which they are not exchanged.

A. Snapshot has been designed for hub and spoke topologies. It is not recommended in meshed networks where static routes are more efficient.

A. There is no limit on the number of clients. Snapshot does not require a one-to-one correlation of client routers to B-channels. If a client wants to connect at a time when all interfaces are busy, the retry parameter assures that snapshot updates are exchanged in a timely manner.

A. Yes.

A. No, this does not happen. Snapshot only wakes up on its interval, and will refuse to let the routing update packets go across the dialer link unless Snapshot views the link as "currently active for routing updates."

A. Snapshot's main strengths in DDR environments come down to offering a dynamic routing multiprotocol solution while respecting cost-control. Triggered Update solutions are likely to generate instability if there is any network change, which makes them non-scalable. Besides this, they require a specific adaptation for each routing protocol.