Les équipements réseaux ne cessent de s’approcher des applicatifs : chiffrement, compression, cache (ou accéleration en termes marketing), qualité de service, partage de charge, stockage, iPBX, détection si ce n’est prévention d’intrusion et maintenant même anti-spam !
Revenons sur une de ces avancées qui bien qu’ancienne (elle date de 2000) reste peu connue et utilisée : Cisco NBAR (Network Based Application Recognition) est une fonctionnalité embarquée sur les routeurs Cisco récents permettant la reconnaissance des applications à partir de signatures et non plus uniquement sur des ports TCP/UDP. En l’activant, on peut construire le boitier QoS du « pauvre » en ce sens qu’aucun équipement ou coût suplémentaire n’est nécessaire : l’expert réseau démontre sa plus-value !
Evidemment, l’architecture doit être routée (ce qui élimine certaines topologies : les LANs étendus au moyen de liens Ethernet 802.1Q, qu’ils soient fournis par des opérateurs ou bien des fibres noires) et sous contrôle ( les routeurs ne doivent pas être gérés par un tiers, typiquement un opérateur ou un hébergeur).
NBAR permet d’identifier les flux , à l’instar des ACLs, mais en utilisant des signatures pour détecter les applications utilisant des ports mouvants (par nature tels skype, h.323, ou par « accident »HTTP, Citrix,etc..) ou bien se camouflant (canaux cachés avec stunnel, protocoles P2P : kazaa, emule, winMX , etc..). Ces signatures, nommées PDLM, sont mises à jour régulièrement et téléchargeables sous forme de mises à jour sur le site web de Cisco (nécessite un accès CCO). Certains flux utilisant des ports statiques généralement inchangés ou non modifiables (typiquement DNS, Exchange ou bien Netbios) sont définis comme tels dans NBAR (i.e sans signature applicative).
Malheureusement, la plupart de ces signatures sont très orientées P2P (on trouve le même biais dans les boitiers de QoS des constructeurs Allot ou Packeteers) ou bien VoIP /ToIP. On peut imaginer que le marché entrevu par le filtrage à grande échelle des flux P2P par les FAIs a justifié ce positionnement.
Certaines signatures demandes à être testées : nous avons découvert début 2007 que la signature TFTP d’un des constructeurs majeurs de boitiers de QoS ne fonctionnait pas (TFTP utilise des ports UDP dynamiques négociés lors de la session de contrôle) : c’est très problématique surtout lorsqu’on sait que la plupart des IP Phones bootent en chargeant leur logiciel par TFTP. Comment ce trafic pourrait-il être protégé si il n’est pas reconnu correctement ?
Revenons aux commandes Cisco : une fois le flux identifié, on applique les mécanismes de queueing classiques :
RTR(config-cmap)#match protocol edonkey
RTR(config-cmap)#match protocol napster
RTR(config-cmap)#match protocol fasttrack
[..]
RTR(config-pmap)#classmap bad_trafic
RTR(config-pmap-c)#drop
Si on veut être moins dur (par exemple pour du traffic web à titre personnel), on limite le débit à 100 kbits/s :
RTR(config-cmap)#match protocol http url "*voila.fr*"
RTR(config-cmap)#match protocol http url "*youtube.com*"
[..]
RTR(config)policy-map slow_perso_trafic
RTR(config-pmap)#classmap perso_trafic
RTR(config-pmap-c)#bandwidth 100
Il existe des possibilités pour rendre la QoS récursive (en utilisant des
à l’intérieur d’une
) mais cela sera l’objet d’un autre article…
Reste à l’appliquer sur l’interface Se0/0 vers Internet :
RTR(config-if)#service-policy input kill_bad_trafic
RTR(config-if)#ip nbar protocol-discovery
La puissance de NBAR lorsqu’il est appliqué à HTTP tient à son caractère stateful ( gestion des état en français ?) : bien que ce soient les paquets sortants qui contiennent l’URL, les paquets entrants (c-a-d les données) seront classifiés dans le même flot et ainsi soumis à la politique de QoS (dans le cas présent limitation en téléchargement à 10Kbps -mot clé input).
Enfin, NBAR permet d’obtenir des statistiques d’utilisation applicative en quasi temps réel : une fonctionnalité que nous utilisons assez souvent lors de nos audits réseau et que nous ne disposons pas d’outils de métrologie sur site.
Enter configuration commands, one per line. End with CNTL/Z.
RTR(config)#int fa0/0
RTR(config-if)#ip nbar protocol-discovery
RTR(config-if)#^Z
[10 min plus tard]
On appréciera le fait que les statistiques concernent les paquets entrants et sortant de l’interface selectionnée.
La période de référence (ici 5 min) est modifiable via la commande :
RTR(config-if)#load-interval ?
<30-600> Load interval delay in seconds
Cette variable était déjà utilisé lors du calcul de la charge et de la fiabilité de l’interface :
FastEthernet0/0 is up, line protocol is up
Hardware is MV96340 Ethernet, address is 0019.56bc.1288 (bia 0019.56bc.1288)
Internet address is 172.31.252.31/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
<strong> reliability 255/255, txload 1/255, rxload 1/255</strong>
Encapsulation ARPA, loopback not set
En ce qui concerne la partie monitoring à moyen et long terme, Cisco publie une MIB NBAR qui vise peut-être à concurrencer la norme IETF RMON2 qui n’a jamais vraiement décollé. Des frameworks de monitoring tels que Cacti peuvent ainsi grapher les stats NBAR.
Un dernier point : surveillez l’accroissement de CPU dû à NBAR. Ci dessous un extrait de la FAQ de NBAR :
Q. What type of performance can I expect with NBAR?
A. NBAR can classify stateful protocols with 300-byte packets with average flow lengths at 90 Mbps with just a 15 percent increase in CPU. For protocols classified by static port numbers, NBAR performs about the same as traditional access control lists (ACLs).
Q. How much memory does NBAR use?
A. NBAR uses 150 bytes of DRAM to track each stateful protocol flow. By default, NBAR allocates 1 MB of memory for flow resources, allowing NBAR to track about 5000 stateful flows without allocating more memory. NBAR will automatically allocate additional memory if needed.
Bonne découverte des flux de votre réseau !
