Lesson 3: Link Status Information | MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration

When you create multiple routing groups and link them together, you establish a system of message pathways across your organization. One or many routes may lead to the same destination. Typically, the most efficient path should be used for message transfer, and additional routes may stand by in case the best path is temporarily unavailable. Exchange 2000 Server features a powerful routing engine that is able to determine the most efficient message routes based on information about the current conditions within the network.

This lesson explains how Exchange 2000 Server determines the best route for a message. It also covers how connector status information is transferred between servers within and between routing groups.

At the end of this lesson, you will be able to:

Explain how message routing is performed in an Exchange 2000 organization.
Describe the purpose of link state information.
Explain how link state information is propagated to guarantee loop-free message routing.

Estimated time to complete this lesson: 75 minutes

Message Routing

Message routing refers to the process of directing messages to their destinations through SMTP virtual server connections, messaging connectors, or gateways. The routing process begins when a message is passed to the SMTP transport engine. For each recipient address of every particular message, the routing engine must determine the correct destination. For this purpose, communication with Active Directory is necessary. The domain naming context contains the actual recipient objects. The configuration naming context, on the other hand, provides access to important connector and routing information.

NOTE
For X.400 Connectors and connectors to foreign messaging systems (gateways), the X.400 MTA performs the message routing. The X.400 MTA of Exchange 2000 Server relies on LDAP to retrieve the required routing information from Active Directory.

If a message is destined for a local recipient, it is transferred to the Information Store service, which delivers the message to the recipient's mailbox. If the recipient does not reside on the local Exchange 2000 server, the message must either be routed to another server in the same routing group by means of an SMTP virtual server, to another server in another routing group, or to a foreign mail system. For all recipients outside the local routing group, the routing engine determines all connectors that are able to transfer the message on a per-recipient basis. The best connector is chosen based on cost values and other criteria, such as connector states. The message is placed into the selected connector's message queue, which in turn transfers the message. If the connector resides on a bridgehead server in the local routing group, the message is transferred to that bridgehead first (see Figure 16.13). You can read more about link state information later in this lesson.

NOTE
The routing information, maintained in the Active Directory configuration naming context, is replicated throughout the Active Directory forest and available to all Exchange 2000 servers.

click to view at full size

Figure 16.13 Possible message destinations

Address Spaces

Exchange 2000 Server determines possible connectors for a particular message by comparing the recipient's address with available address space information associated with each connector. The result of this comparison is a set of connectors that can be used to transfer the message. If no connector is capable of transferring a particular message, a nondelivery report is generated. This report will indicate the server and the reason for the delivery problem (recipient name could not be resolved).

When connecting routing groups, you associate possible destinations with messaging connectors by means of the Connected Routing Groups tab. The RGC, however, does not provide this tab. Because this connector is used to connect to routing groups only, destination information can be determined implicitly from the connector configuration. By specifying information about connected routing groups, you implicitly configure Exchange address spaces.

You can add explicit address spaces to a connector via the Address Space tab. Each connector requires at least one address space, but multiple address spaces can be defined. Address spaces consist of an address type, such as SMTP, X400, MSMAIL, or CCMAIL, an address portion, and a cost value. You can use wildcards to simplify the address space definition. An address space such as SMTP:* would refer to all possible SMTP addresses. An asterisk (*) represents a multicharacter wildcard, and a question mark (?) can be used as a single-character wildcard. Table 16.1 gives examples of e-mail addresses.

Table 16.1 Examples of E-Mail Addresses

Address Type (Mail System)	Address Example	Address Space
Lotus cc:Mail	user at postoffice	at postoffice
MS Mail (PC)	NETWORK/PO/user	NETWORK/PO
SMTP	Administrator@Bluesky-inc-10.com	Bluesky-inc-10.com
X.400	c=US;a= ;p=BLUESKY;s=Titmouse;g=Carl	c=US;a= ;p=BLUESKY;

Assigning Cost Values to Connectors

Cost values determine which connector is preferred for message transfer. Costs are associated with address spaces and connected routing group information. Address spaces in turn are associated with a particular connector. The cost value can range from 1 to 100, and the connector that owns the address space with the lowest cost value is tried first. If messages cannot pass this connector, the next available connector is tried. If you assign the same cost value to multiple address spaces on different connectors, Exchange 2000 Server selects a random connector to provide a simple form of load balancing.

Connector Selection

If more than one connector is available to deliver a message, the list of all potential connectors must be reduced to one that will be used to transfer the message. To find the best connector, the link state table (LST) is checked. Only connectors on available routes (where all connectors are operational) are included in the message selection process. If multiple routes are available and each has different costs, the connection with the lowest overall cost value will be chosen (see Figure 16.14). If multiple links have the same costs, Exchange 2000 Server chooses connectors installed on the local computer over connectors installed on remote servers. With more than one potential local connector, random load balancing is performed.

click to view at full size

Figure 16.14 An organization with multiple routing groups

Message Rerouting

If a connector is temporarily unavailable, Exchange 2000 Server will reroute messages over alternative routes (if they exist). For instance, if an RGC has unsuccessfully attempted to transfer a message to its remote bridgehead servers three times, it is marked as unavailable, and other possible connectors may be chosen for message transfer. If all possible connectors are unavailable, the message remains in the local message queue until at least one connector is operational again. If the message expires in the interim (the default wait is 48 hours), Exchange 2000 Server sends a nondelivery report to the originator.

Rerouted messages maintain a retry count for each connector that has been tried. At every rerouting, the retry count is incremented for the current connector. If the maximum number of retries is reached for a particular connector, that connector is excluded from the routing process. If all connectors reach their maximum retry count, the message is returned with a nondelivery report to the originator.

NOTE
Exchange Development Kit (EDK) gateways and connectors to foreign messaging systems are always considered available. Exchange 2000 Server considers the message delivered when it reaches the connector's message queue. Rerouting is not performed, even if the EDK connector cannot deliver the message.

Rerouting and Activation Schedules

If more than one potential connector is able to deliver a message, Exchange 2000 Server checks activation schedules. If a connector is currently active, its state is known as Active Now. Active connectors are the first choice. If the connector is currently not active but scheduled to connect at a later time, its state is called Will Become Active In The Future. If multiple connectors exist that will become active in the future, Exchange 2000 Server selects the connector that becomes active first. The third state is called Remote Initiated. This means that the connector does not initiate any connection itself. Instead, it waits for a remote server to connect. The fourth state, Never, indicates a disabled connector. For instance, you can set a particular X.400 Connector to Never if you want to accomplish maintenance routines, because in this state the connector does not initiate or receive connections. However, setting an SMTP Connector to Never Run does not bring the connector into Never state. The connector remains available, and messages may be routed to it. Only the message transfer is temporarily disabled. One way to avoid message routing to this connector is to set its maximum message size to 1 KB.

NOTE
Messages routed to a remote initiated connector will wait in the connector's queue until the remote bridgehead server requests message delivery. Because scheduled connectors are considered available, messages are not rerouted while they are awaiting their retrieval.

Link State Information and Routing Group Masters

Link state information helps to indicate whether a particular connector or routing group is available or unavailable. All link state information is held in an LST, which is used to find the most efficient route for a message based on connector availability.

NOTE
You can view the LST in Exchange System Manager. In the console tree, expand Tools, and then Monitoring and Status. Select the Status container. In the details pane, all connectors and servers in your organization, together with link state information, are displayed.

Link State Information

Link state information eliminates problems with message looping between servers because each Exchange 2000 server can determine the availability of every connector in the organization. If a downstream connector is currently unavailable, the corresponding link is marked as down. Consequently, messages are not sent to this connector. If no other path exists, messages are held in a queue at the source until the link state information indicates that the downstream connector is available again.

NOTE
There are only two possible states for any given link (up or down). LSI also includes connector costs for efficient message routing. However, retry counts or activation schedules are not included in link state information.

Link State Table

Every Exchange 2000 server maintains an LST containing information about the current state of each connector. The LST is a small, in-memory database, and each entry (routing group, connector, server) in the database requires approximately 32 bytes of memory. The LST database is not stored on disk. To examine the LST in detail, use the Winroute utility. WINROUTE.EXE is available in the \Support\ Utils\i386 directory on the Exchange 2000 Server CD. This utility is available in the Standard and Enterprise Editions. It connects to TCP port 691 (the Link State Port) on the specified Exchange 2000 server to extract the link state information in raw format. Winroute also interprets the data for easier readability.

Link State Algorithm

The propagation of link state information differs within and between routing groups. To propagate the link state information to all servers in an organization, a link propagation protocol known as link state algorithm (LSA) is used. LSA is based on the Open Shortest Path First (OSPF) protocol.

Within a routing group, a nominated routing group master keeps track of link state information and propagates it to the rest of the servers within the routing group. When a nonmaster server detects that a particular connector is unavailable, it immediately connects to the master's TCP port 691 to provide the new link state information. The master incorporates the changes into the LST and propagates the new information to all remaining servers in the routing group. Again, connections are established to TCP port 691. All servers within a routing group need to communicate with the routing group master through a reliable TCP/IP connection.

Between routing groups, link state information is transferred via main messaging connectors. Typically, the information is transferred using the X-LINK2STATE command over RGC and SMTP Connectors. When you link routing groups together by means of an X.400 Connector, link state information is exchanged between the MTAs as part of the normal message transmission. A binary large object is sent to the receiving MTA before interpersonal messages are transferred.

NOTE
As messages are transferred between two routing groups, link state information is automatically propagated. In addition, a periodic poll updates the link state information.

Changing the Routing Group Master

The master server is normally the first server in a routing group. If this server fails or is taken offline, link state information is no longer propagated within the routing group. Individually, every server still generates and receives link state information, but there is a chance that other servers send messages over a link in which a downstream connection is unavailable. Consequently, if you shut down a routing group master for a significant period of time, nominate a different master using Exchange System Manager to avoid inefficient message routing. Expand the desired routing group and select the Members container. In the details pane, right-click the corresponding server object and select the Set As Master setting.

Message Rerouting Based on Link State Information

Message routing based on link state information is most effective in environments with redundant pathways to destinations. Figure 16.15 shows an organization with four routing groups linked together in ring form using connectors with different cost values.

In the example shown in Figure 16.15, messages from routing group A flow to routing group D as follows:

A user sends a message to a recipient with a mailbox in routing group D. Because of the lower overall sum of cost values, the message is transferred to routing group C first.
The receiving bridgehead attempts to open a connection to the target bridgehead in routing group D. Because this link is not operational, the connector is marked as unavailable after three unsuccessful connection attempts.
The bridgehead connects to the routing group master through TCP port 691 and transmits new link state information. The master incorporates the information into the LST and notifies all other servers in the routing group about the changes.
NOTE
If the connection had been marked unavailable before routing group D began routing the message, it would not have forwarded the message to routing group C.

Figure 16.15 Rerouting of messages based on link state information
The bridgehead server reroutes the message based on costs and link state information and determines a path via routing groups A and B. Consequently, the message is transferred back to routing group A. However, before the actual message is sent, link state information is propagated using the X-LINK2STATE command verb after issuing an EHLO command to the bridgehead in routing group A.
Upon receiving the new link state information, the local bridgehead immediately connects to its master through TCP port 691 and transmits the new information. The master incorporates the data into the LST and notifies all other servers in the routing group about the changes.
Using the updated LST, the local bridgehead determines that the message must be routed via routing group B. A connector is available on another bridgehead server in the local routing group. Therefore, the message is transferred to this server directly via SMTP.
The second bridgehead routes the message based on the new LST information to routing group B. Yet, before the actual message is transferred, the most recent link state information is propagated using the X-LINK2STATE command.
The bridgehead server in routing group B immediately connects to its master through TCP port 691 and transmits the new information. The master incorporates the data into the LST if it hasn't been received through other messages yet and notifies all other servers in the routing group about the changes.
The bridgehead in routing group B routes the message to the bridgehead in routing group D and also propagates the new link state information using the X-LINK2STATE command over TCP port 25.
The bridgehead server in routing group D informs its master, which updates the LST and notifies all other servers in the routing group about the changes.
The message is delivered to the recipient's mailbox.
At this point, all servers in the organization have been informed about the unavailability of the connector between routing groups C and D. Subsequent messages to routing group D are not routed via this path. Messages are routed to routing group B instead. If the connector between routing groups B and D went down for any reason, no message paths to routing group D would be available. Consequently, messages are not rerouted and remain in their queues until the link state information indicates an operational connector on either side.

NOTE
After a connector is tagged as unavailable, the original bridgehead server continues to retry the connection at 60-second intervals even if no messages are awaiting transfer. As soon as a connection can be established, the connector is considered available again, and the bridgehead notifies the local routing group master about the link state change.