Le Numérique - Les métiers de demain

Gestion des journaux - 2ème partie: utilisation de Tenshi- Gestion et supervision réseau

D'abord assurez vous que vos routeurs sont configurés pour envoyer les
logs (journaux) à votre serveur
 Mettre à jour la configuration de syslog-ng
Si vous ne l'avez pas encore fait, loggez vous sur votre machine virtuelle et devenez l'utilisateur root:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ sudo bash
#
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Configurer syslog-ng pour qu'il réception et sauvegarde les journaux de tout routeur dans un seul fichier, pour faciliter l'inspection et l'analyse:
Éditer `/etc/syslog-ng/conf.d/10-network.conf`,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
# cd /etc/syslog-ng/conf.d/
# editor 10-network.conf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
... et ajouter ceci avant la dernière accolade fermante ( }; ):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
file("/var/log/network/everything", owner(root) group(root)
perm(0644));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Au final, le contenu de ce fichier doit ressembler à:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
filter f_routers { facility(local0); };
log {
source(s_src);
filter(f_routers);
destination(routers);
};
destination routers {
file("/var/log/network/$YEAR/$MONTH/$DAY/$HOST-$YEAR-$MONTH-$DAY-
$HOUR.log"
owner(root) group(root) perm(0644) dir_perm(0755) create_dirs(yes)
template("$YEAR $DATE $HOST $MSG\n"));
file("/var/log/network/everything", owner(root) group(root)
perm(0644));
};
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Ceci activera la collecte de TOUT messages syslog qui correspond à la
catégorie (facility) local0 et le stockage dans un seul fichier, afin que nous puissions lancer un script de supervisision sur ces messages.
Assurez-vous d'avoir sauvé le fichier et quittez l'éditeur.
Redémarrez syslog-ng afin qu'il charge la nouvelle configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
# service syslog-ng restart
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Rotation des journaux
Créez un script qui effectuera la remise à zéro du fichier des journaux
afin qu'il ne devienne pas trop gros (copier & coller).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
# editor /etc/logrotate.d/everything
/var/log/network/everything {
daily
copytruncate
rotate 1
postrotate
/etc/init.d/tenshi restart
endscript
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Puis sauvez le fichier et quitter l'éditeur.
## Installation de tenshi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
# apt-get install tenshi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Configuration de tenshi
Configuration de Tenshi pour que celui-ci vous envoie des alarmes par mail quand le routeur est reconfiguré (copier & coller):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
# editor /etc/tenshi/includes-available/network
set logfile /var/log/network/everything
set queue network_alarms tenshi@localhost sysadm@localhost [*/1 * *
* *] Log check
group_host 10.10
network_alarms SYS-5-CONFIG_I
network_alarms PRIV_AUTH_PASS
network_alarms LINK
group_end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Puis sauvez le fichier et quitter l'éditeur.
Créer un lien symbolique pour que le fichier de configuration de Tenshi soit chargé (copier & coller):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
# ln -s /etc/tenshi/includes-available/network /etc/tenshi/includesactive
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Enfin, redémarrer Tenshi:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
# service tenshi restart
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Tester Tenshi
Loggez vous sur votre routeur, et effectuez des commandes "config" diverses (Exemples ci-dessous):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ ssh cisco@rtrX [où "X" est le numéro de votre
routeur]
rtrX> enable
Password: <password>
rtrX# config terminal
rtrX(config)# int FastEthernet0/0
rtrX(config-if)# description Description Change for FastEthernet0/0 for Tenshi
rtrX(config-if)# ctrl-z
rtrX# write memory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Ne vous déconnectez pas immédiatement - comme dans les exercices syslog-ng précédemment, effectuez un shutdown / no shutdown de
l'interface loopback:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
rtrX# conf t
rtrX(config)# interface Loopback 999
rtrX(config-if)# shutdown
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
attendre quelques secondes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
rtrX(config-if)# no shutdown
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Finir et sauvez la config ("write mem"):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
rtrX(config-if)# CTRL-z (équivalent à 'exit' 2 fois)
rtrX# write memory
rtr1# exit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Vérifiez que vous recevez des mails de la part de Tenshi pour l'utilisateur sysadm. Une méthode de vérification rapide est de regarder dans le répertoire du mail:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ ls -l /var/mail
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
* Note: Tenshi inspecte /var/log/network/everything une fois par minute,donc vous devrez attendre jusqu'à une minute pour que le mail arrive jusqu'à l'utilisateur sysadm.
Assurez vous que vous vous êtes loggés en tant que sysadm (et pas root).
Soit vous ouvrez une nouvelle session avec ssh sur votre machine virtuelle,
soit vous quittez l'utilisateur root (exit).
Ensuite, faire:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ mutt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Utilisez les flèches pour sélectionner un message envoyé par "tenshi@localhost", puis appuyer sur `ENTER` pour le lire, et `q` pour revenir à l'index, et `q` à nouveau pour quitter mutt.
Si les mails n'arrivent pas, vérifier alors les choses suivantes:
* Les journaux arrivent-ils dans le fichier `/var/log/network/ everything` ?
$ tail /var/log/network/everything
* Ces messages de logs montrent-il bien un nom de machine tel que 'rtr5',
voire une adresse IP comme 10.10.5.254 ? Souvenez-vous, tenshi est configuré de telle façon qu'il ne regarde que les noms de machine commençant pas 'rtr ou bien les IP commençant par '10.10' (ceci
dépend de la façon dont vous avez configuré tenshi)
* Vérifiez la configuration tenshi. Redémarrer tenshi si vous la modifiez.
* Si vous êtes coincé quand même, demander à un instructeur de vous aider.
## Faculcatif: Ajouter une nouvelle règle à Tenshi
Voyez si vous arrivez à ajouter une nouvelle règle à Tenshi pour qu'un email soit envoyé si un individu essaye de faire "enable" sur votre routeur, avec un mauvais mot de passe.
Indices:
* "PRIV_AUTH_FAIL" est la chaîne que Cisco IOS utilise dans les messages dans ce cas.
* Pour tester votre nouvelle règle, connectez vous à votre routeur, tapez "enable" suivi d'un mot de passe incorrect

Utilisation de syslog-ng-Gestion et surveillance de réseau

Notes :
------
* Les commandes précédées de "$" signifient que vous devez exécuter la commande en tant qu'utilisateur général - et non en tant
qu'utilisateur root.
* Les commandes précédées de "#" signifient que vous devez
travailler
en tant qu'utilisateur root.
* Les commandes comportant des lignes de commande plus spécifiques
(par exemple "RTR-GW>" ou "mysql>") signifient que vous exécutez
des commandes sur des équipements à distance, ou dans un autre
programme.

Exercices
---------
Veuillez identifier les participants qui utilisent le même routeur que vous, s'il y'en a. Constituez un groupe et faites ensemble l'exercice suivant. Il s'agit de désigner une personne pour se
connecter au routeur de votre groupe, mais chacun d'entre vous participera à la configuration effective.
1. Configurez votre routeur virtuel afin qu'il envoie des messages syslog à votre serveur :
Vos routeurs sont capables d'envoyer des messages syslog à de multiples destinations, ainsi un routeur peut envoyer des messages à 4 voire 5 destinations différentes. Nous devons donc configurer le routeur pour qu'il envoie des messages à chacun des PC de votre groupe.
Vous allez vous connecter en SSH au routeur de votre groupe et effectuer les opérations suivantes :
$ ssh cisco@10.10.X.254
rtrX> enable
rtrX# config terminal
Répétez la commande "logging 10.10.X.X" pour chaque PC de votre groupe. En d'autres termes, si votre groupe est sur le routeur 6 et que vous utilisez les PC 18, 20, 22, 24 et 26 vous répéterez la
commande à cinq reprises avec l'IP de chaque machine (10.10.6.18, 10.10.6.20, et ainsi de suite).
rtrX(config)# logging 10.10.X.X
rtrX(config)# logging facility local5
rtrX(config)# logging userinfo
rtrX(config)# exit
rtrX# write memory
Regardons le résumé de la configuration des journaux (logs) avec 'show logging'
rtrX# show logging
Déconnectez-vous du routeur (exit)
rtrX# exit
C'est fait. Le routeur devrait maintenant envoyer des paquets UDP SYSLOG à votre PC sur le port 514. Pour vérifier, ouvrez une session sur votre PC et effectuez l'opération suivante :
$ sudo bash
# apt-get install tcpdump (ne vous inquiétez pas si il est déjà installé)
# tcpdump -e -s0 -ni eth0 port 514
Puis demandez à une personne de votre groupe de se connecter au routeur et d'entrer les commandes suivantes :
$ ssh cisco@10.10.X.254
rtrX> enable
rtrX# config terminal
rtrX(config)# exit
rtrX> exit
Des informations de TCPDUMP devraient s'afficher sur l'écran de votre PC. Celles-ci devraient ressembler à ce qui suit :
02:20:24.942289 ca:02:0d:b3:00:08 > 52:54:4a:5e:68:77, ethertype IPv4 (0x0800),
length 144: 10.10.0.6.63515 > 10.10.0.250.514: SYSLOG local5.notice, length: 102
02:20:24.944376 ca:02:0d:b3:00:08 > c4:2c:03:0b:3d:3a, ethertype IPv4 (0x0800),
length 144: 10.10.0.6.53407 > 10.10.0.241.514: SYSLOG local5.notice, length: 102
Vous pouvez maintenant configurer le logiciel de journalisation sur votre PC afin qu'il reçoive ces informations et les enregistre dans un nouvel ensemble de fichiers :
2. Installez syslog-ng
Ces exercices s'effectuent en tant qu'utilisateur root. Si vous n'êtes pas un utilisateur root sur votre machine, vous pouvez le devenir en tapant :
$ sudo bash
# apt-get install syslog-ng
2. Éditez /etc/syslog-ng/syslog-ng.conf
Localisez les lignes
source s_src {
system();
internal();
};
et remplacez-les par :
source s_src {
system();
internal();
udp();
};
Sauvez le fichier et quitter.
Maintant, créez une configuration pour nos logs d'équipement réseau:
# cd /etc/syslog-ng/conf.d/
# editor 10-network.conf
Dans ce fichier, copier et coller les lignes suivantes:
filter f_routers { facility(local5); };
log {
source(s_src);
filter(f_routers);
destination(routers);
};
destination routers {
file("/var/log/network/$YEAR/$MONTH/$DAY/$HOST-$YEAR-
$MONTH-$DAY-$HOUR.log"
owner(root) group(root) perm(0644) dir_perm(0755)
create_dirs(yes)
template("$YEAR $DATE $HOST $MSG\n"));
};
Sauvez le fichier et quitter.
3. Créez le répertoire /var/log/network/
# mkdir /var/log/network/
4. Redémarrez syslog-ng:
# service syslog-ng restart
5. Tester syslog
Pour s'assurer qu'il y ait des messages syslog, reconnectez vous au routeur et effectuez des commandes "config", puis déconnectez vous,
c'est à dire:
# ssh cisco@10.10.X.254
rtrX.ws.nsrc.org> enable
rtrX.ws.nsrc.org# config terminal
rtrX.ws.nsrc.org(config)# exit
rtrX.ws.nsrc.org> exit
Veillez à vous déconnecter du routeur. Si un trop grand nombre de personnes se connectent et oublient de se déconnecter, d'autres ne pourront pas accéder au routeur.

6. Sur votre PC, regardez si des messages commencent à apparaître sous /var/log/network/2015/.../
$ cd /var/log/network
$ ls
$ cd 2015
$ ls
... ceci vous montrera le contenu du répertoire pour le mois en cours
... faites 'cd' et le nom de ce répertoire
$ ls
... recommencer au niveau suivant (le jour du mois)
$ ls
En cas de problème
------------------
Si aucun fichier n'apparait sous le répertoire /var/log/network, alors
une autre commande à essyer pendant qu'on est loggé sur le routeur, en
mode configuration, est de faire un shutdown / no shutdown sur une
interface
Loopback (locale), par eemple:
$ ssh cisco@rtrX
rtrX> enable
rtrX# conf t
rtrX(config)# interface Loopback 999
rtrX(config-if)# shutdown
Attendre quelques secondes
rtrX(config-if)# no shutdown
Puis quitter, et sauver la configuration ("write mem"):
rtrX(config-if)# exit
rtrX(config)# exit
rtrX# write memory
rtr1# exit
Vèrifiez les logs sous '/var/log/network'
# cd /var/log/network
# ls
... suivre la hiérarchie des répertoires.
Toujours pas de logs ?
Essayez la commande suivante pour envoyer un message de log en local:
# logger -p local0.info 'Hello World!'
Si aucun fichier n'a été créé sous '/var/log/network', alors vérifier la configuration pour des fautes de frappe. Ne pas oublier de redémarrer le service syslog-ng à chaque fois que vous changez la configuration.
Quelles autres commandes pouvez vous employer sur le routeur (ATTENTION!) qui provoqueront l'envoi de messages syslog ? Vous pouvez essayer de vous loger sur le router et taper un mot de passe incorrect pour "enable" Assurez-vous de faire un "ls" dans le répertoire de vos logs pour
voir si des logs ont été créés à un moment ou un autre

Installation des outils nfdump et NfSen- Suite Supervision Netflow

Objectifs
* Apprendre à installer les outils nfdump et NfSen
Notes
* Les commandes précédées de "$" signifient que vous devez exécuter la commande en tant qu'utilisateur général - et non en tant qu'utilisateur root.
* Les commandes précédées de "#" signifient que vous devez travailler en tant qu'utilisateur root.
* Les commandes comportant des lignes de commande plus spécifiques
(par exemple "RTR-GW>" ou "mysql>") signifient que vous exécutez des commandes sur des équipements à distance, ou dans un autre programme.
Prérequis
Il est attendu que vous ayez déja configuré votre routeur pour exporter les flux vers un PC dans votre groupe et que votre groupe voisin a configuré leur routeur pour qu'il exporte les flux vers le même PC.
Configurer votre collecteur

• Installer Nfdump et les outils associés.

Nfdump fait partie des outils de collection Netflow. Nous allons installer plusieurs outils supplémentaires dont nous aurons besoin un peu plus tard.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ sudo apt-get install rrdtool mrtg librrds-perl librrdp-perllibrrd-dev \libmailtools-perl php5 bison flex
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Si on vous demande "Make /etc/mrtg.cfg owned by and readable only by root?"
choisir "<Yes>" et appuyer sur ENTREE pour continuer.
 Compilation et installation de nfdump
Il nous manque des outils: nfcapd, nfdump, nfreplay, nfexpire, nftest, nfgen
Il y a un paquetage dans Ubuntu mais celui ci est trop ancien.
Nous avons donc re-compilé un paquetage plus récent, prêt à être
téléchargé du NOC:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
cd /tmp/
wget http://noc.ws.nsrc.org/downloads/nfdump_1.6.6-1_i386.deb
wget http://noc.ws.nsrc.org/downloads/nfdump-flowtools_1.6.6-1_i386.deb
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Installation:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
sudo dpkg --install nfdump_1.6.6-1_i386.deb
sudo dpkg --install nfdump-flow-tools_1.6.6-1_i386.deb
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~

• Test et installation de nfcapd et nfdump

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
mkdir /tmp/nfcap-test
nfcapd -E -p 9001 -l /tmp/nfcap-test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
... au bout d'un certain temps, une série de flux devrait être
affichée
sur votre écran.
Arrêtez l'outil avec CTRL-C, et inspectez le contenu de /tmp/nfcaptest
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ ls -l /tmp/nfcap-test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Vous devriez voir un ou plusieurs fichiers nommés nfcapd.2013xxyyzz
Inspectez ce(s) fichier(s) avec nfdump:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
nfdump -r /tmp/nfcap-test/nfcapd.2013xxyyzz | less
nfdump -r /tmp/nfcap-test/nfcapd.2013xxyyzz -s srcip/bytes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Vous devriez y trouvez quelques informations utiles :)

• Installation et configuration de NfSen

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
cd /usr/local/src
sudo wget http://noc.ws.nsrc.org/downloads/nfsen-1.3.6p1.tar.gz
sudo tar xvzf nfsen-1.3.6p1.tar.gz
cd nfsen-1.3.6p1
sudo wget http://noc.ws.nsrc.org/downloads/nfsen-socket6.patch
sudo patch -p0 < nfsen-socket6.patch
cd etc
sudo cp nfsen-dist.conf nfsen.conf
sudo editor nfsen.conf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Ajuster la variable $BASEDIR
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$BASEDIR="/var/nfsen";
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Ajuster le chemin où résident les outils:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
# nfdump tools path
$PREFIX = '/usr/bin';
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Configurer le bon utilisateur afin qu'Apache puisse accéder aux fichiers:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$WWWUSER = 'www-data';
$WWWGROUP = 'www-data';
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Paramétrer la taille du buffer (tampon) à une petite taille, pour qu'on reçoive des données rapidement:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
# Receive buffer size for nfcapd - see man page nfcapd(1) $BUFFLEN = 2000;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Trouver la section avec la définition des sources (%sources), et la modifier ainsi:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
%sources=(
'rtr1' => {'port'=>'9001','col'=>'#0000ff','type'=>'netflow'},
'rtr2' => {'port'=>'9002','col'=>'#00ff00','type'=>'netflow'},
);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Maintenaint, sauver le fichier et quitter l'éditeur.

• Créer l'utilisateur netflow sur le système

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ sudo useradd -d /var/netflow -G www-data -m -s /bin/false netflow
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~

• Installer NfSen et commencer à l'utiliser

Assurons nous que nous sommes au bon endroit:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ cd /usr/local/src/nfsen-1.3.6p1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Enfin, on peut installer:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ sudo perl install.pl etc/nfsen.conf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Appuyer sur ENTREE quand on vous demande le chemin de Perl.
## Installer le script de démarrage (initialisation)
Afin que nfsen démarre et s'arrête automatiquement quand votre machine démarre, ajoutez un lien depuis le répertoire init.d pointant sur le script d'initialisation de nfsen:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
sudo ln -s /var/nfsen/bin/nfsen /etc/init.d/nfsen
sudo update-rc.d nfsen defaults 20
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Démarrer nfsen
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
sudo service nfsen start
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
## View flows via the web:
La page nfsen se trouve ici:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
http://pcX.ws.nsrc.org/nfsen/nfsen.php
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Si vous voyez un message similaire:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Frontend - Backend version missmatch!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
... ce n'est pas grave, il suffit de recharder la page et il disparaît.
Fini! Continuons avec le labo 3, exercice3-NfSen-PortTracker
* NOTES:
## Ajour de sources supplémentaires
Pour ajouter de nouvelles sources à nfsen, il suffit de faire ainsi:
- rédiger /var/nfsen/etc/nfsen.conf, and ajouter les sources, par
exemple:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
%sources = (
'rtrX' => { 'port' => '900X', 'col' => '#0000ff', 'type' =>'netflow' },
'rtrY' => { 'port' => '900Y', 'col' => '#00ff00', 'type' =>'netflow' },
'rtr10' => { 'port' => '9010', 'col' => '#ff0000', 'type' =>'netflow' }, # <- new);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~

• - Reconfigurer NfSen.

Il faudra faire ceci chaque fois que aller modifier /var/nfsen/etc/
nfsen.conf:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ sudo /etc/init.d/nfsen reconfig
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Vous devriez alors voir:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
New sources to configure : rtr10
Continue? [y/n] y
Add source 'rtr10'
Reconfig done!

Supervision Netflow- Gestion et Surveillance de réseau

Objectifs
* Apprendre à exporter des flux depuis un routeur Cisco
Notes
* Les commandes précédées de "$" signifient que vous devez exécuter la commande en tant qu'utilisateur général - et non en tant
qu'utilisateur root.
* Les commandes précédées de "#" signifient que vous devez travailler en tant qu'utilisateur root.
* Les commandes comportant des lignes de commande plus spécifiques (par exemple "RTR-GW>" ou "mysql>") signifient que vous exécutez des commandes sur des équipements à distance, ou dans un autre programme.
Exporter les flux depuis un routeur Cisco
Pendant cet exercice, on vous demande d'exporter les flux depuis votre routeur vers deux PC dans la classe. Vous devez travaiiler en groupe. C'est à dire, pour le groupe 1, les utilisateurs des
pc1, pc2, pc3 et pc4 doivent travailler ensemble, et choisir une machine sur laquelle les flux arriveront.
Par ailleurs, vous exporterez un second flux depuis le routeur de votre groupe, vers le groupe voisin du vôtre. Par exemple, si vous êtes dans le groupe 1, et si le groupe 2 a désigné le pc5 comme
celui qui recevra les flux, alors vous configurerez votre routeur pour qu'il utilise pc5 comme seconde destination pour les flux. Et si vous choisissez pc1 pour recevoir les flux de votre routeur
(rtr1), alors il devra également recevoir des flux du routeur 2 (rtr2).

Pour résumer:
Group 1, Routeur 1
-----------------
rtr1 ==> pc1 port 9001
rtr1 ==> pc5 port 9002
Group 2, Routeur 2
-----------------
rtr2 ==> pc5 port 9001
rtr2 ==> pc1 port 9002
Choisir la meilleure combinaison pour vos groupes.
On peut faire ça de la manière suivante:
* groupes 1 et 2
* groupes 3 et 4
* groupes 5 et 6
* groupes 7 et 8
Si il y a un groupe 9, voyez avec les instructeurs.
Si vous avez 3 groupes, on peut faire:
rtr1 ==> pc1 port 9001
rtr1 ==> pc5 port 9001
rtr2 ==> pc5 port 9002
rtr2 ==> pc9 port 9001
rtr3 ==> pc9 port 9002
rtr3 ==> pc1 port 9002
... la règle étant:
- chaque routeur doit exporter vers deux destination: une dans votre groupe, une dans un autre groupe
- chaque PC désigné dans le groupe reçoit deux flux: un de votre groupe, et un depuis un autre groupe
Configuration:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~

$ ssh cisco@rtr1.isetn.rnu.tn
rtr1.isetn.rnu.tn> enable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Si ssh n'est pas encore activé:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ telnet 10.10.1.254
Username: cisco
Password:
Router1>enable
Password:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Rappel - ceci est un EXEMPLE pour le cas suivant - à vous d'adapter!
rtr1 ==> pc1 on port 9001
rtr1 ==> pc5 on port 9002
Les autres groupes (2,3,4,5,6,7,8,9) feront différemment.
La section suivante active l'export des flux sur l'interface FastEthernet 0/0.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
rtr1.isetn.rnu.tn# configure terminal
rtr1.isetn.rnu.tn#(config)# interface FastEthernet 0/0
rtr1.isetn.rnu.tn#(config-if)# ip flow ingress
rtr1.isetn.rnu.tn#(config-if)# ip flow egress
rtr1.isetn.rnu.tn#(config-if)# exit
rtr1.isetn.rnu.tn#(config)# ip flow-export destination 10.10.1.1 9001
rtr1.isetn.rnu.tn#(config)# ip flow-export destination 10.10.2.5 9002
rtr1.isetn.rnu.tn#(config)# ip flow-export version 5
rtr1.isetn.rnu.tn#(config)# ip flow-cache timeout active 5
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Ceci découpe les flux de long durée en fragments de 5 minute. Vous pouvez choisir n'importe quel intervalle de temps entre 1 et 60 minutes. Si vous laissez la valeur par défaut de 30 minutes, vos
graphes auront des pics de traffic.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~

rtr1.ws.nsrc.org(config)# snmp-server ifindex persist
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Ceci active la persistence des index SNMP de vos interfaces. C'est
pour
garantir que les valeurs de ifIndex ne changent pas si vous ajoutez
ou supprimez des modules interface à vos équipements réseau.
Maintenant, configurons les paramètres de ip flow top-talkers:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
rtr1.isetn.rnu.tn(config)#ip flow-top-talkers
rtr1.isetn.rnu.tn(config-flow-top-talkers)#top 20
rtr1.isetn.rnu.tn(config-flow-top-talkers)#sort-by bytes
rtr1.isetn.rnu.tn(config-flow-top-talkers)#end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
On va maintenant vérifier ce qu'on à fait:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
rtr1.ws.nsrc.org# show ip flow export
rtr1.ws.nsrc.org# show ip cache flow
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Notez la distribution de la taille des paquets. Quel sont les deux
tailles de paquets les plus présentes ?
See your "top talkers" across your router interfaces
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
rtr1.isetn.rnu.tn# show ip flow top-talkers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Si cela a l'air ok, alors écrire la configuration running-config
dans
la NVRAM (c'est à dire la configiration de démarrage):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~

rtr1.isetn.rnu.tn#wr mem

Vous pouvez maintenant quitter le routeur:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
rtr1.isetn.rnu.tn#exit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Vérifier que les flux arrivent bien depuis votre routeur, jusqu'au PC
désigné pour recevoir les flux dans votre groupe.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ sudo tcpdump -Tcnfp port 9001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Attendez quelques secondes, et vous devriez voir quelque chose
ressemblant
à ceci:
06:12:00.953450 IP s2.isetn.rnu.tn.54538 > noc.isetn.rnu.tn.9009:
NetFlow v5, 9222.333 uptime, 1359871921.013782000, #906334, 30 recs
started 8867.952, last 8867.952
10.10.0.241/0:0:53 > 10.10.0.250/0:0:49005 >> 0.0.0.0
udp tos 0, 1 (136 octets)
started 8867.952, last 3211591.733
10.10.0.241/10:0:0 > 0.0.0.0/10:0:4352 >> 0.0.0.0
ip tos 0, 62 (8867952 octets)
[...]
Si vous utilisez Netflow v9, notez que l'exemple ci-dessus ne sera
pas
identique, comme la version de tcpdump dans Ubuntu ne décode pas
toujours
correctement le Netflow v9.
Vérifier que les flux venant du routeur de votre groupe voisi
arrivent
bien sur le PC désigné pour recevoir les flux dans VOTRE groupe (il
faut
attendre que ceux-ci soient prêts et que l'export des flux soit
activé):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
$ sudo tcpdump -Tcnfp port 9002
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
Ce labo est terminé.

Maintenant, allons faire l'exercice 2 exercise2-install-nfdumpnfsen.

Filtrage de routes BGP et fonctionnalités avancées

Topologie:

Figure 1 – Numéros d'AS BGP

Notes relatives au TP

Le module précédent a permis de s'initier à la configuration de BGP externe, sans toutefois expliquer comment contrôler quels sont les réseaux annoncés à quels AS. Le but de ce module est donc de vous présenter les types de politiques de routage disponibles en utilisant BGP.

Dans les étapes 2 à 6, nous allons configurer chaque AS pour en faire un “AS refusant le transit (non-transit AS)”, c'est à dire que l'AS refusera aux AS auxquels il est connecté d'acheminer du traffic de l'un vers l'autre. Cela signifie que la connectivité dans la salle sera rompue - par exemple, AS3 ne sera plus capable de voir les réseaux d'AS10, etc... C'est un choix délibéré ayant pour but de montrer l'efficacité du filtrage BGP.

Ceci est réalisé lors de l'étape 2, en configurant un filtre pour les routes sortantes (outgoing route filter) permettant l'envoi des seuls préfixes locaux vers les peers eBGP. Nous nous assurons également que les peers nous envoient seulement leurs préfixes locaux, grâce à l'ajout d'un filtre entrant (incoming filter). En règle générale, il est bon de configurer des filtres dans les deux sens, afin de protéger contre les erreurs de configurations des deux côtés du peering. Lors de l'étape 4, nous allons utiliser les filtres AS-PATH. Enfin dans l'étape 6, nous arriverons au même résultat en utilisant les communautés BGP.

Important : chaque étape doit être suivie et terminée par tous les participants avant que la prochaine étape puisse démarrer, puisque les techniques utilisées changent à chaque étape et qu'elles ne peuvent pas fonctionner dans un environnement incohérent. Ne démarrez pas l'étape suivante sans avoir obtenu le feu vert de vos instructeurs. Si vous démarrez sans attendre, il est très probable que le routage cesse de fonctionner, empêchant ainsi les autres groupes de comprendre les effets réels de leurs configurations.

Important : gardez la configuration utilisée pour le Module 6.

Étapes du TP

1.      Implémentation des politiques BGP. Avant de faire la moindre configuration dans ce module, il faut impérativement comprendre comment implémenter les politiques BGP. Il est possible d'ajouter des listes de préfixes (prefix lists), des filtres as-path (as-path filters) ou des route-maps directement depuis la CLI. Cependant, ils ne seront pris en compte que pour les updates BGP reçues après l'ajout de ces nouvelles politiques. Ceci s'explique par le fait que BGP envoie des updates incrémentales décrivant les changements aux routes annoncées ou retirées. Pour appliquer une politique de routage à l'intégralité de la table de routage BGP reçue ou envoyée à un peer, la session BGP doit être "réinitialisée". Dans les anciennes versions de l'IOS, cela signifiait détruire la session BGP puis la redémarrer. Cependant, comment on peut l'imaginer, cela causait de graves problèmes de stabilité sur le réseau du fournisseur. Ainsi, le RFC2918 (Route Refresh Capability / Fonction de rafraîchissement de route) a été ajouté à la plupart des implémentations modernes de BGP pour permettre des mises à jour correctes des sessions BGP lorsque des changements de politiques les rendaient nécessaires.

Pour implémenter les changements de politiques dans tous les exemples à venir, utilisez les commandes suivantes, par exemple pour implémenter de nouvelles politiques entrantes et sortantes sur le peering entre Routeur 1 et Routeur 13:

Router1# clear ip bgp 10.10.15.14 out

Router1# clear ip bgp 10.10.15.14 in

Note 1: N'oubliez pas les sous-commandes 'out' et 'in' dans les commandes clear ci-dessus - si vous les oubliez, cela forcera une réinitialisation complète de la session BGP. Relisez la présentation BGP si vous n'êtes plus sûr de la raison pour laquelle c'est une mauvaise idée.

Note 2: Plutôt que d'utiliser l'adresse IP du voisin pour rafraîchir la session BGP, il est également possible d'utiliser son numéro d'AS (ASN). Puisque le routeur 13 est dans l'AS 40, l'autre jeu de commandes possible serait :

Router1# clear ip bgp 40 out

Router1# clear ip bgp 40 in

Filtrage en utilisant les listes de préfixes (prefix-lists)

2.      Configuration des filtres de préfixes basés sur les adresses réseau. Pour cette configuration, nous allons utiliser les listes de préfixes, qui sont une méthode de contrôle des informations de réseaux échangées au sein des peerings BGP. Le but de cette manoeuvre est de configurer les peerings eBGP de sorte que seuls les réseaux des AS voisins soient échangés.

Exemple: Routeur R13 (peering avec R1)

      !

ip prefix-list out-peer permit 10.40.0.0/20

ip prefix-list out-peer deny 0.0.0.0/0 le 32

!

ip prefix-list in-peer permit 10.10.0.0/20

ip prefix-list in-peer deny 0.0.0.0/0 le 32

!

router bgp 40

 no synchronization

 network 10.40.0.0 mask 255.255.240.0

 neighbor 10.10.15.13 remote-as 10

 neighbor 10.10.15.13 description eBGP peering avec Routeur1

 neighbor 10.10.15.13 prefix-list out-peer out

 neighbor 10.10.15.13 prefix-list in-peer in

 no auto-summary

!

     Exemple: Routeur R1 (peering avec R13)

!

ip prefix-list out-peer permit 10.10.0.0/20

ip prefix-list out-peer deny 0.0.0.0/0 le 32

!

ip prefix-list in-peer permit 10.40.0.0/20

ip prefix-list in-peer deny 0.0.0.0/0 le 32

!

router bgp 10

 no synchronization

 network 10.10.0.0 mask 255.255.240.0

 neighbor 10.10.15.14 remote-as 40

 neighbor 10.10.15.14 description Peering avec Routeur13

 neighbor 10.10.15.14 prefix-list out-peer out

 neighbor 10.10.15.14 prefix-list in-peer in

 no auto-summary

!

Note : une liste de préfixes IOS possède toujours une dernière entrée implicite deny any même si elle n'est pas mentionnée dans la configuration. Certains FAIs ajoutent l'entrée implicite deny any parce qu'ils considèrent que c'est une bonne habitude, et une mesure de sécurité.

Note : ces listes de préfixes sont seulement appliquées aux peerings avec les autres AS. On les appelle des peerings externes (utilisés par eBGP). Il n'y a généralement pas besoin d'appliquer ce genre de filtres aux peerings iBGP.

ARRÊTEZ ET ATTENDEZ ICI

3.      Retrait de la configuration précédente. Cette étape illustre comment retirer la configuration définie à l'étape précédente. C'est indispensable avant de passer à la suite.

Exemple: Routeur R1

Router1#conf t

Router1(config)#router bgp 10

!

! On enleve d’abord la liste de prefixes du peering BGP avec R13

!

Router1(config-router)#no neighbor 10.10.15.14 prefix-list out-peer out

Router1(config-router)#no neighbor 10.10.15.14 prefix-list in-peer in

!

! Maintenant on enleve les listes ells-memes

!

Router1(config)#no ip prefix-list out-peer

Router1(config)#no ip prefix-list in-peer

!

! Voila, la configuration est nettoyee, comme il faut.

!

Router1(config)#end

!

! Puis on rafraichit le peering BGP pour enlever l’ancienne politique

!

Router1#clear ip bgp 40 out

Router1#clear ip bgp 40 in

Router1#

Filtres AS-PATH

4.      Configuration de filtres de préfixes basés sur l'attribut AS path : Durant cette étape nous allons utiliser les listes d'accès AS path, qui sont un autre moyen de contrôler les réseaux échangés dans les peerings BGP.

Exemple : Routeur R14 (peering avec R2)

 

ip as-path access-list 2 permit ^$

ip as-path access-list 3 permit ^10$

!

router bgp 40

 neighbor 10.40.15.18 remote-as 10

 neighbor 10.40.15.18 filter-list 2 out

 neighbor 10.40.15.18 filter-list 3 in

!

 Exemple : Routeur R2 (peering avec R14)

ip as-path access-list 2 permit ^$

ip as-path access-list 3 permit ^40$

!

router bgp 10

 neighbor 10.40.15.17 remote-as 40

 neighbor 10.40.15.17 filter-list 2 out

 neighbor 10.40.15.17 filter-list 3 in

!

Q. Pourquoi est-ce que la liste de filtres sortants arrive à une correspondance pour l'as-path null et non le numéro d'AS local, dans les exemples ci-dessus ?

A. Parce que l'attribut AS-PATH est positionné après application des listes de préfixes, filtres d'as-path et route-maps. Si l'AS local était inclus dans la configuration des listes de filtres sortants, les préfixes seraient ignorés parce que l'attribut AS-PATH n'est pas encore positionné à ce moment.

Pour vérifier que l'expression régulière fonctionne comme prévu, utilisez la commande exec

“show ip bgp regexp <expression-reguliere>” pour montrer tous les chemins qui correspondent à l'expression régulière spécifiée. N'oubliez pas que la commande “clear ip bgp <neighbour address> [in|out]” est requise pour implémenter ce filtre.

Notez bien que les filtres AS Path autorisent tous les préfixes émis par l'AS voisin - dans l'exemple précédent qui utilisait les filtres de préfixes, seuls les agrégés de l'AS voisin pouvaient passer les filtres.

5.      Retrait de la configuration précédente. Cette étape illustre comment retirer la configuration définie à l'étape précédente. C'est indispensable avant de passer à la suite.

Exemple : Routeur 2

Router1#conf t

Router1(config)#router bgp 10

!

! On enleve la liste de filtres du peering BGP avec R14

!

Router1(config-router)#no neighbor 10.40.15.17 filter-list 2 out

Router1(config-router)#no neighbor 10.40.15.17 filter-list 3 in

!

! Puis les listes de filtres elles-memes

!

Router1(config)#no ip as-path access-list 2

Router1(config)#no ip as-path access-list 3

!

! Voila, la configuration est nettoyee, comme il faut.

!

Router1(config)#end

!

! Puis on rafraichit le peering BGP pour enlever l’ancienne politique

!

Router1#clear ip bgp 10.40.15.17 in

Router1#clear ip bgp 10.40.15.17 out

Router1#

Communautés BGP pour le filtrage (et route-maps)

6.      Introduction aux concepts de communautés BGP et route-maps. Cette étape explique comment utiliser ces concepts pour le tagging, l'identification et finalement le filtrage de préfixes. Nous obtiendrons des résultats similaires à ceux des étapes précédentes.

Sur chaque routeur, configurez BGP de sorte à ce qu'il envoie à ses peers externes une communauté pour tous les préfixes appartenant à l'AS local. La communauté doit suivre le format [Numéro d'AS]:[Numéro de Routeur]. Par exemple, Routeur8 doit utiliser la communauté 30:8.

Exemple : Routeur R8

! Affiche les communautes en utilisant le format 16-bits:16-bits plutot que

! un seul entier de 32-bits.

!

ip bgp-community new-format

!

ip prefix-list out-match permit 10.30.0.0/20 le 26

!

      route-map outfilter permit 10

       match ip address prefix-list out-match

       set community 30:8

      !

      router bgp 30

       neighbor 10.20.15.17 remote-as 20

       neighbor 10.20.15.17 route-map outfilter out

       neighbor 10.20.15.17 send-community

      !

Notes :

1)      La commande show ip bgp <network> permet de voir l'attribut de communauté dans la table BGP.

2)      L'attribut de communauté est un champ défini sur 32 bits. Par contention établie à l'IETF, ce champ est séparé en deux sous-champs de 16 bits chacun pour une interprétation plus aisée. Les 16 bits de poids fort contiennent le numéro d'AS tandis que les 16 bits de poids faible représentent une valeur dont la signification est bien définie pour les deux AS participant au peering. Les seules exceptions sont les chaînes de caractères définies spécifiquement, telles que no-export et local-as.

Q: Pourquoi faut-il mettre send-community pour les peerings eBGP ?

A: Puisque les valeurs de communauté ne sont pas propagées par défaut, vous devez le configure explicitement sur le routeur.

7.      Retrait de la configuration précédente. Cette étape illustre comment retirer la configuration définie à l'étape précédente. C'est indispensable avant de passer à la suite.

Exemple : Routeur 9

Router8#conf t

Router8(config)#router bgp 30

!

! On enleve d’abord la route-map du peering eBGP

!

Router8(config-router)#no neighbor x.x.x.x route-map outfilter out

!

! Puis la route-map elle-meme

!

Router8(config)#no route-map outfilter

!

! Et maintenant la liste de prefixes utilise par la route-map

!

Router8(config)#no ip prefix-list out-match

!

! Voila, la configuration est nettoyee, comme il faut.

!

Router8(config)#end

!

! Puis on rafraichit le peering BGP pour enlever l’ancienne politique

!

Router8#clear ip bgp 10.20.15.17 out

Router9#

Communautés BGP

8.      Configuration des communautés BGP. Lors de l'étape 6, la communauté d'appartenance d'un réseau était générée au point de peering où les deux routeurs BGP pouvaient communiquer. Malgré l'intérêt pédagogique de cette technique, la façon de faire usuelle, est d'attacher l'information de communauté à un réseau lorsque le réseau est injecté dans la table de routage BGP.

Chaque groupe doit assigner une communauté au bloc réseau client (le /26) dont il est l'origine (originator) pour BGP. Relisez la documentation de BGP pour trouver comment faire. Chaque routeur doit assigner une communauté de format [Numéro d'AS]:[Numéro de Routeur] exactement comme à l'étape précédente.

Exemple : Routeur R3

     

      ip bgp-community new-format

      !

route-map community-tag permit 10

       set community 10:3    

      !

      router bgp 10

       no synchronization

       network 10.10.0.128 mask 255.255.255.192 route-map community-tag

       neighbor 10.20.15.1 remote-as 20

       neighbor 10.20.15.1 send-community

       no auto-summary

      !

      ip route 10.10.0.128 255.255.255.192 null0

           

     Vérifiez que le routeur apparaisse bien avec sa communauté dans la table de routage BGP.

Q: Pourquoi est-ce que les peers externes, mais pas les internes, sont-ils les seuls à voir la communauté configurée sur le réseau ?

A: Voir précédemment. Tous les peerings nécessitent la sous-commande BGP send-community pour pouvoir propager l'attribut de communauté à ses peers.

9.      Communautés sur les peerings BGP internes. Comme pour l'étape précédente, paramétrez maintenant les peerings internes pour que l'attribut de communauté de votre réseau soit envoyé aux peers locaux.

Astuce : ajoutez simplement la ligne de configuration neighbor x.x.x.x send-community pour tous les peerings iBGP. N'oubliez pas de rafraîchir les sessions de peering BGP pour que les changements de configuration soient implémentés.

10.  Configuration du filtre de préfixe entrant basé sur l'attribut de communauté. L'objectif ici est d'accepter seulement les réseaux reçus par le peering BGP externe du voisin. (C'est similaire à ce qui était fait aux étapes 2 et 4 avec les filtrages par préfixe ou AS path). Par exemple, R13 devrait seulement accepter les réseaux dont R1 est origine, et devrait utiliser l'information de communauté que R1 a ajouté au réseau pour y parvenir.

Exemple : Routeur R13

ip community-list 3 permit 10:1

!

route-map infilter permit 10

 match community 3

!

router bgp 40

 neighbor 10.10.15.13 route-map infilter in

!

Le choix du numéro de liste de communauté (community-list) revient à chaque groupe. En effet, il n'est annoncé dans aucun peering BGP ni utilisé de la moindre façon à part pour identifier la liste de communauté (de façon similaire au numéro d'access-list).

11.  Mise en place de l'attribut local-preference sur les routes eBGP reçues. Dans cet exemple, une préférence locale va être mise en place pour les routes correspondant au filtre de communauté mis en place à l'étape 10. Conservez la route-map utilisée à l'étape 10 - une ligne de configuration supplémentaire va y être ajoutée. Il faut également permettre les autres réseaux reçus par les filtres et dont la préférence locale a la valeur par défaut.

Q. Pourquoi ?

A. Sans la seconde directive, la route-map implémente une directive deny par défaut et aucun autre préfixe n'est autorisé.

Exemple :

route-map infilter permit 10

 match community 3

 set local-preference 120

!

route-map infilter permit 20

Souvenez-vous qu'après la définition d'une nouvelle politique, la session BGP doit être rafraichie pour que cette nouvelle politique puisse être mise en oeuvre. Comme le routeur ne conserve pas systématiquement toutes les mises à jour reçues de son peer, cette étape est nécessaire. Vous pouvez dans ce but utiliser la commande exec “clear ip bgp <peer address> in”.

Groupes de peering BGP (peer-groups)

12.  Configuration de la fonctionnalité de groupes de peering pour les peers iBGP. Les groupes de peering BGP aident a réduire la charge machine du routeur en générant et propageant des mises à jour vers les peers qui ont la même politique. Cette étape configure des groupes de peering BGP for les peers iBGP dans chaque AS. Remplacez la configuration individuelle de chaque peer iBGP par une configuration de groupe de peering, comme dans l'exemple ci-dessous.

Exemple : Routeur R9

router bgp 30

 neighbor ibgp-peers peer-group

 neighbor ibgp-peers description Groupe de peering utilise pour iBGP

 neighbor ibgp-peers remote-as 30

 neighbor ibgp-peers update-source loopback 0

 neighbor ibgp-peers send-community

 neighbot ibgp-peers next-hop-self

 neighbor ibgp-peers password cisco

!

Note : l'ancienne configuration antérieure au groupe de peering doit être retirée avant de convertir vers la configuration utilisant les groupes de peering.

router bgp 30

 no neighbor 10.30.15.224

 no neighbor 10.30.15.226

!

 neighbor 10.30.15.224 peer-group ibgp-peers

 neighbor 10.30.15.226 peer-group ibgp-peers

!

Q: Quels sont les avantages procurés par les groupes de peering ?

A: Les groupes de peering BGP permettent d'utiliser une configuration commune sur plusieurs peers BGP. L'application la plus courante est pour iBGP. Tous les peers BGP internes dans un réseau d'un même FAI ont tendance à avoir la même relation les uns avec les autres. Plutôt que de définir une configuration conséquente par peer, et d'avoir à changer chaque peering quand il faut faire des modifications, la configuration peut être définie dans un groupe de peering, et seul le groupe doit être changé pour modifier la configuration de tous les peers iBGP. Cela réduit considérablement la surcharge de travail induite par toute modification, la charge processeur du routeur et simplifie grandement les configurations et leur visualisation.

Il est fortement recommandé d'utiliser la sous-commande peer-group de façon systématique pour la configuration de peers BGP. Comme dit précédemment, la plupart des peers iBGP ont la même configuration, il est donc très important de simplifier les configurations pour tous les intervenants du réseau. De plus, une configuration qui utilise beaucoup de groupes de peering est habituellement plus lisible qu'une configuration ayant une section distincte par peer, en particulier dans les réseaux ayant de nombreux peers.

Note : à l'avenir dans ce workshop, toute configuration devra être faite avec des groupes de peering autant que possible (surtout pour les configurations iBGP).

13.  Résumé : Dans ce module, nous avons découvert certaines des fonctionnalités de configuration des peerings BGP disponibles dans l'IOS Cisco. Nous encourageons le lecteur à essayer toutes sortes de permutations des exemples donnés au cours du TP. L'utilisation des communautés est en train de gagner en popularité maintenant que la fonctionnalité est reconnue pour son utilité dans le contrôle des politiques de routage entre différents AS. Les rafraîchissements de route et les groupes de peering sont également beaucoup utilisés dans les backbones de FAI car ils facilitent énormément l'administration et la configuration d'un réseau opérationnel.

  

Questions de revisions :

1. Pourquoi l'utilisation des rafraichissements de routes est-elle la meilleure méthode d'implémentation des nouvelles politiques BGP ?

2. Pourquoi l'utilisation des filtres AS-PATH fournit-elle moins de granularité queles filtres de préfixes pour une session BGP ? Quelle est la meilleure solution pour un réseau de FAI, et pourquoi ?

3. Quand faut-il mettre l'attribut de communauté sur un préfixe BGP ?

4. Est-ce que l'IOS envoie les communautés BGP par défaut pour iBGP ? et pour eBGP ? Dans la négative, de quoi les opérateurs doivent-ils se souvenir ?