Realisations/2011-2012/Projet/Rapport: PRES2011-Projet1-FOURMAUX-PFRES-RapFinal.tex

%% 
%% File:    PRes10v2.tex
%% OldFile:    PRes09v2.tex
%% OldFile:    PRes08v2.tex
%% OldFile:    PRes07v2.tex
%% OldFile:    PRes06v1.tex
%% Author:  Olivier Fourmaux (olivier.fourmaux@upmc.fr)
%%
%% 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Type et package

\documentclass[a4paper,12pt]{article}

\usepackage[francais]{babel}
\usepackage{fancyhdr}
\usepackage[T1]{fontenc}
\usepackage{ucs}
\usepackage[utf8x]{inputenc}
\usepackage{graphicx}
\usepackage{calc}
\usepackage{url}
\usepackage{boxedminipage}
\usepackage{lmodern}

\makeatletter
\usepackage{subfig}
\usepackage{verbatim}
\usepackage{abstract}
\usepackage{amsthm}
\usepackage{booktabs}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{enumerate}
\usepackage{tabularx}
\usepackage[table]{xcolor}
\usepackage{pifont}
\usepackage[toc,page]{appendix}
\usepackage{multicol}
\usepackage{tocvsec2}
\usepackage{framed}
\usepackage{lastpage}
\usepackage{cleveref}
\usepackage[unicode=true, pdfusetitle,
 bookmarks=true,bookmarksnumbered=false,bookmarksopen=false,
 breaklinks=false,pdfborder={0 0 1},backref=false,colorlinks=false]
 {hyperref}

\definecolor{lightgray}{gray}{0.9}
\settocdepth{section}

\theoremstyle{remark}
  \newtheorem*{rem*}{Remarque}

\colorlet{shadecolor}{gray!25}   % you may try 'blue' here
\renewenvironment{leftbar}{%
  \def\FrameCommand{\textcolor{shadecolor}{\vrule width 3pt} \hspace{10pt}}%
  \MakeFramed {\advance\hsize-\width \FrameRestore}}%
{\endMakeFramed}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Définitions à personnaliser 

%% Pour les noms, utilisez la premiere lettre du prénom suivi du 
%% nom de famille (premiÚre lettre majuscule, reste en minuscule).


%%%% Indiquer le nom de l'encadrant ci-dessous:

\def\nomEncad{O.~FOURMAUX}

%% Si le projet est co-encadré indiquer les deux noms à la suite dans 
%% le même champs


%%%% Indiquer les noms des étudiants participant ci-dessous:

\def\nomEtudA{B.~BACHELART}
\def\nomEtudB{B.~BARON}
\def\nomEtudC{B.~GONZALEZ}
\def\nomEtudD{A.~RAGALEUX}

%% Si le projet est encadré par moins de 4 étudiants laissez
%% les variables inutiles vides


%%%% Indiquer la référence (numero) et le nom du sujet ci-dessous:

\def\refProjet{1} 
\def\titreProjetCourt{Evolution PFRES}
\def\titreProjetLong{Evolution de la PlateForme spécialité RESeau (PFRES)}

%% Le titre court ne doit pas faire plus d'une vingtaine de caractÚre
%% résumez le à quelques mots essenciels


%%%% Indiquer le type de document et sa version ci-dessous:

\def\typeDoc{Rapport final}
 
%% - Rapport intermédiaire
%% - Rapport final

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Définitions à ne pas modifier
 
%%%%% ||| Mise en page verticale ||| 
\setlength{\voffset}{-1in} % a4:reste 297mm pour les 5 suivants:
\setlength{\topmargin}{15mm}         % avant l'en-tête
\setlength{\headheight}{20mm}        % hauteur de l'en-tête 
\setlength{\headsep}{10mm}           % entre l'en-tête et le corps
\setlength{\textheight}{230mm}       % hauteur du corps
\setlength{\footskip}{14mm}          % pied de page par rapport au corps 

%%%%% --- Mise en page horizontale ---
\setlength{\hoffset}{-1in} % a4:reste 210mm 
\setlength{\oddsidemargin}{25mm}     % entre hoffset et le corps
\setlength{\evensidemargin}{25mm}    % entre hoffset et le corps
\setlength{\marginparwidth}{0mm}     % largeur de la marge
\setlength{\marginparsep}{0mm}       % séparateur corps marge
\setlength{\textwidth}{160mm}        % largeur du corps

\def\annee{2011-12}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Début du document

\begin{document}

\selectlanguage{francais}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Définition des en-têtes et pied de pages
\pagestyle{fancyplain}
\lhead[\fancyplain{}{\texttt{Université Pierre et Marie Curie}\\
          Master Informatique\\ UE \textbf{PRes} fév. \annee \\ \nomEncad}]
      {\fancyplain{}{\textsc{Université Pierre et Marie Curie}\\
          Master Informatique\\ UE \textbf{PRes} \annee \\ \nomEncad}}
\chead[\fancyplain{}{\textbf{Projet \refProjet\\\titreProjetCourt}}]
      {\fancyplain{}{\textbf{Projet \refProjet\\\titreProjetCourt}}}
\rhead[\fancyplain{}{\nomEtudA\\\nomEtudB\\\nomEtudC\\\nomEtudD}]
      {\fancyplain{}{\nomEtudA\\\nomEtudB\\\nomEtudC\\\nomEtudD}}
\lfoot[\fancyplain{}{\includegraphics[width=3cm]{img/UPMC_sorbonne.pdf}}]
      {\fancyplain{}{\includegraphics[width=3cm]{img/UPMC_sorbonne.pdf}}}
\cfoot[\fancyplain{}{\textbf{\thepage/\pageref{LastPage}}}]
      {\fancyplain{}{\textbf{\thepage/\pageref{LastPage}}}}
\rfoot[\fancyplain{}{\typeDoc}]
      {\fancyplain{}{\typeDoc}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

~

      \begin{center}
        \begin{boxedminipage}{12cm}{
            \begin{center}
              ~\\\LARGE\textbf{\titreProjetLong}\\
              ~\\\large Encadrant: \textbf{\nomEncad}\\
              ~\\\large Etudiants: \textbf{\nomEtudA, \nomEtudB, \nomEtudC, \nomEtudD}\\
            \end{center}
            }
        \end{boxedminipage}
      \end{center}

~

\tableofcontents

\newpage

\section{Cahier des charges}

\subsection{Introduction}
Un réseau informatique permet à plusieurs terminaux de communiquer entre eux afin d'assurer des échanges d'informations : du transfert de fichiers, du partage de ressources (périphériques et données), de la messagerie ou de l'exécution de programmes à distance.

L'Internet est un réseau informatique mondial constitué d'un ensemble sous-réseaux autonomes (AS ou \emph{Automous System}) dont la finalité est de connecter tous les équipements informatiques du monde.

Ainsi ce projet s'intéressera à l’étude des réseaux informatiques (le réseau Internet ainsi que les réseaux locaux d'entreprises connectés à Internet) en commençant par l'acquisition des équipements (réseaux et informatiques), et en poursuivant par la mise en place des différents protocoles et à la configuration des différents services. Cette étude sera réalisée aussi bien du point de vue d'un ISP (\emph{Internet Service Provider}) que d'une entreprise.

Cependant l'immensité du réseau Internet et le nombre phénoménal de protocoles et équipements le constituant rendent l'analyse d'Internet peu modulaire, bien trop complexe et souvent impossible en raison de nombreuses contraintes économiques et sécuritaires.

\subsection{Finalité}

Le but de ce projet est de concevoir une plateforme réseau et de \textbf{multiplier les services applicatifs offerts par cette derniÚre}.

L'objectif visera donc à   s'approcher d'une architecture basée sur le modÚle Internet en utilisant des équipements réseaux professionnels afin de simuler au mieux l'architecture réelle. Chacune des quatre armoires représente un systÚme autonome (AS) particulier suivant le modÚle d’une entreprise ou d’un cœur de réseau (semblable à  un ISP).  
     
Chaque systÚme autonome doit alors se gérer lui-même en prenant en compte les problématiques de services applicatifs de base, de qualité de servicee, de routage et de sécurité en utilisant des technologies variées.

Chaque AS est censé être différent au niveau matériel réseau, cette hétérogénéité suit le modÚle de l’Internet qui comporte de nombreux systÚmes et équipements différents.

La plate-forme pourra alors servir à différentes expérimentations telles que VoIP ou vidéo sur IP.

Il est nécessaire à des fins expérimentales et statistiques de pouvoir analyser le trafic qui transite au sein des commutateurs de chaque AS, de ce fait, le trafic de chaque commutateur sera dupliqué sur un port où une sonde pourra capturer le trafic. Cependant l'analyse statistique et/ou analytique des données capturées de ne fait pas partie des objectifs du projet, nous nous contenterons simplement d'en fournir les outils.

\subsection{Nouveautés par rapport à l'année précédente}
Les objectifs du projet sont semblables à ceux de l'année derniÚre. Cependant il a été décidé de recommencer à partir de zéro (voir section \ref{sec:analyse}, Analyse).

De même, les équipements réseaux disponibles sont en grande partie repris de l'année précédente hormis quatre contrÎleurs de console (ACS) et quatre contrÎleurs d'alimentation (un par AS) :
\begin{itemize}
\item Les d'ACS (\emph{Advanced Controller System}) permettent d'administrer les différents systÚmes sans devoir établir une connexion spéciale (eg. en SSH) à chacun d'entre eux.
\item Les contrÎleurs d'alimentation fourniront en énergie les équipements de la plateforme et permettront d'obtenir des statistiques sur la consommation globale. Ils ne permettent cependant pas d'activer ou de désactiver un équipement à distance.
\end{itemize}

L’accÚs distant à  la plate-forme s’effectuera en SSH via une passerelle.

\subsection{Réalisations}
A la fin du projet, auront été réalisées les tâches suivantes (la liste présentée n'est pas exhaustive) :
\begin{itemize}
        \item Installation des contrÃŽleurs d’alimentation,
        \item Installation des contrÎleurs de console et test de l'accÚs aux équipements,
        \item Re-câblage des liaisons réseaux,
        \item Re-configuration d'un \emph{proxy} vers l'extérieur,
        \item Vérification des configurations des équipements,
        \item Configuration de VLANs,
        \item Configuration IPv4 et IPv6,
        \item Protocoles de routage (OSPF, BGP),
        \item Mise en place de MPLS dans l'AS 3 qui comporte au moins trois routeurs,
        \item Mise en place de protocoles de sécurité (IPSec, SSL/TLS, VPN),
        \item Mise en place de services (web, QoS, VoIP\dots),
        \item Vérification du bon fonctionnement en charge.
\end{itemize}

\vspace{10pt}

\clearpage

\section{Plan de développement}
Le projet va s'étaler sur environ 5  mois et il faudra répondre au cahier des charges durant cette période. 
Ainsi, un plan de développement a été conçu pour mener à bien le projet.

Le choix a été fait de permettre une compréhension globale de la plateforme aux quatre participants. Par conséquent, le câblage et la configuration basique des équipements seront effectués conjointement au sein du groupe. \\
La mise en place des services applicatifs, ainsi que les configurations plus avancées des équipements (protocoles de routage, MPLS, protocoles de sécurité) seront quant à eux réalisés individuellement ou par groupe de deux afin d'optimiser le temps imparti.

\subsection{Prise de connaissance de la plateforme}
\textbf{Durée.} \emph{1 semaine}

Liste des équipements composant la plateforme et tests de bon fonctionnement avec une éventuelle remise en état de certains équipements.

Prise de connaissance de ce qui avait été fait l'année derniÚre au cours d'un projet similaire au notre (lecture du précédent rapport et du wiki).

\subsection{Analyse et conception}
\textbf{Durée.} \emph{3 semaines}

Analyse des choix de conception du projet de l'année derniÚre.

Choix des services à implémenter dans chaque AS en réponse au cahier des charges et en fonction des fonctionnalités offertes par les différents équipements.

Modification du plan de câblage afin de prendre en compte les différents équipements qui ont été ajoutés ou supprimés de la plateforme.

Conception d'un nouveau plan d'adressage ainsi que d'une nouvelle topologie logique.

\subsection{Câblage et configuration des équipements}
\textbf{Durée.} \emph{3 semaines}

L'analyse et la conception impliqueront des modifications de l'architecture physique et logicielle de la plateforme. 

Le câblage sera ainsi modifié afin de répondre aux nouvelles contraintes induites par la phase précédente.

Une re-configuration complÚte des équipements réseau sera ensuite réalisée afin de prendre en compte les modifications faites au niveau physique ainsi que d'être en accord avec la nouvelle topologie logique retenue lors de la phase d'analyse.

Une approche \textit{bottom-up} (ascendante) lors de la configuration sera privilégiée pour s'assurer au fur-et-à -mesure du bon fonctionnement des modifications.

Ré-Installation des systÚmes d'exploitation d'une partie des serveurs de la plateforme.
 

\subsection{Protocoles de routage et implémentation de services}
\label{impleServices}
\textbf{Durée.} \emph{5 semaines}

Dans un premier temps, les protocoles de routage inter et intra-AS devront être configurés dans les routeurs afin chaque AS soit accessible depuis n'importe quel autre systÚme autonome. En parallÚle il faudra  implémenter les services de base offert par une entreprise ou un FAI (DNS, SMNP, HTTP, NTP, FTP, \dots). 

Puis la mise en place de services plus avancés nécessaires à notre étude (Voix sur IP, Vidéoconférence, \dots) sera réalisée individuellement ou par groupe de deux étudiants. Afin de prendre en compte les contraintes imposées par ces nouveaux services (temporelle, pertes, bande passante) une configuration plus poussée des équipements cœur des AS devra être effectuée (QoS, MPLS, \dots).

\subsection{Tests de fonctionnement}
\textbf{Durée.} \emph{5 semaines}

Différents tests de fonctionnement seront réalisés pour chaque service mis en place lors de l'étape précédente \ref{impleServices}. Ces tests seront opérés par échelon  : 
\begin{itemize}
        \item Test de fonctionnalités : vérifications permettant de s'assurer que les fonctions implémentées répondent aux aux attentes. Ces tests s'effectueront sur trois niveaux différents selon le type de service :
        \begin{itemize}
                \item Service disponible en local seulement (un VLAN particulier),
                \item Service disponible dans l'ensemble d'un AS,
                \item Service disponible sur toute la plateforme.
        \end{itemize}
        \item Tests de performances : vérification permettant de s'assurer que les services soient fonctionnels avec un débit, un temps d'attente ou une latence raisonnables.
        \item Tests de robustesse : vérification permettant de s'assurer que les services testés supportent une montée en charge.
\end{itemize}

Pour chaque service tous les niveaux d'évaluation devront être validés afin qu'il soient considérés comme intégré à la plateforme.

\subsection{Documentation}
\textbf{Durée.} \emph{Tout le long du projet}

Cette section a dû être modifiée pour le présent rapport. En effet, il était question de documenter précisément la plateforme en fonction de l'avancement du projet en utilisant un wiki géré par Trac.
Cependant la modification des pages du Trac n'a jamais été possible (ou a été rendue difficile par des dysfonctionnements répétitifs) et par conséquent sera réalisé à l'aide un fichier partagé entre les membres du groupe.
Ce fichier devra ensuite être retravaillé sous la forme d'un manuel au format pdf pour une lecture plus aisée et plus pédagogique pour les futurs utilisateurs de la plateforme.

\clearpage
% \begin{landscape}
%       \pagestyle{plain}
\subsection{Diagramme de Gantt}

\begin{figure}[htbp]
        \centering
                \includegraphics[height=4.83in]{img/gantt.pdf}
        \label{fig:gantt}
\end{figure}
% \end{landscape}
\clearpage

\section{Contexte technologique}
\subsection{L'Internet actuel}

Une vison de l'Internet tel qu'il est actuellement est un ensemble de systÚmes autonomes (\emph{Autonomous Systems}, AS) inter-connectés les uns avec les autres. Un systÚme autonome correspond à un réseau unique ou un groupe de réseaux, contrÎlé par un administrateur commun (ou un groupe d'administrateurs) au nom d'une entité administrative unique (telle qu'une université ou une entreprise commerciale). Un systÚme autonome est aussi parfois considéré comme un domaine dans lequel une unique politique de routage interne est mise en place.\newline

Aujourd'hui, de par la complexité de la topologie physique, il est extrêmement difficile de cartographier les équipements réseau de cœur composant l'Internet. Afin de pouvoir acheminer des données d'un émetteur à  un destinataire, les routeurs (qui connaissent, au moins, partiellement la topologie) ont pour rÃŽle d'établir des chemins (routes) entre un émetteur et un destinataire pour chacune de leurs unités de données. Cette opération (le routage) est extrêmement importante puisqu'en plus d'assurer le bon fonctionnement de l'Internet, elle est directement liée au temps de réponse (ou latence) pour les utilisateurs. Il est donc nécessaire qu'un routeur choisisse le prochain de nœud de façon fiable et rapide.  Pour cela les routeurs doivent s'échanger des informations sur la topologie du réseau en utilisant un protocole de routage. Il existe deux types de protocole de routage : les protocoles intra-AS (eg. RIP, OSPF) et les protocoles inter-AS (eg. BGP). De nos jours, le routage inter-AS est réalisé en prenant de plus en plus compte des paramÚtres économiques et politiques en dépit de la recherche du plus court chemin à  l'instar du routage intra-AS. Actuellement les protocoles de routage s'adaptent et de nouveaux protocoles émergent afin de répondre à  des besoins plus récents en terme de routage : le \emph{multicast} (une source, plusieurs destinataires) et \emph{anycast} (une source, plusieurs destinataires potentiels mais un seul est choisi).\newline

L'Internet était à l'origine dénué de tout dispositif de sécurité, cependant, avec sa popularité croissante, les problématiques de confidentialité, d'intégrité et d'authentification des données sont devenues de plus en plus présentes pour être aujourd'hui un des sujets les plus sensibles et les plus actifs dans le monde des réseaux et télécommunications. En effet avec la multiplication et le risque croissant de certaines attaques, il est maintenant in-envisageable de faire transiter des données ne serait-ce que légÚrement sensibles sans utiliser des mécanismes de sécurité. De plus indépendamment du pouvoir de défense élevé que présentent les techniques cryptographiques actuelles, un nouveau type d'attaque a vu le jour consistant à rendre inutilisable des services proposés par des machines en les submergeant de trafic inutile (attaque par \emph{Denial of Service}, DOS).\newline

La finalité des réseaux et d'Internet est de fournir aux utilisateurs un accÚs à diverses applications connectées tels que le web, l'accÚs aux mails ainsi que le transfert de fichier ou simplement leur fournir l'heure.\newline
L'apparition perpétuelle de nouvelles applications implique souvent des contraintes supplémentaires sur les couches inférieures de l'architecture du modÚle TCP/IP, remettant parfois en cause les principes fondateurs d'Internet.
Parmi les nouvelles applications phares de l'actualité, il y a la voix sur IP ou la vidéoconférence. Les fortes contraintes temporelles et en terme de débit (notamment pour la vidéoconférence) amÚnent à intégrer de la qualité de service (QoS) afin de privilégier certains flux ou classes de service dans les routeurs, les rendant ainsi plus complexes.\newline

L'Internet de nos jours fait également face à une autre problématique : le protocole IPv4 sur lequel se base l'architecture TCP/IP montre ses limites devant l'accroissement de la demande d'adresses.\newline
En effet la croissance exponentielle du nombre de foyer connecté à internet et le nombre toujours plus important d'objets connectables laissent penser que le NAT et CIDR ne suffiront plus à faire perdurer le protocole IPv4.
Spécifié fin 1998, le protocole IPv6 a pour but de résoudre ce problÚme de pénurie d'adresses ainsi que de prendre en compte de façon native des contraintes plus récentes et diverses améliorations (QoS, Auto-configuration, Multicast, \dots) sans remettre en cause les principes fondateurs d'Internet, à  savoir un cœur de réseau qui soit le plus simple possible.

\subsection{De la nécessité de l'expérimentation}
Ce projet prend toute sa forme dans un contexte d'expérimentation.

En effet, avant d'implémenter de nouvelles fonctionnalités à grande échelle sur l'ensemble d'un réseau, il est nécessaire de tester leur bon fonctionnement sur une version réduite de ce réseau.

\clearpage
\section{Analyse}
\label{sec:analyse}
\subsection{Liste du matériel et de leurs fonctionnalités}
 Des contrÎleurs d'alimentation et des contrÎleurs de consoles ont été ajoutés à cette plateforme par rapport aux années précédentes. De plus, un routeur Juniper de l'AS 3 est hors-service.

\subsection{Liste du matériel}

\rowcolors{1}{}{lightgray}
\noindent{\scriptsize
\begin{tabularx}{\textwidth}{>{\hsize=.1\hsize}X|>{\hsize=.23\hsize}X>{\hsize=.25\hsize}X>{\hsize=.23\hsize}X>{\hsize=.23\hsize}X}
 & \textbf{Armoire 1} & \textbf{Armoire 2} & \textbf{Armoire 3} & \textbf{Armoire 4}\\
\midrule
 & AS 1 (Entreprise) & AS 2 (Coeur) & AS 3 (Coeur) & AS 4 (Entreprise)\\
Alimentation & \multicolumn{4}{c}{Avocent PM 1000 (\emph{Power Distribution Unit})}\\
ContrÃŽleur & \multicolumn{4}{>{\columncolor{lightgray}}c}{Cyclades ACS 5000 (\emph{Advanced Console Server})}\\
Commutateur & 1 Cisco WS-C3560-24PS & 1 Cisco WS-C2960G-24TC-L & 2 HP ProCurve 2900-24G & 1 Extreme x450e-24P\\
Routeur & 1 Cisco 2801 & 2 Cisco 3825 & 4 Juniper J4350 & 2 Juniper J2300\\
Serveur & 3 & 2 & 2 & 3\\
Firewall & 1 Cisco ASA 5510 & N/A & N/A & 2 Juniper SSG20\\
Matériel & \multicolumn{4}{c}{Téléphones IP Cisco SPA962}\\
\end{tabularx}}

\subsubsection{Routeurs}
\rowcolors{1}{}{lightgray}
\noindent{\scriptsize
\begin{tabularx}{\textwidth}{l|>{\centering\arraybackslash}X>{\centering\arraybackslash}X>{\centering\arraybackslash}X>{\centering\arraybackslash}X}
                                                   &  \textbf{Cisco 2801}            &  \textbf{Cisco 3825}     & \textbf{Juniper J4350} & \textbf{Juniper J2300}\\
\midrule                                                                            
                  Ethernet Gigabit &                   \ding{52} &            \ding{52}     &                      \ding{52} &                      \ding{52}\\
          IEEE 802.1q VLAN &                   \ding{52} &            \ding{52}     &                      \ding{52} &                      \ding{52}\\
                      IPv6 &                   \ding{52} &            \ding{52}     &                      \ding{52} &                      \ding{52}\\
                Routage IP &                   \ding{52} &            \ding{52}     &                      \ding{52} &                      \ding{52}\\
                       QoS &                   \ding{52} &            \ding{52}     &                      \ding{52} &                      \ding{52}\\
                       VPN &                   \ding{52} &            \ding{52}     &                      \ding{52} &                      \ding{52}\\
                 Multicast &                   \ding{52} &            \ding{52}     &                      \ding{52} &                      \ding{52}\\
                      MPLS &                   \ding{52} &            \ding{52}     &                      \ding{52} &                      \ding{52}\\
        SystÚme d'exploitation & Cisco IOS 2801 v12.4(22)YB5 & Cisco IOS 3825 v12.4(22) &                                 JUNOS 8.2R2.4 &                                  JUNOS 8.2R1.7\\
                                Interfaces &                      2 FastEthernet &          32 FastEthernet &                 4 Gigabit Ethernet &                             2 FastEthernet\\
\rowcolor{white} 
                                                   &                                                     &           4 Gigabit Ethernet &                                                            &                                                           \\
\end{tabularx}
}

\subsubsection{Commutateurs}

\rowcolors{1}{}{lightgray}
\noindent{\scriptsize
\begin{tabularx}{\textwidth}{l|>{\centering\arraybackslash}X>{\centering\arraybackslash}X>{\centering\arraybackslash}X>{\centering\arraybackslash}X}
                                                   & \textbf{Cisco WS-C3560-24PS} & \textbf{Cisco WS-C2960G-24TC-L} & \textbf{HP ProCurve 2900-24G (J9049A)} & \textbf{Extreme Network Summit X450e-24p}\\
            \midrule
          Ethernet Gigabit &                               \ding{52} &                     \ding{52} &                 \ding{52} &                                   \ding{52}\\
          IEEE 802.1q VLAN &                               \ding{52} &                     \ding{52} &                 \ding{52} &                                   \ding{52}\\
                      IPv6 &                               \ding{52} &                     \ding{52} &                 \ding{52} &                                   \ding{52}\\
                     Trunk &                               \ding{52} &                     \ding{52} &                 \ding{52} &                                   \ding{52}\\
                Routage IP &                               \ding{52} &                     \ding{52} &                 \ding{52} &                                   \ding{52}\\
                       QoS &                               \ding{52} &                     \ding{52} &                 \ding{52} &                                   \ding{52}\\
                       VPN &                               \ding{52} &                     \ding{52} &                 \ding{52} &                                   \ding{52}\\
                       PoE &                               \ding{52} &                     \ding{52} &                 \ding{52} &                                   \ding{52}\\
        SystÚme d'exploitation &                  Cisco IOS C3560 v12.2(25)SEB4 & Cisco IOS C2960 v12.2(25)SEE2 &                           T.12.06 &                   ExtremeWare XOS v1150b10 \\
                                Interfaces &                                     24 FastEthernet &                       24 Gigabit Ethernet &       24 Gigabit Ethernet &                                        24 Gigabit Ethernet \\
\rowcolor{white} 
                                                   &                                      2 Gigabit Ethernet &                                                           &               (10/100/1000BASE-T) &                                            (10/100/1000BASE-T) \\
\end{tabularx}
}

\subsubsection{Firewalls}

\rowcolors{1}{}{lightgray}
\noindent{\scriptsize
\begin{tabularx}{\textwidth}{l|>{\centering\arraybackslash}X>{\centering\arraybackslash}X}
                           & \textbf{Cisco ASA 5510 Series} &         \textbf{Juniper SSG20}\\
             \midrule
                                           IPS &                      \ding{52} &                      \ding{52}\\
                       VPN &               SSL, DTLS, IPSec &                          IPSec\\
           IEEE 802.1x NAC &                      \ding{52} &                      \ding{52}\\
                      DHCP &                      \ding{52} &                      \ding{52}\\
                      IPv6 &                      \ding{52} &                      \ding{52}\\
                       NAT &                      \ding{52} &                      \ding{52}\\
                Routage IP &                      \ding{52} &                      \ding{52}\\
                       QoS &                      \ding{52} &                      \ding{52}\\
    SystÚme d'exploitation &  Cisco Adaptive Security Appliance Software v7.1(2) &            ScreenOS v6.2.0r13.0\\
                                Interfaces &                     3 FastEthernet &                 4 FastEthernet\\
\end{tabularx}
}

\rowcolors{1}{}{}

\subsection{Implémentation des protocoles avancées et services}

En plus des services applicatifs standards et essentiels associés aux protocoles : HTTP (web), FTP (transferts de fichier), SMTP (envoi de courriels), POP/IMAP (réception de courriels), SNMP (administration), DHCP (autoconfiguration), NTP (heure), DNS (annuaire), les sections suivantes présentent les protocoles et/ou services plus récents et moins courants qui seront intégrés à la plateforme et reflétant un désir de se rapprocher d'un modÚle moderne et réaliste.
 
\subsubsection{IPv6}
Les commutateurs, et surtout les routeurs de la plateforme supportent le protocole IPv6. De plus les services réseaux des systÚmes d'exploitation installés sur les serveurs sont également compatibles avec le protocole IPv6. Ainsi la mise en place d'un plan d'adressage IPv6 et des services associés  sera effectuée. Cependant pour correspondre au mieux à la réalité des réseaux d'aujourd'hui, IPv4 sera favorisé par les applications. 

\subsubsection{Sécurité}
La sécurité devra être assurée à différents niveau de l'architecture :
\begin{itemize}
        \item IPSec : pour la sécurité des paquets IP,
        \item SSL/TLS : pour la sécurité des échanges,
        \item VPN : pour établir une connexion sécurisé entre les deux réseaux d'entreprises de la plateforme.
\end{itemize}
De plus, la mise en œuvre de mécanismes de défense contre les attaques de déni de service (DoS) pourra être envisagée (sous réserve de temps disponible).

\subsubsection{VoIP et QoS}
La VoIP (Voix sur IP) permet de faire passer la voix par internet pour communiquer gratuitement d'ordinateur à ordinateur. L'implémentation du protocole SIP (\emph{Session Initiation Protocol}) sera mise en place afin d'intégrer ce service. Un serveur applicatif de type \emph{Registar} ainsi qu'un proxy SIP devront être installés.\\
Une fois ce service réalisé de la qualité de service (QoS) pourra être configurée dans les routeurs. Le modÚle DiffServ (différentiation des paquets par classe de service) sera considéré.
 
\subsubsection{MPLS}
MPLS est un protocole dont la finalité est de commuter des paquets IP. Les contraintes vis-à -vis de la plateforme sont les suivantes :
\begin{itemize}
        \item MPLS entre AS actuellement non supporté par les équipements CISCO,
        \item MPLS ne fonctionne que si il y au moins un routeur de cœur (\emph{Label Switch Router}, LSR). 
\end{itemize}
Par conséquent seul l'AS 3 remplit les critÚres pour faire fonctionner MPLS. En effet il s'agit du seul AS possédant strictement plus de deux routeurs. Ce protocole sera alors implémenté sur ce systÚme autonome.


\subsection{Evolutivité}
L'architecture physique choisi permet de faire évoluer l'architecture logique aisément sans avoir à modifier le câblage du matériel. 

\clearpage
\section{Conception}
\subsection{Architecture physique générale de la plateforme}
La topologie physique en étoile (tous les équipements sont reliés au commutateur) a été conservée par rapport au projet de l'année derniÚre. Cependant un re-câblage à été opéré afin de faciliter la visualisation des câbles à la sortie des différents équipements. 

De plus les câbles reliant les AS passent maintenant au dessus des armoires (et non en dessous) afin de mettre les liens physiques inter-AS en évidence, ainsi que d'éviter leurs détériorations par les roues des armoires (si jamais la plateforme devait être déplacée).

\begin{figure}[htbp]
        \centering
                \includegraphics[scale=.25]{img/racks.pdf}
        \caption{Elements composant la plateforme, salle Intel 25/26 110}
        \label{fig:racks}
\end{figure}


De plus les contrÎleurs de consoles ainsi que les contrÎleurs d'alimentation ont été intégrés à la plateforme comme suit (pour chaque AS) :
 
\begin{figure}[htbp]
        \centering
                \includegraphics[scale=.25]{img/ACS.pdf}
        \caption{Intégration de l'\emph{Advanced Controller Server} dans l'AS 1}
        \label{fig:ACS}
\end{figure}

Convention : les premiers ports des contrÎleurs de console sont réservés aux commutateurs, les suivants sont réservés aux routeurs, les \emph{firewalls} et enfin les serveurs.

\subsection{Architecture logique générale de la plateforme}
Une topologie logique inspirée de celle du projet de l'année derniÚre a été retenue. 

Cependant à la place des adresses IP privées (10.0.0.0/8) existantes, des adresses IP publiques seront utilisées, donc routables sur l'ensemble du réseau. Cela est possible puisque la plateforme ne sera pas connectée à l'Internet. Par conséquent le plan d'adressage à été entiÚrement ré-établi.\\

Les plages d'adresses utilisées pour chaque AS sont les suivantes :\newline

\rowcolors{1}{}{lightgray}
\begin{tabularx}{0.962\textwidth}{XXX}
        \textbf{Numéro de de l'AS} & \textbf{Adresse IPv4} & \textbf{Adresse IPv6} \\
        \midrule
        AS 1 & \verb!23.7.100.0/24! & \verb!2a00:b82:8502::/48!\\
        AS 2 & \verb!28.5.0.0/16! & \verb!2e70:13::/32!\\
        AS 3 & \verb!13.8.0.0/16! & \verb!2d05:37::/32!\\
        AS 4 & \verb!4.11.100/24! & \verb!2a00:285:42::/48!\\
        VLAN Internet  & \verb!10.40.130.0/24!  & N/A\\
\end{tabularx}
\rowcolors{1}{}{}

\vspace{10pt}
Le VLAN Internet est détaillé dans une sous-section ci-dessous.
Pour les plages d'adresses des AS, les valeurs des deux premiers octets des \emph{NetID} correspondent aux différentes dates de naissances des participants du projet (c'est un bon moyen de se souvenir des anniversaires !). La valeur en décimale du troisiÚme octet est à 100 si le réseau considéré est une entreprise et à 0 si le réseau est un FAI (dans ce cas le troisiÚme octet fait d'ailleurs parti de l'\emph{HostId} de ce réseau).

Bien évidemment le découpage CIDR est utilisé pour IPv4 et les plages utilisées sont détaillés dans les présentations détaillées des AS. 

\subsection{VLANs et conventions}

En dehors du VLAN d'administration les routeurs possÚdent toujours les plus hautes adresses logiques que leur plage puisse offrir.

\subsubsection{\emph{Port mirroring}}

Tout le trafic traversé dans un commutateur sera dupliqué sur une interface particuliÚre reliée à un sonde qui aura pour objectif d'observer le trafic global de l'AS considéré.
 
\subsubsection{VLAN d'administration}
Un VLAN d'administration par AS sera mis en place afin de gérer les équipements, de diagnostiquer des problÚmes ainsi que d'obtenir diverses statistiques (en utilisant le protocole SNMP). Chaque AS possédera un réseau privé en dehors de la topologie logique que l'on a souhaité simuler connectant tous les équipements d'une armoire. 

Ainsi la topologie physique et logique des VLANs d'administration est une topologie en étoile.
Les différents numéros (\emph{tag}) des VLANs d'administration sont facilement identifiables :
\vspace{-12pt}
\begin{multicols}{2}
        \begin{itemize}
                \item AS 1 : VLAN 100
                \item AS 2 : VLAN 200
                \item AS 3 : VLAN 300
                \item AS 4 : VLAN 400 
        \end{itemize}
\end{multicols}
\vspace{-12pt}

 De plus ces VLANs ne présentent pas d'adresse IPv6 car l'utilisation de IPv6 n'aurait apporté aucun intérêt expérimental.

\subsubsection{VLANs d'extrémités}
Les ``VLANs d'extrémités'' correspondent aux VLANs  connectant les différents serveurs entre eux ainsi qu'une ou plusieurs \emph{gateways}. Il s'agit donc des sous réseaux locaux aux entreprises et FAI centralisant sur ces derniers leurs PCs et serveurs. Le numéro d'un VLAN d'extrémité est établit selon la convention suivante :\\
Soit $x$ le numéro de l'AS considéré, si l'AS $x$ n'a qu'un seul VLAN d'extrémité alors le numéro de ce VLAN sera $xx0$. Si l'AS $x$ a plusieurs VLANs d'extrémités alors celui qui relie le plus d'équipements prend le numéro $xx0$, le suivant $xx1$, etc.  

\subsubsection{VLAN de liaison point à point}
Ces VLANs sont principalement utilisés pour inter-connecter des routeurs en point à point, ils correspondent donc à des plages d'adresses en \verb!/30!.

Lorsque la liaison est entre deux AS différents alors le numéro du VLAN suit la convention suivante :
\begin{leftbar}
        Soit $x$ (resp. $y$) le numéro de l'AS le plus grand (resp. petit) des deux. Le numéro de VLANs point à point entre l'AS $x$ et l'AS $y$ est $xy0$. Par exemple la liaison entre le routeur de l'AS 1 et de l'AS 2 correspondra au VLAN 210.
\end{leftbar}

Lorsque les VLANs de liaison point à point sont intra-AS ils suivent la même convention que la section précédente (ils auront donc les numéros de VLANs les plus élevés dans leurs AS).

\subsubsection{VLAN Téléphonique}
Ces VLANs ont été rajoutés sur la plateforme pour l'installation des services de VoIP, ils suivent les conventions des VLANs d'extrémité et ne diffÚrent que par le traitement de leurs trafics par les commutateurs et routeurs. En effet il s'est avéré nécessaire de séparer les flots de type voix sur IP des autres flots afin de favoriser les paquets temps réels (VoIP) via des mécanismes de QoS.

\subsubsection{VLAN Internet}
Le VLAN d'accÚs a internet est un VLAN particulier qui a pour objectif de permettre aux contrÎleurs de consoles d'être accessible depuis l'extérieur et de connecter les serveurs à internet.
Ce VLAN est complÚtement indépendant de l'architecture logique de la plateforme et n'a aucun intérêt expérimental. En effet il a été mis en place pour pouvoir accéder aux contrÎleurs hors de la salle du projet et pour faciliter considérablement le téléchargement et l'installation de paquets manquants sur les serveurs.\newline

Le VLAN a pour tag le numéro 999 et inter-connecte tous les systÚmes autonomes à la passerelle \verb!gate-net.rsr.lip6.fr! :
\begin{itemize}
        \item Les contrÎleurs de console (ACS 5016) sont inter-connectés les uns aux autres via ce VLAN. Leurs adresses sur ce VLAN  sont de la forme \verb!10.40.130.x0! avec $x$ le numéro de l'AS considéré,
        \item Les serveurs de tous les AS peuvent accéder à Internet en configurant le proxy HTTP, leurs adresses sur ce VLAN sont de la forme \verb!10.40.130.xy! avec $y$ le numéro du serveur dans l'AS $x$.
\end{itemize}

La passerelle \verb!gate-net.rsr.lip6.fr! fait en effet office de \emph{proxy} pour HTTP et HTTPS en utilisant Squid. Les serveurs ont alors accÚs à Internet sur leur Interface connecté au VLAN 999.

\clearpage
\subsection{AS 1 : Entreprise 1}
Cet AS simule une entreprise moyenne connectée à un FAI (AS 2).\newline

Cette entreprise est protégée du trafic entrant par un \emph{firewall} avant que les paquets puissent atteindre l'unique \emph{gateway} de l'AS. Ce routeur délimite le réseau interne de l'entreprise composé de trois PC/serveurs.

Le VLAN d'administration de l'AS regroupe tous les équipements. Le protocole IPv6 n'est pas déployé sur ce sous-réseau.

\begin{figure}[htbp]
        \centering
        \subfloat[Visualisation de l'AS 1]{\includegraphics[scale=0.7]{img/AS/as1.pdf}}
        \subfloat[Administration de l'AS 1]{\includegraphics[scale=0.7]{img/AS/as1_admin.pdf}}
        \caption{AS 1}
\end{figure}

\clearpage
\subsection{AS 2 : Coeur 1}
L'AS 2 est un FAI connecté directement à la premiÚre entreprise (AS 1) ainsi qu'à un second FAI (AS 3).\newline

Ce premier FAI est composé de deux routeurs, MIR et ISS. ISS est directement connecté à un routeur de bordure de l'AS 3 via une liaison point à point ainsi qu'à un des routeurs de l'AS 4 (la seconde entreprise). MIR est quant à lui simplement relié à l'AS 1. Ces deux routeurs sont directement reliés aux serveurs du FAI via un commutateur.

\begin{figure}[htbp]
        \centering
        \advance\leftskip-1cm
        \subfloat[Visualisation de l'AS 2]{\includegraphics[scale=0.7]{img/AS/as2.pdf}}
        
        \subfloat[Administration de l'AS 2]{\includegraphics[scale=0.7]{img/AS/as2_admin.pdf}}
        \caption{AS 2}
\end{figure}

\clearpage
\subsection{AS 3 : Coeur 2 (sans routeur Juniper 3)}

Ce second FAI est connecté à  l'entreprise 2 par un premier routeur. Un second routeur est utilisé afin de relier directement le premier FAI (AS 2). Enfin un dernier routeur (routeur de cœur d'AS) est placé entre les deux routeurs de bordures, celui-ci a pour rÃŽle de permettre aux clients d'accéder aux serveurs de ce FAI.\newline

La topologie logique ``en ligne'' retenue est due au fait qu'elle soit la seule possible pour observer et implémenter le protocole MPLS sur l'AS.

\begin{figure}[htbp]
        \centering
        \subfloat[Visualisation de l'AS 3]{\includegraphics[scale=0.7]{img/AS/as3_.pdf}}
        
        \subfloat[Administration de l'AS 3]{\includegraphics[scale=0.7]{img/AS/as3_admin_.pdf}}
        \caption{AS 3}
\end{figure}

\clearpage
\subsection{AS 4 : Entreprise 2}

L'AS 4 simule une entreprise plus importante que celle de l'AS 1 et avec des moyens financiers plus importants.\newline

Cette entreprise possÚde deux routeurs qui sont chacun connectés à un FAI différent afin d'améliorer la fiabilité de la connexion Internet (\emph{multi-homing}). Bien évidement ces routeurs tous deux protégés par un firewall matériel. Une DMZ (\emph{DeMilitarized Zone}) à été mise en place dans laquelle sont installés les serveurs publiques de l'entreprise susceptibles d'être accédés depuis Internet sans entrer dans le véritable réseau de cette entreprise. Le réseau local de l'entreprise est constitué de deux serveurs/PC et d'un \emph{load balancer}. Ce dernier récupÚre tout le trafic sortant du réseau privé et le répartit entre les deux FAI selon la charge sur leur réseau par exemple.

\begin{figure}[htbp]
        \centering
        \advance\leftskip-1cm
        \subfloat[Visualisation de l'AS 4]{\includegraphics[scale=0.7]{img/AS/as4.pdf}}
        \subfloat[Administration de l'AS 4]{\includegraphics[scale=0.7]{img/AS/as4_admin.pdf}}
        \caption{AS 4}
\end{figure}

\clearpage
\section{Compte-rendu du projet}

\subsection{Configuration globale de la plate-forme}

\subsubsection{Un nouveau départ}

    Au début du projet, la question de réutiliser ou non la topologie physique/logique, les configurations des équipements réseaux et les configurations des serveurs s'est sérieusement posée. Cependant différents facteurs nous ont mené à repenser la plate-forme :
\begin{itemize}
        \item La présence de 4 contrÎleurs de consoles constituant la nouveauté au niveau matériel par rapport aux projets des années précédentes,
    \item L’absence en début de projet de routeurs dans l’AS 2 ne nous a pas permis de prendre en main et de tester la configuration précédente,
    \item Le manque d’expérience quant à la prise en main des différents équipements déjà configurés aurait impliqué un démarrage de projet difficile et brouillon,
    \item La panne du routeur Juniper 3 dans l’AS 3 impliquait une refonte complÚte de cet AS.
\end{itemize}
    
Le câblage a donc dû être repensé en prenant en compte les éléments précédents.


\subsubsection{Distributions des serveurs}

          L’hétérogénéité des distributions présentes sur les serveurs, ainsi que la présence de machines virtuelles sur ces derniers et le manque de connaissances de ce qui avait été mis en place l’année précédente nous a poussé à  réinstaller les systÚmes d’exploitation sur les serveurs.
        
Notre choix s’est porté sur une distribution Debian récente qui a été installée sur l'ensemble des serveurs de la plate-forme. Ce choix s'explique par une bonne maîtrise de la distribution par les membres du projet qui a permis de rendre les installations des services plus efficaces.\\
De plus les services redondant on pu ainsi être installer plus rapidement lorsque qu'un même service devait être installé sur plusieurs serveurs par la même personne.

\subsubsection{ContrÃŽleurs de consoles}

L’acquisition de contrÃŽleurs de console (\emph{Advanced Controller Server} ou ACS), un par AS, a permis une configuration des équipements plus aisée que précédemment car l’accÚs aux différentes équipements pouvait être effectué même en cas de problÚme de configuration réseau de la plate-forme (sans avoir besoin de se connecter manuellement et successivement à  chaque machine que l’on souhaite configurer en passant par son port série).

    Dans chaque armoire, toutes les machines sont reliées par le port série au contrÃŽleur de consoles. L’accÚs aux contrÃŽleurs de console peut se faire par telnet, ssh, mais aussi via une interface web, sur un navigateur web.

    Par la suite, la création d’un VLAN (le VLAN 999) comprenant les 4 contrÃŽleurs de consoles et la passerelle pour permettre l’accÚs à  l’Internet et l’accÚs à  la plate-forme depuis l'extérieur a permis une configuration encore plus simple.

\subsubsection{Accessibilité depuis l’Internet}

        L’accÚs à  la plate-forme depuis l’extérieur est possible par SSH en se connectant au serveur \verb!sphinx.lip6.fr! puis à  la passerelle gate\verb!-net.rsr.lip6.fr! présente dans l’armoire de l’AS 1. On peut ensuite se connecter aux 4 contrÃŽleurs de console :
\vspace{-7pt}\begin{multicols}{2}
        \begin{itemize}
                \item AS 1 : \verb!10.40.130.10!,
                \item AS 2 : \verb!10.40.130.20!,
                \item AS 3 : \verb!10.40.130.30!,
                \item AS 4 : \verb!10.40.130.40!.
        \end{itemize}
\end{multicols}\vspace{-5pt}

L'accÚs à distance étant fastidieux (trois sauts SSH sont nécessaires), une manipulation simple permet d'accéder aux contrÎleurs de consoles en une seule commande à partir de n'importe quelle machine connectée à internet (cette manipulation a été détaillée dans le manuel).

\subsubsection{AccÚs à  l’Internet depuis la plate-forme}

        Un proxy HTTP (Squid) a été mis en place sur la passerelle. Il permet aux serveurs présents dans chaque AS de se connecter à l’Internet. Les navigateurs web et les applications courantes telles que \verb!apt-get! ont été configurés pour se connecter à l’Internet via ce proxy.
        
    Un VLAN a été spécialement créé pour permettre cet accÚs (VLAN numéro 999). Ce VLAN regroupe les contrÎleurs de console qui doivent être accessibles via la passerelle \verb!gate-net.rsr.lip6.fr! ainsi que tous les serveurs, sans distinction d'AS, qui n'ont plus dans de sens dans cette configuration. La plage d'adresses du VLAN est \verb!10.40.130.0/24!.

        De plus des interfaces non utilisées (en gris sur les schémas) des commutateurs de chaque AS ont été configurées pour appartenir au VLAN 999. On peut ainsi en se connectant avec un ordinateur portable sur l'un de ces ports, accéder à  Internet et aux différents équipements (via le contrÃŽleur de console). Pour faciliter la configuration de la machine connectée, un serveur DHCP a été mis en place sur le serveur 2 de l’AS 1 afin d’attribuer une adresse dans la plage \verb!10.40.130.0/24!.

\begin{figure}[htbp]
        \centering
                \includegraphics[scale=.7]{img/AS/vlan999.pdf}
        \caption{Topologie du VLAN 999, d'accÚs à la plateforme et à Internet}
        \label{fig:AS_vlan999}
\end{figure}


\subsubsection{VLANs et plan d’adressage}

        Un VLAN d’administration par AS a été mis en place afin de gérer les équipements. Chaque AS a ainsi un réseau privé dans lequel chaque équipement de l’armoire possÚde une interface. Ainsi la topologie physique et logique des VLANs d’administrations est une topologie en étoile. Les différents numéros des VLANs d’administration sont les suivants :
\vspace{-12pt}\begin{multicols}{2}
        \begin{itemize}
                \item AS 1 : VLAN 100
                \item AS 2 : VLAN 200
                \item AS 3 : VLAN 300
                \item AS 4 : VLAN 400
        \end{itemize}
\end{multicols}\vspace{-5pt}
        
Ces interfaces possÚdent seulement une adresse IPv4. Ces réseaux sont inaccessibles depuis tout autre AS. Les ``VLANs d’extrémités'' correspondent aux VLANs connectant les différents serveurs entre eux ainsi qu’une ou plusieurs \emph{gateways}. Il s’agit donc des sous-réseaux locaux aux entreprises et FAI centralisant sur ces derniers leurs PCs et serveurs. Le numéro d’un VLAN d’extrémité est établi selon la convention suivante :
\begin{leftbar}
        Soit $x$ le numéro de l’AS considéré, si l’AS $x$ n’a qu’un seul VLAN d’extrémité alors le numéro de ce VLAN sera $xx0$. Si l’AS $x$ a plusieurs VLANs d’extrémités alors celui qui relie le plus d’équipements prend le numéro $xx0$, le suivant $xx1$, etc.
\end{leftbar}

Les VLANs interconnectant les AS sont utilisés pour connecter des routeurs de bordure en point à point, ils correspondent donc à des plages d’adresses en \verb!/30!. Lorsque la liaison est entre deux AS différents, alors le numéro du VLAN suit la convention suivante :
\begin{leftbar}
        Soit $x$ (resp. $y$) le numéro de l’AS le plus grand (resp. petit) des deux. Le numéro du VLAN point à point entre l’AS $x$ et l’AS $y$ est $xy0$. 
\end{leftbar}

Par exemple la liaison entre le routeur de l’AS 1 et de l’AS 2 correspond au VLAN 210.

        Pour limiter la présence des câbles à l’extérieur des armoires, le choix a été fait de n’utiliser qu’un seul câble entre chaque armoire et de mettre en place des \emph{trunk} (en utilisant du \emph{tagging}) sur les VLANs entre les commutateurs. 

\subsubsection{Routage}

Les protocoles de routage utilisés sont listés ci-dessous selon les AS :

\vspace{7pt}
\rowcolors{1}{}{lightgray}
\noindent\begin{tabularx}{\textwidth}{>{\bfseries}l|>{\hsize=.45\hsize}X>{\hsize=.55\hsize}X}
        \textbf{AS} & \textbf{Protocole de routage IPv4} & \textbf{Protocole de routage IPv6}\\
        \midrule
        AS 1 & \multicolumn{2}{>{\columncolor{lightgray}}l}{Il n'y a pas de routage interne (il n’y a qu’un seul routeur)}\\
        AS 2 & OSPF (pour le passage à  l’échelle) & Statique (Cisco IOS ne gÚre pas OSPFv3)\\
        AS 3 & OSPF & OSPFv3\\
        AS 4 & OSPF & OSPFv3\\
\end{tabularx}
\vspace{7pt}

Le protocole BGP (\emph{Border Gateway Protocol}) est utilisé pour le routage externe dans tous les cas.

Dans les différents AS, plusieurs cas se présentent :
\begin{itemize}
        \item L’AS 1 n’ayant qu’un seul routeur, il n’y pas de raison de mettre en place un protocole de routage interne,
        \item Les autres AS possédant plusieurs routeurs, le choix d’utiliser OSPF (IPv4) et OSPFv3 (IPv6) a été fait afin de permettre une communication \emph{host-to-host} dans chaque AS.
\end{itemize}

\begin{rem*}
        Pour des questions de comptabilité (la version IOS à notre disposition n’ayant pas OSPFv3), le routage interne est statique dans l’AS 2 en ce qui concerne IPv6.
\end{rem*}

Le routage externe utilise toujours BGP, les AS 4 et AS 1 étant des AS entreprises, ils ne diffusent que leur propre préfixe (l’AS 4 étant multi-homé, il faut faire attention à bloquer le fonctionnement transitif de BGP qui s’effectue par défaut), les AS 3 et AS 2, quant à eux, utilisent le principe par défaut de BGP : ils diffusent aux voisins tout ce qu’ils ont appris (sauf pour les relations de \emph{peering}, mais ce n'est pas le cas ici).

\subsubsection{VoIP}
        
La VoIP est une technique qui permet de communiquer par la voix sur des réseaux compatibles IP.\newline

Afin d’implémenter la VoIP sur la plateforme, nous avons choisi d’utiliser Asterisk. Asterisk implémente les protocoles H.320, H.323 et SIP, ainsi qu’un protocole spécifique nommé IAX (\emph{Inter-Asterisk eXchange}). Ce protocole IAX permet la communication entre deux serveurs Asterisk ainsi qu’entre client et serveur Asterisk.
Asterisk peut également jouer le rÎle de \emph{registrar} et de passerelle avec les réseaux publics (RTC, GSM, etc.).\newline

Pour rendre fonctionnelle la voix sur IP, il faut que chacun des serveurs Asterisk enregistre ses utilisateurs locaux. Ainsi on a enregistré le téléphone de l’AS 1 sur le serveur Asterisk de ce même AS en utilisant le numéro téléphonique ``100''. De même, le second téléphone présent dans l’AS 4 est enregistré auprÚs de son serveur Asterisk respectif au numéro ``200''.\newline 

De plus, pour que la communication inter-AS puisse fonctionner il faut enregistrer les serveurs Asterisk entre eux afin qu’un appel de l’AS 1 vers l’AS 4 puisse être relayé au serveur Asterisk distant (et réciproquement).

\begin{figure}[htbp]
        \centering
                \includegraphics[scale=.7]{img/voip_bgp.pdf}
        \caption{Trafic VoIP dans la platforme}
        \label{fig:img_voip_bgp}
\end{figure}

\clearpage
\subsubsection{QoS (\emph{Quality of Service})}

        La QoS est rapidement devenue indispensable, en effet, lors des premiers tests, le fait d’envoyer des données à  haut débit (à  l'aide de la commande \verb!iperf!) écrasait sensiblement les données VoIP (segments RTP et SIP). Il a été choisit de mettre en place des rÚgles permettant de favoriser le trafic VoIP par rapport à  tout autre trafic, cela grâce au champ IP DSCP (anciennement IP Precedence).\newline
        
Les routeurs de bordures (ceux ayant des voisins BGP) se chargent de marquer les paquets en positionnant une valeur au champ DSCP selon les rÚgles prédéfinies :
\begin{itemize}
        \item DSCP AF41 (\emph{Assured Forwarding}, avec un \emph{Paket Loss Priority} faible) associé à SIP, donc aux segments ayant pour port source ou destination le port UDP/5060,
        \item DSCP EF (\emph{Expedited Forwarding})  associé à RTP, donc aux segments ayant pour port UDP source ou destination un port compris entre les ports 16384 et 32767.
\end{itemize}
\vspace{7pt}

De ce fait, le trafic VoIP sera favorisé par rapport au trafic restant (notamment à l'aide du \emph{scheduling} : séparer les flots dans différentes files).

\begin{figure}[htbp]
        \centering
                \includegraphics[scale=.7]{img/throughput_5.pdf}
        \caption{Capture de trafic entre Juniper 2 (AS 3) et MIR (AS 2)}
        \label{fig:slides_throughput_5}
\end{figure}

Nous pouvons donc constater que les trafics de voix (RTP, en rouge) et de signalisation (SIP, en vert) restent constants, même quand il y a du trafic transversal (avec \verb!iperf!, en beu).


\clearpage
\subsection{Configuration des AS}

\subsubsection{AS 1 -- Entreprise 1}

        \paragraph{Topologie}

La topologie prévue lors de la premiÚre partie du projet a été modifiée. Le firewall Cisco étant réticent à toute tentative de configuration, il a été retiré. De plus un VLAN supplémentaire a été crée pour la VoIP. Il regroupe le routeur Cisco, le téléphone VoIP et le \verb!serveur1.ent1.org! qui héberge le serveur Asterisk.\newline
        Comme expliqué précédemment, les serveurs ont été intégré à  un VLAN 999 pour permettre l'accÚs à  Internet depuis les serveurs et faciliter l’accÚs à  ces même serveurs depuis l’extérieur.
        
        \begin{figure}[htbp]
                \centering
                \subfloat[Visualisation de l'AS 1]{\includegraphics[scale=0.7]{img/AS/as1.pdf}}
                \subfloat[Administration de l'AS 1]{\includegraphics[scale=0.7]{img/AS/as1_admin.pdf}}
                \caption{AS 1}
        \end{figure}

        \paragraph{Routage}
        
        La topologie de l’AS 1 étant simple, il n’y a qu’un seul routeur qui interconnecte tous les réseaux IP, aucun protocole de routage interne n’est donc nécessaire.

        En ce qui concerne le routage externe (inter-AS), BGP est naturellement utilisé pour remplir cette tâche. L'AS 1 étant connecté uniquement à  son fournisseur d’accÚs (AS 2), le routeur passerelle de l’AS 1 se contente donc d’importer toutes les routes apprises par son fournisseur (AS 2) et lui exporte et annonce son réseau ``AS 65001 --  \verb!23.7.100.0/24!''.

        \paragraph{Services}
        
Tous les services de l'AS 1 sont présenté dans le tableau suivant, puis détaillés par la suite.

\vspace{7pt}
\rowcolors{1}{}{lightgray}
\noindent\begin{tabularx}{\linewidth}{l|X}
\textbf{Equipement} & \textbf{Services}\tabularnewline 
\midrule 
Routeur Cisco & DHCP\tabularnewline
\verb!serveur1.ent1.org! & Apache, Asterisk, \verb!iperf!\tabularnewline
\verb!serveur2.ent1.org! & Apache, DHCP, IPSec, Nagios/Cacti, VPN (OpenVPN)\tabularnewline 
\verb!serveur3.ent1.org! & Apache, DNS, NTP, FTP (\verb!ProFTPD!)\tabularnewline 
\end{tabularx}

                \subparagraph{DHCP}
Un serveur DHCP a été activé et configuré sur le routeur Cisco. Il ne propose des adresses que sur le VLAN 111. Les adresses sur les interfaces des autres VLAN sont configurées manuellement. Par ailleurs, un serveur DHCP (\verb!serveur2.ent1.org!) a été configuré pour l’adressage sur le VLAN 999 dans la plage d’adresses $[100,\,200]$.

                \subparagraph{DNS}
Le serveur \verb!serveur3.ent1.org! héberge le service DNS. Il gÚre la la zone \verb!ent1.org! correspondant au réseau \verb!23.7.100.0/24!. Il contient les noms \verb!serveur1.ent1.org!, \verb!serveur2.ent1.org! et \verb!serveur3.ent1.org! de la zone. La résolution inverse a également été configurée.
                
                \subparagraph{NTP}
Le service NTP est installé sur le serveur \verb!serveur3.ent1.org!. Les clients de l’AS contactent ce serveur NTP périodiquement (toutes les 30 minutes) en utilisant \verb!crontab! pour la synchronisation de l’heure. De même, ce serveur NTP contacte le serveur NTP référence de la plateforme (\verb!serveur2.core1.org!) réguliÚrement.
                
                \subparagraph{IPSec}
IPSec/ESP (\emph{Encapsulation Security Payload}) en mode transport a été configuré afin de garantir la confidentialité des données entre \verb!serveur2.ent1.org! de l'AS 1 et \verb!serveur1.ent2.org! de l'AS 4.

                \subparagraph{Nagios/Cacti}
Pour superviser les équipements SNMP et obtenir des informations d’ordre général sur les équipements (serveurs inclus) locaux à l'AS 1, Nagios et Cacti ont été installés sur le \verb!serveur2.ent1.org!. \newline

Ces services utilisent le VLAN d’administration de leur AS hÃŽte (le VLAN 100). Pour Nagios les paramÚtres à  vérifier et à  tester ont été choisis en fonction de l’équipement supervisé. Par exemple pour un serveur on testera l'accessibilité général du serveur, l’accÚs HTTP au serveur, l’accÚs SSH, la charge, le nombre d’utilisateurs connectés et la place restante sur le disque dur.\newline

Cacti est un outil \emph{open-source} permettant de consulter aisément des mesures de performances effectuées ayant pour source des serveurs (et les services fonctionnant sur ceux-ci), ou autres équipements réseaux. Pour que la supervision soit effective nous avons bien sur dû s’assurer que les équipements soient compatibles SNMP, et configurés pour l'utilisation de SNMP.

                \subparagraph{VPN}
Un VPN a été mis en place entre \verb!serveur1.ent2.org! et \verb!serveur2.ent1.org!. OpenVPN a été installé sur les deux serveurs d’extrémité. Le serveur \verb!serveur1.ent2.org! a été désigné comme serveur dans la configuration du VPN. \newline

Pour mettre en place ce service il a fallu générer un certificat d’autorité de certification (pour authentifier les entités en communication), les couples clés privées/clés publiques du serveur et du client OpenVPN ainsi que les paramÚtres du protocole Diffie-Hellman (pour l'échange de clés). Il est possible d’obliger les serveurs d’une entreprise a passer par le VPN afin de communiquer avec l’entreprise distante, cependant, pour conserver un caractÚre général, aucun serveur n’utilise le VPN.
                
                \subparagraph{FTP}
Le serveur FTP ProFTPd est présent sur le serveur \verb!serveur3.ent1.org!. Un fichier de 1 Go a été crée dans son répertoire pour vérifier son fonctionnement. Le serveur FTP a été configuré pour pouvoir être accessible à la fois par compte administrateur ou par un compte utilisateur classique.

                \subparagraph{VoIP}
Le serveur de téléphonie \emph{open-source} Asterisk de l’AS 1 a été placé sur le serveur \verb!serveur1.ent1.org!. Un VLAN supplémentaire a été crée (le VLAN 122), et le sous-réseau \verb!23.7.100.48/29! a été dédié à la téléphonie.

                \subparagraph{HTTP}
Apache2 a été installé sur chacun des serveurs de l'AS 1. Nous avons choisi de conserver la page d’accueil par défaut. Cependant ces serveurs Apache sont nécessaire pour offrir à  certains services une interface web : pour les outils de supervision, notamment, Cacti ou Nagios. Ces interfaces web peuvent permettre la configuration et la maintenance des services de maniÚre plus aisée et sont parfois indispensables.

\subsubsection{AS 2 -- Réseau Coeur 1}

        \paragraph{Topologie}

La topologie présente dans le rapport intermédiaire a pu être mise en place, le routeur MIR est connecté à l’entreprise 1 (AS 1) et le routeur ISS au réseau coeur 2 (AS 3) ainsi qu’à l’entreprise 2 (AS 4). Comme prévu, l’AS comprend un réseau interne qui regroupe les deux serveurs et les deux routeurs, un réseau d’administration et enfin le VLAN 999, qui a été ajouté à la configuration.
                
\begin{figure}[htbp]
        \centering
        \advance\leftskip-1cm
        \advance\rightskip-1cm
        \subfloat[Visualisation de l'AS 2]{\includegraphics[scale=0.7]{img/AS/as2.pdf}}
        \subfloat[Administration de l'AS 2]{\includegraphics[scale=0.7]{img/AS/as2_admin.pdf}}
        \caption{AS 2}
\end{figure}

        \paragraph{Routage}
        L’AS 2 est fournisseur d’accÚs important sur notre ``Internet expérimental'' : il relie trois ASs différents.
        
        L’AS 2 possÚde plusieurs sous-réseaux et surtout deux routeurs, MIR et ISS. Le besoin d’un protocole de routage interne (ou de routes statiques) est ici nécessaire. Nous avons fait le choix d’utiliser dans la mesure du possible quelque chose de dynamique et de \emph{scallable} (qui passe à  l’échelle).

        OSPF a été retenu, il est simple et rapide à mettre en place.
        Malheureusement la version IOS à  notre disposition n’implémente pas OSPFv3. Le routage IPv6 interne a dû être configuré de maniÚre complÚtement statique.

        Le routage interne est donc en OSPF en ce qui concerne IPv4, et statique pour IPv6.\newline

        En ce qui concerne le routage externe (inter-AS), l’AS 2 possÚde plusieurs pairs :
        \begin{itemize}
                \item L’AS 1, dont il est l’unique fournisseur,
                \item L’AS 4, dont il est le fournisseur d’accÚs de secours,
                \item L’AS 3, un fournisseur d’accÚs voisin avec lequel un \emph{peering} (relation pair-à -pair) a été négocié. 
        \end{itemize}
        
        \begin{rem*}
                Pour des raisons de simplicité d’expérimentation, on considÚre que AS 2 et AS 3 sont pairs (peering).
        \end{rem*}

        L’AS 2 exporte/annonce donc vers tous ses voisins, l’intégralité de ses routes apprises. Par ailleurs, l’AS 2 importe les routes annoncées par :
        \begin{itemize}
                \item L'AS 4, son client : une seule route apprise (AS de type entreprise),
                \item L'AS 3, son pair : routes de tous les clients de l’AS 3,
                \item L'AS 1, son client, : une seule route apprise (AS type entreprise).
        \end{itemize}

        
        \begin{rem*}
                Pour des raisons d’expérimentation, les routes annoncées via l’AS 3 se voient attribuer une valeur de \emph{local-preference} à 200, afin de pouvoir forcer le trafic à utiliser MPLS-TE de l’AS 3 pour aller vers l’AS 4.
        \end{rem*}

        \paragraph{Services}
        
Les services de l'AS 2 sont présentés dans le tableau suivant, puis détaillés par la suite.

\vspace{7pt}
\rowcolors{1}{}{lightgray}
\noindent\begin{tabularx}{\linewidth}{l|X}
\textbf{Equipement} & \textbf{Services}\tabularnewline 
\midrule 
Routeur Cisco MIR (\verb!28.5.0.29/27!) & DHCP\tabularnewline
\verb!serveur1.core1.org! & Apache\tabularnewline
\verb!serveur2.core1.org! & Apache, NTP, DNS (Cacti/Nagios)\tabularnewline 
\end{tabularx}

                \subparagraph{DHCP}
Un serveur DHCP a été activé et configuré sur le routeur Cisco MIR. Il ne propose des adresses que sur le VLAN 222. Les adresses sur les interfaces des autres VLAN (administration, Internet et interconnexion) sont configurées manuellement.

                \subparagraph{DNS}
Le serveur \verb!serveur2.core1.org! héberge le service  DNS. Il gÚre la la zone \verb!core1.org! correspondant au réseau \verb!28.5.0.0/16!. Il contient les noms \verb!serveur1.core1.org! et \verb!serveur2.core1.org! de la zone. La résolution inverse a également été configurée.

                \subparagraph{NTP}
Le service est installé sur le serveur \verb!serveur2.core1.org!. Ce serveur, en plus de synchroniser les clients de son propre réseau, est le serveur référence de toute la plateforme. Par conséquent il reçoit périodiquement des requêtes des serveurs NTP de ses AS voisins. 

                \subparagraph{HTTP}
Apache2 a été installé sur chacun des serveurs. La page d’accueil reste celle par défaut.

                \subparagraph{Cacti}
Cacti a été implémenté sur le \verb!serveur2.core1.org! de cet AS. Cacti est un outil open-source permettant de consulter aisément des mesures de performances effectuées ayant pour source des serveurs (et les services fonctionnant sur ceux-ci), ou autres équipements réseaux.

Pour que la supervision soit effective nous avons bien sur dû s’assurer que les équipements soient compatibles SNMP, et configurés.

\subsubsection{AS 3 -- Réseau Coeur 2}

        \paragraph{Topologie}

La panne trÚs rapide du routeur Juniper 3 nous a forcé à  reprendre totalement l’architecture de l’AS. Par la suite le routeur Juniper 4 est, lui aussi, tombé en panne, compromettant nos chances d’implémenter MPLS dans l’AS. Mais sa ``résurrection'' quelques semaines avant la fin du projet nous a permis de remettre en place l’architecture prévue dans la premiÚre partie du projet. Nous avons donc une topologie en ``ligne'' avec le routeur Juniper 2 inter-connecté à  l’AS 2 et le routeur Juniper 4 inter-connecté à  l’AS 4.

\begin{figure}[htbp]
        \centering
        \advance\leftskip-2cm
        \advance\rightskip-2cm
        \subfloat[Visualisation de l'AS 3]{\includegraphics[scale=0.7]{img/AS/as3_.pdf}}
        \subfloat[Administration de l'AS 3]{\includegraphics[scale=0.7]{img/AS/as3_admin_.pdf}}
        \caption{AS 3}
\end{figure}

        \paragraph{Routage}
        L’AS 3 est un autre fournisseur d’accÚs, reliant deux AS différents (l'AS 2 et l'AS 4).
         
        L’AS 3 possÚde de nombreux sous-réseaux surtout de nature point-à -point (entre routeurs) mais également un sous-réseau où quelques serveurs intégrant de nombreux services sont présents.

        L’AS 3 possÚde la particularité de posséder un réseau de commutation de paquet grâce à  MPLS-TE, ce qui permet de traiter les paquets de maniÚre rapide.
        Il est le seul à intégrer de la qualité de service type IntServ grâce au \emph{Traffic-Engineering} fonctionnant sur la base du couple MPLS-TE (fonctionnel)/RSVP-TE (signalisation).

        Cet AS possÚde trois routeurs (malheureusement un autre routeur est présent mais hors-service pour le moment) et a pour vocation d’être un réseau à  haute disponibilité, OSPF a été choisi comme protocole de routage interne.

        Les routeurs Juniper présents sur cet AS ont un OS supportant OSPFv3, ce qui nous a permis d’implémenter également le protocole de routage dynamique OSPF (v3) pour le protocole IPv6.

        En ce qui concerne le routage externe (inter-AS), l’AS 3 possÚde deux pairs :
        \begin{itemize}
                \item L’AS 4, dont il est le fournisseur d’accÚs principal,
                \item L’AS 2, un fournisseur d’accÚs voisin avec lequel un \emph{peering} (Pair-Pair) a été négocié.
        \end{itemize}

        \begin{rem*}
                Pour des raisons de simplicité d’expérimentation, on considÚre que AS 2 et AS 3 sont pairs (peering).
        \end{rem*}

        L’AS 3 étant fournisseur d’accÚs, il exporte et annonce donc vers tous ses voisins l’intégralité de ses routes apprises.
        L’AS 3 importe les routes annoncées par :
        \begin{itemize}
                \item L'AS 4, son client : une seule route apprise (AS type entreprise),
                \item L'AS 2, son pair : routes de tous les clients de l’AS 2.
        \end{itemize}
                
        \paragraph{MPLS}
MPLS-TE a été mis en place afin de garantir un débit minimum sur les liens entre les deux routeurs de bordure Juniper 2 et Juniper 4, dans le cas contraire le flux sera refusé. Le protocole RSVP est utilisé afin de garantir le fonctionnement de cette configuration. 
MPLS-TE (reposant sur RSVP) a un fonctionnement de type IntServ, contrairement au fonctionnement de MPLS (reposant sur LDP) qui, lui, a un comportement de type DiffServ (PHB).


\begin{rem*}
        MPLS-TE a pour but d’utiliser une route différente de celle normalement proposée par le protocole de routage interne (ce qui est fait en MPLS) afin de répartir les flux sur différents liens, ici, bien sûr, cela n’est pas possible puisque le routeur Juniper 3 est en panne, mais la remise en service de celui-ci nous permettrait de rendre utile cette configuration.
\end{rem*}


        \paragraph{Services}
Les services de l'AS 3 sont présentés dans le tableau suivant, puis présentés plus en détail par la suite.

\vspace{7pt}
\rowcolors{1}{}{lightgray}
\noindent\begin{tabularx}{\linewidth}{l|X}
\textbf{Equipement} & \textbf{Services}\tabularnewline 
\midrule 
Routeur Juniper 1 (\verb!13.8.0.30!) & DHCP\tabularnewline
\verb!medial.core2.org! & Apache\tabularnewline
\verb!pseudol.core2.org! & Apache, Cacti/Nagios, DNS, NTP\tabularnewline 
\end{tabularx}

                \subparagraph{DHCP}
Un serveur DHCP a été activé et configuré sur le routeur Juniper 1 (adresse IPv4 : \verb!13.8.0.30!). Il ne propose des adresses que sur le VLAN 331. Les adresses sur les interfaces des autres VLAN (administration, Internet et interconnextion) sont configurées manuellement.

                \subparagraph{DNS}
Le serveur PSEUDOL héberge le service  DNS. Il gÚre la la zone \verb!core2.org! correspondant au réseau \verb!13.8.0.0/16!. Il contient les noms \verb!pseudol.core2.org! et \verb!medial.core2.org! qui correspondent aux deux serveurs de la zone. La résolution inverse a également été configurée.

                \subparagraph{NTP}
Le service est installé sur le serveur PSEUDOL. Les clients de l’AS contactent ce serveur NTP périodiquement (toutes les 30 minutes) en utilisant \verb!crontab! pour la synchronisation de l’heure. De même, ce serveur NTP contacte le serveur NTP référence de la plateforme (\verb!serveur2.core1.org!) réguliÚrement.
Le serveur PSEUDOL est également le serveur de référence pour le serveur NTP de l’AS 4, il reçoit et traite donc ses requêtes.

                \subparagraph{HTTP}
Apache2 a été installé sur chacun des serveurs. La page d’accueil est celle par défaut.

                \subparagraph{Nagios/Cacti}
Pour superviser les équipements SNMP et obtenir des informations d’ordre général sur les équipements (serveurs inclus) de l'AS 3,  Nagios et Cacti ont été installés sur le serveur PSEUDOL. 

\subsubsection{AS 4 -- Entreprise 2}

        \paragraph{Topologie}
L’entreprise 2, simulée par l’AS 4, possÚde une architecture plus complexe. 
La présence de deux routeurs ainsi que de deux \emph{firewalls} a permis la mise en place d’une topologie logique comprenant une DMZ, un \emph{load balancer}, qui permet de répartir le trafic provenant du réseau interne (correspondant au VLAN 443) entre les deux routeurs ``passerelles'' (Juniper 1 et Juniper 2).

\begin{figure}[htbp]
        \centering
        \advance\leftskip-1cm
        \subfloat[Visualisation de l'AS 4]{\includegraphics[scale=0.7]{img/AS/as4.pdf}}
        \subfloat[Administration de l'AS 4]{\includegraphics[scale=0.7]{img/AS/as4_admin.pdf}}
        \caption{AS 4}
\end{figure}

        \paragraph{Routage}
        L’AS 4 est une entreprise souhaitant avoir une connexion à  haute disponibilité, elle a donc fait le choix d’utiliser deux fournisseurs d’accÚs différents : AS 3 et AS 2. Cependant, l’AS 2 facturant le trafic à  ses clients plus cher que l’AS 3, l’entreprise a fait le choix d’utiliser comme fournisseur d’accÚs principal l’AS 3, et d’utiliser l’AS 2 uniquement en cas d’indisponibilité de la part de l’AS 3.

        L’AS 4 possÚde deux routeurs ``passerelles'', chacun permettant d’atteindre un fournisseur donné, ces routeurs ``passerelles'' sont également reliés entre eux dans un sous-réseau où un \emph{load-balancer} est présent, ce \emph{load-balancer} permet de répartir la bande passante des liens internes sur les routeurs passerelles.\newline

        En ce qui concerne les routeurs, nous avons fait le choix d’utiliser le protocole de routage OSPF, afin d’éviter une configuration manuelle qui demanderait plus de temps. En revanche, le \emph{load-balancer} n’implémentant pas OSPF (ce qui est dommage), nous avons dû rajouter certaines routes statiquement afin de garantir un accÚs intégral au réseau.
        En ce qui concerne le routage externe, l’AS 4 possÚde donc deux voisins et est dit \emph{multi-homé}, en fonctionnement haute disponibilité.\newline

        Puisque le fournisseur d’accÚs réseau principal est l’AS 3 (moins onéreux, et pour des raisons expérimental, on force le trafic à  utiliser MPLS-TE présent sur l’AS 3), on attribuera un \emph{local-preference} plus important.

        On importe donc via BGP toutes les routes annoncées via AS 2 avec un \emph{local-preference} par défaut (100), et toutes les routes annoncées via AS 3 avec un \emph{local-preference} de 200 afin de préférer ce fournisseur tant qu’il est disponible.

        On exporte/annonce notre propre route seulement ``AS 65004 -- \verb!4.11.100.0/24!'' aux fournisseurs.\newline

        Le comportement par défaut de BGP sur les OS des routeurs est d’annoncer aux voisins toutes les routes apprises, cependant dans notre cas, nous sommes juste client de deux fournisseurs différents, nous avons donc dû filtrer les routes annoncées pour restreindre les annonces BGP à notre unique réseau. L’entreprise 2 (AS 4) est directement connectée aux AS 3 et AS 2, elle est donc \emph{multi-homée} avec un fonctionnement à haute disponibilité.

        \paragraph{Services}
L'ensemble des services de l'AS 4 sont regroupés dans le tableau suivant, puis détaillés par la suite :

\vspace{7pt}
\rowcolors{1}{}{lightgray}
\noindent\begin{tabularx}{\linewidth}{l|X}
\textbf{Equipement} & \textbf{Services}\tabularnewline 
\midrule 
\verb!serveur1.ent2.org! & Apache, Asterisk, IPSec, VPN (OpenVPN)\tabularnewline
\verb!serveur2.ent2.org! & Apache, Nagios/Cacti\tabularnewline 
\verb!serveur3.ent2.org! & Apache, DHCP, DNS, FTP (ProFTPD), \verb!iperf!, NTP\tabularnewline
\end{tabularx}

                \subparagraph{DHCP}
Un serveur DHCP a été activé et configuré sur le serveur \verb!serveur3.ent2.org!. Il ne propose des adresses que sur le VLAN 443. Les adresses sur les interfaces des autres VLAN sont configurées manuellement.

                \subparagraph{DNS}
Le \verb!serveur3.ent2.org! héberge le service DNS. Il gÚre la la zone \verb!ent2.org! correspondant au réseau \verb!4.11.100.0/24!. Il contient les noms \verb!serveur1.ent2.org!, \verb!serveur2.ent2.org! et \verb!serveur3.ent2.org! de la zone. La résolution inverse a également été configurée.

                \subparagraph{NTP}
Le service NTP est installé sur le serveur \verb!serveur3.ent2.org!. Les clients de l’AS 4 contactent ce serveur NTP périodiquement (toutes les 30 minutes) en utilisant \verb!crontab! pour la synchronisation de l’heure. De même, ce serveur NTP contacte son serveur de référence (le serveur PSEUDOL) qui est le serveur NTP de l'un de ses fournisseurs, l’AS 3.

                \subparagraph{IPSec}
IPSec/ESP (\emph{Encapsulation Security Payload}) en mode transport a été configuré afin de garantir la confidentialité des données entre les serveurs \verb!serveur2.ent1.org! (AS 1) et \verb!serveur1.ent2.org! (AS 4).

                \subparagraph{Nagios/Cacti}
Pour superviser les équipements SNMP et le obtenir des informations d’ordre général sur les équipements (serveurs inclus) de l'AS 4, Nagios et Cacti ont été installés sur le \verb!serveur2.ent2.org!. 

                \subparagraph{VPN}
Un VPN a été mis en place entre les serveurs \verb!serveur1.ent2.org! (AS 4) et \verb!serveur2.ent1.org! (AS 1). OpenVPN a été installé sur les deux serveurs d’extrémité. Le serveur \verb!serveur1.ent2.org! a été désigné comme serveur dans la configuration du VPN.\newline

Pour ce faire il a fallu générer un certificat d’autorité de certification (pour authentifier les entités en communication), les couples clés privées/clés publiques du serveur et du client OpenVPN, ainsi que les paramÚtres du protocole Diffie-Hellman (pour l'échange de clés).\newline

Il est possible d’obliger les serveurs d’une entreprise a passer par le VPN afin de communiquer avec l’entreprise distante, cependant, pour conserver un caractÚre général et capturer le trafic  en clair, aucun serveur n’utilise le VPN.

                \subparagraph{FTP}
Le serveur FTP ProFTPd est présent sur le serveur \verb!serveur3.ent2.org!. Un fichier de 1 Go a été crée dans son répertoire pour vérifier son fonctionnement. Il est accessible par un compte administrateur ou par un compte utilisateur classique.

                \subparagraph{VoIP}
Le serveur de téléphonie open-source Asterisk de l’entreprise 2 (AS 4) a été placé sur le serveur \verb!serveur1.ent2.org!. Un VLAN (444) correspondant au sous-réseau \verb!4.11.100.64/28! a été crée pour la téléphonie. Il regroupe le routeur Juniper 1, le téléphone IP et le serveur \verb!serveur1.ent2.org!

                \subparagraph{HTTP}
Apache2 a été installé sur chacun des serveurs. La page d’accueil est celle par défaut.

\clearpage
\appendix
\section{Annexes}

\subsection{Documentation}

Le projet a été principalement documenté dans un fichier pdf qui est disponible sur la page web du projet : \url{https://tibre.lip6.fr/trac/pfres/wiki/Realisations/2011-2012/Projet}. Le document, ainsi que les sources seront disponibles au téléchargement pour assurer une continuité avec les futurs étudiants qui auront affaire à cette même plateforme d'expérimentation.

Par ailleurs, une description du projet, ainsi que des différents ASs est présente sur cette même page web. Il s'agit de décrire globalement la plateforme en présentant chaque AS avec sa topologie, et ses services. Pour plus de détails sur les implémentation, se référer au manuel, qui est plus détaillé.

Enfin, les sources qui sont référencées dans le chapitre 6 du manuel seront mises à disposition également.

\subsection{Propositions d'évolution pour la plateforme}
Nous proposons l'ensemble des évolutions suivantes qui semblent pertinentes pour la plateforme de la spécialité réseau :
\begin{itemize}
        \item Mise en place d'un serveur de  mails (IMAP/POP3/SMTP),
        \item Mise à niveau de la passerelle qui fait le lien entre la plateforme et la connexion au réseau du LIP6,
        \item Plus grande hétérogénéité dans les systÚmes d'exploitation des serveurs,
        \item Développement des outils de supervision (intégration de plus de \emph{plug-ins} pour Nagios par exemple),
        \item Routage : implémentation de IS-IS et RIP dans les AS de c\oe ur,
        \item Réparation du serveur Juniper 3 (la figure \ref{fig:img_voip-j3} donne un exemple de l'intégration du routeur Juniper 3 dans la plateforme),
        \item Mise à jour de tous les \emph{firmwares} des équipements afin d'avoir les fonctionnalités les plus récentes à disposition,
        \item Implémentation des protocoles NIS (authentification homogÚne) et NFS (systÚme de fichier homogÚne) dans l'ensemble de la plateforme,
        \item Ajout de fonctionnalités mobiles à la plateforme (MobileIP, point d'accÚs Wifi),
        \item Utilisation de NetKit pour étendre la plateforme en créant de nouveaux ASs,
        \item Utilisation de machines virtuelles pour ajouter et diversifier du trafic,
        \item Implémentation de protocoles de routage multicast (PIM-SM, PIM-DM, PIM-SSM).
\end{itemize}

\subsection{Concernant le routeur Juniper 3}

        Le systÚme de fichier (partitionné en UFS) de la carte compact flash du routeur Juniper 3 semble être corrompu. De ce fait, il faudrait le remplacer avec une version non corrompue. Cependant, la version que nous avons trouvée (\verb!junos-jsr-10.3R2.11-export-cf1024!) est faite pour une carte compact flash de 1024 Mo (au lieu de 256 Mo, taille de la carte compact flash actuelle).
        
        Comme indiquée sur \textcolor{blue}{\href{http://kb.juniper.net/InfoCenter/index?page=content&id=KB12170&smlogin=true}{cette page web}}, la manipulation reste facile d'accÚs. Cependant, le fichier \verb!junos-jseries-8.2R2.4-export-cf256! (qui est le systÚme de fichiers actuel des routeurs J4350) nécessaire reste introuvable. 
        
        Nous avons également prévu une topologie différente intégrant le routeur Juniper 3, si par hasard ce dernier fonctionnait à nouveau.
        
        \begin{figure}[htbp]
                \centering
                        \includegraphics[scale=0.7]{img/AS/as3.pdf}
                \caption{Visualisation de l’AS 3}
                \label{fig:PFRES_AS_as3}
        \end{figure}
        
        Cette topologie permettrait alors de faire transiter le trafic VoIP sur un chemin (LSP) différent du reste du trafic qui transiterait donc sur un LSP différent.
        \begin{figure}[htbp]
                \centering
                        \includegraphics[scale=1.1]{img/voip-j3.pdf}
                \caption{Intégration du routeur Juniper 3 pour MPLS/VoIP}
                \label{fig:img_voip-j3}
        \end{figure}
\end{document}