Link State Administration

[Previous] [Next]

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 protocols, not the connectors, 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. SMTP 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.oaktree.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 that we have four servers: Tucson, Folsom, Minneapolis, and Indianapolis.

It is important to note that each server's display of the overall routing topology will be different because not all of the 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. Figure 13-13 shows a trace of a message sent from ssmith to benglish, listing the path it took. The reason the message does not pass through Minneapolis is that it is not 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.

Figure 13-12. Routing topology for hr.oaktree.com.

Figure 13-13. Trace of a message passing through the Folsom server.

Scenario 1: First Link Is Unavailable

A message sent from ssmith to benglish must travel over two separate links (Indianapolis/Folsom and Folsom/Tucson) and through three different servers (Indianapolis, Folsom, and Tucson). Let's assume that Folsom has gone off line for some reason and that ssmith sends a message to benglish. As Figure 13-14 shows, the message is initially placed in the outbound queue for the California Indiana RGC.

Figure 13-14. Message held in the outbound queue of the California Indiana Routing Group Connector.

Managing Messages in Outbound Queues

When a message is held in an outbound queue, it doesn't automatically appear in the contents pane (the right pane). The reason for this is that if messages are accumulating in the queue, enumerating those messages for display could take anywhere from several seconds to several minutes once you've selected the queue. Instead, Microsoft has given us a handy way of knowing that something is wrong with the queue. As you can see in Figure 13-15, the icon in the scope pane (the left pane) for the California Indiana routing group queue has changed to show that it is in the retry state, and the details pane contains a reminder that the queue needs to be enumerated.

Enumerating a queue simply involves right-clicking anywhere in the contents pane to reveal the shortcut menu shown in Figure 13-15. Choosing Enumerate 100 Messages from this menu causes the first 100 messages in that queue to be enumerated. Since our sample queue contains only one message, enumerating the queue displays a single message, as shown back in Figure 13-11.

Figure 13-15. Enumerating an outbound queue.

Once you can see a message in the queue, there are several things you can do with it. First, you can freeze the message. If you do so, the message will remain in the queue, even if the link starts working again. 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. When you unfreeze the message, it is sent immediately. You can freeze and unfreeze a message by right-clicking the message itself and making your selection from the shortcut menu (Figure 13-16).

Figure 13-16. Shortcut menu for messages in an outbound queue.

The shortcut menu also allows you to delete a message in an outbound queue. When doing so, you can specify either that a nondelivery report (NDR) be sent to the originator or that no NDR be sent. Figure 13-17 shows the NDR the originator will receive if the message is deleted with the Delete (Send NDR) command.

Figure 13-17. NDR sent to the originator of a deleted message.

Creating a Custom Filter for Messages You can perform additional message management by right-clicking the queue itself and choosing Custom Filter. In the Custom Filter dialog box, shown in Figure 1318, you can filter messages for the Delete (Send NDR), Enumerate, Freeze, and Unfreeze actions.

If you choose Enumerate in the Action list box, you can specify how many messages should be enumerated. The default is to enumerate the first 100 messages. In the Select Messages That Are area, you can filter the queued messages based on a combination of characteristics, such as whether they are frozen, their size, their age, their originator, their recipient, and whether they have experienced delivery failure (Figure 13-19). Once the messages are sorted, you can apply any of the four actions to the filtered messages.

Figure 13-18. Custom Filter dialog box.

Figure 13-19. Unfreezing messages to a certain recipient.

For instance, if all of the messages in a queue have been frozen and the link is operational again, you could filter the messages to unfreeze only those addressed to a certain recipient or distribution group. This gives the administrator maximum flexibility in how messages are managed in a queue once a link becomes operational again. When you click OK, the action you've chosen is applied to the filtered messages. Once you have created a customized filter, you can make it the default filter for a certain action. Check the Set As Default Filter check box to do so.

Resuming Normal Operation

Just because the messages have been sent doesn't mean that the link state information is back to normal. Once Folsom is up and running, the messages might transfer, yet the connector icon will still show the link as being in a retry state (Figure 13-20). 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.

Figure 13-20. Empty queue in a retry 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, ssmith sends another message to benglish, but this time the Tucson server is unavailable.

When ssmith sends the message, it is routed from Indianapolis to Folsom, where it waits until the Tucson server comes back up or the message's expiration time is reached, in which case the user is sent an NDR. Figure 13-21 shows the message sent from ssmith sitting in the outbound queue of the Folsom server's Arizona California RGC.

Figure 13-21. Message in outbound queue for California Arizona Routing Group Connector.

Scenario 3: Alternate, Higher-Cost Route Is Available

One of the features 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. For this scenario, let's increase the connector cost between Folsom and Indianapolis to 100. Figure 13-22 shows the new topology. Now suppose that benglish in Tucson sends a message to ssmith in Indianapolis.

Figure 13-22. New topology for hr.oaktree.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. Figure 13-23 shows the results of a trace of the message.

If you are ever in doubt as to which path a message has taken, track the message. For more information on how to do so, consult Chapter 22.

Figure 13-23. Trace of a message routed over the link between Indianapolis and Folsom.

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. 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. Figure 13-24 shows the various queues that have been created for this message. (Since these domain names are fictitious and therefore don't really exist, all of the queues are in a retry state.)

Figure 13-24. Multiple outbound queues for domain names.