IP SLA et supervision
Définition
IP SLA (Internet Protocol Service Level Agreement, parfois écrit IPSLA) génère sur l'équipement Cisco des sondes actives - requêtes ICMP, TCP, UDP - et mesure le résultat : délai, réponse, gigue, perte. Là où SNMP lit des compteurs passifs, IP SLA provoque le réseau et mesure ce que l'utilisateur ressentirait. Ses résultats alimentent le track objects, la CLI, et les syslog.
Contexte
Le blueprint 200-301 liste IP SLA dans les services de supervision (avec les concepts de monitoring). L'attendu : comprendre ce qu'IP SLA mesure, connaître l'opération icmp-echo, savoir qu'elle se combine aux objects track pour pilote le forwarding (floating static, HSRP), et lire show ip sla statistics.
Détails techniques
Les opérations utiles
| Opération | Ce qu'elle sonde | Cas d'usage |
|---|---|---|
| icmp-echo | Reachability et round-trip vers une IP | Backup de lien, mesure de latence |
| icmp-jitter | RTT, gigue et perte entre deux points | Qualité VoIP vers un SBC |
| tcp-connect | Ouverture TCP vers un port/service | Santé d'un serveur applicatif |
| udp-jitter | Gigue/perte sur un flux UDP simulé | Dimensionnement voix/vidéo |
| dns | Temps de résolution d'un nom | Performance DNS |
| http | GET d'une URL mesuré en ms | Expérience applicative web |
| path-echo | Chemin complet (façon traceroute) | Cartographie des sauts |
Cycle de vie d'une sonde
Une opération se crée (ip sla 1), se configure, puis se schedule (ip sla schedule 1 life forever start-time now). Le routeur peut agir sur le résultat via un object track : l'état du track (up/down) pilote ensuite une route statique ou un mécanisme de redondance.
R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0
R1(config-ip-sla-echo)# frequency 10
R1(config-ip-sla-echo)# timeout 1000
R1(config)# ip sla schedule 1 life forever start-time now
R1(config)# track 1 ip sla 1 reachability
R1(config-track)# up 2 down 2
frequency 10 : une sonde toutes les 10 secondes. timeout 1000 : 1000 ms de délai avant de considérer la réponse perdue. up 2 down 2 sur le track : il faut 2 succès consécutifs pour repasser up, 2 échecs pour passer down (anti-rebond).
L'exemple canonique : floating static pilotée
Sans IP SLA, une route statique ne se retire que si son interface locale tombe. Avec next-hop récursif, un lien mort plus loin ne la retire pas. Le coupling track + route corrige ça :
R1(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.2 track 1
R1(config)# ip route 0.0.0.0 0.0.0.0 10.2.2.2 10
La route par défaut principale disparaît de la table dès que le track 1 passe down (le next-hop 10.1.1.2 ne répond plus à l'icmp-echo) ; la backup à AD 10 devient active. C'est le montage le plus demandé aux exams de type lab.
Lecture des résultats
R1# show ip sla statistics
IPSLA results (Entry offset time 0)
Operation number : 1
Latest operation status : OK
RTT operation type : IPv4
MinRtt AvgRtt MaxRtt LatestRtt
11ms 12ms 19ms 12ms
R1# show track 1
Track 1
Reachability is UP
1 change (interval 11:23:45)
Time: 00:12:44.123 -- state up
show ip sla statistics expose les RTT min/avg/max : un avg stable avec un max à 20 fois le min signale un bufferbloat, pas une panne. Côté J/S (jitter) pour les sondes voix, IOS renvoie jitter, mean random one-way delay, MOS estimé sur certaines plateformes.
Où IP SLA brille, où il s'arrête
- Bien : mesurer la performance perçue (un ping depuis la source réelle du trafic), déclencher des réactions réseau, comparer deux ISP avant un contrat.
- Limité : la sonde part de l'équipement, pas du PC de l'utilisateur ; un IP SLA depuis R1 ne prouve pas le chemin d'un PC de l'aile B. Les sondes permanentes consomment CPU : frequency 10 partout sur un 900 series se paie.
- Différent de NetFlow : NetFlow observe le trafic existant en passif, IP SLA injecte du trafic synthétique en actif.
Exemple concret
Un site double-homé, ISP-A en 10.1.1.2, ISP-B en 10.2.2.2. Une ping probe ICMP vers 203.0.113.1 (DNS public) via l'interface sortante de chaque ISP, frequency 5, track associé à chaque route par défaut. Un matin, le CPE d'ISP-A reste vivant (ping local OK) mais son upstream est coupé : la route statique classique ne bronche pas, le site reste aveugle. Avec le montage IP SLA, trois échecs (down 3) plus tard, la route disparaît, le track syslog le signale (%TRACK-6-STATE), le trafic bascule en 4 secondes. Retour réel documenté sur plusieurs incidents de ce type : la sonde ICMP vers une IP loin derrière l'opérateur est le seul moyen de voir une panne d'upstream côté client.
Pièges fréquents
- Oublier
ip sla schedule: la sonde configurée ne tourne pas, le track reste inconnu. - Sonde sans
source-interface: la réponse revient par un autre chemin, la mesure ne vaut rien. - Track sans
up x down x: un seul ping perdu fait basculer tout le site, oscillation. - Confondre reachability (track 1 ip sla 1 reachability) et RTT (track rtt) : le second peut être up avec un RTT dégradé.