Link State Administration

This section takes a look at how to manage the link state information for your Exchange system. (Refer to Chapter 3 for a discussion of how the link state protocol works.) Administration of link state information takes place inside the Queues container for a server and is mainly a function of queue management. We will be most concerned with the SMTP protocol (Figure 13-11), since it is used by both the Routing Group Connector and the SMTP connector.

Figure 13-11: Queues in Exchange System.

Before launching into our discussion, let’s look at the topology for a network that we will use as an example. Figure 13-12 shows that our fictitious company, hr.trainsbydave.com, has offices in four cities: Folsom, Tucson, Minneapolis, and Indianapolis. It also shows the user located in each city that we will use to illustrate messaging and connectivity. We are assuming that each connector’s cost is equal to 1. Furthermore, the Routing Group Connectors are named by state, such as California Arizona RGC for the link between Folsom, California, and Tucson, Arizona. And finally, the servers are named after their location, so we have four servers: Tucson, Folsom, Minneapolis, and Indianapolis.

13-12 : Routing topology for hr.trainsbydave.com.

It is important to note that each server’s display of the overall routing topology will be different because not all routes or connectors are displayed in Exchange System for any given server. Take a moment to familiarize yourself with this topology before reading on.

When ssmith sends a message to benglish, it must pass through the Folsom server. The message does not pass through Minneapolis because it does not represent the lowest-cost route. By default, routing will occur over the route with the lowest cost, which in this case is Indianapolis to Folsom to Tucson, for a total cost of 2.

Now that you are familiar with our fictitious company, let’s look at how the link state protocol works when a link goes down. We’ll cover four different scenarios and illustrate how the link state protocol is administered.

Scenario 1: First Link Is Unavailable

Normally, a message sent from benglish to ssmith would have to travel over two separate links (Indianapolis/Folsom and Folsom/Tucson) and through three different servers (Tucson, Folsom, and Indianapolis). However, let’s assume that the Folsom server has gone offline for some reason and that benglish sends a message to ssmith. As Figure 13-13 shows, messages are initially placed in the outbound queue for the RGC.

Figure 13-13: Messages held in the outbound queue of the California Arizona RGC.

Managing Messages in Outbound Queues

Microsoft has given us a handy way of knowing that something is wrong with the queue—icons. As you can see in Figure 13-13, the icon in the results pane (the right pane) for the California Arizona routing group queue has changed to show that it is in the retry state (a small blue arrow on the icon).

You can manage queues and the messages inside in several ways. First, you can freeze a queue by right-clicking it and choosing Freeze. If you do so, messages in the queue remain there even if the link starts working again. Freezing a queue can be a good way of making sure that message delivery is not attempted while you troubleshoot a problem. If you double-click a queue to find the actual messages inside, you’ll find that you can also freeze individual messages. Freezing a message is handy if you know that a particular message in the queue is either quite large or very unimportant and you want to hold it back until the rest of the messages have been sent. You can unfreeze a queue or an individual message by right-clicking the object and choosing Unfreeze. When you unfreeze a queue or message, message delivery resumes immediately.

You can also delete any individual message in an outbound queue by right- clicking it and choosing Delete (or just by clicking it and pressing the Delete key). When doing so, you can specify whether or not to send a nondelivery report to the originator.

Resuming Normal Operation

Just because the messages have been sent doesn’t mean that the link state information is back to normal. Once a server is up and running, the messages might transfer, yet the connector icon will still show the link as being in a retry state. This is nothing to be alarmed about. Wait a few minutes and check the queue again; you’ll usually find that the icon shows the queue in a normal state.

Scenario 2: Destination Link Is Unavailable

We’ve seen what happens to a message when the first hop becomes unavailable. Now let’s take a look at what happens to a message when the final hop becomes unavailable. In this scenario, benglish sends another message to ssmith, but this time the Indianapolis server is unavailable.

When benglish sends the message, it is routed from Tucson to Folsom, where it waits until the Indianapolis server comes back up or the message’s expiration time is reached, in which case the user is sent an NDR.

Scenario 3: Alternate, Higher-Cost Route Is Available

One feature of the link state protocol is its ability to detect when part of the overall route is down and reroute a message over a higher-cost link. Recall from Chapter 3, though, that improvements to the link state protocol in Exchange Server 2003 mean that links are not marked as unavailable if they are the only link between two locations or if the link state is oscillating.

For this scenario, let’s increase the connector cost between Folsom and Indianapolis to 100. Figure 13-14 shows the new topology. Now suppose that benglish in Tucson sends a message to ssmith in Indianapolis.

Figure 13-14: New topology for hr.trainsbydave.com.

Given the connector costs, normal routing for this message would flow through Minneapolis. Let’s say, however, that the link between the Minneapolis and Folsom routing groups is down. This will force messages to be routed over the higher-cost link between Indianapolis and Folsom.

Note

If you are ever in doubt as to which path a message has taken, track the message. For more information about how to do so, consult Chapter 26, “Monitoring Exchange Server 2003.”

Scenario 4: Message Has Multiple Destinations

If a message is sent to both internal and external recipients, a temporary queue is set up for each external domain name as well as each internal Exchange Server 2003 that hosts a recipient of the message. For instance, suppose that we’ve sent a message to a group of fictitious domain names. When the message is sent, the advanced queuing engine creates the necessary queues. The link state protocol does not concern itself with these outbound SMTP queues to external domains. Its only concern is keeping link state information current for the internal servers.