Common Routing Topologies

 

This topic discusses two commonly deployed messaging topologies:

  • A centralized messaging topology in which all servers have full-mesh connectivity and communicate point-to-point.

  • A distributed messaging topology in which a single hub or data center connects to numerous branch office sites.

Centralized Messaging Topology

In a centralized messaging topology, you have a single data center or hub site in which all servers are connected by high-speed, reliable bandwidth. Even if this site spans a large geographical area, as long as all your servers are connected by the same reliable bandwidth, you can use a single routing group.

The advantages of a centralized messaging topology include ease of administration and more efficient mail flow because all servers communicate in a point-to-point manner.

However, if you have some servers in a central location that are connected by a slower network, it is best to group these servers in a separate routing group. One server with unreliable network connectivity in a single routing group can generate link state traffic. Because all other servers need to be notified if this server or a routing group connector on this server becomes unavailable, the routing group master (the server that is responsible for communicating information about the routing topology to servers within a routing group) must propagate changes in this server's status to all the servers in the routing group. For more information about the routing group master, see Designating a Routing Group Master.

Distributed Messaging Topology

In a branch office or distributed messaging topology, typically one or more data centers are connected to several smaller branch office locations using a hub-and-spoke network design. In this scenario, your servers in the central hub are grouped together in a single routing group where all servers have reliable network connectivity. Each branch office location constitutes its own routing group.

Generally, in the central hub site, you have dedicated bridgehead servers that connect to the branch office routing groups. These routing groups are often leaf-noderouting groups, that is, routing groups that have only a single inbound routing group connector and a single outbound routing group connector in exact opposite connections. No other connectors can exist in a leaf-node routing group.

There are three possible configurations for a leaf-node routing group:

  • A routing group with an inbound connector to a single routing group and no outbound connectors.

  • A routing group with an outbound connector to a single routing group and no inbound connectors.

  • A routing group with an outbound connector to a single routing group. See the figure for examples of leaf-node routing groups.

In Exchange Server 2003, if no alternate path exists for a connector connecting to or from a leaf-node routing group, the connector state is always marked as "up" (in service). Exchange Server 2003 no longer changes the connector state to "down" (unavailable) if no alternate path exists. Instead, Exchange queues mail for delivery and sends it when the route becomes available. This change enhances performance because it reduces the propagation of link state information, which is particularly relevant in a distributed messaging environment where a hub-and-spoke topology is used. Consider that you have a single routing group connector connecting the remote site, a leaf-node routing group to the hub, and another routing group connector connecting the hub to the remote site. If the routing group connector becomes unavailable at either the hub or the remote site, messages queue until the connector becomes available. No link state traffic is generated, and the network is not affected.

The following figure illustrates a distributed messaging topology in a typical hub-and-spoke configuration. In this topology, each physical site maps to a routing group. In the central site, all servers are in one routing group and communicate point to point. Because each of the remote office sites has only one available route to the central site, if a connector is unavailable in a remote site, mail queues until it becomes available and no link state changes are propagated.

Distributed messaging topology in a typical hub-and-spoke configuration

bf7e4990-11e0-47d1-84fe-f391514f92b4