Requires Free Membership to View
SearchUnifiedCommunications.com members gain immediate and unlimited access breaking industry news, expert advice on UC, technical guides, and more -- all at no cost. Join me on SearchUnifiedCommunications.com today!
Kate Gerwig, Editorial Director
 |
||||
|
|
|||
|
||||
On routers, the configuration is often more complex, as routers normally employ a routing protocol such as OSPF, BGP or RIP to collect information about where addresses are and then calculate a loop-free path through the network to reach them. The process of all the routers in a network choosing the best paths through the network and reaching equilibrium is called "convergence." After a change in the network -- such as a circuit or router failure -- all the routers go through this process again, which we call "reconvergence."
|
||||
|
|
|||
|
||||
The time it takes to reconverge is a function of many things, including the routing protocol, selected timer settings, and the number of devices and circuits in the network. Obviously, the more devices and alternate paths there are, the longer it will take the routers to figure everything out. But unless your network is very large (or poorly designed) this is usually not an issue.
The timer settings usually control such variables as how long routes are kept, how often updates are sent, how often "hello" packets are sent, and how long to wait to receive a "hello" packet before declaring that a neighboring router is unavailable. In theory, the lower these numbers are, the faster the network reconverges. But if you set the numbers too low, you can create instability. This happens, for instance, when a very brief hiccup causes a few packets to be dropped. This would normally be transparent to the routing protocols and cause only a few retransmissions by applications, but because your timers have been set so sensitively, these dropped packets cause neighboring routers to break their relationship, and then the whole network reconverges. So the end result is a dropped call instead of a couple of seconds of poor call quality.
Since everyone's network is different, your network team should tune these timers to your network, but you should take care to model how long it takes to restore connectivity after any type of failure.
You also want to understand the characteristics of alternate paths. Assuming your primary path through the network is sized appropriately and configured with QoS and so on, if a given component in that path fails, what is the alternate path? And do you want your voice media to traverse this path? Or would you prefer your voice media to take a special path, like failing over to a local PSTN gateway instead of using a backup WAN circuit?
About the author:
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently,CCSP: Secure PIX and Secure VPN Study Guide, published by Sybex.
This was first published in April 2007