Snapshot Routing provides an efficient and cost-effective routing solution in Dial-on-Demand Routing (DDR) environments.
Snapshot Routing is a routing update mechanism that answers two key customer concerns:
ISDN is the primary target for Snapshot Routing, but other media, such as dedicated leased lines, can also benefit from its reduction of periodic updates.
This document describes Snapshot Routing. There's also links to sample configurations. We will focus our attention on the use of Snapshot for ISDN DDR environments.
As mentioned above, Snapshot Routing is only one of the possible solutions to implement Dial-on-Demand. We will briefly cover other solutions that allow the implementation of Dial-on-Demand Routing.
Finally, a "Questions & Answers" section addresses remaining questions regarding Snapshot Routing functionality.
Snapshot Routing allows dynamic routing protocols to run over DDR lines. Usually, routing broadcasts (routes and services) are filtered out on DDR interfaces and static definitions are configured instead.
With Snapshot, normal updates are sent across the DDR interface for a short duration of time called an "Active Period." After this, routers enter a Quiet Period during which the routing tables at both ends of the link are frozen. Snapshot is therefore a "triggering" mechanism that controls routing update exchange in DDR scenarios.
Only in the Active Period do routers exchange dynamic updates. During the Quiet Period, no updates go through the link (up or down) and the routing information previously collected is kept unchanged (frozen) in the routing tables.
The lengths of the Active Period and Quiet Period are user configurable.
By default, each DDR connection (triggered by user data) starts an Active Period during which routers update their tables.
Afterwards, routers freeze the received information, enter the Quiet Period and stop sending routing updates -- until the next data connection or the expiration of the Quiet Period. If, during the Quiet Period, no connection has been triggered, the Snapshot mechanism triggers a call to update its information at the end of the Quiet Period interval.
Moreover, Snapshot's principle is to let normal routing protocols update naturally their routing tables. The routing protocol timers remain unchanged when Snapshot is used. Therefore, in order for the received information to reliably represent the network topology, the Active Period needs to last long enough to let several routing updates come through the link. The Active Period's minimum duration is five minutes.
As an option, you can prevent Snapshot Routing from using data connections as Active Periods. Snapshot Routing will then update its routing table regularly after each Quiet Period.
Snapshot can be used with all "periodic route update" protocols for all supported protocols on DDR lines. These are:
Snapshot Routing brings you the following benefits:
Finally, when your network becomes very large, Snapshot Routing will scale easily to the size of your network. Using static routes would not scale in terms of manageability of the network configuration. Snapshot Routing therefore has better scaling properties than other solutions.
Snapshot mechanism is explained hereafter:
Some terminology:
Routing information is exchanged during Active Periods. At the end of this period, the routers take a snapshot of the entries in the routing table. These entries remain frozen during the Quiet Period. At the end of the Quiet Period, another Active Period starts during which routing information is again exchanged.
If the line is not available when the router transitions from the Quiet to the Active Period, we enter a Retry Period, where the router will repeatedly attempt to connect until an Active Period is successfully entered.
By default, Snapshot is configured to take advantage of data transfers and exchange the routing information. The "suppress-statechange-updates" keyword, configured on client routers, is fully described in the next section.
The configuration of the Active Period can be set between 5 and 100 minutes; the Quiet Period between 5 minutes and 65 days. The Retry time is set to the Active Period length + 3 minutes.
Using the "no suppress-statechange-updates" Option
With the "no suppress-statechange-updates" option (default option) you take advantage of connections that are brought up by interesting data traffic. When this option is used, the routing updates are going to be exchanged during each data transfer, and Snapshot will consider that connection as an Active Period start.
Snapshot will in this case enforce the data connection time to last at least as long as the Active Period. Snapshot actually freezes routing information based on the routing updates that are sent during the Active Period. To make sure that frozen information accurately reflects the network status at freeze time, Snapshot enforces a connect time (or Active Period) long enough for several updates to cross the link. If the Active Period were to allow just one routing update broadcast, and should that update be lost, (for example, because of noise on the line), you could either age out routes or not hear about newly added routes.
Snapshot expects the Active Period to last at least three times the routing updates interval.
As a result, Snapshot forces all these data connections to last at least 5 minutes. This might cause increased communication costs in environments where numerous but very short data transfers take place. In other environments, this does not impact the communication cost, as data transfers usually last more than the minimal 5 minutes.
Snapshot and Link State Protocols
Contrary to Distance Vector Protocols, Link State routing protocols send periodic "hellos" to the neighbors, as well as Link State Packets.
The hellos are exchanged between the neighbors every 5 or 10 seconds. They are inherent in the operation of Link state protocols as they allow the discovery of the routing neighbors. They would trigger the link-up every 5 or 10 seconds. Therefore the Link State routing protocols (NLSP, OSPF, IS-IS, ...) are not usable in Dial-on-Demand environments.
EIGRP also relies on the exchange of hellos between neighbors, and for that reason, should not be used with Snapshot, either.
Snapshot Routing is an innovative alternative to static routing which allows the efficient use of a dynamic routing protocol in DDR environments. However, Cisco offers the choice of using simple static solutions if dynamic routing is not worth it. Static routes exist in the IOS for IP, Novell, Apple, Vines and DECnet.
Before implementing the Snapshot mechanism, here are the key points to check:
In other cases, you can control the frequency of 'active periods' (set to several hours or every day for instance) during which routing information is exchanged.
If data connections are short (less than 5 minutes) and calls frequent, the 'send-update-every-time' will affect the bill.
Opening 'active periods' independently of data connections offers a stable 'update' cost, i.e., Snapshot can use low night-time rates.
If all these questions are answered in the affirmative, then Snapshot Routing will be your preferred solution to run your DDR network.
Here's a few sample configurations using Snapshot routing.
IOS
DDR: Dynamic Routing Snapshot IP RIP)
DDR: Dynamic Routing Snapshot IPX RIP/SAP)
700 Series
DDR: Dynamic Routing to an IOS Router (Snapshot IP RIP)
DDR: Dynamic Routing to an IOS Router (Snapshot IPX RIP/SAP)
Q: What does Snapshot Routing bring me when I do DDR routing?
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).
Q: How does Snapshot Routing work?
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.
Q: What happens if the link doesn"t come up when Snapshot wants to use it?
A: The client site keeps monitoring '"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.
Q: What protocols and what routing protocols are supported by Snapshot?
A: Snapshot allows the use of all "distance vector" routing protocols over DDR lines. They include:
- RIP & IGRP for IP
- RTMP for Appletalk
- RIP & SAP for IPX
- RTP for Vines
Q: What's the minimum Active Period that I can define for Snapshot?
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).
Q: Does Snapshot use the connections established by data transfer?
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: snapshot routing will trigger the link-up and start an active period at the expiration of the Quiet Period.
Q: It would be nice if snapshot updates could happen whenever the link is up. This would mean that under normal circumstances routing information would be exchanged during normal operation and additional calls would not be required. Is this possible?
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->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.
Q: Are there network topologies that I can't realize with Snapshot Routing?
A: Snapshot has been designed for hub and spoke topologies. It is not recommended in meshed networks where static routes are more efficient.
Q: If I have a primary interface on the central site (server), can I support more than 30 clients?
A: There is no limit on the number of clients. Snapshot does not require a 1-to-1 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.
Q: Is Snapshot Routing also supported on other products?
A:Yes, it is also supported on these products.
- Cisco 700 Series
- LAN2LAN
Q: When using Snapshot Routing, the customer is worried that losing a file server (and therefore its internal network) will trigger 50 calls to his remote sites. Is this true?
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."
Q: Why is Snapshot Routing better than the Triggered Updates solution?
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.
All contents copyright © 1992--1999 Cisco Systems, Inc. Important Notices and Privacy Statement.