Advanced Routing Configuration
This topic presents some advanced routing configuration topics. It explains the following:
Using connectors for load balancing and failover Configurations that you can use to enable load balancing or failover between connectors.
Advanced link state configuration Specific scenarios for disabling or suppressing link state information.
Using Connectors for Load Balancing and Failover
Routing uses the costs that are associated with routing group connectors to determine the best way to deliver messages internally. Routing also uses the costs that are associated with SMTP and X.400 connectors to determine the best method for delivering external mail. It is important to understand that routing always chooses the connector with the closest matching address space and then the lowest cost. You can also use connectors to load balance messages or configure connectors for failover.
The disadvantage to using connectors for load balancing or failover is that both configurations increase the size of the link state table that is replicated across the Exchange organization. Remember, the larger the link state table, the more demands on system performance.
Configuring Connectors for Load Balancing
If you want to configure a connector to load balance requests between two or more bridgehead servers, create a single connector with the desired address space, for example, * for an SMTP connector, and then assign two different Exchange servers and SMTP virtual servers as bridgehead servers. Routing chooses the bridgehead server at random and effectively load balances the requests that are sent through this connector. However, if a message reaches one of these bridgehead servers, and this server becomes unavailable, routing does not automatically choose the alternate route. Mail simply queues until this server becomes available. There is no rerouting among bridgehead servers once a message reaches the intended bridgehead server.
Link state only contains a connector's state, and a connector is always considered available if one bridgehead server is available. If one bridgehead server becomes unavailable, routing still considers this connector a valid path and chooses randomly among the available bridgehead servers.
Configuring Connectors for Failover
If you want to configure connectors to failover automatically, you can create two separate connectors on different bridgehead servers, each with a different cost. Link state for a connector is determined by its local bridgehead server. If the bridgehead server on the preferred connector with the lowest cost is unavailable, that connector is considered unavailable and routing automatically chooses the second connector. When the bridgehead server hosting the connector with the lower cost becomes available, Exchange servers then begin using it again.
If you use two connectors with the same cost, Exchange servers will randomly pick which bridgehead server and connector they use, and if this bridgehead server becomes unavailable, they will fail over to the second connector. However, once the first bridgehead server becomes available, the servers will not failback to this server because the route has the same cost as the server they are already using.
Suppressing Link State Traffic for Connectors
Exchange 2003 suppresses link state traffic when connections are oscillating, or when no alternate route exists to a leaf-node routing group. These improvements reduce the amount of traffic that is generated by link state. Additionally, if you use the default option of Any local server can send over this connector for a routing group connector, this connector state is always marked as up. Using this option effectively suppresses any link state traffic that is generated by changes in this connector's state. However, this option is not possible for SMTP connectors or X.400 connectors.
In environments with extremely low bandwidth and high latency, some companies choose to suppress link state traffic between routing groups. You can suppress link state traffic on individual servers for all connectors by changing a registry key value. When you suppress link state traffic on a server, the server ignores any link state changes on any connectors for which it is a bridgehead server. Link state information for connectors on other servers is still updated, and organizational link state information is still propagated across all servers in the organization; however, the server with link state traffic suppressed does not send any information about its connectors. The following table lists the advantages and disadvantages of suppressing link state traffic.
Suppress link state traffic on a server if the following conditions exist:
You have a connector whose status is not important to other servers in the rest of the Exchange organization (for instance, a connector that is used exclusively by a routing group or a small number of servers to send mail to the Internet).
If you have network problems that cause a connector to oscillate between an available and an unavailable state. Remember, in Exchange 2003, an oscillating connection is a connector that changes state twice (up and down) within one link state interval, which is 10 minutes by default. If a connector is marked as unavailable after the link state interval, and then it becomes available after another window, link state traffic is generated. Also, if your Exchange organization contains Exchange 2000 servers, these servers do not have the link state improvements that are provided by Exchange 2003, and they will generate traffic for oscillating links.
Advantages and disadvantages of suppressing link state traffic
| Advantages | Disadvantages |
|---|---|
Suppression of link state traffic is relatively simple to configure and can be applied to individual servers for isolated conditions. |
You cannot create redundant paths or alternate connectors on a server where link state traffic is suppressed. Link state changes on the primary connector are never detected; therefore, messages are not rerouted to an alternate connector because routing assumes that the primary connector is available. |
Suppressing link state traffic on a server can decrease network traffic that is caused by frequent changes. A reduction in network traffic is particularly advantageous in situations where network bandwidth is very limited. The actual gain from reduced traffic depends on the size of the Exchange organization and the frequency of link state changes that are replicated. |
Suppressing link state traffic on a single server does not completely eliminate link state traffic between routing groups. |
Note
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.
It is important to understand that changing this registry key does not stop the propagation of the link state table across servers. It suppresses only the link state traffic that is caused by a connector state change.
For detailed instructions, see How to Suppress Link State Information on a Server.