📡 Supervision (Monitoring) – SNMP, NetFlow, Logs & Outils
Guide complet IDEO-Lab sur la collecte, l'analyse et l'alerte des métriques réseau.
Concept & Piliers
Proactif vs Réactif. Les 3 piliers (Dispo, Perf, Logs).
Supervision ProactifMétriques & Concepts
Baseline, Alerting, Métriques (Latence, CPU...).
Baseline AlertingNMT (Network Management)
Systèmes NMS, OOB Management.
NMS Out-of-BandDisponibilité : ICMP
Protocole ICMP (Ping, Echo Request/Reply).
ICMP Ping DisponibilitéDisponibilité : fping
Outil de ping en parallèle (multi-cibles).
fping ScanPerformance : Smokeping
Outil de graphing (Latence, Gigue, Perte) via RRDtool.
Smokeping Latence RRDtoolProtocole : SNMP
Simple Network Management Protocol (Agent, Manager).
SNMP PerformanceSNMP : GET vs TRAP
Polling (Pull) vs. Alertes (Push).
SNMP GET SNMP TRAPSNMP : MIB & OID
MIB (Dictionnaire) & OID (Adresse de la métrique).
MIB OIDProtocole : NetFlow
Analyse de flux (Qui parle à qui ?). 7-Tuple.
NetFlow Cisco VisibilitéVariantes : sFlow, J-Flow
sFlow (Sampling) vs NetFlow v9 (Template).
sFlow J-FlowOutils Flux (Collector)
nfdump, nfsen, PRTG, SolarWinds NTA.
nfdump CollectorProtocole : Syslog
Standard de logging (PUSH, UDP 514), Niveaux (0-7).
Syslog Logs UDP 514Outil : ELK Stack
Elasticsearch, Logstash, Kibana, Beats. Analyse L7.
ELK ElasticsearchOutils : Splunk & Graylog
Alternatives à ELK (Commercial vs Open Source).
Splunk GraylogNMS : Nagios / Icinga 2
Classique, Check-based (Scripts), Alerte (0-3).
Nagios Icinga 2NMS : Zabbix
All-in-one, Agent/Agentless, Auto-discovery.
Zabbix AgentNMS : Prometheus & Grafana
Moderne, Pull (Scrape), Time-Series DB, Dashboards.
Prometheus GrafanaCheat-sheet : Protocoles
SNMP vs NetFlow vs Syslog.
Comparatif ProtocolesCheat-sheet : Outils NMS
Nagios vs Zabbix vs Prometheus.
Comparatif OutilsCheat-sheet : Outils SNMP
snmpwalk, snmpget. (Linux).
Qu'est-ce que la Supervision (Monitoring) ?
La supervision réseau (Network Monitoring) est le processus continu de collecte et d'analyse de données sur l'état et la performance d'un réseau informatique et de ses composants (routeurs, switchs, serveurs, applications).
L'objectif est de passer d'une gestion réactive à une gestion proactive :
- Réactif : "Le téléphone sonne. Le PDG dit que le site est lent." (Échec).
- Proactif : "Je reçois une alerte. L'usage CPU du serveur web est à 90% depuis 5 minutes. Je vais investiguer *avant* que le PDG ne s'en rende compte." (Succès).
Les 3 Piliers de la Visibilité (M.E.L.T)
Une supervision complète repose sur trois types de données (parfois appelés les 3 piliers, ou "Metrics, Events, Logs, Traces") :
| Pilier | Question | Exemples de Métriques/Données | Protocole Clé |
|---|---|---|---|
| Disponibilité (Fault) | Est-ce UP ou DOWN ? | Statut (Up/Down), Perte de paquets (Loss). | ICMP (Ping) |
| Performance (Metrics) | Est-ce LENT ou PLEIN ? | CPU (%), RAM (%), Bande Passante (bps), Latence (ms). | SNMP, WMI |
| Logs (Events) | Que s'est-il PASSÉ ? | "Login Échoué", "Port Fa0/1 Down", "Config Modifiée". | Syslog, SNMP Traps |
| Flux (Flows/Traces) | QUI parle à QUI ? | "IP A a envoyé 500MB à IP B sur le port 443". | NetFlow, sFlow |
Métriques (Ce qu'on mesure)
- Disponibilité (Fault) :
- Ping (ICMP) : L'hôte répond-il ?
- Port Check (TCP) : Le service (ex: Port 80) répond-il ?
- Perte de Paquets (Loss) : (ex: 5% de perte).
- Performance (Ressources) :
- Bande Passante (Bandwidth) : (bits/sec) Utilisation du lien WAN.
- Latence (Latency) : (ms) Temps de réponse.
- Gigue (Jitter) : (ms) Variation de la latence (critique pour la VoIP).
- CPU Load : (%) Charge du processeur (du routeur ou serveur).
- Memory Usage : (%) Utilisation de la RAM.
- Disk Usage : (%) Espace disque (critique pour les serveurs de logs).
Baseline (Ligne de Base)
C'est la "norme" de votre réseau. La supervision collecte des données sur une longue période (ex: 1 mois) pour établir ce qui est normal.
Exemple de Baseline : "L'usage CPU de ce serveur est de 20% en journée, 70% pendant la sauvegarde de 2h du matin, et le reste du temps à 5%."
Alerting (Alertes)
L'alerte est déclenchée quand une métrique dévie de la baseline. C'est le passage au "proactif".
- Seuil Statique : (Simple)
ALERTE si CPU > 90% pendant 5 min. - Seuil Dynamique : (Intelligent)
ALERTE si CPU > 30% à 4h du matin(anormal selon la baseline).
NMS (Network Management System)
Le NMS est le serveur central qui exécute le logiciel de supervision (ex: Nagios, Zabbix, SolarWinds).
C'est le "Manager" qui effectue le "Polling" (interrogation) de tous les "Agents" (switchs, routeurs, serveurs) du réseau.
In-Band vs. Out-of-Band (OOB) Management
Comment l'admin accède-t-il au NMS et aux appareils ?
In-Band (Dans la bande)
(Défaut) On utilise le réseau de production (le même que les utilisateurs) pour superviser et administrer (ex: SSH, SNMP).
Risque : Si le réseau de production tombe (ex: boucle STP, panne de routage), vous perdez aussi l'accès à vos switchs/routeurs pour le dépanner.
Out-of-Band (OOB) (Hors bande)
(Bonne pratique) On construit un deuxième réseau physique, totalement séparé (switchs dédiés, 4G/LTE), utilisé uniquement pour l'administration (Ports "Mgmt", "Console").
Avantage : Si le réseau de production tombe, le réseau OOB est toujours UP, permettant à l'admin de se connecter pour diagnostiquer.
ICMP (Internet Control Message Protocol) est un protocole de Couche 3 (Réseau) utilisé pour le diagnostic et les messages d'erreur (il n'transporte pas de données utilisateur).
Ping (Echo Request / Echo Reply)
C'est l'outil de base de la supervision de disponibilité.
La commande ping envoie un paquet ICMP Type 8 (Echo Request) à une destination.
Si la destination est joignable, elle répond avec un paquet ICMP Type 0 (Echo Reply).
Usage en Supervision (Nagios, Zabbix...)
Le NMS "ping" toutes les 1 ou 5 minutes chaque appareil critique (serveur, routeur) :
- Réponse reçue (temps=10ms) : Hôte = UP.
- "Request Timed Out" (Perte) : Hôte = DOWN (-> Alerte !).
fping (Fast Ping) est un outil (Linux) similaire à ping, mais optimisé pour la supervision de multiples cibles (scanning).
ping vs fping
ping(séquentiel) : Envoie paquet 1, attend réponse 1. Envoie paquet 2, attend réponse 2. (Lent pour 1000 hôtes).fping(parallèle) : Envoie 1000 paquets (mode round-robin) puis écoute les réponses. (Très rapide).
Exemple d'usage
Scanner tout un sous-réseau (-g) et n'afficher que les hôtes "Alive" (-a) :
$ fping -a -g 192.168.1.0/24 192.168.1.1 is alive 192.168.1.10 is alive 192.168.1.50 is alive
C'est souvent le moteur utilisé par les NMS (Nagios, Zabbix) pour le "Network Discovery".
Smokeping est un outil de supervision (open-source) spécialisé dans la visualisation de la qualité de la connexion (Latence, Gigue, Perte).
Fonctionnement (RRDtool)
Il "ping" (ou utilise d'autres sondes) en continu (ex: 20 pings toutes les 5 minutes) des cibles (ex: 8.8.8.8, votre passerelle FAI, votre serveur web).
Il stocke les résultats (Latence min/max/moyenne, Perte) dans une base de données RRDtool (Round Robin Database), qui est optimisée pour les données "Time-Series" (horodatées).
Résultat (Le "Smokegraph")
Il génère des graphiques "Smokegraphs" :
- L'axe X est le temps (ex: 24h).
- L'axe Y est la latence (ex: 0-100ms).
- La zone "pleine" (Médiane) est en vert.
- La "fumée" (en gris) représente la Gigue (Jitter) (la variation entre min/max).
- Les barres rouges représentent la Perte (Loss).
Permet de voir en un coup d'œil si un lien WAN est stable ou non.
L'Outil de Supervision "Performance"
SNMP est le protocole standard (Couche 7, UDP 161/162) utilisé pour superviser (monitorer) et gérer des équipements réseau (switchs, routeurs, serveurs, imprimantes...).
C'est le protocole n°1 pour la supervision de performance (CPU, RAM, Bande Passante).
Composants
- Manager (NMS) : Le serveur de supervision (ex: Nagios, Zabbix) qui pose les questions.
- Agent : Le logiciel qui tourne sur l'appareil (ex: le switch Cisco) et qui possède les réponses.
- MIB (Management Information Base) : Le "dictionnaire" (voir 3.3) que le Manager utilise pour savoir quelles questions poser.
Versions & Sécurité
| Version | Sécurité (Authentification) | Statut |
|---|---|---|
| SNMPv1 | "Community String" (Texte clair, ex: "public"). | Obsolète (Non sécurisé). |
| SNMPv2c | "Community String" (Texte clair). | Courant (Non sécurisé). (Utilisé en interne, bloqué par les firewalls). Ajoute le GetBulk. |
| SNMPv3 | Utilisateur + Mdp (MD5/SHA) + Chiffrement (DES/AES). | Moderne (Sécurisé). Recommandé, mais plus complexe à configurer. |
SNMP utilise deux modes de communication (sur des ports UDP différents).
Polling (Pull) - Port UDP 161
C'est le mode le plus courant, utilisé pour la performance.
Le Manager (NMS) initie la requête (ex: toutes les 5 minutes).
GET Request: "Donne-moi la valeur de l'OID X (ex: CPU)."GETNEXT Request: "Donne-moi la valeur de l'OID suivant X."GETBULK Request: (v2c+) "Donne-moi les 10 prochains OIDs." (Efficace).SET Request: (Rare, dangereux) "Change la valeur de l'OID Y." (Gestion).
Traps (Push) - Port UDP 162
C'est le mode d'alerte, utilisé pour les pannes (faults).
L'Agent (Switch) initie la requête (non sollicitée).
Exemple : 1. Le Port Fa0/1 tombe (DOWN). 2. L'Agent (Switch) envoie immédiatement un "SNMP TRAP" au Manager (NMS). 3. Message : "Port Fa0/1 est DOWN !" (Le NMS n'a pas eu à attendre le prochain cycle de polling de 5 min pour le découvrir).
Le "Dictionnaire" des Métriques
MIB (Management Information Base) : Un "dictionnaire" (un fichier texte structuré) qui décrit toutes les variables (métriques) qu'un appareil peut superviser. (ex: IF-MIB pour les interfaces, HOST-RESOURCES-MIB pour CPU/RAM).
OID (Object Identifier) : L'"adresse" unique, numérique et hiérarchique (arborescente) d'une métrique spécifique.
Structure de l'arbre OID :
1 (iso)
└ 3 (org)
└ 6 (dod)
└ 1 (internet)
└ 2 (mgmt)
└ 1 (mib-2)
└ 1 (system)
└ 1 (sysDescr) -> .1.3.6.1.2.1.1.1.0
└ 3 (sysUpTime) -> .1.3.6.1.2.1.1.3.0
└ 2 (interfaces)
└ 2 (ifTable)
└ 1 (ifEntry)
└ 10 (ifInOctets - Octets entrants)
└ .1 (Interface 1) -> .1.3.6.1.2.1.2.2.1.10.1
└ .2 (Interface 2) -> .1.3.6.1.2.1.2.2.1.10.2Outil : snmpwalk (Linux)
L'outil de diagnostic de base. Il utilise GETNEXT en boucle pour "marcher" (walk) dans l'arbre OID d'un agent et afficher toutes les valeurs.
# Commande pour "walker" toute la branche 'system' # -v2c : Utilise la version 2c # -c public : Utilise la community "public" # 192.168.1.1 : Cible (Agent) # .1.3.6.1.2.1.1 : OID de départ (system) $ snmpwalk -v2c -c public 192.168.1.1 .1.3.6.1.2.1.1 iso.3.6.1.2.1.1.1.0 = STRING: "Cisco IOS Software..." (sysDescr) iso.3.6.1.2.1.1.2.0 = OID: ... (sysObjectID) iso.3.6.1.2.1.1.3.0 = Timeticks: (1234567) 1 day... (sysUpTime) ...
Outil : snmpget
Demande un seul OID.
$ snmpget -v2c -c public 192.168.1.1 .1.3.6.1.2.1.1.3.0 iso.3.6.1.2.1.1.3.0 = Timeticks: (1234567) 1 day...
Le "Qui-Quoi-Où" du Trafic
Problème : SNMP vous dit : "Votre lien WAN est saturé (90% d'utilisation)". Mais il ne vous dit pas POURQUOI (Qui ? Quel service ?).
NetFlow (protocole inventé par Cisco) est la solution. Il analyse le trafic et génère des "méta-données" sur les flux (flows).
Qu'est-ce qu'un "Flow" (Flux) ?
C'est une "conversation" unidirectionnelle, identifiée par le 7-Tuple :
- IP Source
- IP Destination
- Port Source
- Port Destination
- Protocole (TCP/UDP)
- Interface d'entrée
- Type of Service (ToS / DSCP)
Architecture
NetFlow (Push) est composé de 3 éléments :
- Exporter : Le routeur/switch qui voit le trafic. Il analyse les paquets, agrège les statistiques (ex: "Flow A = 500 paquets, 50MB") et exporte (PUSH) ces métadonnées.
- Collector : Un serveur (dédié) qui "écoute" (UDP 2055, 9996...) et collecte/stocke ces rapports de flux.
- Analyzer : Une interface graphique (NMS) qui lit les données du Collector pour générer des graphiques (ex: "Top Talkers", "Top Applications").
| Protocole | Propriétaire | Méthode | Description |
|---|---|---|---|
| NetFlow v5 | Cisco | Stateful (Cache) | Version "fixe" (legacy). Capture 100% du trafic, l'agrège dans le cache du routeur, puis l'exporte. (Lourd pour le routeur). |
| NetFlow v9 | Cisco | Stateful (Template) | Moderne. Le routeur envoie d'abord un "template" (structure) au Collector, puis envoie les flux. (Standard *de facto*). |
| IPFIX | IETF | Stateful (Template) | Le standard "officiel" (IETF) basé sur NetFlow v9. |
| J-Flow | Juniper | Stateful (Template) | L'implémentation de Juniper (similaire à NetFlow v9). |
| sFlow | InMon (HP...) | Stateless (Sampling) | (Concurrent). Ne suit pas les flux. Il échantillonne (samples) 1 paquet sur N (ex: 1/1000). Très léger pour le routeur, mais moins précis. |
L'écosystème NetFlow nécessite un "Collector" et un "Analyzer".
Outils Open Source
- nfdump / nfsen : (CLI / Web) Outils (Linux) de base.
nfdumpcapture et filtre les flux.nfsenest une ancienne interface web pour nfdump. - Elastiflow : Un pipeline moderne basé sur ELK Stack. Utilise Logstash pour recevoir les flux et Kibana pour les visualiser (très puissant).
Outils Commerciaux (NMS)
- PRTG Network Monitor : Intègre un collecteur de flux (NetFlow, sFlow).
- SolarWinds NTA (NetFlow Traffic Analyzer) : Module spécialisé pour SolarWinds Orion.
Le "Journal de Bord" du Réseau
Syslog est un protocole de logging (journalisation) standard (Couche 7). C'est un protocole "PUSH" (non-fiable).
Les appareils (routeurs, switchs, firewalls, serveurs Linux) envoient (poussent) leurs messages d'événements (logs) à un Serveur Syslog central (le "Collector").
Transport : Utilise UDP 514 (Défaut, non fiable) ou TCP 514 / TCP 6514 (Syslog-NG/RELP, fiable).
Format (Exemple)
<34> Oct 11 22:14:15 [Switch-A] %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
Niveaux de Sévérité (Severity)
Les logs sont classés par niveau de criticité (de 0 à 7).
| Niveau | Mot-clé | Description |
|---|---|---|
| 0 | Emergency | Système inutilisable (Panic). |
| 1 | Alert | Action immédiate requise (ex: Corruption). |
| 2 | Critical | Erreur critique (ex: Panne matérielle). |
| 3 | Error | Erreur (ex: %LINK-3-UPDOWN). |
| 4 | Warning | Avertissement (ex: Config modifiée). |
| 5 | Notice | Événement normal mais significatif. |
| 6 | Informational | Information (ex: Login réussi). |
| 7 | Debug | Verbeux (pour débogage uniquement). |
Le Stack ELK (Elastic) est la solution open-source leader pour l'agrégation et l'analyse de logs (Log Management).
C'est le moteur de nombreux SIEM (Security Information and Event Management).
Composants (ELKB)
[Serveurs/Routeurs] ──(Logs)──► [ BEATS ]
│
▼
[ LOGSTASH ]
(Collecte, Parse (Grok), Enrichit)
│
▼
[ ELASTICSEARCH ]
(Base de données NoSQL. Indexe, Stocke)
│
▼
[ KIBANA ]
(Interface Web, Visualisation, Dashboards)- Beats : Agents légers (ex: Filebeat lit
/var/log, Packetbeat analyse le réseau). - Logstash : Le pipeline "ETL". Reçoit de Beats, parse les logs (via filtres Grok) pour les structurer (de
"Login failed for user bob"à{user: "bob", status: "failed"}). - Elasticsearch : La base de données NoSQL qui stocke et indexe ces logs structurés (JSON).
- Kibana : L'interface web (UI) pour rechercher, visualiser et créer des dashboards.
Alternatives populaires à ELK pour la gestion de logs (SIEM).
Splunk
Modèle : Commercial (Très cher).
Le leader "historique" du marché SIEM. Extrêmement puissant, rapide, et "facile" (comparé à ELK).
- Avantage : Tout-en-un (Collector, Indexer, GUI). Langage de requête (SPL).
- Inconvénient : Coût (licence basée sur le volume de logs/jour).
Graylog
Modèle : Open Source (avec version Enterprise).
Un concurrent direct d'ELK, souvent considéré comme plus simple à mettre en place pour la gestion de logs pure.
- Avantage : Plus "intégré" qu'ELK (Logstash+Elastic+Kibana).
- Technologie : Utilise Elasticsearch (ou OpenSearch) en backend, mais remplace Logstash/Kibana par sa propre stack (Java/MongoDB).
Nagios est le NMS "classique" (open-source), très robuste. Icinga 2 est un fork moderne de Nagios.
Modèle "Check-Based" (Basé sur les Vérifications)
Nagios est un ordonnanceur (scheduler). Il n'effectue aucune supervision lui-même. Il se contente d'exécuter des scripts (Plugins) à intervalle régulier.
Plugin : Un script (Bash, Perl, Python) qui vérifie UNE chose et retourne un code de sortie.
(Exemple : check_ping) $ /usr/lib/nagios/plugins/check_ping -H 8.8.8.8 -w 100,5% -c 200,10% OK - 8.8.8.8: rta 10.5ms, lost 0% | ... $ echo $? 0
Codes de Sortie (États)
| Code | État | Description |
|---|---|---|
| 0 | OK | Le service fonctionne. |
| 1 | WARNING | Avertissement (ex: Disque > 80%). |
| 2 | CRITICAL | Panne (ex: Hôte DOWN, Disque > 95%). -> Alerte ! |
| 3 | UNKNOWN | Erreur de plugin (ex: SNMP timeout). |
Zabbix est une solution de supervision "tout-en-un" (open-source) qui concurrence Nagios, mais avec une approche plus intégrée.
Agent vs. Agentless
Zabbix supporte plusieurs méthodes de collecte :
- Agent (Zabbix Agent) : (Recommandé) Un petit binaire (
zabbix_agentd) tourne sur le serveur/client. Le NMS (Serveur Zabbix) l'interroge. (Permet des checks L7 complexes, ex: "check_mysql_query"). - Agentless (Sans Agent) : (Pour les équipements réseau) Le NMS utilise des protocoles standards :
- ICMP : (Ping) pour la disponibilité.
- SNMP : (Polling) pour les métriques (CPU, Trafic...).
Fonctionnalités (All-in-One)
Contrairement à Nagios (qui a besoin de RRDtool/PNP4Nagios pour les graphs), Zabbix inclut tout :
- Collecte : (Agent, SNMP, ICMP).
- Stockage : (Base de données SQL - MySQL/Postgres).
- Graphing : (Génération de graphiques).
- Alerting : (Gestion des alertes).
- Web UI : (Interface de configuration et de dashboards).
- Auto-Discovery : Peut scanner un réseau et ajouter automatiquement les hôtes trouvés.
Prometheus est la solution open-source (CNCF) de monitoring de référence pour les environnements Cloud Native (Conteneurs, Kubernetes, Microservices). Il est souvent couplé à Grafana pour la visualisation.
Prometheus (Modèle PULL)
Contrairement à Zabbix (Agent) ou Syslog (Push), Prometheus utilise un modèle PULL (Scrape).
Fonctionnement :
- Les cibles (serveurs, applications) exposent leurs métriques sur un endpoint HTTP (ex:
http://serveur:9100/metrics). C'est un Exporter (ex:node_exporter). - Le serveur Prometheus "scrape" (interroge) ce endpoint toutes les 15 ou 30 secondes (Pull).
- Il stocke les données dans sa propre TSDB (Time-Series Database).
- Il gère les alertes (via Alertmanager).
Grafana (Visualisation)
Grafana est un outil de visualisation (Dashboarding) open-source (concurrent de Kibana).
Il ne collecte et ne stocke rien. C'est une interface "lecture seule".
Fonctionnement :
- Vous ajoutez une "Data Source" (ex: Prometheus, Elasticsearch, Zabbix, MySQL...).
- Vous créez un Dashboard.
- Vous ajoutez un Panel (graphique).
- Vous écrivez une requête (ex: PromQL) pour récupérer les données de Prometheus.
- Grafana affiche le graphique.
| Protocole | Type | Usage Principal | Question Répondue |
|---|---|---|---|
| ICMP (Ping) | Polling (Pull) | Disponibilité (Fault) | "Est-il UP ou DOWN ?" |
| SNMP (GET) | Polling (Pull) | Performance (Metrics) | "Quel est son CPU ? Sa Bande Passante ?" |
| SNMP (TRAP) | Événement (Push) | Disponibilité (Fault) | "Un port vient de TOMBER !" |
| Syslog | Événement (Push) | Logs (Events) | "QUE s'est-il passé ? (ex: Login échoué)" |
| NetFlow / sFlow | Flux (Push) | Visibilité (Traces) | "QUI (IP) a saturé la bande passante et avec QUOI (Port) ?" |
| Outil | Modèle | Usage Principal | Graphing |
|---|---|---|---|
| Nagios / Icinga 2 | Check-based (Scripts) | Alerting (Up/Down). (Check OK/Warn/Crit). | Séparé (RRDtool, PNP4Nagios). |
| Zabbix | Agent / Agentless (Pull) | Monitoring All-in-One (Serveurs, Réseau). | Intégré (simple). |
| Prometheus | Pull (Scrape Exporters) | Monitoring Cloud/Conteneurs (Time-Series). | Séparé (Grafana). |
| ELK Stack | Push (Agents Beats) | Analyse de Logs (SIEM). | Intégré (Kibana). |
Nécessite le paquet snmp (net-snmp-utils).
snmpget
Récupérer un seul OID.
# Usage: snmpget -v [version] -c [community] [IP] [OID] # Récupérer le sysUpTime (temps écoulé) $ snmpget -v2c -c public 192.168.1.1 1.3.6.1.2.1.1.3.0
snmpwalk
"Marcher" dans l'arbre OID (GETNEXT).
# Usage: snmpwalk -v [version] -c [community] [IP] [OID_de_départ] # "Walker" toute la table des interfaces $ snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.2 # "Walker" la description des interfaces (ifDescr) $ snmpwalk -v2c -c public 192.168.1.1 .1.3.6.1.2.1.2.2.1.2 ifDescr.1 = STRING: "FastEthernet0/1" ifDescr.2 = STRING: "FastEthernet0/2"
