Graphes de Terrain

1/72

Paris traceroute et load-balancingDynamique de la topologie de l’internet

Détection d’événements dans la dynamiqueBiais induit par la dynamique

Graphes de TerrainDynamiques de l’internet

Clémence Magnien

LIP6 – CNRS and Université Pierre et Marie Curie

[email protected]

14 février 2013

1/72

[email protected]

2/72



Jusqu’à présent on a supposé :

une seule route entre une source et une destination

routes fixes au cours du temps

...les deux sont faux

2/72

3/72



1 Paris traceroute et load-balancingBiais associé au load-balancing

2 Dynamique de la topologie de l’internetContexte et approcheTracetreeMesuresAnalyse

3 Détection d’événements dans la dynamique

4 Biais induit par la dynamique

3/72

4/72



Biais associé au load-balancing

Outline





4/72

5/72




Principaux travaux de référence

Fabien Viger, Brice Augustin, Xavier Cuvellier, ClémenceMagnien, Matthieu Latapy, Timur Friedman et Renata Teixeira

Detection, understanding, and prevention of traceroutemeasurement artifactsComputer Networks 52-5, 2008.

5/72

6/72




Load-balancing

Load-balancing (équilibrage de charge)

Hop 6 Hop 7 Hop 8 Hop 9

20

10 01

10 01

2 1

1 0

S L ECA

B D

L envoie les paquets pour E tantôt vers A, tantôt vers B.

6/72

7/72




Problème causé par le load-balancing

Traceroute −→ Information manquante ou fausse

7/72

7/72







20

10 01

10 01

2 1

1 0

S L ECA

B D

7/72

7/72







20

10 01

10 01

2 1

1 0

S L ECA

B D

L 0

7/72

7/72







20

10 01

10 01

2 1

1 0

S L ECA

B D

0AL 0

7/72

7/72







20

10 01

10 01

2 1

1 0

S L ECA

B D

0

0

A

DL 0

7/72

7/72







20

10 01

10 01

2 1

1 0

S

0

0

A

DL 0 E1

L ECA

B D

Faux liensNœuds non vus

7/72

8/72




Problèmes – 2

Boucles:

TTL = 6

TTL = 8

TTL = 7

TTL = 9

What we see:Hop 6 Hop 7 Hop 8 Hop 9

Hop 8Hop 7Hop 6

1

20

0 1

100 1

0

1 2000S L

A

B CE AL E

8/72

9/72




Problèmes – 3

Cycles:

Différence de longeur entre routes = k

→ cycle de longueur k

9/72

10/72




Load-balancing

Plusieurs types de load-balancing :

par paquet→ aléatoire, round-robin

par flot→ paquets d’une même application sur le même chemin

par destination→ paquets pour une même destination sur le même chemin

10/72

11/72




traceroute et load-balancing

par paquet → aucun contrôle

par flot

par destination

11/72

11/72






par flot

par destination

Flot = IPs + ports source & destination, protocole

traceroute varie systématiquement le port destination→ les paquets suivent systématiquement des chemins différents

11/72

11/72






par flot

par destination

Pas de biais dans les mesures avec traceroute

11/72

12/72




Paris-traceroute

Variante de traceroute :les ports source/dest sont gardés constants pendant toute lamesure(utilisation d’autres champs de l’en-tête pour identifier les paquets)

→ pas de problème avec le load-balancing par flot

12/72

13/72




Question

Quel est l’impact en pratique du load-balancing ?

Comparer des mesures avec traceroute et paris-traceroute

13/72

14/72




Mesures

5000 destinationsune passe :

un traceroute vers chaque destinationun paris-traceroute vers chaque destination

1 465 passes (74 jours)

14/72

15/72




Boucles

avec traceroute : ∼ 7% des IP ont une boucle→ 90% des boucles disparaissent avec paris-traceroute

15/72

16/72




Cycles

Cycles : rares avec traceroute (fréquence 0.6%)→ 80% des cycles disparaissent avec paris-traceroute

load-balancing ou événements rares ?

16/72

17/72




Diamants

0

0

0

0

00

0

A

B E

C

LD

G

(L0, D0) → taille 3(L0, E0), (A0, G0), (B0, G0) → taille 2

Le load-balancing crée des diamants

17/72

18/72




Diamants

traceroute :

28 231 diamants

diamants vers 90% des destinations

21.3 diamant / destination en moyenne

paris-traceroute :

52% des diamants disparaissent

diamants vers 89% des des destinations

9.7 diamant / destination en moyenne

18/72

18/72




Diamants

1e-05

1e-04

0.001

0.01

0.1

1

0 10 20 30 40 50 60 70 80

Fre

quen

cy

Size of the global diamonds

1e-05

1e-04

0.001

0.01

0.1

1

0 10 20

Fre

quen

cy


18/72

18/72




Diamants

1e-05

1e-04

0.001

0.01

0.1

1

0 10 20 30 40 50 60 70 80

Fre

quen

cy


1e-05

1e-04

0.001

0.01

0.1

1

0 10 20

Fre

quen

cy


Moins de diamants avec paris-traceroute

Diamants moins gros

le load-balancing par flot crée de faux liens

18/72

19/72




Diamants – questions

Diamants restants : load-balancing par paquet ou vrais liens ?

Certains diamants sont vus avec paris-traceroute mais pastraceroute

événements ?

19/72

20/72



Contexte et approcheTracetreeMesuresAnalyse

Outline





20/72

21/72




Principaux travaux de référence

Matthieu Latapy, Clémence Magnien et Frédéric Ouédraogo

A Radar for the internetFirst International Workshop on Analysis of Dynamic Networks,2008.

Clémence Magnien, Frédéric Ouédraogo, Guillaume Valadonet Matthieu Latapy

Fasts dynamics in Internet topology: observations and firstexplanationsFourth International Conference on Internet Monitoring andProtection, 2009.

21/72

22/72




Résumé

Cartographie au niveau IP

Long et coûteux

Tendances actuelles

Données massives(multiplier sources et destinations, mesures distribuées, . . . )

Améliorer la qualité

Dynamique ?

22/72

23/72




Notre approche

Ce qu’une machine voit de l’internet est :• intéressant en soi• (plus) facile à mesurer• (plus) facile à interpréter• peut être mesuré efficacement (temps, charge)

notion de vision égo-centrée

Mesure efficace + simple =⇒ Répétition

étude de la dynamique

Radar

une source, des destinations, mesures périodiques

23/72

24/72




Vue égo-centrée

24/72

25/72




Mesure avec traceroute

25/72

25/72




Mesure avec traceroute

*

25/72

26/72




Charge déséquilibrée

*

26/72

26/72




Charge déséquilibrée

many probes onlinks closest

0

500

1000

1500

2000

2500

3000

0 5 10 15 20 25 30

x = distance du moniteur, y = # sondes

26/72

27/72




Limites de traceroute

charge déséquilibrée

⇒ information redondante

pas un arbre

⇒ complique l’analyse

→֒ nécessité d’un outil dédié

tracetree

27/72

28/72




Tracetree

Mesures en arrière, en parallèle, arrêt lorsque les chemins serencontrent

28/72

28/72




Tracetree

*

Mesures en arrière, en parallèle, arrêt lorsque les chemins serencontrent

28/72

28/72




Tracetree

*

Limite du rayon (TTL max):Sonder jusqu’à une distance donnée du moniteur

28/72

29/72




Tracetree et radarTracetree

1 paquet par lien

mesure homogène et rapide

arbre

−→ programme disponible, écrit en C .

Radar

Une source

Un ensemble de destinations

Mesures périodiques avec tracetree

Tracetree : mêmes problèmes que traceroute pour la qualité de lamesure

29/72

30/72




tracetree vs traceroute: comparaison empirique

traceroute

tracetree

13400

13500

13600

13700

13800

13900

14000

14100

14200

14300

20 30 40 50 60 70 80 90 100 110

x=nb de passes, y=nb d’adresses IP

30/72

30/72





tracetree

traceroute

13400

13500

13600

13700

13800

13900

14000

14100

14200

14300

1e+06 2e+06 3e+06 4e+06 5e+06 6e+06 7e+06

x=nb de paquets, y=nb d’adresses IP

30/72

30/72





tracetree

traceroute

A B

13400

13500

13600

13700

13800

13900

14000

14100

14200

14300

1e+06 2e+06 3e+06 4e+06 5e+06 6e+06 7e+06

x=nb de paquets, y=nb d’adresses IP

30/72

31/72




Paramètres

Plusieurs paramètres des mesures

Quelles sources / destinations?Combien de destinations?

Délai entre passes?Timeout?

. . .

Compromis

Haute fréquenceGrande quantité de donnéesFaible charge sur le réseau

31/72

32/72




Paramètres: la fréquence

— Moniteur de test— Moniteur de contrôle

speed−upmeasurement

10400

10600

10800

11000

11200

11400

11600

11800

12000

0 10 20 30 40 50 60 70 80

x=# heures, y=# IP

32/72

33/72




Paramètres: nombre de destinations


3000 d.

1000 d.

10000 d.

3000 d.

0

5000

10000

15000

20000

25000

30000

0 10 20 30 40 50 60 70 80 90

x=# heures, y=# IP

33/72

33/72




Paramètres: nombre de destinations


3000 d.

1000 d.

10000 d.

1000 d. (sim)

3000 d.3000 d. (sim)

0

5000

10000

15000

20000

25000

30000

0 10 20 30 40 50 60 70 80 90

x=# heures, y=# IP

33/72

34/72




Nos mesures

Deux ensembles de paramètres:

normal: 3000 destinations, 10 min. délai entre passes,TTL max 30, ... ∼ 100 passes / jour

rapide: 1000 destinations, 1 min. délai entre passes,TTL max 15, ... > 800 passes / jour

Sources: PlanetLab et autres (> 100)

Destinations: Aléatoires, répondant au ping

Plusieurs mois de mesure ininterrompue

Données disponibles pour étude

34/72

35/72




Analyse de la dynamique

Caractéristiques attendues :

dynamique normaleload-balancingchangements dans les routes. . .

événements spécifiquespannes. . .

35/72

36/72




Analyse

Quelle dynamique ?

Pour :

mieux comprendre

modéliser, simuler

détecter des événements

...

Comment répondre cette question ?

Pas de méthode toute faite

36/72

37/72




Étude d’une passe

Variations en fonction :

de la source

du moment

Quelques tendances générales

∼ 12 000 IP

∼ 12 000 étoiles

la plupart des nœuds à distance 13-18

On observe toujours le même type de comportements

37/72

38/72




Visualisation

Fichier externe out3.gif

38/72

39/72




Propriétés simples au fil du temps

Première approche :Évolution de propriétés simples au fil du temps

nombre d’IP

nombre d’étoiles

durée des passes

. . .

39/72

39/72





0

2000

4000

6000

8000

10000

12000

14000

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

IP

Date

Nombre d’IP par passe

source au Japondeux mois de mesures∼ 6 000 passes

39/72

39/72





0

2000

4000

6000

8000

10000

12000

14000

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

IP

Date

Nombre d’IP par passe

Plus ou moins constant (changement de régime)Pics vers le bas → déconnections ?Pas de pics vers le haut

39/72

40/72




Présence des IP

Distribution du nombre de présences

Toutes les IP vues pendant la mesure (∼ 29 000)Pour chaque IP : nombre de passes où on l’a vue

−→ Distribution

40/72

40/72




Présence des IP

2 mois ∼ 6000 passes

0

500

1000

1500

2000

2500

3000

3500

0 1000 2000 3000 4000 5000 6000

Nb

IP

Nb times seen

40/72

40/72




Présence des IP


0

500

1000

1500

2000

2500

3000

3500

0 1000 2000 3000 4000 5000 6000

Nb

IP

Nb times seen

Beaucoup d’IP éphémères(vues très peu de fois)

Un nombre non négligeable d’IP stables(vues presque à chaque fois)

40/72

41/72




Présences vs apparitions

0

200

400

600

800

1000

1200

1400

0 1000 2000 3000 4000 5000

App

ariti

ons

Observations

1 2 3 4 5 6 7 8• • • • •

5 présences, 2 apparitions

41/72

41/72





-200

0

200

400

600

800

1000

1200

1400

0 1000 2000 3000 4000 5000

App

ariti

ons

Observations

Parabole : load-balancing

p = 1/2 −→ x = n/2, y = 1/2 ∗ 1/2 ∗ n = n/4

41/72

41/72





-200

0

200

400

600

800

1000

1200

1400

0 1000 2000 3000 4000 5000

App

ariti

ons

Observations

p quelconque : x = np, y = p(1− p)n−→ y = n ∗ x/n ∗ ((n − x)/n)

41/72

41/72





-200

0

200

400

600

800

1000

1200

1400

0 1000 2000 3000 4000 5000

App

ariti

ons

Observations

Deux classes différentes

parabole : load-balancing

proche de l’axe des x : addresses stables

41/72

42/72




Dynamique : stabilisation?

Comportement attendu

x = # de passesy = # d’adresses IP distinctes depuis le début

42/72

43/72




Dynamique : stabilisation ?

Nombre d’IP distinctes observées depuis le début

10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

30000

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

dist

inct

IP

Date

nouvelles IP observées en permanence

43/72

44/72




Disparitions

Nombre d’IP distinctes qu’on ne verra plus jamais

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

dist

inct

IP

Date

Renouvellement continu des IP observées

44/72

45/72




Tentatives d’explication

Croissance surprenante

Deux explications “naturelles”

ip aléatoires

ip dynamiques

45/72

46/72




IP vues une seule fois ?

10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

dist

inct

IP

Date

>= 2

46/72

46/72





10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

dist

inct

IP

Date

>= 2>= 10

46/72

46/72





10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

dist

inct

IP

Date

>= 2>= 10>= 50

46/72

46/72





10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

dist

inct

IP

Date

>= 2>= 10>= 50

>= 200

46/72

46/72





10000

12000

14000

16000

18000

20000

22000

24000

26000

28000

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

dist

inct

IP

Date

>= 2>= 10>= 50

>= 200>= 1000

De nouvelles IP récurrentes...Élimine l’hypothèse des IPs aléatoires

46/72

47/72




Des IP dynamiques ?Destinations “stables”... (un critère possible: le père dans l’arbre atoujours la même adresse)

200

400

600

800

1000

1200

1400

1600

1800

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

dist

inct

IP

Date

courbes de mesures sur ces adresses ont même allure.

Élimine l’hypothèse des IPs dynamiques

47/72

48/72




Autonomous Systems

Autonomous System (AS) : institution indépendanteChaque IP est dans un AS−→ Nombre d’AS vus depuis le début de la mesure

48/72

48/72




Autonomous Systems

900

920

940

960

980

1000

1020

1040

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

As

Date

48/72

49/72




Routeviews

Projet Routeviews

Nombreux moniteursHistorique des tables de routage

49/72

49/72




RouteviewsSimulation du radar au niveau ASMoniteur proche de la source

Table de routage

4.23.112.0/24 4777 2516 215 171327500 2497 215 17132

4.23.113.0/24 4777 2516 324 218897500 2497 324 218892497 174 21889

4.23.114.0/24 4812 3015 174 53137500 2497 174 5313

49/72

49/72




RouteviewsSimulation du radar au niveau ASMoniteur proche de la sourceDestination → préfixe

Table de routage

4.23.112.0/24 4777 2516 215 171327500 2497 215 17132

4.23.113.0/24 4777 2516 324 218897500 2497 324 218892497 174 21889

4.23.114.0/24 4812 3015 174 53137500 2497 174 5313

49/72

49/72




RouteviewsSimulation du radar au niveau ASMoniteur proche de la sourceDestination → préfixe→ensemble de chemins d’AS

Table de routage

4.23.112.0/24 4777 2516 215 171327500 2497 215 17132

4.23.113.0/24 4777 2516 324 218897500 2497 324 218892497 174 21889

4.23.114.0/24 4812 3015 174 53137500 2497 174 5313

49/72

49/72




Routeviews

800

850

900

950

1000

1050

1100

1150

1200

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

As

Date

49/72

50/72




Nouveaux AS ?

AS observés après le début de la mesure (72)→ Nouveaux ?

Historique des tables de routage

70 AS dans la première table de routage

Observations dûes à la dynamique BGP

50/72

51/72




Tous les as sont-ils équivalents ?

Distribution de la taille observée

1

10

100

1000

1 10 100 1000 10000

Nb

dist

inct

IP

Date

51/72

52/72




Nouveautés à l’intérieur des as ?

Plus gros AS : 1333 IP

300

400

500

600

700

800

900

1000

1100

1200

1300

1400

26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08

Nb

dist

inct

IP

Date

52/72

53/72




Conclusion sur les apparitions d’IP

Renouvellement continu des IP observées

pour les IP volatiles

pour les IP stables

Nouvelles IP observées

à l’intérieur des AS déjà vus

dans des AS nouvellement observés

Observation de nouveaux AS ← dynamique BGPRemarque:lien avec les nouveaux diamants observés avec paris-traceroute:découverte d’IPs entre la passe de traceroute et celle deparis-traceroute.

53/72

54/72




Causes importantes des apparitions d’IP

1000

2000

3000

4000

5000

6000

7000

0 500 1000 1500 2000 2500 3000

Nom

bre

de lie

ns

Nombre de passes

pente

load-balancing

évolution du routage+ load-balancing

+ évolution du routage

54/72

55/72



Outline





55/72

56/72



Approches

Plusieurs approches pour détecter les événements

Par signature

Si on sait à quoi ressemble un événement (signature)→ détection de la signature dans les données

Top-down

Pas d’a priori sur la dynamique−→ on cherche à détecter les événements différents de ladynamique normale

56/72

57/72



Méthodologie

[Detecting Events in the Dynamics of Ego-centered Measurementsof the Internet Topology

Hamzaoui, Latapy, Magnien, 2010]

Distribution d’une statistique, trois cas possibles :

homogène

hétérogène

homogène avec outliers

57/72

58/72



Nombre de nœuds par passe

0

2000

4000

6000

8000

10000

12000

1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Statistique au fil du temps

58/72

58/72




0

5

10

15

20

25

30

35

0 2000 4000 6000 8000 10000 12000

Distribution

58/72

58/72




0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

0 2000 4000 6000 8000 10000 12000

Distribution cumulative inverse

58/72

58/72




0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

0 2000 4000 6000 8000 10000 12000


Conclusion

Pics vers le bas significatifs

Événements non intéressants (pertes de connexion locales)

58/72

59/72



Nombre de nœuds dans plusieurs passes consécutivesStatistique : nombre d’IP distinctes dans l’union de 5 passes

7000

8000

9000

10000

11000

12000

13000

14000

1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Statistique au fil du temps

59/72

59/72




0

5

10

15

20

25

30

35

7000 8000 9000 10000 11000 12000 13000 14000

Distribution

59/72

59/72




0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

10500 11000 11500 12000 12500 13000 13500 14000


59/72

59/72




0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

10500 11000 11500 12000 12500 13000 13500 14000

Conclusion

Pics significatifs

Pics vers le haut → changements

Pics vers le bas significatifs ? (perte de connexion localelongue ?)

59/72

60/72



Interprétation des événements

Événement statistiquement significatif détecté→ Interprétation ?But : compréhension, pertinence de l’événement

Deux approches

Corrélations avec des événements connus

Dessin

60/72

61/72



Tickets d’incidents AbileneDans certains cas, correspondance entre un incident détecté et unticket d’incident

0

200

400

600

800

1000

0 1000 2000 3000 4000 5000 6000 7000

AFFECTED: Peer SINET (CHIC)

STATUS: Unavailable

START TIME: Thursday, May 17, 2007, 11:47 AM (1147) UTC

END TIME: Pending

DESCRIPTION: Peer SINET’s connection the Internet2 IP

Community is unavailable. SINET Engineers

have been contacted, however, no cause of

outage has been provided yet. SINET is multi-homed.

TICKET NO.: 10201:45

TIMESTAMP: 07-05-18 00:40:43 UTC

61/72

62/72



Tickets d’incidents Abilene

Dans certains cas, correspondance entre un incident détecté et unticket d’incident

0

200

400

600

800

1000

0 1000 2000 3000 4000 5000 6000 7000

STATUS: Available

START TIME: Thursday, May 17, 2007, 11:47 AM (1147) UTC

END TIME: Friday, May 18, 2007, 3:51 AM (0351) UTC

DESCRIPTION: Peer SINET was unavailable to the the Internet2 IP

Network Community. SINET Engineers reported the

reason for outage was due to a fiber cut in New York.

SINET is multi-homed.

TICKET NO.: 10201:45

TIMESTAMP: 07-05-18 07:39:16 UTC

62/72

63/72



Dessin

63/72

64/72



Pour aller plus loin

Comparer les événements détectés avec d’autres statistiques

Caractérisation automatique du type de distributionfit

Détection automatique et rigoureuse des outliers

64/72

65/72



Outline





65/72

66/72



Présence des IP

Distribution du nombre de présences

Toutes les IP vues pendant la mesure (∼ 29 000)Pour chaque IP : nombre de passes où on l’a vue

−→ Distribution

66/72

66/72



Présence des IP


0

500

1000

1500

2000

2500

3000

3500

0 1000 2000 3000 4000 5000 6000

Nb

IP

Nb times seen

66/72

66/72



Présence des IP


0

500

1000

1500

2000

2500

0 1000 2000 3000 4000 5000 6000

Nb

IP

Nb times seen

66/72

66/72



Présence des IP

2 mois ∼ 6000 passes — Distrib. cumulative

0

5000

10000

15000

20000

25000

30000

0 1000 2000 3000 4000 5000 6000

Nb

IP

Nb times seen

66/72

66/72



Présence des IP

1 mois ∼ 3000 passes — Distrib. cumulative

0

5000

10000

15000

20000

25000

0 1000 2000 3000 4000 5000 6000

Nb

IP

Nb times seen

66/72

67/72



Observations dépendantes de la durée de la mesure ?

Mesure plus longue :

Moins d’IP stables

Plus d’IP éphémères

Conclusion ?

Méthodologie

Augmenter la taille de la fenêtre de mesure

Évolution de la distribution

67/72

68/72



Distributions normalisées

Problème :

Valeur max en x : nombre de passes

Valeur max en y : nombre total d’IP vues en N passes

Les courbes ne sont pas directement comparables

Normalisation

y : fraction des IP observées

x : fraction des passes

68/72

69/72



Résultats10 000 passes → ∼ 100 jours

69/72

69/72



Résultats10 000 passes → ∼ 100 jours

Mesure plus longue :

Moins d’IP stables

Plus d’IP éphémères

Pas de convergence69/72

70/72



Étudier la convergenceNombre d’IP vues au moins x% des passes,en fonction de la durée de mesure

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

0 2000 4000 6000 8000 10000 12000

0.100.300.500.900.99

0.9950.999

∼ 2 000 IP présentes à 99.5% des passes→ noyau stable ?

70/72

71/72



Lien avec la détection d’événementsPour certains moniteurs / certaines périodes

0

500

1000

1500

2000

2500

3000

3500

4000

0 50 100 150 200 250 300 350 400 450 500

"parse_hash_1_501.dat"

500 passes au totalBeaucoup d’IP vues 25 ou 475 passes

événement de durée 25 passesvidéo events.avi

71/72

72/72



Conclusion

Dynamique(s) rapide(s)

Besoin de comprendre

Influence sur la cartographie

Étudier rigoureusement l’impact de la durée/la fréquence demesure ?

72/72

Graphes de Terrain

Documents

Transcript of Graphes de Terrain