Introduction

---

Objectif :

Mise en place d’une qualité de service au travers d’un réseau MAN.

 

Sur chaque site géographique nous avons :

– Un réseau INTERNET en clair

– Un réseau INTRANET crypté (via IPSEC)

Le Site de Paris est notre site principal, il héberge les réseaux INTERNET et INTRANET.

 

Contraintes :

– Ne pas être dépendant du Fournisseur d’accès PROLAN en termes de routage.

– Garantir un débit minimum pour les réseaux INTERNET et INTRANET

– Être flexible pour l’ajout de nouveau site en terme de :

– Qualité de service

– Routage

 

Pourquoi mettre en place de la CBWFQ ?

– Nous voulons une qualité de service afin de garantir une bande passante à une plage d’adresse IP et non par rapport à un type de service.

Pourquoi des tunnels GRE ?

– Être indépendant en termes de routage.

– Avoir une CBWFQ par site.

 

Mise en place des Tunnels GRE

---

– Sur le site d’accueil (PARIS), nous allons devoir configurer un tunnel GRE pour chaque site clients.

– Sur les sites clients (NICE et TOURS), nous allons devoir configurer un tunnel GRE vers le site d’accueil.

 

Routage

---

En termes de routage, nous devons distinguer deux mondes :

– Avant le montage des Tunnels GRE (Underlying)

– Quand les tunnels GRE sont montés (Overlay)

 

Pour le monde Underlying, nous allons mettre en place du routage statique.

Le site de PARIS veut monter un Tunnel GRE avec NICE. Le tunnel GRE aura comme IP source la patte WAN du routeur de site de PARIS et comme IP destination la patte WAN du routeur de site de NICE. Il va donc falloir indiquer par quel chemin le routeur de PARIS va pouvoir joindre la patte WAN du routeur de site de NICE. (Et vice et versa)

Pour le monde Overlay, nous allons mettre en place du routage dynamique OSPF.

Tous nos sites clients vont apprendre leurs routes par défaut via le protocole OSPF. La route par défaut sera donc leurs tunnels GRE. Ce protocole va aussi permettre aux sites clients d’annoncer au site d’accueil les réseaux présents sur leurs sites géographiques.

CBWFQ

---

CBWFQ = Class-Based Weighted Fair Queueing (Mise en file d’attente pondéré basée sur les classes)

 

 

      Nous devons garantir une bande passante minimum pour nos deux types de réseau en cas de congestion réseau.

     Pour se faire, nous allons mettre en place de la qualité de service.

     Nous allons donc mettre en place de la CBWFQ.

 

 

Afin de prioriser nos flux en cas de congestion réseau, nous allons :

– Classifier nos flux via des access-list afin de placer nos paquets dans des files d’attente.

– Attribuer un pourcentage par file d’attente

– Appliquer nos politiques CBWFQ sur nos interfaces Tunnel

 

Classification

---

Nous allons classifier via des access-lists nos flux :

– INTRANET

– INTERNET

– PRIORITAIRE (SNMP, SSH, NTP, LOG)

 

Les flux qui ne seront pas classifié iront dans la file d’attente DEFAULT.

Les flux prioritaire sont appelés LLQ (Low Latency Queueing)

 

Gestion des files d’attentes

---

La commande policy-map va nous permettre de créer nos files d’attentes.

Pour ce faire, il faut lui spécifier :

– Une class-map

– Un pourcentage ou une bande passante

Spécifier un pourcentage permet de faire le moins de modification possible en cas d’augmentation ou de diminution de débit vers le fournisseur d’accès.

En cas de congestion réseau, il existe deux types d’action possible :

Policing

     En cas de congestion réseau, des paquets vont être droppés afin de respecter la limite de bande passante fixée. Ce qui obligera l’émetteur de baisser sa vitesse de transmission en TCP.

 

Shaping

      En cas de congestion réseau, des paquets vont être choisi aléatoirement pour être placés dans des files d’attentes afin de respecter la limite de bande passante fixée. Ces paquets seront traités lorsqu’il y aura de la bande passante disponible.

 

La CBWFQ configuré fait du traffic shaping grâce à la commande :

shape average percent 100

 

Mise en application de la CBWFQ

---

      La Qualité de service CBWFQ va être mise en place sur chaque interface tunnel.

Pour appliquer la CBWFQ, nous allons utiliser la commande

service-policy output XXXXX

 

Pour spécifier à quel moment la liaison est saturé, nous allons utiliser la commande :

bandwidth 30000  (Pour 30Mbps)