Ils ont l’avantage d’être :

• un point d’entrée pour aider à la résolution d’incidents
• un outil de communication pour les services de direction et les opérationnels permettant de connaître le comportement en temps réel et d’une façon historisée de l’application

En quoi cela consiste?

Il s’agit d’un ensemble de trois éléments qui propose des informations clés sur la performance d’une application métier.

Comment peut-il aider?

Pour le reporting

Dans un unique rapport, vous pouvez expliquer à un utilisateur métier ou un un responsable comment la performance de l’application se comporte au fil du temps, quels serveurs ont subit des dégradations et quelles zones IP (VLAN, WAN, Wireless, etc.) ont été impactées.

• RTT – Performance réseau

• SRT – Performance Serveur

• DTT – Livraison de la réponse applicative à travers le réseau

Pour la résolution d’incidents

Pour les administrateurs réseau, ce rapport fournit toutes les informations sur une application métier demandée:

• valider s’il y a la présence d’un ralentissement

• identifier l’origine des ralentissements (réseau, application, livraison de la réponse)

• quels utilisateurs ou serveurs ont été impactés

En un seul clic, vous en pouvez conclure s’il y a eu un ralentissement ou pas, quelle a été l’origine de la dégradation, et quelles zones clients ont été impactées.

En un second clic (c’est à dire 2 clics au total !), vous pouvez déterminer si tous les clients de la zone ont été impactés ou si la dégradation des temps de réponse serveur est due à une autre application hébergée sur le même serveur

Composants

1er élément : L’évolution du temps de réponse utilisateur dans le temps

Illustration 2 : EURT Graph / Graphique EURT

Ce graphique EURT montre:

• l’évolution du ressenti utilisateur concernant une application sur une période de temps

• Le nombre de transaction vous aide a prendre en considération l’évolution de l’EURT avec rigueur et bon sens (vous ne considérerez pas la dégradation de l’EURT pour 10 transactions applicative de la même manière que pour 10 000 transactions)

La répartition de l’EURT en 3 composants compréhensibles (RTT pour la latence réseau, SRT pour le temps de réponse Serveur et DTT pour le temps de transfert) vous permet d’identifier, dans une première approche, quelle est l’origine éventuelle de cette dégradation de performance.

Par exemple dans la copie d’écran ci-dessus, nous pouvons observer une augmentation du temps de réponse du serveur, en remarquant que le temps nécessaire pour envoyer la réponse au client n’a pas augmenté. Soit le serveur, au global, répond lentement, soit des queries spécifiques prennent un temps de traitement plus important (informations accessibles dans les données de détails).

2ème élément: EURT par Serveur

Illustration 3 : EURT by server / EURT par Serveur

Ce que nous pouvons observer ici est une comparaison de l’EURT sur une application pour chaque serveur qui héberge cette application.

Dans notre exemple, il est évident qu’Atlantis a tendance à réagir plus lentement que Brax. En cliquant sur ce serveur, et en consultant un second tableau de bord appelé «tableau de bord Serveur/Application», vous serez en mesure de déterminer si ce phénomène est permanent ou ponctuel et s’il est dû au chargement de cette application ou à une autre application hébergée sur le même serveur.

3ème élément : EURT par Zone Client

Illustration 4: EURT by Client zone / EURT par Zone Client

Ce que nous pouvons voir ici c’est la répartition de l’EURT pour cette application entre les différentes zones clientes. Dans une première analyse, vous pouvez déterminer quelle zone a été impactée par une dégradation et quels sont les différents niveaux de performance en fonction du ressenti utilisateur (selon l’endroit où les utilisateurs sont localisés).

Par exemple, dans la copie d’écran ci-dessus, nous pouvons en conclure que une zone a été touchée par une dégradation du temps de réponse du serveur. Egalement, nous observons qu’il y a des différences significatives entre les zones IP, avec des valeurs du RTT disparates entre chaque zone (latence réseau).

L’accès au détail à partir des Tableaux de bords

SecurActive APS offre deux tableaux de bords supplémentaires:

1. Tableau de bord Zone client / Application
2. Tableau de bord Serveur / Application

1. Tableau de bord Zone Client / application

Vous pouvez accéder à ce tableau de bord par le menu ou en cliquant sur une zone client spécifique dans le tableau de bord de l’application.

Ce tableau de bord contient trois éléments d’information :

• le graphique de L’EURT (pour une période sélectionnée), pour une zone client et une application
• La répartition de l’EURT par serveur (comparaison de la performance offerte par les différents serveurs pour cette zone client)
• L’EURT par client (identification des clients impactées par le ralentissement, ou identification d’un client spécifique générant du volume, ou identification d’un client ayant les moins bonnes performances applicative).

Illustration 5: Client zone / application dashboard / Tableau de bord Zone client/ application

2 Tableau de bord Serveur / Application

Vous pouvez accéder au tableau de bord soit à partir du menu principal soit en cliquant sur un serveur en particulier à partir du tableau de bord application.

Ce tableau de bord contient trois éléments d’information :

• Le graphique de l’EURT dans la période sélectionnée pour ce serveur et cette application
• La répartition de l’EURT par zone client (vous pouvez comparer la performance offerte par ce serveur pour différentes zones client)
• Comparaison avec d’autres applications hébergées par ce serveur (de sorte que vous pouvez identifier si les pics de transaction d’une autre application a impacté la performance de cette application. Vous pouvez également voir le volume de données, le volume de transaction et les métriques de performance pour toutes les applications hébergées par ce serveur).

Illustration 7: Server / application dashboard / Tableau de bord serveur / application

Interactions

Les tableaux de bords ont été développés de sorte qu’en un simple clic vous puissiez accéder à l’information qui vous intéresse de manière plus détaillée:

• Si vous cliquez sur le graphique de l’EURT (dans un des trois tableaux – au choix), vous vous concentrez sur une période de temps courte (par exemple un pic temps de réponse serveur – selon le niveau d’agrégation vous pouvez soit atteindre un faible niveau d’agrégation pour une courte période soit les conversations de performance correspondante). Ce clic vous permettra d’obtenir la répartition par serveur et par zone pour la période de temps spécifique).

• Si vous cliquez sur un serveur, vous accèderez au tableau de bord serveur/application.

• Si vous cliquez sur la zone client, vous accèderez au tableau de bord zone client / application.

Il a un énorme impact sur la perception de la performance pour l’utilisateur final.

Il s’agit d’un des trois principaux facteurs qui impacte directement le niveau de satisfaction des utilisateurs quand il doivent avoir accès à leurs applications clés:

• RTT (Round Trip Time): Combien de temps prend un paquet pour transiter sur le réseau, de la partie cliente vers un serveur et en retour. Cette mesure est significative d’une latence réseau.

• SRT (Server Response Time) : Combien de temps prend un serveur pour répondre à la demande d’un client (cette mesure correspond à l’intervalle de temps entre la demande du client et l’arrivée des premiers paquets de la réponse envoyée par le serveur). Cela représente la capacité du serveur et de l’application a répondre aux requêtes applicatives.

• DTT (Data Transfer Time): Combien de temps s’écoule pour le transfert de la réponse du serveur vers le client (cette mesure correspond à l’intervalle de temps entre le premier paquet et le dernier paquet de la réponse) Cela représente le temps nécessaire pour que l’utilisateur reçoive toute la réponse applicative.

EURT Graph / Graphique EURT

Metrics Description / Description des métriques

Voici un exemple concret :

|Time     | 192.168.20.216                        |

|         |                   | 82.237.175.5      |

|2,814    |         36619 > http [SYN]            |TCP: 36619 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460         TSV=5337586 TSER=0 WS=6

|         |(36619)  ——————>  (80)     |

|2,877    |         http > 36619 [SYN,            |TCP: http > 36619 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1452 TSV=165654660 TSER=5337586 WS=6

|         |(36619)  <——————  (80)     |

|2,877    |         36619 > http [ACK]            |TCP: 36619 > http [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=5337602 TSER=165654660

|         |(36619)  ——————>  (80)     |

|2,877    |         GET /misc/hackers.j           |HTTP: GET /misc/hackers.jpg HTTP/1.1

|         |(36619)  ——————>  (80)     |

|2,952    |         http > 36619 [ACK]            |TCP: http > 36619 [ACK] Seq=1 Ack=499 Win=6912 Len=0 TSV=165654678 TSER=5337602

|         |(36619)  <——————  (80)     |

|2,952    |         HTTP/1.1 304 Not Mo           |HTTP: HTTP/1.1 304 Not Modified

|         |(36619)  <——————  (80)     |

|2,952    |         36619 > http [ACK]            |TCP: 36619 > http [ACK] Seq=499 Ack=191 Win=6912 Len=0 TSV=5337620 TSER=165654678

|         |(36619)  ——————>  (80)     |

|2,961    |         GET /favicon.ico HT           |HTTP: GET /favicon.ico HTTP/1.1

|         |(36619)  ——————>  (80)     |

|3,048    |         HTTP/1.1 404 Not Fo           |HTTP: HTTP/1.1 404 Not Found  (text/html)

|         |(36619)  <——————  (80)     |

|3,085    |         36619 > http [ACK]            |TCP: 36619 > http [ACK] Seq=843 Ack=693 Win=8000 Len=0 TSV=5337654 TSER=165654702

|         |(36619)  ——————>  (80)     |

|18,057   |         http > 36619 [FIN,            |TCP: http > 36619 [FIN, ACK] Seq=693 Ack=843 Win=7936 Len=0 TSV=165658456 TSER=5337654

|         |(36619)  <——————  (80)     |

|18,097   |         36619 > http [ACK]            |TCP: 36619 > http [ACK] Seq=843 Ack=694 Win=8000 Len=0 TSV=5341407 TSER=165658456

|         |(36619)  ——————>  (80)     |

|27,918   |         36619 > http [FIN,            |TCP: 36619 > http [FIN, ACK] Seq=843 Ack=694 Win=8000 Len=0 TSV=5343862 TSER=165658456

|         |(36619)  ——————>  (80)     |

|27,982   |         http > 36619 [ACK]            |TCP: http > 36619 [ACK] Seq=694 Ack=844 Win=7936 Len=0 TSV=165660937 TSER=5343862

|         |(36619)  <——————  (80)     |

Quel phénomène impacte le DTT?

• Latence réseau: plus le temps est long pour que chaque paquet transite à travers le réseau, plus l’utilisateur attendra pour avoir la réponse complète.
• La taille de la réponse : plus la taille de la réponse est grande, plus le temps de transfert sera long.
• Congestion de la bande passante : moins la bande passante est disponible, plus le temps de transfert de la réponse sera long
• Traitement prioritaire: la classe de Service pour ce flux a une priorité basse
• Retransmission et paquets mal formés: plus il y a de retransmission plus cela prendra de temps.
• Fenêtre TCP nulle

Quelles sont les atouts de la mesure EURT?

L’EURT est la somme du RTT, SRT et du DTT. Cette mesure fournit une valeur significative pour représenter la performance perçue par les utilisateurs finaux. En tant que telle, elle offre une valeur objective du ressenti utilisateur sur tout le réseau et pour toutes les applications critiques.

Cette métrique est un élément central des rapports de performance car il synthétise toutes les informations dont a besoin un décisionnaire en une seule mesure.

Client/Server Table / Tableau Client/Serveur

Nous étions récemment chez l’un de nos clients qui vient juste d’installer une appliance APS dans son data Center.

Son infrastructure était plutôt simple :

• tous leurs serveurs de production étaient dans un data center,

• Les utilisateurs étaient localisés soit au siège social (où se trouve le data center) soit sur l’un de leurs sites distants (environ une centaine). Ces sites étaient tous connectés au siège social par un réseau MPLS.
• Ils font partie d’un grand groupe, dont le data center est connecté au même nuage MPLS, qui fournit l’accès à plusieurs services centraux comme le DNS, la messagerie électronique (Lotus Notes) et une passerelle internet sécurisée.

Illustration 1 : Topologie  réseau simplifiée

Rappels

Retransmission de paquets

Les paquets sont renvoyés après avoir été soit perdus soit endommagés.

La retransmission de paquets est identifiée grâce à leur séquence TCP, à leur numéro de séquence et aux valeurs du checksum. Seul les paquets ayant une charge utile non-nulle sont vérifiés.

Délai de retransmission

Intervalle de temps entre un paquet et la dernière retransmission

RD signifie «Retransmission Delay » soit retard dû à la retransmission. RD est défini comme étant le temps entre un paquet et sa dernière retransmission.

Illustration 2 : Calcul du délai de retransmission

Taux de retransmission

Ratio des paquets retransmis sur nombre total de paquets

RR signifie «Retransmission Rate » soit Taux de retransmission. RR est défini comme un ratio des paquets retransmis sur le nombre de paquets dans une conversation.

Illustration 2 : Calcul du retard du à la retransmission

Ce que nous avons observé

Le responsable réseau de notre client nous faisait part de la plainte d’un de ses utilisateurs finaux, situé sur un site distant. Il se plaignait d’être victime de lenteur d’accès à une application située sur le data center. En regardant le graphique de la performance de l’application, nous avons observé une somme significative de Retransmission Delay (du serveur vers le client) et aucun autre changement à part une légère augmentation du DTT (temps de transfert des données) pour l’application en question.

Illustration 3: Exemple de graphique de performance d'application

Nous avons élargi notre champ d’investigation en regardant dans le graphique de la performance du réseau et en nous attachant à toutes les applications (pour les clients situés sur des sites distants et les serveurs du datacenter) : nous avons pu observer que les temps de Retransmission Delay étaient hauts quel que soit l’application utilisée. Mais aussi que le «Retransmission Delay » (RD) était impacté principalement dans la direction du serveur vers le client.

Illustration 4 : Exemple de graphique de performance réseau

Nous avons fait l’hypothèse qu’il devrait y avoir des congestions entre le data center et le site distant dans la direction suivante : Data center → site distant. En conséquence, nous avons regardé le graphique APS relatif à la bande passante pour étudier le trafic entre le data center et le site distant.

Nous avons fait l’hypothèse qu’il devrait y avoir des congestionsentre le data center et le site distant dans la direction suivante : Data center → site distant. En conséquence, nous avons regardé le graphique APS relatif à la bande passante pour étudier le trafic entre le data center et le site distant. Nous avons observé un pic de trafic (principalement dû à Windows SUS) qui atteignait 1.2 Mbps; ce qui nous a permis de comprendre que notre client avait un dysfonctionnement dans la mise en œuvre de sa priorisation de flux.

Notre client a trouvé cette valeur de 1.2 Mbps intéressante bien que, pour lui, ce ne soit pas au premier coup d’œil, quelque chose qui lui permette de déterminer si cela était bien une congestion. Car en effet, la bande passante disponible sur le site distant était de 2 Mbps (et le maximum de bande passante disponible sur le data center était de 80 Mbps et seulement une très faible quantité de cette bande passante était utilisée).

Nous avons donc décidé de nous pencher sur le graphique SNMP fourni pour le routeur du site distant par son opérateur telecom. Ce graphique de bande passante, nous a permis de voir que le trafic entrant de 2Mbps sur 30 minutes, était constant.

Conclusion sur le sens des retransmissions

Les retransmissions sont significatives et vous devriez examiner les retransmissions pour déterminer :

• si elles sont intermittentes ou continues
• quel est le périmètre à observer (de quelle (s) zone (s) client pour tous les serveurs ou pour un seul).

Nous avons appris que certains paquets n’atteignent pas les autres hôtes ou que les acquittements ne retournent pas vers l’émetteur.

Dans un sens, la direction des retransmissions (serveur → client ou client → serveur) peut être peu significative, car la congestion provoque des retransmissions dans les deux sens (par exemple, une congestion d’un serveur vers un client pourrait générer quelques retransmissions d’un serveur vers un client – les paquets envoyés par le serveur ne reçoivent pas assez rapidement l’acquittement et le serveur les retransmet – et du client vers le serveur – car même si les paquets venant du client vers le serveur arrivent assez rapidement, l’acquittement des paquets du serveur vers le client souffre d’une congestion et le client retransmet les paquets originaux). Vous devriez garder en mémoire que l’équilibre des retransmissions entre un client→serveur et serveur→client dépend aussi de l’équilibre du trafic entreces deux directions.

Conclusion relative à l’impact du «retransmission delay» sur le ressenti utilisateur

Dans les deux sens, le «Retransmission Delay» est un bon indicateur de la dégradation du réseau sur la qualité du ressenti utilisateur.

Dans un sens, le «Retransmission Delay» est guidé par la quantité de données envoyées dans cette direction. Cette valeur correspond au temps additionnel pour qu’un utilisateur puisse obtenir ses données.

La retransmission a une seconde conséquence sur le temps requis pour recevoir les données : quand il y a une retransmission, la machine réinitialise ses fenêtres TCP et la taille du buffer à sa taille minimum par défaut. Cela signifie qu’à chaque fois qu’il y a une retransmission, le débit revient à un niveau très bas puis augmente progressivement. Si la retransmission est fréquente alors le débit revient toujours au niveau minimum et n’atteint jamais le niveau optimal. Ceci provoque alors un temps de transfert des données plus important, car le débit pour transférer une réponse applicative reste très lent. Ce phénomène est-ce que nous appelons communément le TCP Slow-Start (voirhttp://en.wikipedia.org/wiki/Slow-start)

It is one of the three main factors that impacts directly the level of satisfaction of users with regards to their access to key application:

• RTT (Round Trip Time): how much time does it take for a packet to travel through the network from the client to the server and back. It is significant of the network latency.
• SRT (Server Response Time): how much time does it take for the server to respond to a client’s request (it corresponds to the time interval between the client’s request and the first packet of the response sent by the server). It is significant of the Server and application’s ability to respond to requests.
• DTT (Data Transfer Time): how much time does it take to transfer the response to the client over the network (it corresponds to the time interval between the first packet and the last packet of the response). It is significant of the time required for the user to receive the whole applicative response.

EURT Graph / Graphique EURT

Metrics Description / Description des métriques

Here is a concrete example:

What phenomena impacts the DTT?

• Network latency: the longer it takes for each packet to get through the network, the more time the end user will wait for the whole response.
• Size of the response: the larger the response is, the more time it takes to transfer it.
• Bandwidth congestion: the least bandwidth is available, the more time it will take to transfer the response.
• Priority handling: the QoS class for this flow has a low priority
• Retransmission and out of order packets: the more retransmission there is, the more time it will take.
• TCP 0 window

What is great about EURT measurement?

EURT is the sum of RTT, SRT and DTT. It provides a meaningful value to represent the performance perceived by End Users. As such it provides an objective value for the QoE (quality of experience) of users throughout the network and for all critical applications.

This metric is central in the performance reporting because it synthesizes all the information a decision maker is looking for in one single figure.

Client/Server Table / Tableau Client/Serveur

I was recently at a customer who just installed an APS unit in their Data Center.

Their infrastructure was fairly simple:

• they had all their production servers in the data center,
• their users were located either in the headquarters (where the data center is located) or in one of their nearly 100 remote sites; these sites were connected to the headquarters through an MPLS network.
• they are part of a larger group, whose data center is connected to the same MPLS cloud, that provides access to some central services like DNS, mail (Lotus Notes) and  access to a secured Internet gateway.

Illustration 1: Simplified network topology

Reminders

Retransmission

Packets being resent, after having been either lost or damaged.

Packet Retransmission is identified thanks to their TCP sequence and acknowledgement numbers, and checksum values. Only packets with a non-null payload are checked.

Retransmission Delay

Time Delay between a packet and the last retransmission.

RD stands for Retransmission Delay. RD is defined as the time between a packet and its last retransmission.

Illustration 2: Retransmission delay calculation

Retransmission Rate

Ratio of retransmitted packets to the total number of packets.

RR stands for Retransmission Rate. RR is defined as the ratio of retransmitted packets to the total number of packets in a conversation.

Illustration 2 : Retransmission Delay Calculation / Calcul du retard du à la retransmission

What we observed

The customer’s network manager was first referring to a complaint from an end user regarding a slow access from their remote site to an application located in their data center.

By looking at the application performance chart, we saw a significant amount of Retransmission Delay (from server to client) and no other change apart from a slight increase in the DTT (Data Transfer Time) for the application in question.

Illustration 3 : Example of Application Performance Chart / Exemple de graphique de performance d'application

We extended our scope of investigation by looking at the network performance chart for all applications (for clients located in the remote sites and servers in the data center): we  observed that the retransmission delay was high, regardless of which application was being used. Also, that the RD occurred mostly in the direction from Server to Client.

Illustration 4 : Example of Network Performance Chart / Exemple de graphique de performance réseau

I made the hypothesis that there might be some congestion between the data center and the remote site in the direction DC → remote site. So we looked at the bandwidth graph of the APS for the traffic between the data center and the remote site: we  observed a peak of traffic (mainly due to Windows SUS – which told me a lot about the lack of control of their network & system administration traffic flows) reaching 1.2Mbps.

The customer found the value of 1.2Mbps interesting, although not enough at first glance for him to be convinced that there was a congestion… because the bandwidth available on the remote site end was 2Mbps (and the maximum bandwidth available on the DC end was 80Mbps, and only a very low amount of this maximum bandwidth was being used).

So we decided to check on the SNMP graphs provided by their telecom operator for the remote site router… and the bandwidth graph was showing a flat line at 2Mbps for 30 minutes for the incoming traffic.

Conclusion on the meaning of retransmissions

Retransmissions are significant and you should have a look at retransmissions to determine:

• whether they are intermittent  or continuous
• what is the perimeter where you can observe them (for which client zone(s), for all servers or one)

What they tell us in the end is that some packets are not reaching the other hosts or that  acknowledgment packets are not getting back to the sender.

The direction of the retransmission (server → client or client → server) may not be so significant as a congestion in one way may induce retransmission in both ways (for example, congestion from server to client would generate some retransmissions from server to client – the packets sent by the server do not get acknowledged fast enough and the server retransmits them- and from the client to the server – because even though the packets from the client to the server reach the server fairly fast, the acknowledgment packets from the server to the client suffer from the congestion and the client retransmits the original packets). You should also keep in mind that the balance of retransmission between client → server and server → client also depends on the balance of traffic between both directions.

Conclusion on the impact of the retransmission delay on the User Experience

In 2 ways Retransmission Delay is a good indicator of the impact of network degradation on the Quality of Experience of network users:

• Retransmission delay in one way is driven by the quantity of data sent in that direction; this value corresponds to the additional time required for a user to get all their data.
• Retransmission has a secondary consequence on the time required to receive  data: when there is a retransmission, the host resets its TCP window and the size of the buffer to its minimum default size. This means that each time there is a retransmission, the throughput is going back to a very low level and then start increasing again progressively. If retransmissions are frequent, then the throughput often goes back to a minimum level  and never reaches an optimal level. This means a much larger Data Transfer Time, because the throughput to transfer the applicative response remains very low. This phenomenon is what is usually called a TCP Slow-Start (see http://en.wikipedia.org/wiki/Slow-start)

It is extremely useful :

• as a starting point for troubleshooting
• as a tool to communicate to management and business users on how the application is actually performing

What does it consist in?

It is a set of three elements that  display key information on the performance of a business application.

Illustration 1: Overall view of the application dashboard

How can it help?

For reporting

In a single report you have enough to explain a business user or a manager how the application performance went through time, which servers were doing worse and which zones were impacted. On top of the EURT, all this is based on 3 synthetic metrics that are easy to explain, so that you can address non-technically aware people with an understandable speech about « what is going on » :

• RTT – network performance
• SRT – Server Performance
• DTT – Delivery of application response through the network.

For troubleshooting

For network administrators this report brings together all the information about a business application required to:

• validate whether there is a slowdown or not
• identify the origin of a slowdown (network, application, response delivery)
• which users or servers were impacted

In no more than one click, you can conclude on whether there was a slowdown or not, what was the origin of the degradation, which client zones were impacted.

With a single additional click (i.e. 2 clicks in total!), you can view whether all clients in a zone were impacted or if the server response time degradation was due to another application hosted on the same server machine.

Components

1^st element : the evolution of End User Response Time through time

Illustration 2: EURT graph

This EURT graph shows :

• the evolution of the quality of experience for users of this application over the period of time
• the number of transactions help you consider the evolution of EURT with rigor and common sense (you would not consider a degradation of EU Response Time for 10 applicative transactions in the same way as for 10,000).

The breakdown of EURT in 3 intelligible components (RTT for network latency, SRT for Server Response Time and DTT for Data Transfer Time) let you know at first glance what is the origin of the possible performance degradation.

For example in the screen-shot here-above, we can observe an increase in the Server Response Time; the network and the time required to send the response to the client have not increased. Either the server overall responded slower or some specific queries required a much larger treatment time (you can determine this by drilling down to that specific point of time).

2^nd element: EURT by Server

Illustration 3: EURT by server

What we can see here, is a comparison between the EURT for that application on each server that provides this application.

In this case, it is obvious that Atlantis tend to respond much slower than Brax. By clicking on it having a looking at a second dashboard called Server / Application dashboard, we shall be able to determine if this permanent or punctual and whether this due to the load on this application or on another one hosted on the same server.

3^rd element: EURT by Client zone

Illustration 4: EURT by Client zone

What we can see here is a breakdown of the EURT for this application between client zones; at one glance, you can determine which zone was impacted by the degradation and what are the different level of experienced performance depending on where users are located.

For example, from the screen-shot here-above, we could certainly think that mainly one zone was impacted by the Server Response Time degradation and also that there are some significant differences in performance between zones due to differences in RTT values (network latency).

Drill down dashboards

SecurActive APS offers two additional dashbaords

1. Client zone / application dashboard
2. Server / application dashboard

1. Client zone / application dashboard

You can access this dashboard either through the menu or by clicking on a specific client zone in the Application dashboard.

This dashboard contains three bits of information:

• EURT graph through time for this client zone and this application
• EURT breakdown by server (so that you can compare the performance offered by different servers to that client zone)
• EURT per client (so that you can identify whether all clients are impacted by a slowdown, or which individual client generates more volume or has worse application performance).

Illustration 5: Client zone / application dashboard

The breakdown by client is interesting to know whether all the zone was impacted or just some individual users and on which component of the EURT (network latency, server response time or data transfer time and for which number of transaction and amount of traffic).

Illustration 6: Breakdown by client

2. Server / application dashboard

You can access this dashboard either through the menu or by clicking on a specific server in the Application dashboard.

This dashboard contains three bits of information:

• EURT graph through time for this server and this application
• EURT breakdown by client zone (so that you can compare the performance offered to different client zone from that server)
• Comparison with other applications provided by that server (so that you can identify whether a peak of transactions on another application is impacting the performance of that application, and see the volume of data, transactions and performance metrics for all applications provided by this server).

Illustration 7: Server / application dashboard

Interactions

Dashboard have been developed so that a single click drives on more detailed information on the object you are most interested in:

• If you click on the EURT graph in any of these three dashboards, you make a focus on a shorter period of time (for example a Server Response Time peak – depending on the aggregation level you either reach a lower aggregation level for a shorter period or the corresponding performance conversations). At the same time you will get the server and zone breakdown for that more specific period of time.
• If you click on a server, you reach the Server / application dashboard.
• If you click on a client zone, you reach the Client zone / application dashboard.

1. No error message
2. No change in the behavior of the network
3. The evaluation of the severity is based on human  feedback.

This third element results in the following consequences:

• The end cannot precisely express the issue he/she is experiencing. Often this leads to a wrong diagnostic, which consists in blaming the network as being slow.
• The evaluation of the concern is based on a subjective assessment. This results in a conflict between the end user and the administrator on the severity of the concern. For example, the administrator may consider this issue as “non urgent”, as the end user can still work.

During the implementation of a SecurActive probe on a network, we have put in place the “application performance monitoring” on a  file sharing server (port 445). Through this feature, you can monitor the performance of the filesharing application on this server from all the user’s LANs. What was our surprise to see the following graph showing a performance issue between a LAN and this file server (no WAN link was used between the client and the server):

RTTout peak

The peak’s color corresponds to RTT out (reminder: this “RTT out” metric illustrates the network latency on the TCP client side).

RTTout measurement

By clicking on “view sessions”, we could see the corresponding individual conversations and we ran into the IP address of a unique end user.
The administrator then remembered the visit of an end user (whose IP is the one corresponding the diagram above) in the morning, complaining about the performance while accessing a file on this server …

Enjoy  o)

1. Pas ou peu de messages d’erreur
2. Pas de changement de comportement
3. L’évaluation se fait sur l’expression d’une “impression de lenteur” manifestée par un ou plusieurs utilisateurs.

Le troisième point engendre d’autres conséquences :

• En exprimant son souci, l’utilisateur met en accusation un élément du réseau, voire de la totalité du réseau.

• Cette évaluation subjective peut amener un conflit entre l’utilisateur et l’administrateur sur la gravité / véracité du problème.  Par exemple, l’administrateur, considérant que le souci n’empêche pas l’utilisateur de travailler, peut être amené à allouer une priorité secondaire à la correction de ce problème.

Dans l’exemple ci-dessous, nous montrons un exemple d’administration de la performance  via SecurActive NSS, permettant à l’administrateur du réseau de visualiser en quelques secondes sur un graphe, la représentation caractéristique d’un ralentissement sur un serveur de fichier, et ainsi de confirmer l’impression de mauvaise performance perçues par les utilisateurs.

Exemple :

Mise en œuvre de la surveillance des performances d’une application de partage de fichiers (port 445) et consultation des graphes correspondants :

Pic de RTT sortant

Dans graphe ci-dessous, le pic correspond au RTT sortant (pour rappel : cette métrique “RTT sortant” permet d’illustrer les performances par rapport à la latence réseau du coté du client TCP – émetteur des paquets SYN) .

En visualisant  la liste des flux ayant généré ce graphe, il est possible de disposer des adresses IP clientes (en cliquant dans le graphe à l’endroit exact du problème).
L’administrateur dispose à partir de ce moment là, des informations de latence et les adresses IP concernées par les ralentissements.

Il est donc à même d’évaluer les dires et ressentiments de ses utilisateurs, en quelques secondes …

What is ICMP?

ICMP stands for Internet Control Message Protocol and is also a common IP transport protocol. It seems pretty explicit, although most people reduce ICMP to ping reply commands, a good way to test whether a host can be reached through a network and how much it takes for a packet to make a round trip through the network…
Obviously ping and trace-route-like tools are very useful for network administrators… but there is much more to say about ICMP and the help it can provide for network administration & diagnosis.
In total, ICMP can be used to send more than twenty types of control messages. Some are just messages, some others are a way for IP devices or routers to indicate the occurrence of an error. You can get a full list of existing ICMP messages on http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

How does ICMP work?

Ping

Ping is the simplest command using ICMP messages (echo request); it sends towards a network address an echo request packet (or DNS name, which will be resolved into an IP address). The destination can then send back an echo reply packet. The request sender will then be able to know whether the destination is reachable through ICMP or not and get an evaluation of the time required for the ICMP message to make the round trip to the destination. Ping is frequently used to test the availability of a host and to evaluate the network response time. The time-to-live indicated corresponds to the original TTL of the sender minus the number of hops that was necessary to reach the destination. For instance, hereunder the original TTL is 64 (see sniffer screenshot), which means that the ICMP message went through 10 routers (64-54) to reach www.google.com.

xxx@xxx:~$ ping www.google.com PING www.l.google.com (209.85.227.103) 56(84) bytes of data.
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=1 ttl=54 time=12.9 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=2 ttl=54 time=12.5 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=3 ttl=54 time=11.9 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=4 ttl=54 time=12.4 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=5 ttl=54 time=12.4 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=6 ttl=54 time=13.1 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=7 ttl=54 time=12.4 ms

Traceroute

A traceroute is a command (it can traceroute or tracert according to the system which is used) that sends a sequence of ICMP packets with a TTL value which is incremented by one each time. This means that the first packet (TTL = 1) will reach the first router, which will send back an ICMP packet, and the second one (TTL = 2) will reach the second router, which …. and so on. The result will be the list of routers or hops to reach the destination with a response time for each:

traceroute to www.google.fr (209.85.227.99), 30 hops max, 40 byte packets
1 fw1.prod.securactive.lan (192.168.xxx.xxx) 0.234 ms 0.430 ms 0.421 ms
2 82.227.168.254 (82.227.168.254) 6.147 ms 7.136 ms 8.125 ms
3 * * *
4 bzn-crs16-1-be1010.intf.routers.proxad.net (212.27.50.170) 11.576 ms 12.066 ms 13.054 ms
5 cbv-6k-1-po20.intf.routers.proxad.net (212.27.50.190) 14.044 ms * *
6 74.125.50.117 (74.125.50.117) 16.506 ms 15.625 ms 16.514 ms
7 209.85.250.142 (209.85.250.142) 56.473 ms 50.894 ms 50.417 ms
8 209.85.243.111 (209.85.243.111) 21.928 ms 216.239.43.233 (216.239.43.233) 14.945 ms 209.85.243.111 (209.85.243.111) 19.445 ms
9 216.239.49.45 (216.239.49.45) 15.953 ms 14.959 ms 209.85.252.83 (209.85.252.83) 12.945 ms
10 209.85.243.93 (209.85.243.93) 25.932 ms 209.85.243.97 (209.85.243.97) 13.450 ms 209.85.243.89 (209.85.243.89) 16.446 ms
11 wy-in-f99.google.com (209.85.227.99) 14.940 ms 13.429 ms 15.455 ms

Traceroute can help you understand what the route to a certain destination is and eventually where the response time or packet loss can take place.

Error messages

Let’s describe the most typical ICMP error messages you can find on networks.

ICMP Network Unreachable

Context

Let’s take the simplest example: one machine sitting on a LAN (192.168.0.7), has one default gateway (192.168.0.254), which is the router. It is trying to reach a server, which does not sit on the LAN (10.1.0.250) and which cannot be reached, because 192.168.0.254 does not know how to route this traffic.

xxxxx:~$ ifconfig eth0
Link encap:Ethernet  HWaddr 00:21:70:ba:52:ab inet adr:192.168.0.7
Bcast:192.168.0.255  Masque:255.255.255.0 adr inet6: fe80::221:70ff:feba:52ab/64 Scope:Lien
…
traceroute to www.google.com (209.85.229.106), 30 hops max, 60 byte packets
1  192.168.0.254 (192.168.0.254)  1.435 ms  1.717 ms  2.031 ms
2  88.189.126.254 (88.189.126.254)  28.478 ms  39.345 ms  39.342 ms
3  * * *
…..
11  ww-in-f106.google.com (209.85.229.106)  79.061 ms  68.128 ms  79.744 ms

PING 10.1.0.250 (10.1.0.250) 56(84) bytes of data. —
10.1.0.250 ping statistics —
47 packets transmitted, 0 received, 100% packet loss, time 46327ms

Step 1:

Step 1: Network unreachable

Step 2:

Step 2: Network unreachable

Step 3:

Step 3: Network unrechable

ICMP Host Unreachable

Context

Let’s take the simplest example: one machine sitting on a LAN (10.1.2.23), has one default gateway (10.1.2.254/24), which is the router. It is trying to reach a server, which does not sit on the LAN (192.168.1.15). The traffic flows and reaches the last router before the server (192.168.1.254/24; this router cannot reach 192.168.1.15 (because it is unplugged, down or it does not exist).

Step 1:

Step 1: Host unreachable

Step 2:

Step 2: Host unreachable

Step 3:

Step 3: Host unreachable

ICMP Port Unreachable

Let’s take a second example: one machine sitting on a LAN (192.168.0.7). It is trying to reach a server 192.168.0.254, which sits on the LAN on port UDP 4000, on which the server does not respond.

ICMP Port unreachable

All the information you can find in an ICMP error message!

Provided you are used to analying traffic with a sniffer, this looks quite explicit: in the ICMP part of the payload of an ICMP error packet, you can find all the information required to understand which flow triggered the error. Of course, you can read the type and code of the ICMP error, but you can also find the IP source and destination of the error, as well as protocol, source & destination ports.

ICMP Network capture

Where is the challenge with ICMP?

You may be tempted to say: if it is that simple, why do we need on top of any sniffer? All the information sits in the payload…
But in every network, you will find some ICMP errors… they may be due to a user trying to connect to a bad destination, or trying to reach a server on the wrong port… The key is in having a global view of how many errors you have normally and currently and from where to where. The key to leveraging ICMP information is in having a relevant view of it and understanding what it means.

How can ICMP help on network diagnostic and security monitoring?

From the explanation here above, we can keep in mind that by analysing ICMP errors we can be identify machines that try to connect networks or machines, that are routable from the LAN’s machine or ones that try to connect on actual servers but for services whose ports are not open.
Here are some examples of phenomena that can be identified that way:

Misconfigured workstation

A workstation repeats a large volume of missed attempts to connect to a limited number of servers: it may be that this machine does not belong to the company’s workstations (external consultant on the network, whose laptop is trying to reach common resources on his home network -DNS, printers,…), or it may be the machine of someone coming from a remote site with its own configuration or a machine that has been simply wrongly configured.

How would we see it?

A large number of ICMP Host Unreachable errors coming from one or several routers to this machine or this group of machines. The ICMP information contained in the payload of each of these errors would probably show they are trying to reach a certain number of hosts for some services or applications.

Migration legacy

A certain number of machines keep requesting DNS resolution to a DNS server which has been migrated (this could be true for any application available on the network). Their users certainly feel worse performance when trying to use these services.

How would we see it?

A large number of ICMP Host Unreachable errors coming from one or several routers to a group of machines. The ICMP information contained in the payload of each of these errors would probably show they are all trying to reach the previous IP address of a given server.

Network device misconfiguration

A router does not have a route configured; some machines are trying to reach some resources, unsuccessfully.

How would we see it?

A large number of ICMP Network Unreachable errors coming from one router to many machines. The ICMP information contained in the payload of each of these errors would probably show they are all trying to reach the same network through the same router.

Port scanning

A machine is trying to complete a network discovery. It is trying to connect to all servers around to see on which ports they are open.

How would we see it?

A large number of ICMP Port Unreachable errors coming from one or several routers corresponding to a single machine (the one which is scanning).

Spyware / Worms

An infected machine is trying to propagate its spyware, virus or worm throughout the network; obviously it has no previous knowledge of the network architecture.

How would we see it?

A large number of ICMP Host Unreachable errors coming from one or several routers corresponding to a limited number of hosts, trying to reach a large volume of non existing machines on a limited set of ports.

How you could see that in SecurActive NSS in less than 30 seconds!