Exchange Routing mit GWART und LinkState

Jedes Vermittlungssystem zur Übertragung von Daten muss einen Mechanismus zur Steuerung des Datenflusses implementieren. Dabei muss es folgende Fragen klären:

  • Wegefindung
    Gerade wenn zwischen Start und Endpunkt mehrere Zwischenstationen sind, muss das System ja irgendwie den nächsten "Hop" finden.
  • Kosten und Beschränkungen (Bandbreite, Personen, Größe)
    Für die Bestimmung des optimalen Wegs muss natürlich auch die verfügbare Bandbreite und die Kosten für die Datenübertragung in die Ermittlung eingehen. Gerade für Mail kann es natürlich sinnvoll sein, bestimmte Wege nur für bestimmte Nachrichten zuzulassen, z.B.: abhängig von der die Größe oder dem Absender. Dies schlägt sich ebenfalls in den Kosten je Weg nieder.
  • Ausfallsicherung
    Die Verfügbarkeit einer Verbindungen kann nie 100% gesichert werden. Daher muss ein Produkt auch Ausfälle erkennen oder zumindest damit geregelt umgehen können. Es kann dann alternative Wege nutzen, muss hier dann aber Schleifen vermeiden oder die Mail einfach liegen lassen, bis die Verbindung wird verfügbar ist.

Entsprechende Mechanismen sind auch in Exchange wieder zu finden und schon seit Exchange 4.0 implementiert. Das Routing von Exchange hat auch einen Namen:

  • GWART
    Diese Verfahren wurde von Exchange 4.0 bis Exchange 5.5 genutzt
  • Link2State
    Diese Verfahren wurde von Exchange 2000 und 2003 genutzt
  • IP-Routing
    Exchange 2007 nutzt einfach die Infrastruktur des Active Directory und der darunter liegenden TCP/IP-Verbindungen und vertraut darauf, dass diese den "günstigsten" Leitweg nutzen.

Schauen wir uns die verschiedenen Verfahren etwas im Detail an

GWART

GWART ist die Kurzform von "Gateway-Adressroutingtabelle" und bezeichnet eine Tabelle, die jeder Server für sich pflegt. Die Tabelle enthält einfach nur die Ziele mit deren Wegen und die Kosten.

Exchange 5.5 führt aber keinen Status mit, d.h. prüft nicht aktiv, ob eine Verbindung funktionstüchtig ist oder nicht. Exchange 5.5 liest nur zu den vorgegebenen Zeiten die im Verzeichnis konfigurierten Connectoren und deren Kosten und Adressräume und ermittelt daraus eine statische Routingtabelle.

Das Problem dabei ist z.B.: in einer gemischten Umgebung, wenn zwei Exchange 2000/2003 Routinggruppen über zwei Exchange 5.5 Server verbunden sind. Exchange 2000/2003 muss dann davon ausgehen, dass die Verbindung immer besteht, da Exchange 5.5 eben keinen Verbindungsstatus pflegt.

Den Zeitpunkt des Neuaufbaus können Sie im Exchange Administrator In der "Standortkonfiguration" des jeweiligen Standortes konfigurieren.

Normalerweise ist die einmalige Berechnung in der Nacht bei Exchange 5.5 ausreichend. Die Konfiguration von Connectoren ändert sich ja in der Regel nur selten und ist entsprechend statisch. Bei einer Migration mit schneller Installation von Exchange 2000/2003-Servern kann es aber schon einmal wünschenswert sein, diesen Prozess häufiger zu starten.

Auf der nächsten Karteikarte finden Sie dazu dann nicht nur die Routingtabelle, um das Ergebnis zu begutachten, sondern auch einen Button um eine sofortige Neuberechnung zu erreichen.

Das Beispiel hier zeigt nur einen SMTP-Connector am gleichen Standort. Wenn Sie mehrere Standorte haben, dann sehen Sie hier natürlich sowohl die Connectoren zwischen den Standorten, X.400 Connectoren und SMTP-Connectoren an anderen Standorten und natürlich auch Connectoren zu Fremdsystemen wie FAX, SMS etc

Link State Routing

Link State Routing muss bei einem gemischten Betrieb von Exchange 2000/2003 und Exchange 2007 deaktiviert werden, um Nachrichtenschleifen und andere Probleme zu verhindern.

Die statische Funktion von Exchange 4.0 bis 5.5 bedeutet natürlich, dass bei einem Ausfall einer Verbindung der Administrator manuell eingreifen muss und selbst dann das Problem noch nicht gelöst sein kann. Denn auch diese Änderungen passieren im Verzeichnis des Standortes, die als Mail zu den anderen Standorten erst repliziert werden müssen. Exchange 2000/2003 hat daher die Funktion durch ein neues Routingprotokoll erweitert.

Die verschiedenen Connectoren stehen diesmal aber Active Directory, welches losgelöst eigenen Replikationsvorgaben folgt.  Aber die Exchange Server fragen nicht nur diese Informationen ab,  sondern tauschen auch untereinander den Status der Connectoren ab. Dazu sprechen alle Server einer Routinggruppe mit dem Routinggruppenmaster und melden ihm alle Änderungen , von denen Sie Kenntnis erhalten und beziehen von ihm die Aktualisierungen anderer Server.

Über die Routinggruppenconnectoren selbst gleichen sich die Server ebenfalls an. Mit jeder Mail wird als Teil des SMTP-Handshake wird auch ein "Link-Status" mit übertragen, der von dem Empfänger ausgewertet wird. So weiß nach kurzer Zeit jeder Exchange Server in der gesamten Organisation unabhängig von der Replikation des Active Directory den Status aller Connectoren.

Basierend auf diesen Informationen ermittelt die Routingengine dann, was die nächste Station zum Ziel ist. Dabei bewertet die Routingengine auch die Faktoren der Kosten und etwaige Beschränkungen. Sollte es aktuell keinen gültigen Weg geben, dann bleibt die Mail auf dem Server, bis eine Verbindung möglich ist.

Den Status der aktuellen Connectoren sehen Sie am besten mit dem Programm WINROUTE, welches direkt die Routingengine des Exchange Servers befragt. Im Exchange System Manager selbst gibt es aber auch eine Ansicht, die ihnen einen Überblick über die Connectoren und deren Status gibt. Beim Zubehör gibt es dazu die Statusanzeige, die neben den Servern und deren Diensten auch die Connectoren anzeigt.

Hier sehen Sie zwei Connectoren (SMTP Connector und Entwicklung) welche einen Status melden. Nicht alle Connectoren werden jedoch von der Exchange Routingengine berücksichtigt. So ist ein Fax-Connector, welcher nicht die Microsoft SMTP-Server nutzt, im Status nicht sichtbar. In Winroute hingegen ist er samt Kosten, Adressraum und auch Status erkennbar:

Merken Sie sich daher, dass Exchange 2000/2003 einen Status über jeden Connector mitführt und diesen auch zwischen den Server einer Routinggruppe und über Connectoren hinweg sehr zügig mit allen anderen Servern austauscht. Somit kann jeder Server anhand der Konfiguration im Active Directory und dem Status des Connectors den Leitweg berechnen.

Thoughts on Stale Link State information (Part 1)
http://blogs.msdn.com/exchange/archive/2004/03/10/87622.aspx
When a Routing Group Member discovers a down link or a change in the link state that needs to be made, it will send that information to the local Routing Group Master. The local Routing Group Master is able to make changes to its Link State information and propagate those changes to all Members of their local Routing Group (via port 691) and also to other Routing Groups (via port 25.

Es soll nicht verschwiegen werden, dass auch dieses Verfahren dennoch seine Schwächen hat, z.B. wenn Connectoren oszillieren oder sich der Status anderweitig sehr oft ändert und es entsprechend lange Wege von Quelle zu Ziel gibt. Es kann hierbei dann durchaus passieren, das Mails mehrfach übertragen werden oder in Schleifen laufen oder gar nicht erst die Quelle verlassen.

Das Problem von Exchange 5.5, dass Nachrichten immer los gesendet wurden und letztlich am Problempunkt sich dann um so mehr gestaut haben, wurde bei Exchange 2000/2003 zwar gelöst, aber nun kann es passieren, dass Nachrichten nicht mal eine Teilstrecke zurücklegen.

Ein ganz anderes Problem ist, dass Link State Routing von Exchange nicht bei allen Verbindungen genutzt wird. In folgenden vier Fällen ist LinkState deaktiviert, d.h. der Connector ist "nie" Down, auch wenn er nicht funktioniert:

  • SMTP-Connector: DNS für Mailversand
    Überträgt ein SMTP-Connector die Nachrichten an viele andere Gegenstellen, die er per DNS auflöst, dann ist die Nichterreichbarkeit einer einzigen Gegenstelle natürlich kein Grund, den Connector komplette "down" zu kennzeichnen. Leider erkennt der SMTP-Connector aber nicht, wenn keine Gegenstelle erreichbar ist, weil z.B. ein Router "down" ist.
    Das Problem ist nicht vorhanden, wenn Sie die Mails an einen Smarthost weitergeben
  • Conenctoren mit kürzlich geänderten Smarthosts
    Aber auch Connectoren mit einem Smarthost können für einige Zeit für LinkState deaktiviert sein. Exchange scheint wohl LinkState nach einer Änderung des Smarthosts erst nach eingier Zeit
  • Routinggroupconnector: Source = ANY
    Aus mir nicht weiter verständlichen Gründen ist LinkState auf einem Routinggroupconnector deaktiviert, wenn als "Sourcebridgehead" jeder Server in der Routinggruppe zugelassen wird. Nur wenn Sie explizit die Sourcebrigedeheads aufführen (auch wenn dies alle sind), ist LinkState aktiv.
  • Exchange 5.5 und EDK-Connectoren
    Diese "alten" Connectoren unterstützen überhaupt kein LinkState Routing und sind daher per Default immer "Up"
  • Exchange 5.5 als Bridgehead
    Weiterhin wird auf jedem Connector das LinkState deaktiviert, wenn ein Exchange 5.5 Server noch als Bridgehead mit aufgeführt wird. Daher ist das ein Grund möglichst schnell die Connectoren auch umzustellen.
  • Exchange 2007
    Exchange 2007 unterstütze kein LinkState Routing mehr.

Sie sollten sich daher nie allein auf das LinkState von Exchange 2000/2003 verlassen, denn allzu oft ist ein Connector nicht mehr funktionsfähig aber mangels aktivem Status werden weiterhin Nachrichten in diese Richtung gesendet und warten auf ihre Übertragung. Dies können Sie zuverlässig nur durch ein aktives Monitoring der Warteschlangen überwachen.

Exchange 2007 Routing auf IP-Routing

Der Ansatz der GWART hat ebenso seine Probleme wie das LinkStateRouting von Exchange 2000/2003. Daher wurde mit Exchange 2007 das Routing erneut geändert. Vielleicht wird das Verständlich, wenn ich einen Vergleich zum Automobil und dem Urlaubsverkehr ziehe:

  • Die Exchange 5.5 Lösung
    Sie fahren mit dem Auto wie geplant in den Urlaub los und an einer Engstelle stehen Sie wie viele andere Urlauber auch im Stau und warten bis es weiter geht. Niemand kommt auf die Idee, einen Umweg zu suchen.
    Sie werden zugeben, dass die kein optimales Verhalten ist aber kaum Abstimmung erforderlich ist.
  • Der Exchange2000/2003
    Hier schauen Sie aufmerksam die Nachrichten und fahren erst dann los, wenn es eine staufreie Stecke von Zuhause bis zum Urlaubsort gibt. Dabei kontrollieren Sie einfach die Verbindung von Autobahnkreuz zu Autobahnkreuz.. Sie hoffen damit, dass Sie nicht in einem Stau "stecken" bleiben und vermeiden dies schon so weit wie möglich im vorhinein.
    Leider ist die Welt nicht so ideal, denn faktisch werden Sie dann zumindest an den Urlaubswochenende nie losfahren, da es immer irgendwo "staut" und selbst dann ist dies keine Garantie, dass nicht während der Fahrt doch noch ein Stau auftritt. Wenn Sie aber losgefahren sind, dann können Sie anhand der Informationen immer noch ihren Fahrtroute ändern, indem Sie im Autobahnkreuz einfach einen anderen Weg einschlagen.

Exchange 2007 ändert diese Verhalten nun gravierend, indem es weder Leitwege pflegt noch einen Verbindungsstatus pflegt. Es gibt schlicht keine eigene Routingtabelle mehr, sondern Exchange 2007 nutzt die Active Directory Standorte und Dienste. Damit weiß Exchange, von wo nach wo Verbindungen bestehen. Die Übermittlung von Nachrichten orientiert sich nun mehr am Modell der Mitfahrer. Solange eine Mail mit mehreren Empfängern den gleichen Weg hat, wird eine Mail an den Zielserver übertragen. Sobald eine Mail aufgeteilt wird, geht jede Mail ihren eigenen Weg direkt zum Ziel. Nur wenn das Ziel nicht direkt erreichbar ist, dann prüft Exchange, wie er recht nahe an die eigentliche Ziel heran kommt und stellt die Mails an diesen Server zu.

Ob eine Verbindung dort hin nun verfügbar ist oder nicht, wird nicht anhand eines Linkstatus überprüft, sondern einfach versucht. Kommt die Verbindung zustande, dann wird die Mail auch übermittelt. Welcher Weg die Mail dann auf dem Kabel von einer Station zur Anderen nimmt, entscheiden letztlich die IP-Router mit ihren Routingtabellen.

Weitere Links