Routing Topology Update Communications

How Exchange communicates routing information differs depending on whether it is processing an inter-routing group update or an intra-routing group update. This section discusses how specific communication update processes work in several routing topology scenarios, as follows:

• Directory updates to routing group masters   Single Exchange server, single domain controller

• Routing group master updates to routing group members   Two Exchange servers (same routing group), one domain controller

• Inter-routing group updates   Three Exchange servers (two in one routing group, one in another routing group), one domain controller

Directory Updates to Routing Group Masters

The routing group masters receive major updates from a domain controller by means of the Microsoft Active Directory® directory service change notification process. Specifically, Exchange relies on its configuration domain controller for directory update information, which is labeled as Config on a server's properties DS Access tab in Exchange System Manager.

The change notification process begins when the client or workstation on which a new connector or another routing change has been made by using Exchange System Manager contacts the domain controller with a request to add this new connector to Active Directory. The domain controller communicates to the workstation that the addition was successful. The domain controller then notifies the Exchange server that is the routing master of this new connector and sends information about this connector through a series of communications. The following network captures illustrate this process.

The following figure shows an excerpt from a network capture involving a Windows 2000 domain controller where a new connector has been added to a routing group (Exchange 2000). Note frame 147, which shows "AddRequest".

A Windows 2000 domain controller where a new connector has been added to a routing group

This figure shows the client (Workstation) requesting that the domain controller (DC) add a new SMTP connector to the directory. Frame 148 shows the domain controller signaling the successful completion of this addition. Immediately following in frame 149 (see the following figure), the domain controller sends a "SearchResponse" to the Exchange server that notifies Exchange of the new connector.

The domain controller automatically performs this seemingly unsolicited action because the Exchange server has previously signed up for change notification, as all Exchange 2000 and Exchange 2003 servers do. This illustrates the change notification process at work. Within frame 149, the domain controller is only informing Exchange of the name and distinguished name of the new connector.

The domain controller sends a "SearchResponse" message to the Exchange server that notifies Exchange of the new connector

In frames 150 and 151, the domain controller sends more information regarding this addition to both the workstation on which this connector was added and the Exchange server. The following figure illustrates Frame 151 (sent to Exchange). In addition to the name of the object and the distinguishedname, the objectGUID, cn, and objectClass attributes are now included.

The domain controller sends more information regarding this addition to both the workstation on which this connector was added and the Exchange server

After the domain controller sends this information, the workstation queries the domain controller for the full list of attributes regarding the new connector.

In frame 176 (see the following figure), Exchange initiates queries regarding its routing group. Whenever a change notification has been received by the Exchange server, it initiates these actions. In particular, it begins by querying for the distinguished name of the routing group GUID.

Exchange initiates queries regarding its routing group

After receiving the distinguished name of the routing group GUID, Exchange queries for all attributes of any child objects that this object may be a parent to and that are of the object type "msExchconnector". Note the "Single Level" scope of the search versus "Base object" search. This designation indicates that the search is for a child object. Frame 182 (see the following figure) shows this search request.

Search request for a child object

Frame 183 (see the following figure) indicates the partial response from the domain controller.

Partial response from the domain controller

Next, Exchange queries the domain controller and receives the following:

• The FQDN and GUID for any bridgehead server that is associated with the connector in question.

• A query for several attributes of the new connector. This query is based on the GUID of the connector, and it returns the result that is illustrated in the following figure.

  Result of a query for attributes of a new connector

  

As shown in the following figure, the Exchange server sends a "ModifyRequest" message asking the domain controller to replace three attributes of the "legacy GWART" object within the administrative group : GatewayRoutingTree, GWARTLastModified, and ridServer.

Request from the Exchange server to the domain controller to replace three attributes of the "legacy GWART" object

The domain controller responds with a "ModifyResponse" message of success, and the Exchange server continues its query process for various objects within its administrative group.

The entire process that is described in this section shows how domain controllers communicate major topology updates to routing group masters. Following this update, the routing group master must now communicate the information to its member servers. The following section explains how the routing group master communicates this information to its routing group members.

Routing Group Master Updates to Routing Group Members

When the routing group master is informed of an update, it overwrites the link state information that it contains in memory (the OrgInfo packet) with the new information, creating a new MD5 hash based on this information. The routing group master then propagates the new OrgInfo packet to client nodes on the same computer and to subordinate services nodes or routing group members within the routing group. The routing group master communicates with the routing group over TCP port 691.

The following figure illustrates communication occurring on either source or destination port 691. The example illustrates a new connector's addition to a routing group containing two servers.

Routing group master propagates update information to routing group members

Frame 175 is the "SearchResponse" that a domain controller sends to the routing group master that is registered for change notification. Immediately after receiving this information, the routing group master sends the entire OrgInfo packet to the routing group member, as shown in Frame 176 (Figure 15.11). The characters before the first parenthesis in this packet represent the MD5 hash of the OrgInfo packet, which servers use to determine if they have the most up-to-date information.

Because the MD5 hash that it received is different than the hash in memory, the routing group member also processes the OrgInfo packet. After making the appropriate changes to its link state table in memory, the routing group member sends a short reply to the routing group master, followed in the next frame by its newly revised OrgInfo packet, now also referencing the newer MD5 hash that the routing group master sent earlier. The following figure shows the initial reply.

Initial reply from routing group member to routing group master

The OrgInfo reply from the routing group member containing the now up-to-date OrgInfo packet is sent next to the routing group master (see the following figure).

OrgInfo reply from the routing group member

The routing group master processes this information and sends a short acknowledgement to the routing group member.

This process occurs between all routing group members and the routing group master within the particular routing group. Another process, known as polling, ensures that all routing group members have the most up-to-date information from the routing group master.

Polling

Polling is the process of a routing group member querying the routing group master for up-to-date routing information. The following figure illustrates the routing group member polling the routing group master every 5 minutes. Note the time that is associated with each frame (the capture was saved as filtered for communications only over port 691; therefore, the frame numbers that are listed do not reflect the original frame numbers).

Routing group member polling the routing group master

Each two-frame exchange includes the text "Simple_Poll" from the routing group member, and a response from the routing group master. Frame 1 shows the query (see the following figure).

Query from routing group member to routing group master

Frame 2 shows the response (see the following figure).

Response from routing group master to routing group member

In addition to updating the local routing group, the routing group master must update the remaining members of the Exchange organization. The Exchange SMTP service accomplishes inter-routing group updates.

How Updates Are Communicated in an SMTP Conversation

Routing and link state update communications are part of the Exchange Server  2003 and Exchange 2000 SMTP service. The Exchange SMTP service compares the versions of the OrgInfo packet on each server during every SMTP session between two servers. Whether this is an intra-routing group or an inter-routing group has no effect on this process. The process works in the following way:

1. Server 1 initiates the TCP session and contacts Server 2 using SMTP. Server 2 sends a "220 Ready" response to Server 1.

2. Server 1 sends the EHLO command.

3. Server 2 answers with "250" and a list of its implemented ESMTP commands.

4. Server 1 responds with "X-EXPS GSS API" signaling it wants to authenticate by means of the GSS API.

5. Server 2 responds with "334 GSSAPI supported".

6. The next several frames involve the authentication between the two servers, ending with Server 2 responding "235 2.7.0 Authentication successful".

7. After this response, link state communications begin.

8. Server 1 sends the information shown in the following figure to Server 2:

   Information sent from Server 1 to Server 2

   

   The following information is contained in the information sent from Server 1:

   • X-LINK2STATE indicates that this packet contains information pertaining to the organizational routing topology.

   • LAST CHUNK indicates that this will be the last frame of link state communications within the current SMTP session. Other options for this command are:

     - FIRST CHUNK   Indicates that the link state information to follow is spread across several frames, with this frame being the first frame.

     - NEXT CHUNK   Indicates that the link state information to follow is spread across several frames, with this frame being neither the first nor the last frame.

9. Server 2 now compares its MD5 hash to the MD5 hash that Server 1 sent, and one of two actions occurs:

   • If the hashes are identical, Server 2 does not need to receive the complete OrgInfo packet from Server 1. Therefore, Server 2 sends a "DONE_RESPONSE" (see the following figure), and Server 1 sends the "MAIL FROM:" command and completes the process of sending the mail message.

     "Done_Response" sent from Server 2 to Server 1

     

   • If Server 2 does not have the same hash as Server 1, Server 2 sends its entire OrgInfo packet to Server 1 in a process that is similar to the one in which Server 1 sent its information to Server 1. The next section describes this process in the context of inter-routing group updates.

Inter-Routing Group Updates

When a major or minor update occurs within a routing group, the local bridgehead servers that are connected to other routing groups propagate the update to their attached routing groups over SMTP on TCP port 25.

Frames 485-487 (see the following figure) contain the complete OrgInfo packet that is being transmitted from the routing group master to the routing group member that is the local bridgehead server. Frame 488 shows the local bridgehead server's acknowledgement.

Transmission of OrgInfo packet from routing group master to routing group member that is the local bridgehead server

In Frames 489 and 490 (see the following figure), the local bridgehead server queries Active Directory for attributes of the default recipient policy, which is the only recipient policy that existed in the example environment.

Query from local bridgehead server to Active Directory

After having received the responses in Frames 491-494, Frame 495 (see the following figure) shows the local bridgehead server now performing a subtree search on the configuration container for any routing group of which it is a bridgehead (note the "LDAP: Filter Type").

Search by local bridgehead server for routing groups of which it is a bridgehead

After receiving the response, the local bridgehead server now starts to query DNS for the Exchange server in the remote routing group and sets up a TCP session with this remote bridgehead server.

The local bridgehead server proceeds through the steps that were explained in "How Updates Are Communicated in an SMTP Conversation," earlier in this topic. The process is as follows:

1. When the servers compare MD5 hashes, the remote bridgehead server realizes it does not have the same hash as the local bridgehead server, and sends its entire OrgInfo packet to the local bridgehead server. Because this communication occurs by using SMTP, and the SMTP Request For Comments (RFCs) stipulate that any one SMTP data command may not exceed 1 KB in size, it is likely that the OrgInfo packet will be split into several frames. In this situation, the SMTP service uses the various CHUNK commands illustrated in the following figure.

   Use of FIRST_CHUNK command

   

2. The local bridgehead server responds with "X-LINK2STATE MORE" (see the following figure).

   Local bridgehead server response to remote bridgehead server

   

3. The remote bridgehead server sends the next portion of the OrgInfo packet (see the following figure). Note that it just signals "CHUNK":

   Remote bridgehead server response to local bridgehead server

   

4. The remote bridgehead server again responds with "X-LINK2STATE MORE". This communication continues until the remote bridgehead server sends the last portion of the OrgInfo packet, which it signals by using the LAST_CHUNK command (see the following figure).

   Remote bridgehead server signals by using the LAST_CHUNK command that it is sending the last portion of the OrgInfo packet

   

5. After this communication process is complete, the remote and local bridgehead servers reverse roles. After its receipt of the LAST_CHUNK frame from the remote bridgehead server, the local bridgehead server immediately sends a FIRST_CHUNK frame (identifying the start of transmission of its OrgInfo packet) to the remote bridgehead server.

6. After completing the identical process in exchanging the OrgInfo information, the remote bridgehead server responds with a "200 Done" command (see the following figure) after it receives the LAST_CHUNK command.

   Remote bridgehead server signals that it has received the OrgInfo packet in its entirety

   

7. The local bridgehead server now issues the "Quit" command, and the remote bridgehead server acknowledges its receipt by closing the SMTP transmission channel.