| [Top] | [Contents] | [Index] | [ ? ] |
Ceci est le manuel de GNU Zebra pour la version zebra-0.91 [NDT : valable également pour la 0.92]
1. Vue d'ensemble (traduit) Présentation générale de Zebra 2. Installation (traduit) Comment installer Zebra ?
La suite Zebra
3. Commandes élémentaires (traduit) Commandes élémentaires de Zebra 4. zebra (traduit) Le gestionnaire de routage 5. ripd (traduit) Un démon pour le protocole RIP 6. ripngd (traduit) Un démon pour le protocole RIPng 7. ospfd (traduit) Un démon pour le procotole OSPF 8. ospf6d (traduit) Un démon pour le protocole OSPF pour IPv6 9. bgpd Un démon pour le protocole BGP 10. vtysh (traduit) Un shell intégré
Fonctionnalités additionnelles
11. Filtrage Comment filtrer les routes ? 12. Route Map Description des Route Map 13. Support de IPv6 Support de IP version 6 14. Interface avec le noyau Interface entre le noyau et Zebra 15. Support de SNMP Support de SNMP
Annexes
A. Le protocole Zebra B. Format des paquets Index des commandes Liste de l'ensemble des commandes Index des touches Liste de l'ensemble des touches en mode VTY
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Zebra est une suite de logiciels qui founit des services de routage basés sur TCP/IP. Zebra supporte des protocoles tels que RIPv1, RIPv2, RIPng, OSPFv2, OSPFv3, BGP-4 et BGP-4+ (voir la section 1.4 RFC supportées). Il supporte également les fonctionnalités de "réflecteur de route" et "serveur de routes" BGP. En plus des traditionnels protocoles de routage IPv4, Zebra prend en charge les protocoles de routage IPv6. Enfin, avec un démon SNMP qui supporte le protocole SMUX, Zebra prend en charge les MIBs pour les protocoles de routage (see section 15. Support de SNMP).
Zebra utilise une architecture logicielle évoluée afin d'offrir un moteur de routage multi-serveur de haut niveau. Zebra a une interface utilisateur interactive pour chaque protocole de routage et propose des commandes communes à partir du client. Du fait de cette architecture, vous pouvez ajouter facilement de nouveaux protocoles à Zebra. Vous pouvez utiliser la librairie Zebra comme interface utilisateur pour vos logiciels clients.
Zebra est un logiciel GNU officiel et est distribué sous la licence GNU General Public License.
1.1 A propos de Zebra Informations élémentaires sur Zebra 1.2 Architecture système L'architecture système de Zebra 1.3 Plateformes supportées Plateformes supportées et perspectives d'évolution 1.4 RFC supportées RFCs supportées 1.5 Comment se procurer Zebra ? 1.6 Liste de discussion La liste de discussion et de diffusion d'informations 1.7 Comment signaler un bug ? Addresse email pour l'envoi d'informations sur les bugs
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Actuellement, la plupart des réseaux à travers le monde fonctionnenent sous TCP/IP. Internet est accessible dans la plupart des pays, à partir des entreprises ou de chez les particuliers. Quand vous vous connectez à Internet, vos paquets de données transitent par un certain nombre de routeurs qui fonctionnent sous TCP/IP.
Un appareil sous Zebra fonctionne comme un routeur dédié. Avec Zebra, votre machine échange des informations de routage avec les autres routeurs. Zebra utilise ces informations pour mettre à jour les tables de routage du noyau. Ainsi les paquets de données arrivent à la bonne destination. Vous pouvez changer dynamiquement la configuration et vous pouvez visionner le contenu des tables de routage à partir d'un terminal connecté à Zebra.
En plus des fonctionnalités de routage, Zebra permet de configurer certains paramètres des interfaces réseau (l'adresse en particulier), des routes statiques, etc. Si vous avez un petit réseau ou une connexion xDSL, vous pouvez configurer Zebra très facilement : seules quelques manipulations pour activer les interfaces réseau et définir les routes statiques et/ou les routes par défaut seront nécessaires. Si le réseau est plus important ou si sa structure évolue fréquemment, vous pourrez tirer partie des protocoles de routage dynamiques supportés par Zebra comme RIP, OSPF ou BGP. Dans toutes ces situations, Zebra vous accompagnera.
Traditionnellement, la configuration des routeurs sous UNIX passe par les commandes ifconfig
et route. La commande netstat affiche l'état des tables de routage. La plupart de ces
commandes ne sont accessibles qu'aux utilisateurs ayant le statut d'administrateur. L'administration sous Zebra est
conçue diffèremment. Il y a deux modes d'utilisation : le mode "normal" (mode view) et le mode "privilégié" (mode enable).
Dans le mode normal, on ne peut que consulter l'état du système mais dans le mode privilégié, on peut modifier la configuration.
Cette fonctionnalité indépendante de la gestion des comptes d'UNIX sera très appréciable dans l'administration du routeur.
A l'heure actuelle, Zebra supporte les principaux protocoles de routage unicast. Les protocoles de routage multicast comme BGMP, PIM-SM, PIM-DM seront supportés dans la version 2.0 de Zebra. Le support de MPLS est en cours. Dans le futur, des fonctionnalités comme le filtrage TCP/IP, le contrôle QoS, la configuration diffserv seront ajoutées à Zebra. L'objectif final du projet Zebra est de proposer un routeur TCP/IP logiciel, libre et de qualité.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Les routeurs logiciels sont traditionnellement conçus comme un seul processus qui propose l'ensemble des fonctionnalités
de routage. L'approche de Zebra est différente. Il s'agit d'un ensemble de démons qui coopèrent pour construire la table
routage. Plusieurs démons de routage correspondant chacun à un protocole particulier peuvent cohabiter et zebra assure
la coordination entre ces différents démons.
Les démons ripd, ospfd, bgpd prennent en charge respectivement les protocoles
RIP, OSPF version 2 et BGP-4. zebra assure la mise à jour des tables de routage gérées par le noyau et la
redistribution des routes entre les différents démons de routage. Cette architecture modulaire facilite l'ajout d'un nouveau
démon de routage sans affecter le fonctionnement des autres. Il suffit de lancer le démon associé au protocole dont vous avez besoin.
Ainsi, l'utilisateur peut exécuter un démon de routage spécifique qui transmettra les informations de routage vers un point centralisée.
Il n'est pas nécessaire que l'ensemble des démons de routage fonctionnent sur la même machine et une même machine peut exécuter plusieurs fois le même démon de routage. Cette architecture originale offre de nouvelles possibilités pour les systèmes de routage.
+----+ +----+ +-----+ +-----+
|bgpd| |ripd| |ospfd| |zebra|
+----+ +----+ +-----+ +-----+
|
+---------------------------|--+
| v |
|Table de routage du noyau UNIX|
| |
+------------------------------+
Architecture de Zebra
|
Une architecture modulaire de ce type facilite l'extension et la maintenance. En contrepartie, cela multiplie les fichiers
de configuration et les interfaces de configuration. Chaque démon possède son propre fichier de configuration et son propre
terminal virtuel. Par exemple, quand on configure une route statique, il faut travailler sous zebra. Quand
on configure un réseau BGP, il faut travailler sous bgpd. Ceci peut paraître fastidieux. C'est pourquoi Zebra
propose un shell intégré : vtysh. Il peut se connecter à chaque démon via les sockets UNIX
et jouer ainsi le rôle de proxy pour les commandes utilisateur.
Zebra avait été conçu pour fonctionner en mode multi-thread lorsque le noyau supporte ce mécanisme.
Mais pour l'instant, les librairies fournies avec GNU/Linux ou FreeBSD ne sont pas encore parfaitement adaptées aux
services sensibles comme le routage. C'est pourquoi Zebra n'utilise pas les threads mais les appels système
select(2) pour multiplexer les événements.
Quand zebra fonctionnera sous un noyau GNU Hurd, il sera directement responsable de la table de routage.
Sous GNU Hurd, tous les services TCP/IP sont fournis par des processus utilisateur dénommés pfinet.
Zebra fournira l'ensemble des mécanismes de routage. Cette fonctionnalité sera implémentée lorsque GNU Hurd sera
devenu stable.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Actuellement, Zebra fonctionne sous GNU/Linux, BSD et Solaris. Ci-dessous, vous trouverez une liste des versions de ces systèmes
sous lesquels Zebra tourne. Porter Zebra vers d'autres plateformes n'est pas très difficile car la seule partie de code dépendante
de la plateforme se trouve uniquement dans le démon zebra. Les autres démons sont indépendants de la plateforme.
N'hésitez pas à nous informer si Zebra fonctionne sous d'autres plateformes.
Certaines piles IPv6 sont en cours de développement. Zebra supporte les piles indiquées ci-dessous. Pour BSD, la pile IPv6 KAME est recommandée. Pour Solaris, IPv6 n'est pas encore supporté.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
La liste ci-dessous indique les RFC supportées à ce jour.
Lorsque le support de SNMP est activé, les RFC suivantes sont également supportées :
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Zebra est toujours en cours de développement et il n'existe pas encore de version définitive officielle. C'est pourquoi vous trouverez la dernière version version béta de Zebra à l'adresse suivante :
Lorsque la version définitive sera distribuée, vous pourrez l'obtenir sur le site FTP (ou les mirroirs) de GNU. Zebra-1.0 sera la première version définitive du logiciel.
Le site web officiel de Zebra est situé à :
http://www.gnu.org/software/zebra/zebra.html.
Le site des béta testeurs de Zebra est situé à :
Vous pouvez obtenir la dernière version béta de Zebra à cette adresse..
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Il existe une liste de discussion sur Zebra. Si vous avez des commentaires ou des suggestions, envoyez un message à : zebra@zebra.org. Toutes les informations, nouvelles, améliorations, notes passent par cette liste.
Pour vous abonner à la liste de discussion, envoyez un message à majordomo@zebra.org avec dans le corps du message :
subscribe zebra
Pour vous désabonner de la liste, envoyez un message à majordomo@zebra.org avec dans le corps du message :
unsubscribe zebra
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Si vous pensez avoir trouvé un bug, merci d'envoyer un message à bug-zebra@gnu.org. Lorsque vous envoyez un message signalant un bug, merci d'inclure les informations suivantes :
netstat -rn et d'un ifconfig -a.
Les informations issues d'un show ip route à partir de la console de zebra seront également très utiles.
Le fait de signaler des bugs est très important pour améliorer la qualité de Zebra. C'est un logiciel encore en développement, c'est pourquoi, n'hésitez pas à les signaler à : bug-zebra@gnu.org.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Il y a trois étapes pour installer le logiciel : configuration, compilation et installation.
2.1 Configurer le logiciel 2.2 Compiler le logiciel 2.3 Installer le logiciel
La façon la plus simple de rendre Zebra exécutable consiste à saisir les commandes suivantes :
% configure % make % make install |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Zebra possède un script de configuration qui détecte automatiquement la plupart des paramètres de configuration nécessaires pour la machine hôte. Il y a plusieurs options de configuration additionnelles que vous pouvez utiliser pour désactiver le support de IPv6, ne pas compiler certains démons et pour activer le support de SNMP.
bgpd sans la fonctionnalité d'annonce BGP. Cette option convient pour utiliser bgpd
comme listener d'annonces BGP.
Vous pouvez spécifier toutes combinaisons de ces options. Par défaut, les exécutables seront placés dans '/usr/local/sbin' et les fichiers de configuration dans '/usr/local/etc'. Le préfixe d'installation '/usr/local/' et les autres répertoires peuvent être changés en utilisant les options suivantes avec le script de configuration :
Il existe plusieurs options qui ne sont utilisables que sur les systèmes GNU/Linux : (1).
Cette commande configurera zebra et les démons de routage pour la compilation :
% ./configure --disable-ipv6 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Après avoir configuré le logiciel, vous devrez le compiler pour votre système. Tapez simplement la commande
make à la racine des répertoires contenant les sources et le logiciel sera compilé.
Pour *tous* les problèmes que vous rencontrerez à cette étape, n'hésitez pas à le signaler
(voir section 1.7 Comment signaler un bug ?).
% ./configure . . . ./configure output . . . % make |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
L'installation du logiciel sur votre système consiste à copier les fichiers compilés et les fichiers d'aide vers des répertoires prédéterminés. A la fin du processus d'installation, ces fichiers ont été copiés de votre répertoire de travail vers '/usr/local/bin' et '/usr/local/etc'.
Pour installer la suite Zebra, tapez la commande suivante :
% % make install % |
Chaque démon de Zebra possède sa propre interface de commande. Après l'installation, vous devez spécifier le numéro de port qui permet la connexion à chaque démon. Ajoutez les lignes suivantes au fichier '/etc/services' :
zebrasrv 2600/tcp # zebra service zebra 2601/tcp # zebra vty ripd 2602/tcp # RIPd vty ripngd 2603/tcp # RIPngd vty ospfd 2604/tcp # OSPFd vty bgpd 2605/tcp # BGPd vty ospf6d 2606/tcp # OSPF6d vty |
Si vous utilisez un FreeBSD supérieur à la 2.2.8, ces lignes figurent déjà dans '/etc/services'. Il est donc inutile de les ajouter. Si vous spécifiez le numéro de port lors du lancement du démon, il est également inutile d'ajouter ces lignes.
Vous aurez peut-être besoin de modifier les fichiers de configuration '/usr/local/etc/*.conf'. Dans ce cas, reportez-vous à la section 3.1 Commandes de configuration.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Il y a cinq démons de routage utilisables et un démon gestionnaire de l'ensemble. Ces démons peuvent fonctionner sur des machines différentes du démon gestionnaire. Chaque démon écoute sur un port particulier pour répondre aux demandes de connexion à partir d'un terminal virtuel (VTY). Les démons de routage sont :
ripd, ripngd, ospfd, ospf6d, bgpd
zebra
Les sections ci-dessous présentent les commandes communes à l'ensemble des démons de routage.
3.1 Commandes de configuration Commandes utilisées dans les fichiers de configuration 3.2 Options communes de démarrage Démarrage des démons 3.3 L'interface de commande en mode VTY Dialogue avec les démons
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
3.1.1 Commandes de base pour la configuration Quelques commandes de configuration indispensables 3.1.2 Fichier de configuration modèle Un exemple de fichier de configuration
Les fichiers de configuration servent à définir des options de débogage, un mot de passe pour le mode VTY, des options de configuration des démons, le nom d'un fichier journal, etc. Ce fichier sera lu au démarrage par le démon et constituera sa configuration initiale.
Généralement, les fichiers de configuration sont placés dans :
Chaque démon a son propre fichier de configuration. Par exemple, le nom du fichier de configuration par défaut
pour zebra est :
Le nom du démon suivi de '.conf' est considéré comme le nom par défaut du fichier de configuration. Vous pouvez spécifier un autre nom de fichier en utilisant les options -f ou --config-file au lancement du démon.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
filename, utilisez la commande suivante :
log file /usr/local/etc/bgpd.log |
exec-timeout 0 0.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Ci-dessous, vous trouverez un modèle de fichier de configuration pour le démon zebra.
! ! Zebra configuration file ! hostname Router password zebra enable password zebra ! log stdout ! ! |
Les caractères '!' et '#' permettent de saisir un commentaire. Si le premier caractère d'un mot commence par l'un de ces deux symboles, le reste de la ligne sera ignoré car considéré comme un commentaire. Dans l'exemple ci-dessous, le '!' ne sera pas considéré comme un commentaire puisque ce n'est pas le premier caractère d'un mot :
password zebra!password |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Ces options concernent l'ensemble des démons du paquetage Zebra :
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Le terminal virtuel (VTY pour Virtual Terminal [aka TeletYpe]) est un interpréteur de commande. Il permet à l'utilisateur de saisir des commandes à destination des démons de routage.
3.3.1 Vue d'ensemble du VTY L'essentiel sur les VTYs 3.3.2 Différents Modes VTY Définition des modes VTY View, Enable et Other 3.3.3 Utilisation du clavier dans le VTY Touches de déplacement, d'édition et de gestion des commandes
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
VTY est l'acronyme de Virtual TeletYpe. Cela signifie que vous pouvez vous connecter aux démons via telnet.
Pour activer le VTY, vous devez avoir defini un mot de passe. Si ce n'est pas le cas, toute connexion au démon vous sera refusée.
% telnet localhost 2601 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Hello, this is zebra (version 0.91) Copyright 1997-2000 Kunihiro Ishiguro User Access Verification Password: XXXXX Router> ? enable Turn on privileged commands exit Exit current mode and down to previous mode help Description of the interactive help system list Print command list show Show running system information who Display who is on a vty Router> enable Password: XXXXX Router# configure terminal Router(config)# interface eth0 Router(config-if)# ip address 10.0.0.1/8 Router(config-if)# ^Z Router# |
La commande '?' est très utile. Elle vous permet à tout moment de connaître les commandes que vous pouvez saisir.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Le terminal virtuel peut se trouver dans un de ces trois modes :
3.3.2.1 Mode VTY "View" Mode limité à la consultation 3.3.2.2 Mode VTY "Enable" Mode permettant la configuration 3.3.2.3 Autre modes VTY Modes spéciaux(tftp, etc.)
Selon le mode dans lequel se trouve le terminal, certaines commandes ne sont pas accessibles.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
C'est un mode de consultation. Vous vous trouvez dans ce mode après la phase de connexion. Vous pouvez en sortir
de deux façons : soit en quittant le système soit en entrant dans le mode privilégié via la commande enable.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Le mode privilégié permet la configuration. Vous pouvez en sortir de deux façons : soit en quittant le système soit en retournant au mode View.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Ce paragraphe décrira les autres modes...
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Les touches de clavier utilisables dans l'interpréteur de commandes sont décrites dans ces trois paragraphes :
3.3.3.1 Touches de déplacement Touches pour le déplacement du curseur 3.3.3.2 Touches d'édition Touches pour la modification du texte 3.3.3.3 Autre touches Gestion de la session, etc.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Ces touches sont utilisées pour se déplacer à l'intérieur de l'interpréteur de commande. Le symbole C correspond à la touche CTRL. Le symbole M correspond à la touche ALT.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Ces touches sont utilisées pour éditer le texte sur la ligne. Le symbole C correspond à la touche CTRL. Le symbole M correspond à la touche ALT.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Des commandes additionnelles permettent de compléter la ligne de commande en fonction des premiers caractères saisis, d'obtenir de l'aide et de gérer la session de travail.
help sur une ligne vierge.
Si vous appuyez sur la touche ? à la suite d'une commande, vous obtiendrez les différents paramètres
qui permettent de compléter cette commande.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
zebra coordonne le routage IP. Il met à jour les tables de routage du noyau, permet la consultation de
l'état des interfaces réseau et redistribue les routes entre les différents protocoles de routage.
4.1 Lancement de zebra Options au démarrage de zebra 4.2 Commandes relatives aux interfaces réseau Commandes pour la gestion des interfaces 4.3 Commandes relatives aux routes statiques Commandes pour ajouter des routes statiques 4.4 Autres commandes en mode terminal Commands for zebra's VTY
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
En plus des options communes à tous les démons (voir section 3.2 Options communes de démarrage),
zebra possède les options spécifiques listées ci-dessous :
zebra interprète le fichier de configuration et s'arrête immédiatement.
zebra se termine, les routes ajoutées par zebraseront conservées.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
La route statique est un concept fondamental du routage. Grâce à ce mécanisme, on définit les adresses des réseaux que l'on veut joindre ainsi que les interfaces du routeur qui permettent d'atteindre ces réseaux.
ip route 10.0.0.0/8 10.0.0.2 ip route 10.0.0.0/8 ppp0 |
Le premier exemple définit une route statique vers le réseau 10.0.0.0/8 via le routeur d'adresse 10.0.0.2, le second définit la même route mais via l'interface ppp0.
ip route 10.0.0.0 255.255.255.0 10.0.0.2 ip route 10.0.0.0 255.255.255.0 ppp0 |
Contrairement à l'exemple précédent, on a défini le masque de réseau sur 3 octets.
Définition de routes statiques multiples vers une destination unique :
ip route 10.0.0.1/32 10.0.0.2 ip route 10.0.0.1/32 10.0.0.3 ip route 10.0.0.1/32 eth0 |
Si l'interface eth0 est active mais que les routeurs 10.0.0.2 et 10.0.0.3 ne sont pas joignables, seule la dernière route sera activée dans le noyau.
zebra> show ip route
S> 10.0.0.1/32 [1/0] via 10.0.0.2 inactive
via 10.0.0.3 inactive
* is directly connected, eth0
|
Ce mécanisme est connu sous le nom de "route statique flottante".
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Router# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
B - BGP * - FIB route.
K* 0.0.0.0/0 203.181.89.241
S 0.0.0.0/0 203.181.89.1
C* 127.0.0.0/8 lo
C* 203.181.89.240/28 eth0
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
RIP (Routing Information Protocol) est largement répandu parmi les protocoles IGP (Interior Gateway Protocol). Il a été développé dans les années 70 par Xerox est fait partie du protocole de routage XNS. RIP est un protcole à vecteur de distance basé sur les algorithmes de Bellman-Ford. Un routeur RIP envoie ses tables de routage périodiquement à ses voisins. Ainsi, en cas d'un changement de topologie (panne d'une ligne par exemple), l'information se propage et une convergence s'opère automatiquement entre les différents routeurs RIP du réseau. RIP étant un protocole à vecteur de distance, le routeur expédie à ses voisins la distance qu'il a calculé pour atteindre les réseaux présents dans sa table de routage.
[NDT : RIP est un protocole de routage dit "adaptatif". On parle de routage dynamique car il propage ses tables de routage ainsi que des informations sur les changements de topologie.]
ripd supporte RIP version 2 conforme à la RFC2453 et RIP version 1 conforme à la RFC1058.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Le nom du fichier de configuration par défaut de ripd est
'ripd.conf'. Lors de son lancement, ripd le cherche dans le répertoire
'/usr/local/etc'. Si 'ripd.conf' est absent, alors il cherche dans le répertoire courant.
RIP utilise le port UDP 521 pour envoyer et recevoir les paquets RIP.
Le protocole RIP a besoin des informations sur les interfaces gérées par le démon zebra, c'est
pourquoi il est indispensable à ripd. Ainsi, les commandes minimales pour activer RIP sont :
# zebra -d # ripd -d |
Notez bien que zebra doit être lancé AVANT ripd.
Pour arrêter ripd, utilisez la commande kill 'cat /var/run/ripd.pid'.
Certains signaux ont une signification particulière pour ripd.
ripd.
ripd efface toutes les routes définies dynamiquement par RIP
et s'arrête proprement.
En plus des options communes à tous les démons (voir section 3.2 Options communes de démarrage),
ripd possède l'option spécifique suivante :
ripd lorsque le démon se termine.
5.1.1 RIP netmask
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ripd supporte les versions 1 et 2 de RIP ainsi que les masques de sous-réseau.
A l'origine, RIP v1 ne véhiculait pas d'information sur les masques réseau. Le masque était uniquement
déterminé à partir de la classe de l'adresse. Lorsque l'adresse était de classe A, la longueur du masque
était de 8 bits, pour une classe B, il était de 16 et de 24 pour une classe C. Aujourd'hui, la méthode
la plus répandue consiste à associer un masque à l'interface. Ce masque est utilisé pour chaque paquet
reçu. RIP v2 supporte les masques à taille variable (VLSM : Variable Length Subnet Mask). En
étendant le masque réseau par défaut, on peut décomposer l'adresse réseau en sous-réseaux à partir
d'une adresse IP unique. Ceci facilite l'administration de réseaux de taille importante ou qui
intègrent plusieurs segments LANs et WANs.
Note : ripd ne supporte pas les masques réseau non séquentiels inclus dans RIP v2.
Si ripd reçoit une mise à jour qui intègre une adresse réseau et une métrique déjà connue,
l'ancienne information sera remplacée.
Note : pour l'instant, ripd ne supporte pas les routes multiples vers la même destination
avec la même métrique.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
no router rip. Le routeur RIP doit être activé avant toute configuration de routage.
RIP peut être configuré pour traiter les paquets version 1 ou 2,
le mode par défaut étant la version 2 lorsque rien n'est spécifié.
Si RIP est forcé sur version 1 (voir commande version), le paramétrage "Version 1"
sera indiqué. Par contre, le paramétrage "Version 2" ne sera jamais indiqué, qu'il soit forcé ou non.
network 10.0.0.0/24,
RIP sera activé sur toutes les interfaces du routeur dont les adresses IP sont comprises
entre 10.0.0.0 et 10.0.0.255. La commande no network désactive
la commande précédente.
no network nom_if désactive RIP sur l'interface nom_if.
no neighbor adresse désactive l'appareil d'adresse A.B.C.D
comme routeur RIP.
Ci-dessous se trouve une configuration RIP très simple. RIP est activé sur l'interface eth0
et sur les interfaces dont l'adresse réseau correspond avec le préfixe 10.0.0.0/8.
! router rip network 10.0.0.0/8 network eth0 ! |
Déclaration d'une interface passive :
ripd n'expédie plus de paquets multicast ou unicast sauf
si des voisins RIP ont été définis par la commande neighbor.
Gestion des versions du protocole RIP :
Gestion du "clivage d'horizon" (split horizon) :
ip split-horizon. La commande no ip split-horizon permet de désactiver cette fonction.
[NDT : le split horizon évite que des boucles infinies ne se créent lors de la diffusion de routes.]
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[NDT : la commande redistribute indique quels types de routes seront intégrés à la table de routage
gérée par RIP et donc susceptibles d'être diffusés.]
redistribute kernel redistribue les informations de routage
détenues par le noyau vers la table de routage RIP. La commande no redistribute kernel
désactive cette redistribution.redistribute static redistribue les informations de routage
statiques vers la table de routage RIP. La commande no redistribute static
désactive cette redistribution.redistribute ospf redistribue les informations de routage en provenance
de OSPF dans les tables de routage RIP.
redistribute bgp redistribue les informations de routage en provenance
de BGP dans les tables de routage RIP
Vous pouvez indiquer des routes statiques directement dans RIP :
route crée une route statique
utilisée uniquement par RIP. Cette commande ne devrait être utilisée que par de fins connaisseurs
de RIP. Dans la plupart des cas, il est recommandé de créer une route statique dans zebra
puis de la redistribuer dans RIP avec un redistribute static.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Les routes RIP peuvent être filtrées par une liste de distribution (distribute-list).
distribute-list permet d'appliquer une liste d'accès à une interface. access_list
est le nom de la liste d'accès. direct est soit 'in' pour les paquets entrants,
soit 'out' pour les paquets sortants. Cette commande permet de filtrer la constitution de la table
de routage ou la diffusion de routes.Par exemple, dans la configuration ci-dessous, seule la route 10.0.0.0/8 entrant par l'interface 'eth0' sera intégrée à la table de routage :
! router rip distribute-list private in eth0 ! access-list private permit 10 10.0.0.0/8 access-list private deny any ! |
La commande distribute-list peut être appliquée à la fois sur les flux entrants et sortants.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
La métrique utilisée par RIP représente la distance [NDT : nombre de routeurs traversés, également appelée "saut" ou "hop"]
pour atteindre un réseau. Par défaut, ripd ajoute 1 la métrique des routes reçues dynamiquement.
La métrique des routes "redistribuées" (voir section 5.3 Comment diffuser les routes avec RIP ?)
est initialisée à 1 par défaut.
redistribute connected.
Pour modifier cette métrique, utilisez les commandes redistribute connected metric ou
route-map.
La commande
offset-list permet également de modifier la métrique :
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
zebra. Par défaut, la distance des routes
découvertes par RIP est de 120.
[NDT : il s'agit de la distance administrative. Elle permet de ne conserver dans la table de routage qu'une entrée
lorsque le routeur reçoit des routes identiques par différents protocoles. Chaque protocole a une "distance"
par défaut (0 pour les réseaux connectés, 1 pour les routes statiques, 110 pour OSPF, 120 pour RIP, etc.).
Le démon zebra ne conserve que la route provenant du protocole dont la distance administrative est
la plus faible.]| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Ce paragraphe présente le mode d'emploi de la fonctionnalité route-map avec ripd.
L'argument optionnel route-map MAP_NAME peut être ajouté aux commandes redistribute.
redistribute static [route-map MAP_NAME] redistribute connected [route-map MAP_NAME] ... |
Cisco applique les route-map avant que les routes ne soient exportées dans la table de routage de RIP. Dans la
version actuelle de Zebra, ripd applique les route-map après que les routes aient été intégrées à
la table de routage mais avant que les routes ne soient diffusées.
Ceci est une ébauche qui devrait évoluer dans les versions futures.
La commande route-map (voir section 12. Route Map)
est nécessaire pour activer cette fonctionnalité sur le routeur.
Commande match :
show ip rip) l'adresse spécifiée.
ripd n'autorise pour l'instant qu'un seul nom d'interface, il s'agit
du nom de l'interface sur laquelle le paquet sera envoyé.
Comande set:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
! key chain test key 1 key-string test ! interface eth1 ip rip authentication mode md5 ip rip authentication key-chain test ! |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Le protocole RIP fonctionne avec différents temporisateurs (timers). L'administrateur peut les configurer
avec la commande timers basic.
Le paramétrage par défaut est le suivant :
La commande timers basic permet de modifier les valeurs par défaut citées ci-dessus.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Commandes pour afficher les routes connues de ripd.
ripd. Pour les routes qui ont été
reçues via RIP, la commande affiche l'heure à laquelle le paquet a été reçu ainsi qu'un résumé.
Cette commande affiche également les routes qui ont été redistribuées dans RIP.
ripd> show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds with +/-50%, next due in 35 seconds
Timeout after 180 seconds, garbage collect after 120 seconds
Outgoing update filter list for all interface is not set
Incoming update filter list for all interface is not set
Default redistribution metric is 1
Redistributing: kernel connected
Default version control: send version 2, receive version 2
Interface Send Recv
Routing for Networks:
eth0
eth1
1.1.1.1
203.181.89.241
Routing Information Sources:
Gateway BadPackets BadRoutes Distance Last Update
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Commandes permettant le débogage pour le protocole RIP.
debug rip events montrera les événements RIP tels les envois et réceptions de paquets,
les timers et les modifications sur les interfaces.
debug rip packet affichera des informations détaillées sur les paquets RIP :
ports d'origine et de destination et contenu des paquets.
ripd et zebra.
ripd.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ripngd supporte le protocole RIPng conforme à la RFC2080. C'est une
réincarnation pour IPv6 du protocole RIP.
6.1 Lancement de ripngd 6.2 Configuration de ripngd 6.3 Commandes en mode terminal 6.4 Commandes de filtrage
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Il n'y a aucune option de lancement spécifique à ripngd. Vous ne pouvez utiliser
que les options communes (voir section 3.2 Options communes de démarrage).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Actuellement ripngd supporte les commandes suivantes :
zebra.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
distribute-list. access_list est le nom de la liste d'accès.
direct est soit 'in' soit 'out'. Si direct
est égal à 'in', la liste d'accès est appliquée uniquement aux paquets entrants.
distribute-list local-only out sit1 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ospfd est un routeur OSPF version 2 conforme à la RFC2328. OSPF est un
protocole de type IGP (Interior Gateway Protocol ou protocole de routage
intra-domaine). Comparé à RIP, OSPF est adapté à des réseaux de grande
taille et sa période convergence est beaucoup plus courte. OSPF est largement
utilisé dans les grands réseaux d'entreprise ou dans les dorsales des
fournisseurs d'accès à internet.
7.1 Lancement d'ospfd 7.2 Le routeur OSPF 7.3 Les zones OSPF 7.4 OSPF en mode interface 7.5 Comment diffuser les routes avec OSPF ? 7.6 Affichage des informations sur OSPF 7.7 Debogage d'OSPF
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Il n'y a pas d'options spécifiques pour le lancement du démon ospfd, vous pouvez utiliser les options habituelles (voir section 3.2 Options communes de démarrage).
Avant de lancer ospfd, vérfiez que le démon zebra est lancé car ospfd nécessite des informations
sur les interfaces réseau fournies par lui.
Comme tous les autres démons, la configuration de ospfd est faite et stockée dans
le fichier 'opsfd.conf'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Pour lancer le processus de routage OSPF, vous devez taper la commande router ospf.
Pour l'instant, ospfd ne supporte pas de processus de routage OSPF multiples.
ospfd ne supporte
pas encore les processus de routage multiples, vous ne pouvez pas spécifier de numéro de
processus.
router ospf network 10.0.0.0/8 area 0 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ospf6d est un démon conforme à la version 3 d'OSPF (RFC2740) pour les réseaux IPV6.
8.1 Le routeur OSPF6 8.2 Les zones OSPF6 8.3 Les interfaces OSPF6 8.4 Comment diffuser les routes avec OSPF6 ? 8.5 Affichage des informations sur OSPF6
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Le support des zones pour OSPFv3 n'est pas encore implémenté...
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
bgpd is a Border Gateway Protocol 4 (BGP-4) protocol daemon.
BGP-4 is described in RFC1771. bgpd also supports Multiprotocol
Extension for BGP-4 (sometimes known as BGP-4+ or MBGP) which is
described in RFC2283.
BGP-4 is one of the EGPs (Exterior Gateway Protocols) and is used for inter-domain routing.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Default configuration file of bgpd is 'bgpd.conf'.
bgpd searches the current directory first then
/usr/local/etc/bgpd.conf. All of bgpd's command must be
configured in 'bgpd.conf'.
bgpd specific invocation options are described below. Common
options may also be specified (see section 3.2 Common Invocation Options).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
First of all you must configure BGP router with router bgp
command. To configure BGP router, you need AS number. AS number is an
identification of autonomous system. BGP protocol uses the AS number
for detecting whether the BGP connection is internal one or external one.
AS number is a digit between 1 and 65535. The use of AS numbers is described in RFC1930. AS numbers 64512 through 65535 are defined as private AS numbers. Private AS numbers must not to be advertised in the global Internet.
BGP Commands. You can not
create different BGP process under different as-number without
specifying multiple-instance (see section 9.12.1 Multiple instance).
bgpd connects to zebra it gets
interface and address information. In that case default router ID value
is selected as the largest IP Address of the interfaces. When
router zebra is not enabled bgpd can't get interface information
so router-id is set to 0.0.0.0. So please set router-id by hand.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
router bgp 1 neighbor 10.0.0.1 remote-as 2 |
This command must be the first command used when configuring a neighbor.
If the remote-as is not specified, bgpd will complain like this:
can't find neighbor 10.0.0.1 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
router bgp 1 network 10.0.0.0/8 |
bgp
doesn't care about IGP routes when announcing its routes.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In a router bgp clause there are neighbor specific configurations
required.
no neighbor peer remote-as as-number but all
configuration of the neighbor will be deleted. When you want to
preserve the configuration, but want to drop the BGP peer, use this
syntax.
bgpd's default is to not announce the default route (0.0.0.0/0) even it
is in routing table. When you want to announce default routes to the
peer, use this command.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
in or
out.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BGPd outputs logging information to a terminal or to the specified file. It includes routing updates and peer status change information. It also includes date, time, packet type, the peer's IP address, and other routing information.
1999/03/29 17:42:18 Update:[202.216.226.1] 130.58.0.0/16 med: 0 lpref: 0 nexthop: 202.216.226.1 aspath: 4691 3561 5119 3576 3782 i |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When adding IPv6 routing information exchange feature to BGP. There were some proposals. IETF IDR working group finally take a proposal called Multiprotocol Extension for BGP. The specification is described in RFC2283. The protocol does not define new protocols. It defines new attributes to existing BGP. When it is used exchanging IPv6 routing information it is called BGP-4+. When it is used for exchanging multicast routing information it is called MBGP.
bgpd supports Multiprotocol Extension for BGP. So if remote peer
supports the protocol, bgpd can exchange IPv6 and/or multicast routing
information.
Traditional BGP does not have the feature to detect remote peer's
capability whether it can handle other than IPv4 unicast routes. This
is a big problem using Multiprotocol Extension for BGP to operational
network. draft-ietf-idr-bgp4-cap-neg-04.txt is proposing a
feature called Capability Negotiation. bgpd use this Capability
Negotiation to detect remote peer's capabilities. If the peer is only
configured as IPv4 unicast neighbor, bgpd does not send these Capability
Negotiation packets.
By default, Zebra will bring up peering with minimal common capability for the both sides. For example, local router has unicast and multicast capabilitie and remote router has unicast capability. In this case, the local router will establish the connection with unicast only capability. When there are no common capabilities, Zebra sends Unsupported Capability error and then resets the connection.
If you want to completely match capabilities with remote peer. Please
use strict-capability-match command.
You may want to disable sending Capability Negotiation OPEN message
optional parameter to the peer when remote peer does not implement
Capability Negotiation. Please use dont-capability-negotiate
command to disable the feature.
When remote peer does not have capability negotiation feature, remote peer will not send any capabilities at all. In that case, bgp configures the peer with configured capabilities.
You may prefer locally configured capabilities more than the negotiated
capabilities even though remote peer sends capabilities. If the peer is
configured by override-capability, bgpd ignores received
capabilities then override negotiated capabilities with configured values.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
At an Internet Exchange point, many ISPs are connected to each other by
external BGP peering. Normally these external BGP connection are done by
full mesh method. As with internal BGP full mesh formation,
this method has a scaling problem.
This scaling problem is well known. Route Server is a method to resolve the problem. Each ISP's BGP router only peers to Route Server. Route Server serves as BGP information exchange to other BGP routers. By applying this method, numbers of BGP connections is reduced from O(n*(n-1)/2) to O(n).
Unlike normal BGP router, Route Server must have several routing tables
for managing different routing policies for each BGP speaker. We call the
routing tables as different views. bgpd can work as
normal BGP router or Route Server or both at the same time.
9.12.1 Multiple instance 9.12.2 BGP instance and view 9.12.3 Routing policy 9.12.4 Viewing the view
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To enable multiple view function of bgpd, you must turn on
multiple instance feature beforehand.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BGP instance is a normal BGP process. The result of route selection goes to the kernel routing table. You can setup different AS at the same time when BGP multiple instance feature is enabled.
bgp multiple-instance ! router bgp 1 neighbor 10.0.0.1 remote-as 2 neighbor 10.0.0.2 remote-as 3 ! router bgp 2 neighbor 10.0.0.3 remote-as 4 neighbor 10.0.0.4 remote-as 5 |
BGP view is almost same as normal BGP process. The result of route selection does not go to the kernel routing table. BGP view is only for exchanging BGP routing information.
With this command, you can setup Route Server like below.
bgp multiple-instance ! router bgp 1 view 1 neighbor 10.0.0.1 remote-as 2 neighbor 10.0.0.2 remote-as 3 ! router bgp 2 view 2 neighbor 10.0.0.3 remote-as 4 neighbor 10.0.0.4 remote-as 5 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can set different routing policy for a peer. For example, you can set different filter for a peer.
bgp multiple-instance ! router bgp 1 view 1 neighbor 10.0.0.1 remote-as 2 neighbor 10.0.0.1 distribute-list 1 in ! router bgp 1 view 2 neighbor 10.0.0.1 remote-as 2 neighbor 10.0.0.1 distribute-list 2 in |
This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view 2. When the update is inserted into view 1, distribute-list 1 is applied. On the other hand, when the update is inserted into view 2, distribute-list 2 is applied.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To display routing table of BGP view, you must specify view name.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
zebra configuration =================== ! ! Actually there is no need to configure zebra ! bgpd configuration ================== ! ! This means that routes go through zebra and into the kernel. ! router zebra ! ! BGP-4+ configuration ! router bgp 7675 bgp router-id 10.0.0.1 ! ipv6 bgp network 3ffe:506::/32 ipv6 bgp neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as as-number ipv6 bgp neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out ipv6 bgp neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as as-number ipv6 bgp neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out ! ipv6 access-list all permit any ! ! Set output nexthop address. ! route-map set-nexthop permit 10 match ipv6 address all set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225 set ipv6 nexthop local fe80::2c0:4fff:fe68:a225 ! ! logfile FILENAME is obsolete. Please use log file FILENAME ! log file bgpd.log ! |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
vtysh est un interpréteur de commande pour Zebra. [NDT : d'après mes tests, ce shell ne fonctionne
pas correctement. Utilisez plutôt un telnet @_du_routeur numéro_de_port_VTY_du_démon.]
Pour utiliser vtysh, indiquez l'option --enable-vtysh au script de configuration.
Pour utiliser l'authentification PAM, indiquez l'option --with-libpam au script de configuration.
vtysh recherche son fichier de configuration 'vtysh.conf' uniquement dans
'/usr/local/etc'. Il ne le recherche pas dans le répertoire courant car ce fichier
contient des paramètres d'authentification.
Pour l'instant, 'vtysh.conf' n'a qu'une seule commande :
! username foo nopassword ! |
Grâce à cette commande, l'utilisateur foo n'a pas besoin de mot de passe pour utiliser vtysh.
Si PAM a été activé, vtysh utilisera les mécanismes d'authentification de PAM.
If vtysh is compiled without PAM authentication, every user can use vtysh without authentication.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Zebra provides many very flexible filtering features. Filtering is used for both input and output of the routing information. Once filtering is defined, it can be applied in any direction.
11.0.1 IP Access List 11.0.2 IP Prefix List 11.0.3 IP Community List 11.0.4 AS Path Access List
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Basic filtering is done by access-list as shown in the
following example.
access-list filter deny 10.0.0.0/9 access-list filter permit 10.0.0.0/8 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ip prefix-list provides the most powerful prefix based
filtering mechanism. In addition to access-list functionality,
ip prefix-list has prefix length range specification and
sequential number specification. You can add or delete prefix based
filters to arbitrary points of prefix-list using sequential number specification.
If no ip prefix-list is specified, it acts as permit. If ip prefix-list
is defined, and no match is found, default deny is applied.
You can create ip prefix-list using above commands.
le command specifies prefix length. The prefix list will be
applied if the prefix length is less than or equal to the le prefix length.
ge command specifies prefix length. The prefix list will be
applied if the prefix length is greater than or equal to the ge prefix length.
Less than or equal to prefix numbers and greater than or equal to prefix numbers can be used together. The order of the le and ge commands does not matter.
If a prefix list with a different sequential number but with the exact same rules as a previous list is created, an error will result. However, in the case that the sequential number and the rules are exactly similar, no error will result.
If a list with the same sequential number as a previous list is created, the new list will overwrite the old list.
Matching of IP Prefix is performed from the smaller sequential number to the larger. The matching will stop once any rule has been applied.
In the case of no le or ge command,
Version 0.85: the matching rule will apply to all prefix lengths that matched the prefix list.
Version 0.86 or later: In the case of no le or ge command, the prefix length must match exactly the length specified in the prefix list.
11.0.2.1 ip prefix-list description 11.0.2.2 ip prefix-list sequential number control 11.0.2.3 Showing ip prefix-list 11.0.2.4 Clear counter of ip prefix-list
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Route map is a very useful function in zebra. There is a match and set statement permitted in a route map.
route-map test permit 10 match ip address 10 set local-preference 200 |
This means that if a route matches ip access-list number 10 it's local-preference value is set to 200.
12.0.1 Route Map Command 12.0.2 Route Map Match Command 12.0.3 Route Map Set Command
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Zebra fully supports IPv6 routing. As described so far, Zebra supports
RIPng, OSPFv3 and BGP-4+. You can give IPv6 addresses to an interface
and configure static IPv6 routing information. Zebra-IPv6 also provides
automatic address configuration via a feature called address
auto configuration. To do it, the router must send router advertisement
messages to the all nodes that exist on the network.
13.1 Router Advertisement
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
interface eth0 ipv6 nd send-ra ipv6 nd prefix-advertisement 3ffe:506:5009::/64 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are several different methods for reading kernel routing table information, updating kernel routing tables, and for looking up interfaces.
netlink. It makes asynchronous
communication between kernel and Zebra possible, similar to a routing
socket on BSD systems.
Before you use this feature, be sure to select (in kernel configuration) the kernel/netlink support option 'Kernel/User network link driver' and 'Routing messages'.
Today, the /dev/route special device file is obsolete. Netlink communication is done by reading/writing over netlink socket.
After the kernel configuration, please reconfigure and rebuild Zebra. You can use netlink as a dynamic routing update channel between Zebra and the kernel.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
SNMP (Simple Network Managing Protocol) is widely implemented feature for collecting network information from router and/or host. Zebra itself does not support SNMP agent functionality. But conjuction with SNMP agent, Zebra provides routing protocol MIBs.
Zebra uses SMUX protocol (RFC1227) for making communication with SNMP
agent. There are several SNMP agent which support SMUX. We recommend
to use the latest ucd-snmp software.
15.1 How to get ucd-snmp 15.2 SMUX configuration
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ucd-snmp is a free software which distributed so called "as is" software
license. Please check the license which comes with distribution of
ucd-snmp. The authors of ucd-snmp are the University of
California, the University of California at Davis, and the Electrical
Engineering department at the University of California at Davis.
You can get ucd-snmp from ftp://ucd-snmp.ucdavis.edu/. As of this
writing we are testing with ucd-snmp-4.1.pre1.tar.gz.
To enable SMUX protocol support, please configure ucd-snmp
like below.
% configure --with-mib-modules=smux |
After compile and install ucd-snmp, you will need to configure
smuxpeer. I'm now using configuration shown below. This means SMUX client
connects to MIB 1.3.6.1.6.3.1 with password test.
/usr/local/share/snmp/snmpd.conf ================================ smuxpeer 1.3.6.1.6.3.1 test |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To enable SNMP support of Zebra, you have to configure Zebra with
--enable-snmp (see section 2.1 Configure the Software).
! smux peer .1.3.6.1.6.3.1 test ! |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Zebra Protocol is a protocol which is used between protocol daemon and zebra. Each protocol daemon sends selected routes to zebra daemon. Then zebra manages which route is installed into the forwarding table.
Zebra Protocol is a TCP-based protocol. Below is common header of Zebra Protocol.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (2) | Command (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Length is total packet length including this header length. So minimum length is three. Command is Zebra Protocol command.
ZEBRA_INTERFACE_ADD 1 ZEBRA_INTERFACE_DELETE 2 ZEBRA_INTERFACE_ADDRESS_ADD 3 ZEBRA_INTERFACE_ADDRESS_DELETE 4 ZEBRA_INTERFACE_UP 5 ZEBRA_INTERFACE_DOWN 6 ZEBRA_IPV4_ROUTE_ADD 7 ZEBRA_IPV4_ROUTE_DELETE 8 ZEBRA_IPV6_ROUTE_ADD 9 ZEBRA_IPV6_ROUTE_DELETE 10 ZEBRA_REDISTRIBUTE_ADD 11 ZEBRA_REDISTRIBUTE_DELETE 12 ZEBRA_REDISTRIBUTE_DEFAULT_ADD 13 ZEBRA_REDISTRIBUTE_DEFAULT_DELETE 14 ZEBRA_IPV4_NEXTHOP_LOOKUP 15 ZEBRA_IPV6_NEXTHOP_LOOKUP 16 |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Zebra can dump routing protocol packet into file with a binary format (see section 9.14 Dump BGP packets and table).
It seems to be better that we share the MRT's header format for backward compatibility with MRT's dump logs. We should also define the binary format excluding the header, because we must support both IP v4 and v6 addresses as socket addresses and / or routing entries.
In the last meeting, we discussed to have a version field in the header. But Masaki told us that we can define new 'type' value rather than having a 'version' field, and it seems to be better because we don't need to change header format.
Here is the common header format. This is same as that of MRT.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
If 'type' is PROTOCOL_BGP4MP, 'subtype' is BGP4MP_STATE_CHANGE, and Address Family == IP (version 4)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | Destination AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old State | New State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Where State is the value defined in RFC1771.
If 'type' is PROTOCOL_BGP4MP, 'subtype' is BGP4MP_STATE_CHANGE, and Address Family == IP version 6
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | Destination AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old State | New State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
If 'type' is PROTOCOL_BGP4MP, 'subtype' is BGP4MP_MESSAGE, and Address Family == IP (version 4)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | Destination AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Message Packet | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Where BGP Message Packet is the whole contents of the BGP4 message including header portion.
If 'type' is PROTOCOL_BGP4MP, 'subtype' is BGP4MP_MESSAGE, and Address Family == IP version 6
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | Destination AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Message Packet | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
If 'type' is PROTOCOL_BGP4MP, 'subtype' is BGP4MP_ENTRY, and Address Family == IP (version 4)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View # | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Last Change | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | SAFI | Next-Hop-Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Address Prefix [variable] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Attribute [variable length] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
If 'type' is PROTOCOL_BGP4MP, 'subtype' is BGP4MP_ENTRY, and Address Family == IP version 6
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View # | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Last Change | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | SAFI | Next-Hop-Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop Address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop Address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop Address (Cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Address Prefix [variable] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix (cont'd) [variable] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Attribute [variable length] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
BGP4 Attribute must not contain MP_UNREACH_NLRI. If BGP Attribute has MP_REACH_NLRI field, it must has zero length NLRI, e.g., MP_REACH_NLRI has only Address Family, SAFI and next-hop values.
If 'type' is PROTOCOL_BGP4MP and 'subtype' is BGP4MP_SNAPSHOT,
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View # | File Name [variable] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
The file specified in "File Name" contains all routing entries, which are in the format of "subtype == BGP4MP_ENTRY".
Constants: /* type value */ #define MSG_PROTOCOL_BGP4MP 16 /* subtype value */ #define BGP4MP_STATE_CHANGE 0 #define BGP4MP_MESSAGE 1 #define BGP4MP_ENTRY 2 #define BGP4MP_SNAPSHOT 3 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| Jump to: | A B C D E F H I L M N O P R S T V W |
|---|
| Jump to: | A B C D E F H I L M N O P R S T V W |
|---|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| Jump to: | ?
C D L M R T U |
|---|
| Jump to: | ?
C D L M R T U |
|---|
| [Top] | [Contents] | [Index] | [ ? ] |
La configuration du noyau est très souple sous GNU/Linux. Vérifiez bien que la configuration du noyau que vous utilisez correspond à vos besoins. Zebra fonctionnera avec n'importe quelle configuration du noyau mais il existe des recommandations :
zebra peut recevoir les messages de routage netlink et
détecter directement les mises à jour des informations de routage du noyau (voir section 14. Interface avec le noyau).
ripd ou ospfd
car ces protocoles utilisent le multicast
Le support d'IPv6 a été implémenté dans la version 2.2 du noyau de GNU/Linux. Si vous voulez utiliser IPv6 avec Zebra, vérifiez que les librairies ci-dessous ont été installées. Notez que vous n'aurez pas besoin de ces librairies si vous utilisez la librairie GNU C 2.1 ou suivantes.
inet6-apps
inet6-apps inclut les librairies de base comme
inet_ntop et inet_pton. Certains programmes IPv6 élémentaires
comme ping, ftp et inetd sont également inclus.
inet6-apps peut être trouvé à
ftp://ftp.inner.net/pub/ipv6/.
net-tools
net-tools fournit des utilitaires d'activation des interfaces et de routage. Il contient
en particulier ifconfig, route, netstat ainsi que d'autres outils.
net-tools peut être trouvé à
http://www.tazenda.demon.co.uk/phil/net-tools/.
| [Top] | [Contents] | [Index] | [ ? ] |
| [Top] | [Contents] | [Index] | [ ? ] |
1. Overview
2. Installation
3. Basic commands
4. zebra
5. ripd
6. ripngd
7. ospfd
8. ospf6d
9. bgpd
10. vtysh
11. Filtering
12. Route Map
13. IPv6 Support
14. Kernel Interface
15. SNMP Support
A. Zebra Protocol
B. Packet Binary Dump Format
Command Index
VTY Key Index
| [Top] | [Contents] | [Index] | [ ? ] |
| Button | Name | Go to | From 1.2.3 go to |
|---|---|---|---|
| [ < ] | Back | previous section in reading order | 1.2.2 |
| [ > ] | Forward | next section in reading order | 1.2.4 |
| [ << ] | FastBack | previous or up-and-previous section | 1.1 |
| [ Up ] | Up | up section | 1.2 |
| [ >> ] | FastForward | next or up-and-next section | 1.3 |
| [Top] | Top | cover (top) of document | |
| [Contents] | Contents | table of contents | |
| [Index] | Index | concept index | |
| [ ? ] | About | this page |