QoS - Monitoring
Diese Seite ist noch nicht komplett. Speziell Themen wie NetFlow, Cisco IP SLA etc. sind noch nicht beschrieben.
Aber selbst wenn alles theoretisch gut aussieht, können Anwender über Probleme klagen, die sie irgendwie auflösen müssen. Dazu gibt es tatsächlich auch gleich mehrere Wege, die sie einschlagen können. Dabei können sie zwischen Aktiven und passivem Monitoring unterscheiden.
- Passives Monitoring
Ein Programm liest den sowieso vorhandenen Verkehr mit und wertet diesen entsprechend aus. Wenn natürlich nichts übertragen wird, können Sie auch nichts müssen. Dieses Verfahren eignet sich auch nicht für die Ermittlung von Obergrenzen aber es belastet das System auch nicht durch eigene Pakete. Solche Proben müssen aber direkt auf dem Router oder Switch oder über separate Mirror-Ports erfolgen, da sonst der Netzwerkverkehr nicht gesehen werden kann. Ein Sonderfall sind natürlich Endpunkte wie der Lync Client, die auch die Verbindung überwachen und entsprechend berichten können. - Aktives Monitoring
Hierbei senden Sie zyklisch oder sogar regelmäßig eigene Daten die wiederum gemessen werden. Durch diese aktive Messung benötigen Sie natürlich zusätzlich Bandbreite aber sind natürlich auch unabhängig von den Betriebsdaten. Interessant sind diese Optionen auch um durch künstliche Last die Obergrenzen zu ermitteln und kurzfristige Störungen zu erkennen.
Einsatz von QoS und DSCP überprüfen
Auf den vorherigen Seiten haben Sie gelesen, dass man zwar in einem schnellen Netzwerk vermutlich auch ohne QoS-Einstellungen eine Zeit lang überleben kann, aber ratsam ist natürlich schon die Konfiguration von DSCP-Einstellungen. Da kommt natürlich gleich die erste Frage, wie die Funktion dieser Einstellungen überprüft werden kann.
DCSCP-Einstellungen sind Werte im Ethernet/IP-Paket und so sind die üblichen Verdächtigen wie NetMon 3 und Wireshark natürlich prädestiniert die Pakete mit zu schneiden. Hier mal ein Mitschnitt es PCMU Audiopakets von einem Gateway (Mediant 1000) an den Lync Client auf meinem Desktop.
Sie können gut erkennen, dass hier "DifferentiatedServicesField" auf 46 gesetzt ist, wie weiter oben auf dem Bild zur Konfiguration zu sehen ist. Es ist dabei nicht relevant, ob die RTP-Daten verschlüsselt übertragen werden. Auch bei IPV6 gibt es dieses Feld.
- Differentiated services
http://en.wikipedia.org/wiki/Differentiated_services - Implementing Quality of
Service Policies with DSCP
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml
Audio mitschneiden
Ein zweiter, wenngleich aufwändiger, Weg ist ein Mitschneiden der Audio-Verbindungen. Wenn ein Anwender sich dann über schlechte Qualität beschwert, kann die Aufzeichnung heran gezogen werden, um diese neutral wieder zu geben. Wer also z.B. alle Audio-Verbindungen zum Gateway über einen Mirror-Port mitschneidet, kann damit zumindest die Telefongespräche analysieren. Wenn die RTP-Daten nicht verschlüsselt sind, dann kann Wireshark als schnelles Tool hier ganz gute Dienste leisten. Natürlich ist damit keine Langzeitaufzeichnung möglich.
- Netzwerktrace mit Wireshark (www.wireshark.org)
Leider verschlüsselt OCS intern alle Pakete per TLS aber die meisten Firmen verbinden den Mediation Server mit dem Gateway ohne Einsatz von TLS. Das ist auch nicht unbedingt erforderlich, wenn es sich um ein gesondertes LAN handelt. Hier können Sie dann per Netzwerktrace auch die SIP und Audiopakete mitschneiden und sogar "abhören. - Netzwerktrace mit Cain&Abel (www.oxid.it)
Auch das Programm Cain&Abel bietet die Möglichkeit, IP-Pakete auf dem Netzwerk abzulauschen und als Audiodate zu extrahieren. - Netzwerktrace mit SIP-Recorder (http://www.pcbest.net/siprecorder.htm)
Diese Software vereinfacht das Mitschneiden als Spezialist für VoIP. Allerdings zeichnet es nur die ersten 30 Sekunden auf.
Sie wissen natürlich, dass solche Mitschnitte, auch wenn Sie als Fehlersuche gemeint sind, nicht ohne vorheriges Einverständnis der Nutzer erfolgen dürfen.
Endpunkt QoS-Monitoring
Ich empfehle immer den Einsatz der Lync Monitoring Rolle, da damit die Lync Clients und andere Lync Endpunkte ihre Verbindungsdaten am Ende der Verbindung an eine zentrale Stelle melden können. Es geht mir dabei nicht um eine Aufzeichnung, wer mit wem wir lange gesprochen hat. Die Lync Monitoring Rolle bekommt von den Clients umfangreiche Informationen über die Netzwerkübertragung aber auch lokale Eigenschaften wie Headset, CPU-Auslastung und andere Probleme. In Verbindung mit Lync und Telefonie ist dies unabdingbar.
- Lync Monitoring-Server
Der Office Communications Server kennt eine QoS-Rolle, welche installiert und konfiguriert werden muss. Am Ende einer Verbindung überträgt der Client als auch der Mediation Server einen Qualitätsreport im SIP-Paket mit an den OCS-Server, welcher diese Daten dann ablegen kann.
Mit diesen Daten kann zumindest nachträglich festgestellt werden, wann eine Verbindung von Lync wie stark beeinträchtigt war. Natürlich liefern die Daten keine Information über die WAN-Teilstrecke, die das Problem verursacht hat.
Auch andere Endpunkte, z.B. ein Mediant oder selbst ein billiger HT502 liefert per SYSLOG am Ende eines Gesprächs entsprechende Daten. Hier ein gekürztes Beispiel.
%TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] Vinetic::getRTPStat on port 1:0, RTP lost =2 Jitter = 32 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB_22 Stats port(1) channel (0) %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] ====================================== %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nType = . %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nIn%TIME% = 0 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nBufSize = 998 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nMaxBufSize = 1084 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nMinBufSize = 787 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nPODelay = 12 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nMaxPODelay = 1893 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nMinPODelay = 0 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nPackets = 133 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nInvalid = 2 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nLate = 0 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nEarly = 0 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nResync = 0 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nIsUnderflow = 260360 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nIsNoUnderflow = 0 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nIsIncrement = 0 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nSkDecrement = 320 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nDsDecrement = 320 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nDsOverflow = 0 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nRecBytesH = 4 %TIME% Local7.Debug 10.140.0.19 HT-502 [MAC]: [1.0.7.6] JB jbStats.nRecBytesL = 152032
Auch wenn diese Daten so erst mal nur eine Momentaufnahme sind und eine Zentralisierung und Auswertung natürlich noch offen ist, ist es ein möglicher Ansatzpunkt.
Netzwerk QoS-Monitoring
Richtig rund wird die Lösung aber erst, wenn auch die Router und Switche ihren Beitrag dazu leisten. Zumindest die teureren aktiven Komponenten zeichnen schon von sich aus entsprechende Daten auf oder können sogar selbst aktiv "proben" und die Daten z.B. per NetFlow an eine zentrale Konsole senden.
Solche Router "sammeln" selbst statistische Daten über Protokollverteilungen und erlauben entsprechenden Analyseprogrammen diese Daten dann zyklisch abzurufen.
- PRTG 9 Manual: Monitoring Bandwidth via Flows
http://www.paessler.com/manuals/prtg9/flow_monitoring.htm - IP SLA (mit Cisco)
http://www.paessler.com/ip_sla_monitoring
Auch Router können bestimmte Informationen sammeln. Oft ist diese Funktion aber nur für höherpreisige Modelle Verfügbar. Dann aber kann z.B. ein Cisco - Juniper: Real-time-performance Monitoring on Juniper
networks devices
https://www.juniper.net/us/en/local/pdf/app-notes/3500145-en.pdf - NDSAD, a Netflow Traffic Probe
http://www.utm-billing.com/other_products.php
http://sourceforge.net/projects/ndsad/ - Solarwinds NetFlow Configurator
http://www.solarwinds.com/products/freetools/netflow_configurator.aspx (2 Interfaces free)
Unterstützung durch
Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach unter
0800-MSXFAQ (0800-638 28 96) an.
Windows Phone 8
Microsoft Research hat eine kleine Windows Phone 8 App veröffentlicht, die die Netzwerkperformance per GSM und WIFI müssen kann.
Network Speed Test
http://www.windowsphone.com/s?appid=9b9ae06b-2961-41ef-987d-b09567cffe70
Weitere Links
-
VoIP
Telefonieren über IP - Exchange 2007 UM nutzt auch VoIP -
VoIP Sniffer
VoIP Sprachdaten mit Wireshark analysieren. - SIP im Detail
-
PCD Pre-Call Diagnostics
Hilfsprogramm für jeden Desktop zur Überwachung der Netzwerkqualität für VoIP mit OCS -
Voice Quality Improvements in Lync Server 2010
http://blogs.technet.com/b/nexthop/archive/2011/04/04/voice-quality-improvements-in-lync-server-2010.aspx -
Quality of Service (QoS) Overview
http://technet.microsoft.com/en-us/library/gg405407.aspx -
Microsoft Office Communications Server 2007 R2 Requirements für a
QoS Environment
http://technet.microsoft.com/en-us/library/dd441262(office.13).aspx -
Microsoft Office Communications Server 2007 QoE Summary Reports
http://technet.microsoft.com/en-us/library/bb964094.aspx - Ports and Protocols für Internal Servers
http://technet.microsoft.com/en-us/library/gg398833.aspx - Determining External A/V
Firewall and Port Requirements
http://technet.microsoft.com/en-us/library/gg425882.aspx - Media Port Range für Office
Communications Server 2007 R2
http://technet.microsoft.com/en-us/library/dd572230(office.13).aspx - Office Communications Server 2007 Deployment Validation Tool
http://www.microsoft.com/downloads/details.aspx?FamilyId=3596A10D-65CC-4CCA-8470-3F23D5EA55B2&displaylang=en - Office Communications Server 2007 Quality of
Experience (QoE) Monitoring Server Guide
http://www.microsoft.com/downloads/details.aspx?FamilyID=9ed29d74-3391-4902-bf2c-6757410f3335&displaylang=en - Office Communications Server 2007 VoIP Test Set
http://www.microsoft.com/downloads/details.aspx?familyid=7B6AB4F3-2949-4E97-856E-9C4AE323C75A&displaylang=en - http://blogs.msdn.com/byrons/archive/2008/03/19/deployment-validation-tool-part-1-of-2.aspx
- Deployment Validation Tool Webcast
http://blogs.msdn.com/byrons/archive/2008/04/02/deployment-validation-tool-webcast.aspx
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032372044&Culture=en-US - TechNet Webcast: Identifying Audio Quality Issues Pre-Deployment with
the Communications Server 2007 Deployment Validation Tool (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032372044&EventCategory=4&culture=en-US&CountryCode=US - Which Server(s) to deploy the (DVT) Deployment Validation Tool
http://blogs.msdn.com/byrons/archive/2009/04/21/where-to-deploy-the-dvt-deployment-validation-tool.aspx - Vista SP1 ( SP2) DSCP settings für QoS OC 2007 R2
http://communicationsserverteam.com/archive/2009/06/04/458.aspx - Microsoft to Cisco, "Our QoE is better than your QoS
"! as a result of another Independent Study
http://voip-buzz.com/2007/11/09/microsoft-to-cisco-our-qoe-is-better-than-your-qos-as-a-result-of-another-independent-study/ - OCS Quality of Experience (QoE) - Quick Facts
http://blog.insideocs.com/2009/04/27/ocs-quality-of-experience-qoe-quick-facts/ - OCS 2007 R2 – Archiving and Monitoring
http://blogs.technet.com/toml/archive/2009/01/02/ocs-2007-r2-archiving-and-monitoring.aspx - Controlling and Limiting Traffic Profiles in your Network
http://www.hp.com/rnd/pdf_html/traffic_profiles.htm - Overview of the Microsoft RTAudio Speech codec
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=7515