Comunicaciones de las actualizaciones de la topología de enrutamiento

Última modificación del tema: 2005-10-23

La forma en que Exchange comunica la información de enrutamiento varía dependiendo de si está procesando una actualización entre grupos de enrutamiento o dentro de un grupo de enrutamiento. En esta sección se describen los procesos de comunicación de las actualizaciones en varias situaciones de topología de enrutamiento, como sigue:

• Actualizaciones del directorio a maestros de grupo de enrutamiento   Un único servidor de Exchange, un único controlador de dominio
• Actualizaciones de maestros de grupo de enrutamiento a miembros de grupo de enrutamiento   Dos servidores de Exchange (el mismo grupo de enrutamiento), un controlador de dominio
• Actualizaciones entre grupos de enrutamiento   Tres servidores de Exchange (dos en un grupo de enrutamiento, uno en otro grupo de enrutamiento), un controlador de dominio

Actualizaciones del directorio a maestros de grupo de enrutamiento

Los maestros de grupos de enrutamiento reciben las actualizaciones principales de un controlador de dominio mediante el proceso de notificación de cambios del servicio de directorio Microsoft Active Directory®. En concreto, Exchange utiliza su controlador de dominio de configuración para la información de actualización del directorio, que aparece como Config en la ficha Acceso al directorio de las propiedades de un servidor en el Administrador del sistema de Exchange.

El proceso de notificación de cambios empieza cuando el cliente o la estación de trabajo donde se ha agregado un conector nuevo o donde se ha realizado otro cambio en el enrutamiento mediante el Administrador del sistema de Exchange se pone en contacto con el controlador de dominio para pedir que se agregue este nuevo conector a Active Directory. El controlador de dominio comunica a la estación de trabajo que se agregó correctamente. Entonces, el controlador de dominio notifica al servidor de Exchange que es el maestro de enrutamiento de este nuevo conector y envía información acerca de este conector mediante una serie de comunicaciones. La siguiente captura de red ilustra este proceso.

La siguiente ilustración muestra un extracto de una captura de red con un controlador de dominio de Windows 2000 donde se ha agregado un conector nuevo a un grupo de enrutamiento (Exchange 2000). Observe la trama 147, que muestra "AddRequest".

La siguiente ilustración muestra el cliente (Workstation) que solicita que el controlador de dominio (DC) agregue un nuevo conector para SMTP al directorio. La trama 148 muestra el controlador de dominio que señala que se agregó correctamente. Inmediatamente después, en la trama 149 (vea la ilustración siguiente), el controlador de dominio envía "SearchResponse" al servidor de Exchange para notificar a Exchange la presencia del nuevo conector.

El controlador de dominio realiza automáticamente esta acción no solicitada porque el servidor de Exchange había pedido previamente que se le notificaran los cambios, como hacen todos los servidores de Exchange 2000 y Exchange 2003. Esto ilustra el funcionamiento del proceso de notificación de cambios. Dentro de la trama 149, el controlador de dominio sólo está informando a Exchange del nombre y el nombre completo del nuevo conector.

En las tramas 150 y 151, el controlador de dominio envía más información sobre esta incorporación tanto a la estación de trabajo a la que se agregó este conector como al servidor de Exchange. La siguiente ilustración muestra la trama 151 (enviada a Exchange). Además del nombre del objeto, ahora se incluyen los atributos distinguishedname, objectGUID, cn y objectClass.

Cuando el controlador de dominio envía esta información, la estación de trabajo consulta al controlador de dominio toda la lista de atributos del nuevo conector.

En la trama 176 (vea la ilustración siguiente), Exchange inicia consultas sobre su grupo de enrutamiento. Siempre que el servidor de Exchange recibe una notificación de cambios, inicia estas acciones. En particular, empieza por consultar el nombre completo del GUID del grupo de enrutamiento.

Después de recibir el nombre completo del GUID del grupo de enrutamiento, Exchange consulta todos los atributos de los objetos secundarios de los que este objeto pueda ser primario y que sean del tipo de objeto “msExchconnector”. Observe el ámbito "Single Level" (un único nivel) de la búsqueda frente a la búsqueda "Base object" (objeto base). Esta designación indica que se trata de una búsqueda de un objeto secundario. La trama 182 (vea la ilustración siguiente) muestra esta solicitud de búsqueda.

La trama 183 (vea la ilustración siguiente) indica la respuesta parcial del controlador de dominio.

Después, Exchange consulta el controlador de dominio y recibe lo siguiente:

• El FQDN y el GUID de todos los servidores cabeza de puente asociados al conector en cuestión.
• Una consulta de varios atributos del nuevo conector. Esta consulta se basa en el GUID del conector y devuelve el resultado que se muestra en la ilustración siguiente.
  

Como se muestra en la siguiente figura, el servidor de Exchange envía un mensaje “ModifyRequest” solicitando que el controlador de dominio reemplace tres atributos del objeto “legacy GWART” dentro del grupo administrativo: GatewayRoutingTree, GWARTLastModified y ridServer.

El controlador de dominio responde con un mensaje "ModifyResponse" de éxito y el servidor de Exchange continúa su proceso de consulta para varios objetos dentro de su grupo administrativo.

Todo el proceso descrito en esta sección muestra cómo los controladores de dominio comunican las actualizaciones principales de la topología a los maestros de grupo de enrutamiento. Después de esta actualización, el maestro del grupo de enrutamiento debe comunicar ahora la información a sus servidores miembro. En la próxima sección se explica cómo el maestro del grupo de enrutamiento comunica esta información a los miembros de su grupo.

Actualizaciones de maestros de grupo de enrutamiento a miembros de grupo de enrutamiento

Cuando se informa de una actualización al maestro del grupo de enrutamiento, éste sobrescribe la información de estado de los vínculos que contiene en memoria (el paquete OrgInfo) con la nueva información, creando un nuevo hash MD5 basándose en esta información. El maestro del grupo de enrutamiento propaga entonces el nuevo paquete OrgInfo a los nodos cliente del mismo equipo y a los nodos de servicios subordinados o a los miembros del grupo de enrutamiento. El maestro del grupo de enrutamiento se comunica con el grupo a través del puerto TCP 691.

La ilustración siguiente muestra la comunicación que tiene lugar en el puerto 691 de origen o de destino. El ejemplo ilustra que se ha agregado un nuevo conector a un grupo de enrutamiento que contiene dos servidores.

La trama 175 es el mensaje "SearchResponse" que un controlador de dominio envía al maestro del grupo de enrutamiento registrado para recibir notificaciones de cambios. Inmediatamente después de recibir esta información, el maestro del grupo de enrutamiento envía todo el paquete OrgInfo al miembro del grupo, como se muestra en la trama 176 (Figura 15.11). Los caracteres que hay delante del primer paréntesis en este paquete representan el hash MD5 del paquete OrgInfo, que los servidores utilizan para determinar si tienen la información más actualizada.

Como el hash MD5 que ha recibido es distinto del que tiene en memoria, el miembro del grupo de enrutamiento también procesa el paquete OrgInfo. Después de hacer los cambios apropiados en la tabla de estado de los vínculos que tiene en memoria, el miembro del grupo de enrutamiento envía una breve respuesta al maestro del grupo, seguida en la próxima trama por el paquete OrgInfo recién revisado, que ahora hace referencia también al hash MD5 más reciente que el maestro del grupo de enrutamiento envió anteriormente. La ilustración siguiente muestra la respuesta inicial.

La respuesta OrgInfo del miembro del grupo de enrutamiento que contiene el paquete OrgInfo actualizado se envía después al maestro del grupo (vea la ilustración siguiente).

El maestro del grupo de enrutamiento procesa esta información y envía un breve acuse de recibo al miembro del grupo.

Este proceso tiene lugar entre todos los miembros del grupo de enrutamiento y el maestro dentro de un mismo grupo. Otro proceso, conocido como sondeo, garantiza que todos los miembros del grupo de enrutamiento tengan la información más actualizada del maestro del grupo.

Sondeo

El sondeo es el proceso por el cual un miembro de un grupo de enrutamiento consulta al maestro del grupo para ver si hay información de enrutamiento actualizada. La ilustración siguiente muestra el sondeo que el miembro del grupo de enrutamiento realiza al maestro cada 5 minutos. Observe el tiempo asociado a cada trama (la captura se guardó filtrada para ver únicamente las comunicaciones realizadas por el puerto 691; por tanto, los números de trama mostrados no reflejan los números de trama originales).

Cada intercambio de dos tramas incluye el texto "Simple_Poll" del miembro del grupo de enrutamiento y una respuesta del maestro del grupo. La trama 1 muestra la consulta (vea la ilustración siguiente).

La trama 2 muestra la respuesta (vea la ilustración siguiente).

Además de actualizar el grupo de enrutamiento local, el maestro del grupo debe actualizar los miembros restantes de la organización de Exchange. El servicio SMTP de Exchange realiza actualizaciones entre grupos de enrutamiento.

Cómo se comunican las actualizaciones en una conversación SMTP

Las comunicaciones de las actualizaciones en el enrutamiento y en el estado de los vínculos forman parte del servicio SMTP de Exchange Server  2003 y Exchange 2000. El servicio SMTP de Exchange compara las versiones del paquete OrgInfo de cada servidor durante cada sesión SMTP entre dos servidores. El hecho de que sea dentro de un mismo grupo de enrutamiento o entre grupos de enrutamiento diferentes no tiene ningún efecto sobre este proceso. El proceso funciona de la manera siguiente:

1. El servidor 1 inicia la sesión TCP y se pone en contacto con el servidor 2 mediante SMTP. El servidor 2 envía una respuesta "220 Ready" al servidor 1.
2. El servidor 1 envía el comando EHLO.
3. El servidor 2 responde con "250" y una lista de sus comandos ESMTP implementados.
4. El servidor 1 responde con "X-EXPS GSS API", lo que indica que desea autenticarse mediante la API GSS.
5. El servidor 2 responde con "334 GSSAPI supported".
6. Las tramas siguientes corresponden a la autenticación entre los dos servidores y terminan cuando el servidor 2 responde "235 2.7.0 Authentication successful" (autenticación correcta).
7. Después de esta respuesta empiezan las comunicaciones del estado de los vínculos.
8. El servidor 1 envía al servidor 2 la información que se muestra en la ilustración siguiente:
   
   La información enviada por el servidor 1 incluye lo siguiente:
   • X-LINK2STATE indica que este paquete contiene información relativa a la topología de enrutamiento de la organización.
   • LAST CHUNK indica que ésta será la última trama de las comunicaciones de estado de los vínculos dentro de la sesión SMTP actual. Hay otras opciones posibles para este comando:
     - FIRST CHUNK   Indica que la información de estado de los vínculos que sigue ocupa varias tramas, siendo ésta la primera de ellas.
     - NEXT CHUNK   Indica que la información de estado de los vínculos que sigue ocupa varias tramas y ésta no es la primera ni la última de ellas.
9. El servidor 2 compara ahora su hash MD5 con el hash MD5 que envió el servidor 1 y tiene lugar una de dos acciones posibles:
   • Si los hashes son idénticos, el servidor 2 no necesita recibir todo el paquete OrgInfo del servidor 1. Por tanto, el servidor 2 envía "DONE_RESPONSE" (vea la ilustración siguiente), y el servidor 1 envía el comando "MAIL FROM:" y completa el proceso de envío del mensaje de correo.
     
   • Si el servidor 2 no tiene el mismo hash que el servidor 1, el servidor 2 envía todo su paquete OrgInfo al servidor 1 mediante un proceso similar al empleado por el servidor 1 para enviar su información al servidor 2. En la próxima sección se describe este proceso en el contexto de las actualizaciones entre grupos de enrutamiento.

Actualizaciones entre grupos de enrutamiento

Cuando tiene lugar una actualización principal o secundaria dentro de un grupo de enrutamiento, los servidores cabeza de puente locales que están conectados a otros grupos de enrutamiento propagan la actualización a sus grupos conectados a través de SMTP en el puerto TCP 25.

Las tramas 485 a 487 (vea la ilustración siguiente) contienen el paquete OrgInfo entero que se transmite desde el maestro del grupo de enrutamiento al miembro del grupo que es el servidor cabeza de puente local. La trama 488 muestra el acuse de recibo del servidor cabeza de puente local.

En las tramas 489 y 490 (vea la ilustración siguiente), el servidor cabeza de puente local consulta en Active Directory los atributos de la directiva de destinatarios predeterminada, que es la única que existía en el entorno de ejemplo.

Después de haber recibido las respuestas de las tramas 491 a 494, la trama 495 (vea la ilustración siguiente) muestra ahora que el servidor cabeza de puente local realiza una búsqueda en los subárboles del contenedor de configuración para encontrar cualquier grupo de enrutamiento que sea cabeza de puente (observe "LDAP: Filter Type").

Cuando recibe la respuesta, el servidor cabeza de puente local empieza ahora a consultar DNS para el servidor de Exchange del grupo de enrutamiento remoto y establece una sesión TCP con este servidor cabeza de puente remoto.

El servidor cabeza de puente local continúa con los pasos que se explicaron en "Cómo se comunican las actualizaciones en una conversación SMTP", anteriormente en este tema. El proceso es el siguiente:

1. Cuando los servidores comparan los hashes MD5, el servidor cabeza de puente remoto se da cuenta de que no tiene el mismo hash que el servidor cabeza de puente local y le envía todo su paquete OrgInfo. Como esta comunicación se realiza mediante SMTP, y los Request For Comments (RFC) de SMTP estipulan que cualquier comando de datos SMTP no puede tener un tamaño de más de 1 KB, es probable que el paquete OrgInfo se divida en varias tramas. En esta situación, el servicio SMTP utiliza los diversos comandos CHUNK que se muestran en la ilustración siguiente.
   
2. El servidor cabeza de puente local responde con "X-LINK2STATE MORE" (vea la ilustración siguiente).
   
3. El servidor cabeza de puente remoto envía la siguiente parte del paquete OrgInfo (vea la ilustración siguiente). Observe que sólo indica "CHUNK":
   
4. El servidor cabeza de puente remoto vuelve a responder con "X-LINK2STATE MORE". Esta comunicación continúa hasta que el servidor cabeza de puente remoto envía la última parte del paquete OrgInfo, que se indica mediante el comando LAST_CHUNK (vea la ilustración siguiente).
   
5. Una vez completado este proceso de comunicación, los servidores cabeza de puente remoto y local invierten sus papeles. Después de recibir la trama LAST_CHUNK del servidor cabeza de puente remoto, el servidor cabeza de puente local envía inmediatamente una trama FIRST_CHUNK (que identifica el comienzo de la transmisión de su paquete OrgInfo) al servidor cabeza de puente remoto.
6. Cuando se ha completado el proceso idéntico para el intercambio de la información de OrgInfo, el servidor cabeza de puente remoto responde con un comando "200 Done" (vea la ilustración siguiente) después de recibir el comando LAST_CHUNK.
   
7. El servidor cabeza de puente local emite ahora el comando "Quit" y el servidor cabeza de puente remoto acusa recibo de su recepción cerrando el canal de transmisión SMTP.