mesures actives
TRANSCRIPT
2
Métrologie sur un backbone
3
Plan
• En quoi consiste l’administration d’un réseau?
• Pourquoi de la métrologie ?• Approches• Les mesures passives• Les mesures actives• Conclusion
4
l’administration d’un réseau
• Ensemble de fonctions permettant:
• Monitoring (Fault management)
• Sécurité
• Topologie
• Configuration
• Métrologie
5
Pourquoi de la métrologie ?
Pour assurer une meilleure supervision du fonctionnement du réseau et disposer d'un outil d'aide au diagnostic.
Pour optimiser l’architecture et le dimensionnement du réseau.Exemple : RENATER est passé d’un réseau en étoile à un réseau maillé dont le nombre de boucles croît dans le temps (modélisation)
Pour renforcer la sécurité sur le réseau en détectant mieux les incidents ou attaques et en quantifiant leurs conséquences :
Certains incidents surchargent fortement les routeurs de RENATER et dégradent le service offert
Pour permettre une bonne corrélation entre les sources de financement et les usages qui sont faits du réseau :
- Répartition de l'usage du réseau par organisme/client- Permettre de découpler le débit de raccordement du site sur le réseau régional ou le
MAN de celui agréé par RENATER
Pour mieux se préparer à l'introduction de la qualité de service sur le réseau.
6
Plan
• Pourquoi de la métrologie ?• Approches
• La métrologie passive• La métrologie active• Les mesures par lien• Les mesures de bout-en-bout• L’échantillonnage
• Les mesures passives• Les mesures actives• Conclusion
7
Mesures passives
• Mesures passives:• Etude du comportement du trafic après capture. Etude
microscopique (à partir des paquets) ou macroscopique (flux). • Les outils possibles sont : Netflow, cartes (sondes) DAG, Ipanema et
QosMos, tcpdump ...
A
R1 R2
B
R1 R2
8
Mesures par lien
• Les métriques sont :• le nombre de paquets,• le nombre d’octets,• le nombre de paquets droppés • le nombre de flux (ainsi que la taille en paquets et octets de
chaque flux)• Mesures quantitatives • Exemples d’outils:
• SNMP MIBs• RTFM (Real-Time Flow Measurement)• NetFlow de Cisco (base de la proposition IPFIX à l’IETF)
9
Résumé
• On peut considérer deux « couches » de mesures passives :• La couche « flux » :
• Adresses IP source et destination• Numéro de port• protocole (couche 3)• Taille (en octets et paquets)• ...
• La couche réseau : • Utilisation du lien (bit/s, paquets/s)• Comptage des drops• Mesures des équipements :
• Utilisation de la CPU• Température
• Les mesures actives représentent l’utilisation de l’ensemble de ces couches
10
Mesures actives• Mesures actives :
• Etude du comportement d'un trafic sonde (généré pour l'occasion)
• Souvent : générations de trains de paquets sondes toutes les 30 secondes, en employant les différents protocoles (IPv4, IPv6, ICMP, TCP, UDP, parfois ouvertures de sessions applicatives). Plusieurs indicateurs sont regardés : délais, gigue, pertes, qualité audio ... Les outils sont souvent orienté sonde client-serveur.
• Un comportement anormal des paquets sondes met en évidence un problème, mais beaucoup de problèmes ne seront pas visibles car le trafic concerné ne sera pas caractérisé par les trains.
• Les outils possibles sont : Ping, traceroute, RIPE TTM, WitBe, QoSMetrics, NetPerf, pchar ...
CD
Paquets sondes de C vers D
R3 R4
11
Mesures de bout en bout
• Distinction entre les performances de l’hôte et du réseau• Exemple : Temps fibre / performance d’un serveur
web• Toutes les mesures de bout-en-bout (E2E) sont
des mesures actives par nature.• Fournit des statistiques sur le chemin :
• L’aller et le retour sont-ils symétriques ?• Les paquets sondes subissent-ils le même traitement ?
• Possibilité d’inférence entre le trafic « sonde » et le trafic normal.
12
Mesures de bout en bout (2/2)•La perception de l’utilisateur•L’application•L’OS•La pile IP•La carte réseau•Le réseau local •Le réseau régional•La connectivité…•Le réseau national•Les connexions internationales
Ce qu’il faut prendre en compte de chaque côté :
13
L’échantillonnage
• Capture de flux en mode échantillonné(un flux : identifié par les paquets composés le même t-uple : src ip & port, dst ip & port, protocole)
• Envoie de paquets pour des mesures actives en mode échantillonné.
14
Plan
• Pourquoi de la métrologie ?• Approches• Les mesures passives
• Présentation d’un backbone national• Les MIBs et SNMP• NetFlow
• Les mesures actives• Conclusion
15
RENATER-3• Les services:
• IPv4• IPv6• Allocation d'adresses IP
(actuellement 4000 blocs en IPv4)• MPLS (service ATOM )
• Multicast IPv4• Les classes de services (cf
article JRES2003 )
16
Le "Nœud Régional"
Routeur Cisco 12xxx
Réseau deCollecte
Site
Backbone
switch
2,5 Gb/s1 Gb/s
100 Mb/sSite
Réseau deCollecte
17
Les MIBs et SNMP (1/4)
• MIB : bases de données sur les équipements accessibles par le protocole SNMP (Simple Network Management Protocol)
• Logiciels libres très répandus : MRTG, Cricket, RTG...• Une librairie très importante : UCD-SNMP ( aujourd'hui
renommée en Net-SNMP )• Évolution de SNMP
• v1 : Get, GetNext, Set• v2 : Get, GetNext, GetBulk, Set, Inform• v3 : sécurité et capacité d’administration
18
Les MIBs et SNMP (2/4)• Débits des interfaces:
• En Mb/s ou en paquets/s• Visualisation possible par tranche:
• De 24 h (jusqu'aux 4 derniers jours)
• Hebdomadaire• Semestrielle • Annuelle
• Charge de la CPU:
19
Les MIBs et SNMP (3/4)
• MIB v6 (en cours)• MIB MPLS • Les limites:
• Les courbes sont lissées (moyenne sur 5 minutes)• Vision du trafic IP (IPv4 avec IPv6)• Vision couche transport stricte• Difficultés de définir des alarmes sur le comportement d'un
débit:
20
Les MIBs et SNMP (4/4)
Exemple de « deny » de service
21
Exemples de Weathermap
22
23
Plan
• Pourquoi de la métrologie ?• Approches• Les mesures passives
• Présentation d’un backbone national• Les MIBs et SNMP• NetFlow
• Les mesures actives• Conclusion
24
NetFlow
• Définition d’un flux:
Informations sur un flux:- IP source
- IP destination
- port source
- port destination
- protocole
- type de service
- index de l'interface
+
Nombre de paquets du flux
Nombre d'octets du flux
temps: début et fin du flux
Index de sortie (interface)
AS source et destination
Masque des IP source et destination
Cumul des flags TCP
25
TCP/IP Headers
0
Source IP Address
Identification
3115 16
Destination IP Address
Time to Live
Total Lengthflags Fragment Offset
Header Checksum
Version HLEN ToS
Protocol
Source Port Number Destination Port NumberSequence Number
Urgent Pointer
Acknowledgement NumberHeader Reserved Window SizeTCP Flags
TCP Checksum
IP Header
TCP Header
26
NetFlow (suite)
• Exemple d’architecture :
• Caractéristiques :• un débit de 10 Mb/s en journée, 3Mb/s la nuit vers le
collecteur.• 8 millions de flux / 5 minutes en journée, un minimum de 2
millions la nuit (attention, 80% des équipements sont en mode échantillonnage).
27
NetFlow (suite)
• Exemple d'une connexion sur un serveur web:
• Sauvegardes des informations :• Ponctuelle pour le trafic relatifs à :
• Un routeur• Une interface• Une adresse IP• Un AS
• Permanente pour :• Un préfixe (exemple: débit du trafic pour chaque bloc d'adresses)• Certains ports
Adresse sourceAdresse destination Routeur
index d'entrée
index de sortie
Port source
Port dest. Prot Octets Paquets
AS source
AS dest.
193.49.159.141 194.199.8.10 193.51.179.66 16 14 1164 80 6 821 10 0 65037194.199.8.10 193.49.159.141 193.51.179.66 14 16 80 1164 6 14456 14 65037 0193.49.159.141 194.199.8.10 193.51.179.66 16 14 1165 80 6 544 7 0 65037194.199.8.10 193.49.159.141 193.51.179.66 14 16 80 1165 6 6582 7 65037 0193.49.159.141 194.199.8.10 193.51.179.66 16 14 1166 80 6 552 7 0 65037194.199.8.10 193.49.159.141 193.51.179.66 14 16 80 1166 6 6641 7 65037 0193.49.159.141 194.199.8.10 193.51.179.66 16 14 1167 80 6 551 7 0 65037194.199.8.10 193.49.159.141 193.51.179.66 14 16 80 1167 6 6895 8 65037 0193.49.159.141 194.199.8.10 193.51.179.66 16 14 1168 80 6 755 12 0 65037194.199.8.10 193.49.159.141 193.51.179.66 14 16 80 1168 6 20203 17 65037 0193.49.159.141 194.199.8.10 193.51.179.66 16 14 1169 80 6 460 5 0 65037
28
NetFlow (suite : informations retenues pour un préfixe)
L’information contenu dans la BD est disponible via une interface html/php:
Le trafic correspondant à un bloc d’adresses IP peut êtrevisualisé (soit en nb de flux/s soit en bits/s).Il y a environ 4000 blocs d’adresses IP allouées dans RENATER.
NR = nœud RENATER
29
NetFlow (suite)
• Répartition du trafic suivant les ports
• Alarmes sur les problèmes de routages(boucles).
• Matrice de trafic.
• Capture des flux suivant des signatures particulières au niveau du collecteur (ports, nombre de paquets, tailles,…):
• Génération chaque jour d'un top 40 des adresses ayant un trafic "singulier" (P2P, ftp Warez).
• Ces informations sont passées au CERT-RENATER pour y être traitées. Depuis Juin 2002, le trafic ne respectant pas la charte RENATER à baisser de moitié.
30
Protocoles
icmp2%
tcp84%
udp14%
others0%
icmptcpudpothers
Répartitions par protocoles
Répartition des flux et des octets pour le trafic du NR de Lyon
0 10 20 30 40 50
0
20
22
25
53
80
137
445
4662
5020
autres
OctetsFlux
Répartition par ports
31
NetFlow (suite)
• Détection d'attaques :• Lors de dépassement de seuil :
• Extrait des flux :
Adresse sourceAdresse destination Routeur
index d'entrée
index de sortie
Port source
Port dest. Prot Octets Paquets
AS source
AS dest.
194.57.222.66 163.15.163.247 193.51.177.42 5 3 1445 80 6 40 1 1715 7539194.57.222.211 163.15.163.247 193.51.177.42 5 3 1414 63 6 40 1 1715 7539194.57.222.170 163.15.163.247 193.51.177.42 5 3 1191 53 6 40 1 1715 7539194.57.222.190 163.15.163.247 193.51.177.42 5 3 1232 34 6 40 1 1715 7539194.57.222.18 163.15.163.247 193.51.177.42 5 3 1610 25 6 40 1 1715 7539194.57.222.10 163.15.163.247 193.51.177.42 5 3 1582 23 6 40 1 1715 7539194.57.222.139 163.15.163.247 193.51.177.42 5 3 1103 1 6 40 1 1715 7539194.57.222.203 163.15.163.247 193.51.177.42 5 3 1590 116 6 40 1 1715 7539194.57.222.116 163.15.163.247 193.51.177.42 5 3 1877 113 6 40 1 1715 7539194.57.222.34 163.15.163.247 193.51.177.42 5 3 1566 98 6 40 1 1715 7539194.57.222.166 163.15.163.247 193.51.177.42 5 3 1122 90 6 40 1 1715 7539194.57.222.1 163.15.163.247 193.51.177.42 5 3 1975 86 6 40 1 1715 7539194.57.222.182 163.15.163.247 193.51.177.42 5 3 1248 82 6 40 1 1715 7539194.57.222.163 163.15.163.247 193.51.177.42 5 3 1696 70 6 40 1 1715 7539194.57.222.6 163.15.163.247 193.51.177.42 5 3 1270 62 6 40 1 1715 7539
32
NetFlow (suite)
• Une limite :• Plus le trafic augmente, plus le traitement au niveau
de l'équipement devient un problème.
• La solution:L'échantillonnage (Sampled Netflow):
Sur RENATER: 10% des paquets (~1/2 des flux) sauf pour l’Ile de France et les DOM-TOM : 100% des paquets
33
NetFlow (suite et fin)
• Nouveaux formats de transport (v9): • Utilisation de "templates"• Intégration de nouveaux protocoles:
• IPv6• Multicast • MPLS
• Netflow Egress• Différents modes d'échantillonnage :
• Déterministe• Aléatoire
34
Comparaison des modes NetFlow« Full » et « Sampled »
Full Sampled Pertes
Nombre de flux 3416043 1522338 55%
Quantité en octets 19344774677
2078190250 90%
Nombres de paquets
48802075 5303552 90%
Full Sampled Pertes
Nombre de flux 3416043 1522338 55%
Nombre de flux ICMP 241 103 58%
Nombre de flux TCP 3204712 1487522 54%
Nombre de flux UDP 211089 34713 84%
35
36
Un point sur les plate-formes d’administration et
de supervision• Des solutions principalement
commerciales:• SunNet Manager• HP OpenView• IBM Tivoli NetView• …
• Elles sont complètes (SNMP, plug-in NetFlow) mais sont coûteuses en ressources et à l’achat.
37
Plan
• Pourquoi de la métrologie ?• Approches• Les mesures passives• Les mesures actives
• Quelques notions• Les métriques• L’exigence des applications• Les outils usuels• La problématique des mesures actives sur un babckbone haut débit• Présentation des solutions existantes
• Conclusion
38
Quelques notions
• Les différents délais : • La traversée d’un lien : temps de propagation
• Fonction de la distance et de la vitesse de la lumière, 0.1-0.2 seconde pour le tour du globe
• La transmission : délai de transmission• Débit du lien / taille du paquet
• L’attente sur le chemin : délai du aux files d’attentes• Nombre de paquets * débit du lien / taille de paquet
• La cause des paquets perdus : • Une file d’attente est pleine• Le bruit sur le lien (inexistant aujourd’hui, sauf pour le wireless) • Re-routage trop long
39
Principe des mesures unidirectionnelles
• Envoi de paquets UDP contenant une estampille temporelle et un numéro de séquence
• Récupération (sur socket ou capture du trafic) et comparaison de l’estampille à la réception
Délais unidirectionnels, gigue, pertes, déséquencement
40
Les métriques (1/2)
• Standardisées par l'IETF :• groupe IPPM (IP Performance Groups)• délais, gigues, pertes, déséquencement...
• Pour chaque classe de service et type de protocole IP
• Notion de précision importante• Mesures de bout en bout mais aussi en
interne :
41
Les métriques (2/2)• Délai unidirectionnel (cf RFC 2679) :
• importante pour les applications temps réels (VoIP, …)• permet la mesure de la qualité perçue par l’utilisateur (ex : qualité d’une application sur TCP
dépend du délai d’arrivée des paquets et non des acquittements) → plus représentatif que le RTT
• permet la surveillance du réseau et de l’efficacité de l’implémentation des classes de service en distinguant les trajets aller et retour
• Gigue (variation du délai unidirectionnel, cf RFC 3393) :• dû aux variations des files d’attente des routeurs et des trajets • importante dans les applications de type streaming (dimensionnement des buffers)• caractéristique de la dynamique et de la stabilité du réseau
• Taux de pertes unidirectionnel des paquets (cf RFC 2680) :• important pour tous les types d’application• dû à l’encombrement du réseau
• Déséquencement (cf draft-ietf-ippm-reordering) :• paquet déséquencé = paquet en retard (cf IPPM) • importante dans les applications de type streaming (paquet trop en retard = paquet perdu)• dû à l’existence de plusieurs chemins dans le réseau, à un protocole de retransmission sur
erreur, …
42
Exigences des applications
• Applications temps réels (voix sur IP, visioconférence) : les plus exigeantes → délai < 150 ms, gigue < 50 ms, perte modéré, déséquencement faible
• Applications type streaming : existence d’un buffer → contraintes limitées sur le délai unidirectionnel et la gigue. Perte et déséquencement modérés
• Web, mail : délai modéré et perte faible, gigue et déséquencement sans grande importance
• Tansfert de données : délai, gigue et déséquencement sans grande importance, pertes faibles
• Applications interactives (telnet, jeux en ligne) et transactionnel : délais, déséquencement et pertes faibles
43
Un exemple de bottleneck
Sur un réseau haut débit et sur de longue distance, même la perte d’un seul paquet peut gravement affecter les performances. Pour TCP, le débit maximum est :
0.7Rate =
MSS
RTT*
PMatt Mathis*
MSS = Maximum Segment SizeRTT = Round Trip TimeP = Packet Loss
44
Exigences des applications (3) : résumé
Source : http://www.itu.int/osg/spu/wtpf/wtpf2001/infosession/pettitt1.pdf
45
Les outils les plus simples• Ping :
• Utilisé pour tester la disponibilité d’un hôte• Algorithme : utilisation du protocole ICMP
• Envoi d’un paquet « echo request » avec:• Un identifiant par processus ping• Un numéro de séquence par echo request
• L’hôte cible répond avec un ICMP echo reply• Le résultat : RTT, TTL, et numéro de séquence.
• Traceroute :• Utilisé pour découvrir le chemin jusqu’à la destination. • Algorithme : utilisation de ICMP ou UDP et le champ TTL de l’en-tête IP
• Envoi d’un paquet avec TTL=1• Le premier routeur renvoi un ICMP time exceeded.• Envoi d’un paquet avec le TTL à 2 vers la cible, le deuxième routeur répond.• On continu jusqu’à la destination en incrémentant le TTL ou jusqu’au TTL max.
• Inconvéniant des deux méthodes lorsque :• Les chemins aller et retour sont asymétriques • l’ICMP est filtré• Les paquets ICMP ne sont pas traités par les routeurs comme les autres
paquets
46
Ordres de grandeurs sur le backbone
•Délais ≈ quelques ms•Gigue ≈ ms•Pertes << 10-3
•Déséquencement très faible
6
4,19,05
33,4
9,5
11,8
11,5
7,76,8
12,35
6,6110,02
47
Problématiques
• Précision• délai ≈ quelques ms
→ précision ≈ 100 µs
• Synchronisation :• NTP :
• En WAN > 1 ms• instabilité
• GPS : • 10 µs• Problème de coût et d'installation
• Mesures de bout en bout :• Présence de sondes aux extrémités• Décomposition des mesures
Délais unidirectionnels entre deux stations A et B directement reliée, A est synchronisée sur B par NTP, B synchronisée sur son horloge locale.
48
Problématiques : OS
• Station de mesures : supervision temps réel et précise →stabilité de la machine ≈ 100 µs
HORS les OS courants ne sont pas temps réels → latence jusqu’àplusieurs dizaines de ms
Exemple : délai entre deux ordinateurs reliés par un cable
49
Problématiques : OS (2)
Solutions :
• Utiliser OS temps réel (QNX, RTLinux, RTAI …) → développement conséquent
• Appliquer patch pour améliorer OS (lowlatency ou preempt kernel pour linux par exemple) → simple mais moins efficace
• Effectuer un post traitement des résultats pour éliminer les erreurs dus à l’OS → délicat
50
Problématiques : autres
• Localisation : doit permettre mesure pour tous les trajets et mesures end to end→ plateforme dans chaque PoP
• Coordination des mesures et du rapatriement des résultats• Fiabilité : ne pas déclencher fausses alertes• Sécurité : éviter falsification des mesures, intrusion et dénis de
service• Représentativité : montrer conditions subies par les utilisateurs
→ déterminer finement les caractéristiques du trafic de test (taille, DSCP …)
• Exhaustivité : mesures multicast et IPv6
51
Les solutions existantesSAA RIPE TTM Saturne Rude/Crude NIMI Q O S Metrix
Matériel routeurboîtier
(pc/FreeBSD) PC (free BSD) PC (linux) PC (divers OS) boîtier GPS intégré non oui non non non Selon modèle
Sécurité
Authentification sondes par
MD5 possible Aucune AucunePaquets
numérotés Chiffrement IntégréeRéception des
paquets sondes Non précisée
Capture (pcap) + socket Capture (bpf) Socket matérielle
Estampillage Non préciséAvant envoi sur
socket KernelAvant envoi sur
socket Dépend de l’outil utilisé matériel
Paramétrage du DSCP des
paquets sondes oui non oui oui oui
Collecte Distante, par
snmp
Logs locaux envoyés au site
central quotidiennemen
t
Logs locaux, envoi au site
central par rpc de chaque
mesure Logs locaux Logs locauxVers site central
en temps réel
Site web central
Modification/ adaptation de
l’outil Impossible
Possible (mais nécessite
demande à RIPE) Possible Possible
Possible (mais code source imposant) Impossible
Licence commerciale commercialenon définie
actuellement GPL GPL commerciale
Non intégrée Non intégréePrésentation des résultats Non intégrée
Très complète, sur serveur web local et central (à Amsterdam) Non intégrée
52
Déploiement des sondes QoSmetrics sur RENATER
53
Conclusion• La métrologie active :
• Gestion et surveillance proactive du réseau • Identification des goulots d’étranglements• Fourniture au client de statistiques en liens avec ces besoins• Quantification de l’impact de la différenciation de service et
optimisation• Mise en place et surveillance de Service Level Agreement• Tarification en fonction des paramètres du SLA
• La métrologie passive :• Tarification (quantitative)• Sécurité• Diagnostic à posteriori• Visualisation de l’évolution du réseau sur le long terme
54
Quelques liens
• Un cours complet sur SNMP, les MIBs :• http://www.blois.univ-tours.fr/~giaco/SNMP/gi-snmp.html
• Des publications sur TCP, les mesures de bout en bout, les différents MTU :• http://www.psc.edu/~mathis/papers/index.html
• Un site très complet sur les outils de métrologie libres :• CAIDA http://www.caida.org
• Le site de l’unité réseau du CNRS (UREC) sur lequel se trouve de nombreux cours et présentation (ainsi qu’un document sur les outils de supervision pour des réseaux locaux qui peut faireun complément pour la métrologie « locale », l’auteur : FX Andreu ;) ):• http://www.urec.fr
55
IPv6 Network Management
56
Contributions• Simon Muyal, RENATER• Bernard Tuy, RENATER• Jérôme Durand, RENATER• Ralf Wolter, Cisco• Patrick Grossetête, Cisco• Munechika Sumikawa, Hitachi• Patrick Paul, 6WIND
57
Agenda• Introduction• Retrieving information from routers
• TELNET/SSH/TFTP/FTP…• SNMP/MIBs and IPv6• Netflow
• Management platforms• Management tools
• 6NET work• Recommendations (LAN, WAN…)• Examples
• Conclusion & Demo
58
Introduction• IPv6 networks deployed:
• Most are dual stack • LANs (campuses, companies, …)• MANs (RAP, …)• WANs - ISPs (Géant, NRENs, IIJ, NTT/Verio, Abilene, …)• IX’s
• Testbed, pilot networks, production networks• Management tools/procedures are needed
• What applications are available for managingthese networks ?• Equipment, configurations, …• IP services (servers : DNS, FTP, HTTP, …)
59
Introduction
• Different types of networks• Dual stack IPv6 & IPv4 networks• IPv6 only networks (few of them)
• Important to keep in mind • Dual stack is not for ever• One IP stack should be removed… one day• No reasons for network admins to face twice
the amount of work
60
Dual Stack IP networks• Part of the monitoring via IPv4
• Connectivity to the equipment• Tools to manage it (inventory, configurations,
«counters», routing info, …)
• Remaining Part needs IPv6• MIBs IPv6 support• NetFlow (v9)
61
IPv6 only networks• Topology discovery (LAN, WAN ?)• IPv6 SNMP agent • SNMP over IPv6 transport
=> Need to identify the missing parts
62
SSH/TELNET/TFTP…Basic requirements to manage a
network
63
SSH/TELNET/TFTP…
• All routers support IPv6 connections (SSH, TELNET)• Periodic scripts can retrieve information from
the routers over IPv6
• TFTP/IPv6 as well supported on every equipment• Images can be downloaded over IPv6
• FTP/IPv6 not supported on CISCO routers
64
SNMP/MIBs and IPv6• SNMP and IPv6• IPv6 MIBs status• Manufacturers implementations
65
SNMP model
IPv6 information in MIBs can be retrieved over IPv4
66
SNMP over IPv6
• Cisco:• SNMP over IPv6 is available in 12.0(27)S and 12.3(14)T• More features available from 12.0(30)S
• Juniper, Hitachi, 6wind:• SNMP over IPv6 is available
67
IPv6 MIBs Status
68
IPv6 MIBs status
• MIBs are essential for the network management
• SNMP-based applications are widely used but others exist too (NetFlow, XML…)
• SNMP rely upon MIBs …=>Need to have MIBs to collect IPv6 information as
well as get MIBs reachable from an IPv6 address family.
69
IPv6 MIBs /2
• Standardization status at IETF:• At the beginning:
• IPv4 and IPv6 MIBs dissociated
IPv4 IPv6 Remarks
Textual Conventions RFC1902 Definition of IP address formatRFC2465
RFC2466
RFC2452
RFC2454
ICMP MIB
IP MIBRFC2011
TCP MIB RFC2012
UDP MIB RFC2013
70
IPv6 MIBs /3 (Hidden)• Standardization status at IETF: Unified MIBs
• Definition of new Textual Conventions (TC) taking into account both versions of IP:
• RFC2851:• IP:{InetAddressType,InetAddress}
• RFC3291 (Obsolete RFC2851):• New TCs: InetAddressPrefixLength, InetPortNumber,InetAutonomousSystemNumber
• RFC4001 (Obsolete RFC3291):• New TCs: InetZoneIndex, InetScopeType, InetVersion
71
IPv6 MIBs /3
RFC 1902RFC 2851 RFC 3291 RFC 4001
IPv4: ipAddress
OCTET STRING(SIZE(4)) IP: { inetAddressType, inetAddress }
{ INTEGER, OCTET STRING(SIZE(0..255)) }RFC 2465
IPv6: ip6Address
OCTET STRING(SIZE(16))
nov 1996 1998 juny 2000 may 2002 fev 2005
72
IPv6 MIBs /4
Nov 1996
RFC 2013
RFC 2012
RFC 2011
RFC4022
Draft-RFC2013-update04
Draft-RFC2011-update10
RFC 2096 Draft-RFC2096-update07
June 2002 May 2002 June 2005
RFC 2851 RFC 3291
Standardization status at IETF:Today :• Unified MIBs are on standardization track.
Feb 2005
RFC 4001
73
IETF MIB Status /5• draft-ietf-ipv6-rfc2011-update-10.txt
• IP MIB (05/2004) In the RFC Editor’s queue (06/2004)
• RFC4022 • TCP MIB (03/2005)
• draft-ietf-ipv6-rfc2013-update-04.txt • UDP MIB (10/2004), last call (08/2004)
• draft-ietf-ipv6-rfc2096-update-07.txt • IP Forwarding Table MIB (02/2004)
proposed standard RFC(in the RFC Editor's queue… can be considered as done)
74
IETF MIB Status /6• BGP MIB v6: the draft expired (08/2004).
• draft-ietf-idr-bgp4-mibv2-04.txt (01/2004)•A new draft is expected by mid-april 2005
Note that the same people are working on • draft-ietf-idr-bgp4-mib-15.txt (08/2004)
•This draft consider only IPv4 addresses:•« IMPORTS IpAddress » 32 bits
75
IPv6 MIBs implementions
76
IPv6 MIBs implemention/1
• Cisco
• Private Cisco MIBs implement ID-00 of RFC 2011 & 2096 updated drafts
• Working on implementing the new standards
• No distinction between IPv4 and IPv6 traffic at the interface level from the MIBs (available when new IETF MIB get implemented)
• Information available from CLI• show interface accounting• …
77
Cisco: IPv6 CLI
“show interface accounting”• Differentiate IPv4/IPv6 counters at the
interface level for all Cisco routers, except:•Catalyst 6500 / Cisco 7600 supervisor engine 720:Counts only for packets that are software switched, not the hardware switched packets.
•GSR:• ‘show interface counters’ correctly counts IPv6 traffic and separates ingress and egress traffic• Engine 3:* OUTPUT IPv6 traffic is counted under IPv6 (correct)* INPUT IPv6 traffic is counted under IP (will get corrected)
78
IPv6 MIBs implemention/2
• Juniper
• MIB based on RFC 2465
• with different counters for IPv4 and IPv6 traffic
• Or based on filters to collect IPv6 traffic:• Ex:Geant monitoring
79
IPv6 MIBs implemention/3
• Hitachi
• Routers (GR2000/GR4000) and Switches (GS4000) support IPv6 standard MIBs:
• RFC 2452: TCP/IPv6• RFC 2454: UDP/IPv6• RFC 2465: IPv6• RFC 2466: ICMPv6
• The unified MIBs are not implemented yet.
80
IPv6 MIBs implemention/4
• 6WIND
• MIBs based on RFC 2465 and RFC 2466• Checked at our lab.
81
IPv6 MIBs implemention/5
• Net-SNMP
• RFC 2452: TCP/IPv6• RFC 2454: UDP/IPv6• RFC 2465: IPv6• RFC 2466: ICMPv6
• RFC 4001: new textual convention• But no updated MIB
82
IPv6 flow monitoring
83
Netflow & IPFIX model
flow collector
flow export
flow export
flow export
NetFlow for IPv6
6net Core6net CoreNetFlowfor IPv6 Enabled Device
NetFlow Collector(various)
NetFlowExport
Packets(IPv4, UDP)
1. Templates2. Data
Records
Applications:• Performance• Security• Billing•…
• Source Address• Destination Address• Source Port• Destination Port• Layer 3 Protocol Type• DSCP• Input Logical Interface• BGP next hop TOS• MPLS label• MPLS label type (LDP, BGP,
VPN, ATOM, TE Tunnel MID-PT)
IPv4/v6 Traffic
85
NetFlow Version 9
Packet
20
1.1.1.1Packet
HeaderTemplateFlowSet
DataFlowSet
OptionFlowSet
Template Definition (Template FlowSet)
ID = 0 Length 20Template Definition
Tpl ID Length 20Record
Flow Records (Data FlowSet)
Record Record
RecordField #1
Field #2
Field #3
86
NetFlow Version 9Example for Template Definition
L4_PROTOCOL2
DST_AS_NUMBER2
SRC_AS_NUMBER
3(# of Fields)
1001(Template ID)
Length of TemplateStructure
Flow Set ID (0 for Template)Template A
2 2PACKET_COUNT
2
SRC_AS_NUMBER4
SRC_IP_PREFIX
4(# of Fields)
1002(Template ID)
Length of TemplateStructure
Flow Set ID (0 for Template)Template B
2BYTE_COUNT
87
Example for Export Packet
Tem
plat
e A
Same as Template ID for Template B; Refer to
Previous Slide
Tem
plat
e B
Packet Header
10022(# of Records)
As Defined in the Previous Slide
1.1.1.1 2.2.1.1
20 64
365 20
92894 1000
10011
35
23
700
Record 1 Record 2
Data for Template B Data for Template A
88
IPv6 flow monitoring /1
• IETF IPFIX WG• Cisco
• Available on IOS 12.3(7)T and after• IPv6 packets captured (needs IPv6 cef)• Export done with Netflow v9• Still uses IPv4 transport• Need to update your own Netflow Collector
• Cisco NFC v5.0 available• Other collectors are available as well …
89
IPv6 flow monitoring /2• Hitachi
• Support sflow (http://www.sflow.org/) and Netflow is on the roadmap.
• 6WIND:• Not available
• Juniper:• Not available
90
Commercial Management platforms
91
Commercial platforms
Commercial ISPs use to have integrated management platforms (NRENs mainly use GPL or home-made tools)
• HP-OV proposes a version with IPv6 features: NNM 7.0 (sept 2003). Need some hack for automatic IPv6 discovery of CISCO routers.
• Ciscoworks: IPv6 version for • Campus Manager under tests Application note on IPv6 management
• Tivoli Netview doesn’t propose any IPv6 features• Infovista : « no IPv6 plan at the moment »
92
Cisco: NMS Application Support for IPv6
• Cisco NetFlow Collector (NFC) 5.0• Full support for IPv6 records• Note: device export still IPv4 only
• CiscoWorks • Campus - Functional test has started• RME -Functional test starts soon• CiscoView - under development• Beta tests expected for 2H2004
• Cisco Network Registrar (CNR):• Phase 1 (1H2005): Manage IOS DHCPv6 servers• Phase 2: Add DHCPv6 and DNS-over-IPv6
93
« Top ten » …• HP Openview• Ciscoworks 2000
(Campus Manager)• IBM Netview• Infovista, Tivoli• …
IPv6 ready
IPv6 not ready
94
Monitoring tools
• 6NET work• Recommendations…
• LAN (Sites…)• WAN (ISP networks…)
• Examples
95
6Net and IPv6 monitoring tools
• 6Net WP6 : managing large scale IPv6 networks• Tests lots of IPv6 ready tools• Many others ported to IPv6
• 30+ monitoring tools for IPv6• Tested• Implemented • Documented
• URL: http://tools.6net.org/
96
LAN - recommendations• Traffic & service management (web, DNS,
SMTP, IMAP...)• A single tool: Argus, Nagios or Ntop
• End-to-end performance of the IPv6 network• Iperf or Pchar
• Configuration management• Rancid
• Analysis of packets on shared links for occasional troubleshooting• Ethereal, tcpdump or Ntop
• IPv6 multicast management• Multicast beacon
97
WAN - recommendations
• Traffic management• MRTG, Cricket or Nagios
• Equipment and link status:• Intermapper or Nagios
• Routing management:• ASpath-tree (routing policy study)• Home-made scripts (routing fault management)
• For accounting management:• Ipflow, CISCO NFC v5.0 or Home-made collectors
• Configuration management:• Rancid, Home-made inventory tool
• Looking-glass for customers
98
Examples
99
Argus
• Administration of network:• PCs, Switches, Routers• Availability• Traffic on the network
• Administration of services:• http, ftp, dns, imap, smtp...
• Evolution: new features can be easily added
100
101
Nagios
• URL://www.nagios.org• Very complete tool
• Services monitoring• Network monitoring
• Can be complex for a small network• Evolution: new features can be added with
plug-ins• BGP monitoring• …
102
Nagios
103
ASpath-Tree
• Display BGP4+ « topology » from
• BGP4+ routing table• Retrieved from connection to routers
(RSH/SSH…)
• Generate HTML pages.
104
ASpath-Tree
105
Intermapper
106
Looking Glass
• Get information on a router w/o direct connection
• Web Interface• Final user don’t need a login• Allow the user to detect causes of failures
w/o asking the NOC or netadmin
107
Looking Glass
108
Inventory : interfaces & peerings
user WEB, PHP Server
DB serverMysql
RENATER 3GIP
RENATER
NOCRENATERPerl
crontab
SNMP collector
1''
4''
2'' 3''
SNM P Polling1
2
3'
FTP
SSH 12MySql
109
Inventory: Interfaces
110
Inventory: BGP Peerings
111
IPv6 traffic on Cisco routers
• Based on CLI program• "show interface accounting“• Differentiate IPv4/IPv6 counters at the
physical interface level
• One query per hourIPv6 Weather Map of RENATER
112
IPv6 traffic on Cisco routers
113
Conclusion• ISPs –and any other organizations-
need monitoring tools to launch a new service/protocol into production
• Lots of monitoring tools are now ready for IPv6 networks
• But :• Q1: are my usual tools (used for IPv4 monitoring)
available for IPv6 too ?• Q2: what do I need to stress to my favourite vendor
to be ready and manage my IPv6 network ?
114
Retrieve this information …
• http://sem2.renater.fr/• -> Presentations • -> RFCs …
115