CAC IP Management

Für den stabilen Betrieb von CAC ist es erforderlich, das Lync alle IP-Subnetze und die zugeordneten Standorten kennt. Je größer eine Firma wird, desto kniffliger kann es werden den Prozess von geänderten Netzwerkadressen mit Lync abzustimmen. Diese Seite beschreibt diese Herausforderung

CAC primär für Netzwerker

CAC ist eine Funktion von Lync, die maximal durch Clients über einen Link genutzte Bandbreite per Software zu beschränken, so dass die durch QoS garantierte Bandbreite effektiv genutzt wird. Es macht keinen Sinn, wenn per QoS z.B. 1 Megabit garantiert wird aber dann 10 Verbindungen a 100 Kbit diese Leitung nutzen und die 11te Verbindung hinzu kommen kann. Dann werden aus 10 zufriedenen Anwendern 11 schlechtere Verbindungen. CAC reglementiert den Zugang zu einer Verbindung und wenn diese aus Sicht von Lync "belegt" ist, wird eine weitere Verbindung mit einem "Gassenbesetzt" abgelehnt. Dazu sind aber einige Voraussetzungen zu erfüllen:

  • Nur Audio und Video
    Die Steuerung von CAC wirkt nur Audio und Video-Verbindungen. Desktop-Sharing, Powerpoint, Instant Messaging und Präsenz werden nicht limitiert.
  • Alle Endpunkte erfassen
    Damit Lync diese Funktion aber korrekt umsetzen muss, muss es alle Endpunkte der A/V-Verbindungen können. Ein SDP-Kandidat, der nicht per CAC erfasst wird, ist "unrestricted" !
  • QoS erforderlich
    Damit CAC sinnvoll arbeiten kann, muss das Netzwerk natürlich die Bandbreite per QoS entsprechend auch bereit stellen. Ansonsten würde CAC nur die Lync User beschränken um den sonstigen Traffic nicht zu viel wegzunehmen.

Es ist also erforderlich, in Lync die IP-Subnetze komplett zu erfassen und diese über Sites und Regionen zu verknüpfen.

NetName für Subnetz

Viel mehr Subnetze als sie als Firma intern betreiben, gibt es im Internet. Und da ist es schon lange üblich, dass zu einem Subnetz auch eine Dokumentation über den Besitzer, Standort etc. existiert.

Sie sehen aber bei Net at Work z.B. auch, dass viele Objekte "Verweise" auf eine Stammdatenbank (RIPE-Handle) sind. Das macht hier natürlich Sinn. In einem Firmennetzwerk sollten Sie aber auch überlegen, ob sie ihren einzelnen "Subnetzen" einen sprechenden Namen geben. Interessant ist es hierbei, wenn der Name vielleicht einen Rückschluss auf den Standort und die Anbindung zulässt. Denkbar wäre z.B.

Routinghub_Site_SubSite_Netname

Die meisten Firmen haben z.B. ein zentrales MPLS an das Sites angebunden sind und vielleicht noch untersites existieren. Anhand eines solchen Namenkonzepts kann man relativ einfach dann auch Lync Regionen und Sites abbilden. Denkbar sind natürlich auch andere Namenskonzepte.

Source für Sites, Standorte, Subnetze und Links

Die einzige verlässliche Quelle für die verwendeten Subnetze in einer Firma sind die Personen, die IP-Netzwerke verwalten, die WAN-Verbindungen und Standorte können und vielleicht auch die IP-Adressen (per DHCP) vergeben und DNS-Einträge verwalten. Oft ist der gleiche Personenkreis auch für die QoS Einrichtung der Router und das Monitoring der Bandbreite erforderlich.

An diese Quelldaten müssen Sie als Lync Administrator aber nicht nur einmalig heran, sondern idealerweise regelmäßig die Daten mit ihrer Lync Konfiguration abgleichen oder zumindest über einen Prozess informiert werden, wenn sich IP-Adressen und Zuordnungen ändern. Übrigens gibt es diese IP-Netzwerk-Liste auch in LIS Location Information Service

Die gleiche Anforderung gilt natürlich auch für das AD-Team, die ihre AD-Sites und SiteLinks verwalten müssen und indirekt auch für die Exchange Administratoren. Das "Problem" sollte schon früher aufgefallen sein.

Nehmen wir an, dass ihr Netzwerk-Team eine akkurate Dokumentation hat, dann stellt sich natürlich die Frage, wie diese vorliegt und wie diese für Lync genutzt werden können. Kleinere Firmen, in denen wenig Veränderungen und Personen die Umgebung verwalten, können die nächsten Kapitel überspringen und gleich weiter unten bei Auditing weiter schauen. Je größer aber eine Umgebung ist, desto ineffizienter ist eine manuelle Pflege, die zum einen Zeit kostet aber vor allem Fehleranfällig und nicht verzögerungsfrei ist.

PowerShell ist ein sehr effektives Mittel, um in Lync, im AD und anderen Diensten Einstellungen zu prüfen oder sogar automatisiert vorzunehmen. Sie benötigen nur eine passende Quelle und im Bereich auf Netzwerke gibt es hierzu gleich mehrere Optionen:

  • AD
    Wenn der Lync Administrator Glück hat, dann pflegt das AD-Team bereits die Netzwerkstandorte als AD-Sites mit einem schicken Namen und den Subnetzen. Es gibt schon mehrere Skripte, um diese Informationen auszulesen und nach Lync zu übertragen. Allerdings sollten Sie beachten, dass man in AD-Sites sehr gerne mit Super-Netting arbeitet, d.h. mehrere Subnetze zusammengefasst nur einmal definiert. für CAC reicht dies aber nicht für Media Bypass oder LIS
  • DNS
    Ich habe schon Firmen gesehen, die ihre Dokumentation im "Life-System" machen. Beim Einsatz von DNS eigenen sich z.B. TXT-Records dafür, um Sachverhalte zu einem Host aber auch zu einer Domäne zu beschreiben. Das ist insbesondere interessant für den Betrieb, wenn ein Admin so per "NSLOOKUP -q=TXT 10.49.52.0" den Text-Record mit den Stammdaten für das Netzwerk erhalten kann.
  • XLS, Sharepoint Liste, Datenbank
    Allen guten Vorsätzen zum Trotz gibt es aber immer noch viele Firmen, bei denen die "Masterliste" aller vergebenen IP-Adressen letztlich doch eine Excel-Datei auf einem Dateiserver ist oder in moderneren Umgebungen eine Sharepoint-Liste oder eine Datenbank. Auch hier ist es wichtig, diese Daten dort auch akkurat zu pflegen und die notwendigen Daten zu erhalten.

Vielleicht habe ich damit ja auch ihren Datenspeicher beschrieben. Wenn Sie aber bislang gar keine Dokumentation zu IP-Adressen und Subnetzen haben, dann sollten Sie vielleicht damit anfangen oder ihr Netzwerk ist so überschaubar, dass Sie vielleicht auch kein CAC benötigen.

Reliable Source = Network

Interessant wird die Ermittlung eines Netzwerk, wenn man über entsprechende Berechtigungen verfügt und über Routingprotokolle und SNMP-Anfragen sich durch die Router hangelt und so eine Landkarte des Netzwerks erstellt. Allerdings ist die in den meisten Firmen nicht so einfach möglich, da SNMP vielleicht nicht durchgängig konfiguriert ist oder Teilstrecken durch einen anderen Dienstleister bereit gestellt werden, der keinen Zugriff erlaubt. Auch die Anfrage der "Interface Geschwindigkeit" ist keine Garantie über die gemeldete Bandbreite. Viele WAN-Provider stellen als Schnittstelle zum Kunden einfach ein Ethernet/Gigabit-Interface bereit und verbergen den kompletten technischen unterbau. Per SNMP kommen Sie so nicht wirklich weiter

Etwas einfacher ist es meist die Routingtabellen auszulesen und so zumindest eine halbwegs komplette Liste der Subnetze zu erhalten, mit der Sie dann sprichwörtlich "Klinken Putzen" gehen können. Denn es zeigt sich immer wieder, dass in den meisten Firmen keine vollständige und vor allem aktuelle und laufend aktualisierte Dokumentation der Netzwerke existiert.

Auditing

Kennen Sie die Datei "Netlogon.log" auf ihrem Domaincontroller? Ein Windows DC protokolliert hier Anfragen von Clients, die aus einem Subnetz kommen, die nicht in "AD Sites&Services" gepflegt sind. Einen ähnlichen Event gibt es auch bei Lync, nur dass er hier wirklich im "Eventlog" drin steht. Nach meiner Beobachtung erscheint er ca. alle 7h07min mit der ID 36034

Source: CS Bandwidth Policy Service (Core) 
Event number: 36034
Level: 2
Description: The subnets for the following IP Addresses:  are either not configured or the subnets are not associated to a network site.

In den meisten Fällen ist also dieses Eventlog eine wichtige Quelle, um "vergessene" oder später hinzu gekommene IP-Subnetze als Lync Administrator zu erkennen und darauf zu reagieren. Ob es nun gut oder schlecht ist, dass Lync Clients in einem nicht definierten Subnetz "unbeschränkt" arbeiten lässt, müssen Sie nun selbst entscheiden. Auf der einen Seite können die Anwender zumindest arbeiten, aber auf der anderen Seite ist die Qualität vielleicht zu schlecht, um zufriedenstellende Ergebnisse zu erhalten. Sie sollten also auf jeden Fall einen Prozess etablieren, um solche vergessenen Subnetze zu erkennen.

Mit einer passenden Lösung können Sie solche Events sehr einfach erkennen und melden lassen. Selbst der in Windows eingebaute "Taskplaner" kann auf Windows Events Aktionen ausführen, z.B.: eine E-Mail senden.

Weitere Links