Lesson 2: The Routing Infrastructure of Exchange 2000 Server

In a native Exchange 2000 Server organization, message transfer relies entirely on SMTP, which works over any type of network connection, including slow and unreliable links. You do not need to configure anything extra for the servers to communicate with each other. An Exchange 2000 server that must deliver a message to a recipient on another server can simply retrieve the name of the recipient’s home server from Active Directory. It then queries the Domain Name System (DNS) for the Internet Protocol (IP) address of that server, obtains the IP address (the home server is a Windows 2000 server in the same Active Directory forest, so a resource record [RR] should exist in DNS), and uses it to establish a TCP/IP connection to the target host. The sending server can then transfer the message, and the recipient receives it just fine. Is there anything to configure?

This lesson addresses important issues related to the transfer of messages across an Exchange 2000 organization and explains how to design an efficient routing topology. You will read about the purpose of routing groups, their advantages, the best ways to connect them, and how to benefit from Exchange 2000 Server’s capability to recalculate routing paths dynamically based on link state information (LSI).

After this lesson, you will be able to

  • Describe the purpose of routing groups in an Exchange 2000 organization
  • Deploy appropriate messaging connectors between routing groups
  • Design a global routing topology for an Exchange 2000 organization

Estimated time to complete this lesson: 60 minutes

Understanding Message Routing in Exchange 2000 Server

Without implementing a sophisticated routing topology, message transfer is always immediate and direct; that is, the sending station attempts to transfer the message in a straight line to the target host as soon as the user clicks Send. However, this does not necessarily imply that the transfer is accomplished in a resource-conscious manner. Figure 5.6 gives an example of this. A message was addressed to three recipients on different servers in New York. Theoretically, the Exchange 2000 server in San Francisco could have transferred this message just once to the other side and a server in New York could then have split the message into three instances. Instead, because the message transfer is direct, the server sends the same message three times, wasting a significant amount of precious bandwidth.

Figure 5.6 - Inefficient use of WAN connections

The Purpose of Routing Groups

In Chapter 4, "Assessing the Current Messaging Infrastructure," you read that routing groups are server locations interconnected by a backbone and corresponding to network segments or local area networks (LANs). In other words, a routing group is an area of well-connected TCP/IP subnets, where network connectivity is highly reliable and fast so that servers can communicate directly with each other without wasting precious network resources. Getting back to Figure 5.6, the locations of San Francisco and New York are good candidates for routing groups because the servers in each location can talk to each other without affecting the WAN. Keep in mind that within a routing group, message transfer is always direct and accomplished via SMTP.

Creating Routing Groups

You can use the Exchange System snap-in to create routing groups, move servers between them, rename routing groups, or delete them. Moving servers between routing groups is a simple drag-and-drop operation. In a native mode organization, servers from any administrative group can be members of the same routing group. In mixed mode only, routing groups are bound to administrative groups for backward compatibility reasons.

Routing groups are not displayed unless you explicitly enable the Display Routing Groups check box in the General tab of the organization object. If you display administrative groups in addition, you will find the default routing group called First Routing Group under First Administrative Group\Routing Groups. To create an additional group, click the Routing Groups container, point to New, and then select Routing Group. Specify a name and then click OK. You may want to keep the naming of your groups similar to that of administrative groups. One Microsoft recommendation is to use abbreviated names, such as RG, and a four-character identifier for the geographic location (for example, RGSFCA), but you can use full names such as RG San Francisco California as well, which might be more intuitive. There is no technical reason for limiting the routing group names to six characters.

Routing Group Connectors

Communication does not take place between routing groups without explicit configuration of messaging connectors. A routing group connector (RGC) is basically a configuration object that provides Exchange 2000 Server with information about how to transfer messages across a routing group boundary. Important connector parameters are local and remote bridgehead servers, connection times, and a cost value.

Bridgehead servers act as concentrators for message traffic over WAN connections, and the concentrated traffic results in a better use of precious network resources (Figure 5.7). Furthermore, data is compressed by an average ratio of 5:1 before it is sent across a connector. If slow delivery times are acceptable, you can queue messages and transfer them in batches at specified connection times when the general workload is minimal, for example, at night. Be careful, however, when scheduling transmission times. Your users may be upset if the delivery in your environment takes as long as a full day. Perhaps it is more clever to define a size limit and configure a different connection schedule only for oversized messages, which might otherwise delay the transfer of normal or high- priority messages.

The following is a list of RGCs available in Exchange 2000 Server.

  • Routing Group connector This is the easiest connector to install and more powerful than others because it supports multiple source and destination bridgehead servers, which can guarantee message delivery even if a particular bridgehead is down. You can only use this connector to provide a message path between routing groups in the same organization. In native Exchange 2000 Server environments, messages are transferred in transport-neutral encapsulation format (TNEF) based on SMTP. (Do not confuse the Routing Group connector with an RGC—the Routing Group connector is only a particular type of RGC. The naming is misleading.)
  • SMTP connector This connector also uses SMTP for message transfer. The Routing Group connector is easier to maintain, but the SMTP connector gives you more control over the routing configuration. Among other things, it is possible to queue e-mail messages for remote triggered delivery. The SMTP connector is a good choice if you want to connect to a remote bridgehead over an Internet link.
  • X.400 connector If your messaging backbone relies on X.400 to connect different e-mail systems together, you can use X.400 connectors to seamlessly integrate your routing groups into the existing environment. An X.400 connector can provide connectivity to earlier versions of Exchange Server and Exchange 2000 Server in different routing groups or organizations, as well as to any foreign X.400 system. Due to the complexity of the X.400 protocol, the X.400 connector is difficult to configure.

    Figure 5.7 - Efficient use of WAN connections

Note


You cannot use gateway connectors (that is, the MS Mail Connector, or the Connectors to Lotus cc:Mail, Lotus Notes, or Novell GroupWise) to connect routing groups together.

Message Routing over Dial-Up Connections

Exchange 2000 Server does not support dial-up connections directly. Instead, Routing Group, SMTP, and X.400 connectors make use of dial-up connections by means of the Windows 2000 Routing and Remote Access Service (RRAS). Hence, if you want to connect to a remote routing group over an on-demand dial-up connection, you need to install and configure your modem or Integrated Services Digital Network (ISDN) card on a Windows 2000 server that will act as a network router. On this server, enable RRAS via the Routing and Remote Access utility from the Administrative Tools program group. You can then configure the messaging connector as if it were making a LAN connection.

Message Routing over Multiple Connectors

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 then lead to the same destination, as shown in Figure 5.8. Typically, Exchange 2000 Server should use the most efficient path for message transfer. In Figure 5.8, this is the RGC between San Francisco and New York. The additional route via Chicago, on the other hand, may stand by in case the pri-mary connection is temporarily unavailable. For the most efficient routing, use a mesh topology that connects each routing group to every other routing group. This method will limit unnecessary message forwarding.

Figure 5.8 - Multiple routes to the same destination and a rerouting problem

Exchange 2000 Server determines the best connector based on cost values and other criteria, such as connector states. You can assign your connectors a cost value ranging from 1 to 100. The path that has the lowest cost value is tried first. For instance, in Figure 5.8, the path between San Francisco and New York has a cost value of 1. The alternative route via Chicago has a cost value of 2 because the costs of all RGCs in the message path are added together. Hence, Exchange 2000 Server attempts delivery via the direct connection first.

Note


It is possible to configure multiple RGCs (such as an SMTP connector and a X.400 connector) between two routing groups. If you assign these connectors the same cost values, Exchange 2000 Server will perform load balancing over both connectors. With different cost values, the connector with the higher cost acts as a backup for the main connector. Keep in mind that multiple connectors are only efficient if they use different physical network connections.

Message Rerouting

If the RGC between San Francisco and New York has unsuccessfully attempted to transfer a message to its remote bridgehead servers in New York three times, it is marked as unavailable. In this situation, Exchange 2000 Server may choose another possible path for message transfer if one exists. In Figure 5.8, this is the connection between San Francisco, Chicago, and New York, and the messages reach their recipients in spite of the connectivity problem.

Although it is generally desirable to use an alternate path if messages cannot reach their targets directly, message rerouting can impose a subtle problem. Let’s say that the RGC between Chicago and New York is likewise down—because it was the central WAN router in New York that broke down and not just the RGC between San Francisco and New York. The messages would then be rerouted to Chicago without any tangible benefit. In fact, Chicago may now reroute the messages further to Miami while New York is still unavailable, so Miami may forward them to Paris, and Paris may think Chicago is a good alternative. In short, blind message rerouting can lead to a situation where a large number of messages dance around the destination like Rumpelstiltskin around the fire.

Link State Information

Exchange 2000 Server overcomes this dilemma by using a powerful routing algorithm based on LSI. Basically, all servers communicate the state of their connectors (links) to each other, so each server in the organization knows the current state of all connections in the environment. When a connector has repeated delivery problems, Exchange 2000 Server marks it as unavailable and propagates the new state to all other servers so that they stop routing messages to the problematic RGC. Applied to Figure 5.8, this means that if San Francisco has problems transferring local messages to New York, and if Chicago, Miami, and Paris experience the same problems, all connectors to New York will be marked as down. When rerouting a message in San Francisco, no alternative path is open, and the message is not transferred to any other location. The message remains in San Francisco until at least one pathway to New York becomes available again.

Exchange 2000 Server relies on a procedure known as the link state algorithm (LSA) to propagate LSI to all servers (Figure 5.9). When a bridgehead discovers that a local connector is unavailable, it communicates the news to its local routing group master, which consolidates the information and propagates it to all other servers in the routing group. The bridgehead also communicates the news via RGCs to all connected routing groups, where a remote bridgehead receives the LSI and in turn communicates it to its local routing group master, which again propagates the news to all other servers in the routing group, as just explained. When the connector becomes available, updated LSI is propagated again.

Figure 5.9 - The propagation of link state information

Note


The LSA has an important influence in routing group design. Within a routing group, the network connections between all servers and the routing group master must be reliable to guarantee up-to-date LSI on all servers, which is the basis of efficient message routing.

Designing Routing Group Topologies

It is easy to design the routing group topology of an Exchange 2000 organization if you accomplish the work in three stages. You need to decide which servers belong to the same routing group, then determine appropriate RGCs to connect them, and then, with all this information in place, you also must determine the desired message routing topology.

There are three key issues to keep in mind when designing a routing group topology:

  • Servers with fast and reliable network connections should be part of the same group.
  • Routing groups are best connected using a Routing Group connector; SMTP and X.400 connectors are second choices.
  • Dynamic rerouting of messages can be controlled in a hierarchical arrangement of routing groups, which eliminates alternative paths.

Determining Routing Group Boundaries

To determine an appropriate routing group topology for your Exchange 2000 organization, take the diagram of your Active Directory sites and simply rename it Routing Group Diagram. Sites define areas of well-connected TCP/IP subnets and so do routing groups; there is no difference. Another option is to take the network topology documentation created in Chapter 3, "Assessing the Current Network Environment," and draw a circle around every LAN that has a substantial number of users. Again, you will have appropriately identified your routing group boundaries. Servers with slow but resilient connections may be part of the same routing group, but it is better to keep them strictly separated to make best use of the available network bandwidth.

Why did Microsoft separate the Active Directory site and Exchange 2000 routing group topologies? Perhaps the most important reason was to prevent sudden and unexpected changes to the routing topology. If a network administrator moved an Exchange 2000 server to a different IP subnet, the server would then also change its routing group membership immediately. Yet, when you move a server between routing groups, you also move all connectors configured on this server. Thus, by moving the server—and without noticing the problem—the network administrator could actually break the routing topology. Separating the site from the routing group topology eliminates this risk. You now have to update the routing group topology manually. However, keep in mind that moving servers between sites or routing groups is not a concern when designing the routing group structure.

When determining routing group boundaries, consider the following requirements:

  • Routing groups are best mapped to Windows 2000 sites.
  • Servers within the same routing group require permanent and reliable network connections.
  • Servers within a routing group must always be able to contact the routing group master.
  • You can change the routing group boundaries at any time.
  • The routing group topology determines how users can work with public folders, which is explained in Lesson 4.

Determining Routing Group Connectors

It is not required to standardize on a single RGC in your Exchange 2000 organization. For instance, you can connect routing Group A to Group B using an X.400 connector, and Group B to Group A through an SMTP connector, and the message transfer will work fine. RGCs are unidirectional, meaning you have to create and configure them separately in every routing group.

Wherever possible, use a Routing Group connector. This connector is easy to configure and allows you to specify multiple bridgeheads, which increases the fault tolerance. The SMTP connector, on the other hand, gives you more control over the message transfer. It is a good choice if you want to implement remote-triggered message delivery, where remote servers pull queued messages from a central hub. It is also the right choice if you want to connect to a remote routing group via a foreign SMTP-based messaging system, such as a UNIX Sendmail host on the Internet. The X.400 connector is a good choice only in environments with an X.400 backbone because it is the hardest to configure.

Determining the Routing Group Topology

The challenge in designing a routing group topology is to determine how to connect the routing groups together for optimal message transfer. The worst possible choice is to create a huge connector chain, like A – B – C – D – E – F. Could it be any more indirect (and slower) to get a message from A to F?

A much better choice is to connect all routing groups directly with each other: A – B, A – C, A – D, A – E, A – F, B – A, B – C, B – D, and so forth. Unfortunately, this fully meshed model does not scale well to a large number of routing groups. Remember, you have to configure RGCs in each routing group separately, leaving you with the task of configuring 35 connectors for just 6 routing groups (A through F).

Perhaps a better architecture is the hub–spoke topology, where a central routing group assumes the role of a message switch. In the current example, this would require you to configure 10 RGCs, for instance A – B, A – C, A – D, A – E, A – F, B – A, C – A, D – A, E – A, and F – A, provided that A is the central routing group. The most significant advantage of the hub–spoke architecture is that you gain total control over the message transfer. All intergroup traffic must traverse through the central group. There is no chance for any dynamic rerouting because alternate paths between any two routing groups do not exist. The most significant disadvantage of this hierarchical routing topology is, however, that this architecture may not reflect the network infrastructure very well. For instance, routing Groups B and C may be closely located to each other, but all messages must travel through routing Group A, which may be far away. Further, if routing group A fails, all intergroup messaging will fail.

The smart routing capabilities of Exchange 2000 allow you to deploy your RGCs according to the WAN topology of your network and to optimally route messages through the physical links. Hence, if your messaging organization is too complex to establish RGCs between all routing groups, and if you do not need the total control over all message paths, create a hierarchical routing topology of fully meshed subbackbones in a global arrangement (Figure 5.10).

Figure 5.10 - A hierarchical routing topology with fully meshed subbackbones

Note


An optimal routing architecture depends on a detailed analysis of the underlying network infrastructure.

Designing a Routing Group Topology for Adventure Works

For simplicity, it is assumed that Adventure Works maintains four LANs (one in Canada, and the others in the United States, South Africa, and Australia) in a global network environment that is based on reliable VPNs over the Internet. The network connections are fast and dependable, and theoretically, Adventure Works can implement a very simple routing topology based on a single routing group. Yet, John Y. Chen is afraid that the direct server-to-server communication may overwhelm the VPN during peak hours. For this reason, Chen opted to implement a separate routing group for each geographical location. The WAN supports direct connectivity between the routing groups, so Adventure Works will deploy Routing Group connectors in a fully meshed topology, as shown in Figure 5.11.

Activity: Designing Routing Group Topologies

In this activity, you will design a message routing topology for Consolidated Messenger and another company called Litware, Inc.

Figure 5.11 - The routing group topology of Adventure Works’ Exchange 2000 organization

Tip


You can use Figure B.14 in Appendix B as a guideline to accomplish this activity.

Scenario: Consolidated Messenger

According to the explanations from Lesson 1, Consolidated Messenger has implemented two administrative groups to manage the Video department’s Exchange 2000 resources separate from the remaining messaging organization. It is now your task to outline an appropriate routing topology. Keep in mind that all resources belong to the same metropolitan area network (MAN) in Portland, Oregon. For simplicity, the MAN environment can be considered a huge LAN.

  1. How many routing groups are required in Consolidated Messenger’s Exchange 2000 organization?
  2. For political reasons, the Video department requests full control to the routing infrastructure. How would you structure the Exchange 2000 organization to give all messaging administrators of Consolidated Messenger full permissions to the routing topology?

Scenario: Litware, Inc.

Litware, Inc., is a company with 4500 employees in Washington, DC and Los Angeles. Figure 5.12 displays a high-level diagram of Litware’s WAN topology. For simplicity, it is assumed that Washington, DC and Los Angeles are LAN-like environments.

Figure 5.12 - A high-level diagram of Litware’s WAN topology

It is your task to recommend a routing group topology for efficient and reliable message transfer.

  1. How many routing groups would you implement?
  2. How many RGCs would you install for highly reliable messaging connectivity?
  3. Which RGC type would you choose to connect the routing groups?

Lesson Summary

You do not need to configure anything extra for Exchange 2000 servers to communicate with each other, but you may want to place your servers in separate routing groups to make best use of available network resources. Routing groups are areas of well-connected TCP/IP subnets. Within a routing group, servers can communicate directly with each other without wasting precious network resources. Between routing groups, communication does not take place without explicit configuration of messaging connectors. Messaging connectors allow you to concentrate message traffic over slow or unreliable connections to make better use of network links with limited bandwidth.

Messaging connectors that you can use between routing groups are the Routing Group connector, the SMTP connector, and the X.400 connector. The Routing Group connector is the most powerful and the easiest to install. The SMTP connector provides slightly more control over the message transfer. The X.400 connector is the hardest to configure and should only be used in an environment where X.400 connectivity is needed.

You also need to determine how to connect the routing groups together for optimal message transfer. Generally, you have three choices. You can create RGCs between all routing groups, which leads to a fully meshed topology. However, fully meshed structures are not suitable for environments with many routing groups because the number of RGCs quickly gets out of hand. Large organizations may therefore prefer a hierarchical routing group arrangement, but this may not perfectly reflect the underlying network infrastructure. It also prevents Exchange 2000 Server from rerouting messages because alternate paths do not exist. A third, and perhaps the most flexible, structure is a topology of hierarchically arranged, fully meshed subbackbones. Here, individual regions are grouped together in a fully meshed topology, which are then handled as units and fully meshed in the global backbone.



MCSE Microsoft Exchange 2000 Server Design and Deployment Training Kit(c) Exam 70-225
MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)
ISBN: 0735612579
EAN: 2147483647
Year: 2001
Pages: 89

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net