Difference between revisions of "Utilisation d'un ordinateur comme routeur"

From Livre IPv6

 
(→‎<div id="quagga">Zebra - Quagga</div>)
 
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{suivi| BGPJuniper|Juniper|Routeur Solaris|Routeur Solaris}}
 +
 +
__TOC__
 +
 
En IPv6 les fonctions de machine simple («node») et de routeur ont été nettement séparées. Il est donc courant d'utiliser de matériels spécialisés comme routeurs, et de configurer les machines normales comme des noeuds simples, sans fonction de routage (cf. [[Installation d'un équipement]]), et ce d'autant plus qu'un routeur dédié peut devenir complexe (plusieurs protocoles de routage, filtrage des paquets, interfaces spécialisées, VLANs, MPLS...).
 
En IPv6 les fonctions de machine simple («node») et de routeur ont été nettement séparées. Il est donc courant d'utiliser de matériels spécialisés comme routeurs, et de configurer les machines normales comme des noeuds simples, sans fonction de routage (cf. [[Installation d'un équipement]]), et ce d'autant plus qu'un routeur dédié peut devenir complexe (plusieurs protocoles de routage, filtrage des paquets, interfaces spécialisées, VLANs, MPLS...).
  
 
Il est malgré cela toujours possible d'utiliser un ordinateur universel comme routeur, en configurant des routes à la main ou en lançant des logiciels de routage. Il ne faut pas oublier que dans ce cas l'autoconfiguration «sans état» ne peut plus être utilisée, et qu'il faut donner explicitement des adresses aux différentes interfaces.
 
Il est malgré cela toujours possible d'utiliser un ordinateur universel comme routeur, en configurant des routes à la main ou en lançant des logiciels de routage. Il ne faut pas oublier que dans ce cas l'autoconfiguration «sans état» ne peut plus être utilisée, et qu'il faut donner explicitement des adresses aux différentes interfaces.
 +
 +
* [[Routeur Solaris]]
 +
* [[Routeur Linux]]
 +
* [[Routeur FreeBSD]]
 +
* [[Routeur NetBSD]]
 +
 +
=<div id="quagga">Zebra - Quagga</div>=
 +
 +
[http://www.zebra.org Zebra] est un logiciel de routage disponible librement (licence GPL) qui permet de transformer une machine Unix en un véritable routeur. Les protocoles RIP, OSPF, BGP sont implémentés dans leurs instances IPv4 et IPv6. Ce logiciel est architecturé de façon très modulaire (cf. figure Organisation du logiciel de routage Zebra). Chaque protocole de routage est supporté par un processus, et dialogue avec un processus maître (zebra) qui, lui, est chargé de gérer la table de routage de la machine en fonction des informations que lui transmettent les processus correspondants aux protocoles activés. Chaque protocole peut être paramétré en éditant un fichier de configuration spécifique ou de façon interactive au moyen d'un telnet sur un port associé. L'interface de commande et de configuration est calquée sur celle de l'IOS de Cisco. [http://www.quagga.net Quagga] est un logiciel de routage plus récent, dérivé de Zebra, son interface et son utilisation sont très proches de celles de Zebra.
 +
 +
[[image:CS94.gif]]
 +
 +
== Installation de Zebra ou Quagga==
 +
 +
En général, et selon les versions du système, l'un ou l'autre de ces logiciels est disponible avec le support IPv6. En FreeBSD 5.x et NetBSD 2.x, les deux logiciels sont disponibles comme paquetage binaire, il suffit de l'installer par la commande <tt>pkg_add</tt>. En Linux FedoraCore, Quagga est un paquetage RPM standard. En Solaris 10, Zebra est disponible dans les CDs de distribution ; toutefois la version binaire ne connait pas IPv6, il faut récupérer le paquetage source (<tt>SUNWzebraS</tt>) et le compiler pour avoir le support IPv6.
 +
 +
Un autre solution est de récupérer le source sur les sites de référence et de l'installer.
 +
Lancement et configuration initiale
 +
 +
L'installation a créé des binaires, des scripts de lancement et des fichiers d'exemples de configuration. Dans la suite, nous prendrons l'exemple du paquetage Zebra sur FreeBSD ; pour les autres systèmes il faut adapter les chemins d'accès et les noms des scripts.
 +
 +
La première étape consiste à créer le fichier de configuration zebra.conf du processus maître Zebra, puis à lancer le processus. Deux méthodes sont possibles :
 +
 +
* éditer le fichier (si le processus zebra n'est pas lancé)
 +
 +
>'''cd /usr/local/etc/zebra'''
 +
>'''cp zebra.conf.sample zebra.conf'''
 +
>'''vi zebra.conf'''
 +
>'''zebractl start'''
 +
 +
* lancer le processus et utiliser l'interface telnet
 +
 +
>'''cp /usr/local/etc/zebra/zebra.conf.sample /usr/local/etc/zebra/zebra.conf'''
 +
>'''zebractl start'''
 +
>'''telnet localhost zebra'''
 +
Password: '''zebra'''
 +
Router> '''enable'''
 +
Password: '''zebra'''
 +
Router# '''show running-config'''
 +
Router# '''conf t'''
 +
'''^Z'''
 +
Router# '''write'''
 +
 +
La syntaxe est inspirée de celle de l'IOS de Cisco.
 +
 +
Le lancement et l'arrêt de tous les processus zebra en FreeBSD se fait par la commande <tt>zebractl start</tt> (ou <tt>stop</tt>). Pour un lancement au démarrage de la machine, il suffit de faire :
 +
 +
>'''ln -s /usr/local/sbin/zebractl /usr/local/etc/rc.d/zebractl.sh'''
 +
 +
La configuration du processus Zebra décrit les interfaces, les routes statiques et les annonces de préfixe et de routeur. Il faut se méfier des interférences entre Zebra et la configuration globale du système, qui peut faire des choix ou lancer des démons (annonces, [[RIPng]]) sans tenir compte du lancement de Zebra ; de même pour l'activation du relayage des paquets, et le lancement de la configuration automatique des interfaces. Une bonne précaution est de laisser dans la configuration système la déclaration du mode routeur (<tt>ipv6_gateway_enable=YES</tt> dans <tt>/etc/rc.conf</tt> pour FreeBSD), et des adresses des interfaces, et de mettre dans le fichier de configuration Zebra les routes statiques et les annonces de préfixes et routeur (<tt>rtadvd_enable=NO</tt>).
 +
 +
Considérons l'exemple d'une machine thieste qui héberge le logiciel Zebra et qui a un interface Ethernet et un tunnel (voir [[BSD#tunnel|Tunnel sous FreeBSD]]).
 +
 +
La configuration IPv6 des interfaces se fait dans <tt>/etc/rc.conf</tt> par :
 +
 +
ipv6_enable=YES
 +
ipv6_gateway_enable=YES
 +
ipv6_router_enable=NO
 +
rtadvd_enable=NO
 +
ipv6_prefix_xl0="2001:660:282:1"
 +
gif_interfaces="gif1"
 +
gif_config_gif1="192.108.119.167 192.1098.119.189"
 +
ipv6_ifconfig_gif1="3ffe:305:1014:1::1 3ffe:305:1014:1::2"
 +
 +
Le résultat de cette configuration se vérifie par la commande <tt>ifconfig</tt> :
 +
 +
>'''ifconfig xl0'''
 +
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 +
inet 192.108.119.167 netmask 0xffffffc0 broadcast 192.108.119.191
 +
inet6 fe80::204:76ff:fe0b:9bf4%xl0 prefixlen 64 scopeid 0x2
 +
inet6 2001:660:282:1:204:76ff:fe0b:9bf4 prefixlen 64
 +
ether 00:04:76:0b:9b:f4
 +
media: autoselect (100baseTX <full-duplex>) status: active
 +
supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex>
 +
  10baseT/UTP  100baseTX <hw-loopback>
 +
>'''ifconfig gif1'''
 +
gif1: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280
 +
inet6 fe80::203:47ff:fe22:9cd8%gif1 --> :: prefixlen 64
 +
inet6 3ffe:305:1014:1::1 --> 3ffe:305:1014:1::2 prefixlen 128
 +
physical address inet 192.108.119.167 --> 192.108.119.189
 +
 +
==Configuration de l'annonce de préfixe par Zebra==
 +
 +
Sur le schéma de l'exemple figure Session BGP sous Zebra, on veut provoquer l'annonce du préfixe <tt>3ffe:305:1014::/48</tt> par le routeur <tt>thieste</tt> sur le tunnel vers le PC Linux. Cette annonce se traduit par l'extrait du fichier de configuration de Zebra ci -après :
 +
 +
[[image:CS95.gif]]
 +
 +
interface gif1
 +
ipv6 nd send-ra
 +
ipv6 nd prefix-advertisement 3ffe:305:1014::/48
 +
 +
Pour vérifier que l'annonce a bien produit son effet sur la machine Linux qui est à l'autre extrémité du tunnel on trouvera ci-dessous un extrait de la commande <tt>ifconfig</tt> donnée sur cette machine :
 +
 +
testG6 Lien encap:IPv6-dans-IPv4
 +
adr inet6: fe80::c06c:77bd/128 Scope:Lien
 +
adr inet6: 3ffe:305:1014:1::2/0 Scope:Global
 +
adr inet6: 3ffe:305:1014::c06c:77bd/64 Scope:Global
 +
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
 +
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
 +
TX packets:333 errors:0 dropped:0 overruns:0 carrier:0
 +
collisions:0 lg file transmission:0
 +
RX bytes:1144 (1.1 Kb) TX bytes:41292 (40.3 Kb)
 +
 +
==Configuration de routage dynamique==
 +
 +
Une fois le processus maître configuré, il faut configurer les différents processus de routage dynamiques, un par protocole. Pour chaque processus (ripngd, ospf6d, bgpd) il faut d'abord créer un fichier de configuration propre, qui contient les règles d'annonce, d'import et d'export de routes, et les contrôles (mot de passe et filtres de telnet par exemple). Il faut bien entendu s'assurer que le démon pour RIPng (route6d) n'est pas lancé (<tt>ipv6_router_enable=NO</tt>). Une fois les fichiers de configuration créés, la commande <tt>zebractl restart</tt> lancera tous les démons.
 +
 +
Voici deux exemples de configuration minimales pour [[RIPng]] et pour [[OSPFv3]] ; des prototypes sont fournis avec la distribution Zebra dans <tt>/usr/local/etc/zebra</tt> :
 +
 +
>'''cat /usr/local/etc/zebra/ripng.conf'''
 +
! Zebra ripngd configuration
 +
!
 +
hostname Router
 +
password 8 xxxxxxxxx
 +
enable password 8 xxxxxxxxxx
 +
service password-encryption
 +
!
 +
router ripng
 +
network xl0
 +
network gif1
 +
>'''cat /usr/local/etc/zebra/ospf6d.conf'''
 +
! Zebra ospfv3 configuration
 +
!
 +
hostname Router
 +
password zebra
 +
!
 +
router ospf6
 +
router-id 0.0.0.1
 +
interface xl0 area 200.1.0.0
 +
 +
== Configuration BGP4+ ==
 +
 +
Dans l'exemple figure Session BGP sous Zera, le routeur thieste appartenant à l'AS 65400 établi une session BGP4+ avec le routeur horace de l'AS 1938. Sur la machine thieste où le processus zebra a été activé lors des exemples précédents, il faut maintenant activer le processus bgpd après avoir installé son fichier de configuration (<tt>bgpd.conf</tt>). Cette opération est réalisée par la séquence de commandes suivante :
 +
 +
[[image:CS96.gif]]
 +
 +
>'''cp /usr/local/etc/zebra/bgpd.conf.sample /usr/local/etc/zebra/bgpd.conf'''
 +
>'''zebractl restart'''
 +
>'''telnet localhost bgpd'''
 +
 +
La dernière commande permet de contacter le processus <tt>bgpd</tt> pour le configurer interactivement comme on le ferait avec un routeur dédié. La configuration correspondant à l'exemple ci-dessous est listée par la commande <tt>write</tt> :
 +
 +
bgpd# '''write t'''
 +
 
 +
Current configuration:
 +
!
 +
hostname bgpd
 +
password xxxxxx
 +
log stdout
 +
!
 +
router bgp 65400
 +
bgp router-id 192.108.119.167
 +
ipv6 bgp neighbor 2001:660:281:8::1 remote-as 1938
 +
!
 +
line vty
 +
!
 +
end
 +
 +
On peut avoir un état sommaire des sessions BGP4+ par une commande <tt>show</tt> :
 +
 +
bgpd# '''show ipv6 bgp summary'''
 +
BGP router identifier 192.108.119.167, local AS number 65400
 +
175 BGP AS-PATH entries
 +
0 BGP community entries
 +
 
 +
Neighbor AS MsgRcvd MsgSent Up/Down State/PfxRcd
 +
2001:660:281:8::1 1938 209 26 00:15:36 264
 +
 
 +
Total number of neighbors 1
 +
 +
Ou avoir plus d'informations sur les sessions BGP par :
 +
 +
bgpd# '''show ipv6 bgp neighbors'''
 +
BGP neighbor is 2001:660:281:8::1, remote AS 1938, external link
 +
BGP version 4, remote router ID 131.254.200.10
 +
BGP state = Established, up for 00:14:50
 +
Last read 00:00:49, hold time is 180, keepalive interval is 60 seconds
 +
Neighbor capabilities:
 +
Route refresh: advertised and received(old and new)
 +
Address family IPv4 Unicast: advertised and received
 +
Received 200 messages, 8 notifications, 0 in queue
 +
Sent 25 messages, 0 notifications, 0 in queue
 +
Route refresh request: received 0, sent 0
 +
Minimum time between advertisement runs is 0 seconds
 +
 
 +
For address family: IPv6 Unicast
 +
Community attribute sent to this neighbor
 +
264 accepted prefixes
 +
 
 +
Connections established 1; dropped 0
 +
Local host: 2001:660:281:8::2, Local port: 179
 +
Foreign host: 2001:660:281:8::1, Foreign port: 11681
 +
Nexthop: 192.108.119.167
 +
Nexthop global: 2001:660:281:8::2
 +
Nexthop local: ::
 +
BGP connection: non shared network
 +
Read thread: on Write thread: off
 +
 +
La liste des préfixes et leurs attributs est donnée par :
 +
 +
bgpd# show ipv6 bgp
 +
BGP table version is 0, local router ID is 192.108.119.167
 +
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
 +
Origin codes: i - IGP, e - EGP, ? - incomplete
 +
 
 +
Network Metric LocPrf Weight Path
 +
*> ::194.182.135.0/120 0 1938 2200 1103 766 278 6435 6939 513 8933 2852 3263 i
 +
2001:660:281:8::1(fe80::83fe:c80a)
 +
*> 2001:200::/35 0 1938 2200 3425 2500 i
 +
2001:660:281:8::1(fe80::83fe:c80a)
 +
*> 2001:200:12a::/48 0 1938 2200 5511 3549 ?
 +
2001:660:281:8::1(fe80::83fe:c80a)
 +
*> 2001:200:600::/40 0 1938 2200 5511 7667 i
 +
[....]
 +
*> 3ffe:8240::/28 0 1938 2200 1103 8954 109 6342 i
 +
2001:660:281:8::1(fe80::83fe:c80a)
 +
 
 +
Total number of prefixes 264
 +
 +
==Filtrage d'annonce BGP4+ ==
 +
 +
Pour terminer cet exemple de configuration Zebra, on installe trois filtres sur les annonces de préfixes reçus par <tt>thieste</tt> en provenance de son voisin BGP <tt>horace</tt>.
 +
 +
Le filtre nommé <tt>filtre_nlri</tt> porte sur les préfixes eux-même, et rejette les annonces de préfixes contenus dans <tt>3ffe:305:1014::/48</tt> ou dans <tt>2002::/16</tt>.
 +
 +
Le filtre nommé <tt>filtre_as</tt> porte sur les chemins d'AS, il rejette les annonces de préfixes dont l'attribut <tt>as_path</tt> commence par la séquence d'AS : <tt>1938 2200 5511</tt>.
 +
 +
Le filtre nommé <tt>filtre_map</tt> modifie l'attribut <tt>local_pre</tt>. Ce dernier prend la valeur 200 si l'attribut <tt>as_path</tt> du préfixe annoncé commence par la séquence d'AS : <tt>1938 2200 1103</tt>. Dans tous les autres cas l'attribut <tt>local_pref</tt> prend la valeur 100.
 +
 +
La partie concernant BGP du fichier de configuration devient :
 +
 +
router bgp 65400
 +
bgp router-id 192.108.119.167
 +
ipv6 bgp neighbor 2001:660:281:8::1 remote-as 1938
 +
ipv6 bgp neighbor 2001:660:281:8::1 prefix-list filtre_nlri in
 +
ipv6 bgp neighbor 2001:660:281:8::1 filter-list filtre_as in
 +
ipv6 bgp neighbor 2001:660:281:8::1 route-map filtre_map in
 +
!
 +
ipv6 prefix-list filtre_nlri description on ne veut pas se faire annoncer son reseau ni le  2002::/16
 +
ipv6 prefix-list filtre_nlri seq 5 deny 3ffe:305:1014::/48 le 128
 +
ipv6 prefix-list filtre_nlri seq 10 deny 2002::/16 le 128
 +
ipv6 prefix-list filtre_nlri seq 15 permit any
 +
!
 +
ip as-path access-list filtre_as deny 1938 2200 5511 *
 +
ip as-path access-list filtre_as permit .*
 +
!
 +
ip as-path access-list as_prefere permit 1938 2200 1103 *
 +
ip as-path access-list as_prefere deny .*
 +
!
 +
route-map filtre_map permit 10
 +
match as-path as_prefere
 +
set local-preference 200
 +
!
 +
route-map filtre_map permit 20
 +
set local-preference 100
 +
 +
{{suivi| BGPJuniper|Juniper|Routeur Solaris|Routeur Solaris}}

Latest revision as of 16:35, 8 June 2006

Juniper Table des matières Routeur Solaris

En IPv6 les fonctions de machine simple («node») et de routeur ont été nettement séparées. Il est donc courant d'utiliser de matériels spécialisés comme routeurs, et de configurer les machines normales comme des noeuds simples, sans fonction de routage (cf. Installation d'un équipement), et ce d'autant plus qu'un routeur dédié peut devenir complexe (plusieurs protocoles de routage, filtrage des paquets, interfaces spécialisées, VLANs, MPLS...).

Il est malgré cela toujours possible d'utiliser un ordinateur universel comme routeur, en configurant des routes à la main ou en lançant des logiciels de routage. Il ne faut pas oublier que dans ce cas l'autoconfiguration «sans état» ne peut plus être utilisée, et qu'il faut donner explicitement des adresses aux différentes interfaces.

Zebra - Quagga

Zebra est un logiciel de routage disponible librement (licence GPL) qui permet de transformer une machine Unix en un véritable routeur. Les protocoles RIP, OSPF, BGP sont implémentés dans leurs instances IPv4 et IPv6. Ce logiciel est architecturé de façon très modulaire (cf. figure Organisation du logiciel de routage Zebra). Chaque protocole de routage est supporté par un processus, et dialogue avec un processus maître (zebra) qui, lui, est chargé de gérer la table de routage de la machine en fonction des informations que lui transmettent les processus correspondants aux protocoles activés. Chaque protocole peut être paramétré en éditant un fichier de configuration spécifique ou de façon interactive au moyen d'un telnet sur un port associé. L'interface de commande et de configuration est calquée sur celle de l'IOS de Cisco. Quagga est un logiciel de routage plus récent, dérivé de Zebra, son interface et son utilisation sont très proches de celles de Zebra.

CS94.gif

Installation de Zebra ou Quagga

En général, et selon les versions du système, l'un ou l'autre de ces logiciels est disponible avec le support IPv6. En FreeBSD 5.x et NetBSD 2.x, les deux logiciels sont disponibles comme paquetage binaire, il suffit de l'installer par la commande pkg_add. En Linux FedoraCore, Quagga est un paquetage RPM standard. En Solaris 10, Zebra est disponible dans les CDs de distribution ; toutefois la version binaire ne connait pas IPv6, il faut récupérer le paquetage source (SUNWzebraS) et le compiler pour avoir le support IPv6.

Un autre solution est de récupérer le source sur les sites de référence et de l'installer. Lancement et configuration initiale

L'installation a créé des binaires, des scripts de lancement et des fichiers d'exemples de configuration. Dans la suite, nous prendrons l'exemple du paquetage Zebra sur FreeBSD ; pour les autres systèmes il faut adapter les chemins d'accès et les noms des scripts.

La première étape consiste à créer le fichier de configuration zebra.conf du processus maître Zebra, puis à lancer le processus. Deux méthodes sont possibles :

  • éditer le fichier (si le processus zebra n'est pas lancé)
>cd /usr/local/etc/zebra
>cp zebra.conf.sample zebra.conf
>vi zebra.conf
>zebractl start
  • lancer le processus et utiliser l'interface telnet
>cp /usr/local/etc/zebra/zebra.conf.sample /usr/local/etc/zebra/zebra.conf
>zebractl start
>telnet localhost zebra
Password: zebra
Router> enable
Password: zebra
Router# show running-config
Router# conf t
^Z
Router# write

La syntaxe est inspirée de celle de l'IOS de Cisco.

Le lancement et l'arrêt de tous les processus zebra en FreeBSD se fait par la commande zebractl start (ou stop). Pour un lancement au démarrage de la machine, il suffit de faire : 

>ln -s /usr/local/sbin/zebractl /usr/local/etc/rc.d/zebractl.sh

La configuration du processus Zebra décrit les interfaces, les routes statiques et les annonces de préfixe et de routeur. Il faut se méfier des interférences entre Zebra et la configuration globale du système, qui peut faire des choix ou lancer des démons (annonces, RIPng) sans tenir compte du lancement de Zebra ; de même pour l'activation du relayage des paquets, et le lancement de la configuration automatique des interfaces. Une bonne précaution est de laisser dans la configuration système la déclaration du mode routeur (ipv6_gateway_enable=YES dans /etc/rc.conf pour FreeBSD), et des adresses des interfaces, et de mettre dans le fichier de configuration Zebra les routes statiques et les annonces de préfixes et routeur (rtadvd_enable=NO).

Considérons l'exemple d'une machine thieste qui héberge le logiciel Zebra et qui a un interface Ethernet et un tunnel (voir Tunnel sous FreeBSD).

La configuration IPv6 des interfaces se fait dans /etc/rc.conf par : 

ipv6_enable=YES
ipv6_gateway_enable=YES
ipv6_router_enable=NO
rtadvd_enable=NO
ipv6_prefix_xl0="2001:660:282:1"
gif_interfaces="gif1"
gif_config_gif1="192.108.119.167 192.1098.119.189"
ipv6_ifconfig_gif1="3ffe:305:1014:1::1 3ffe:305:1014:1::2"

Le résultat de cette configuration se vérifie par la commande ifconfig : 

>ifconfig xl0
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.108.119.167 netmask 0xffffffc0 broadcast 192.108.119.191
inet6 fe80::204:76ff:fe0b:9bf4%xl0 prefixlen 64 scopeid 0x2
inet6 2001:660:282:1:204:76ff:fe0b:9bf4 prefixlen 64
ether 00:04:76:0b:9b:f4
media: autoselect (100baseTX <full-duplex>) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 
  10baseT/UTP  100baseTX <hw-loopback>
>ifconfig gif1
gif1: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280
inet6 fe80::203:47ff:fe22:9cd8%gif1 --> :: prefixlen 64
inet6 3ffe:305:1014:1::1 --> 3ffe:305:1014:1::2 prefixlen 128
physical address inet 192.108.119.167 --> 192.108.119.189

Configuration de l'annonce de préfixe par Zebra

Sur le schéma de l'exemple figure Session BGP sous Zebra, on veut provoquer l'annonce du préfixe 3ffe:305:1014::/48 par le routeur thieste sur le tunnel vers le PC Linux. Cette annonce se traduit par l'extrait du fichier de configuration de Zebra ci -après :

CS95.gif 

interface gif1
ipv6 nd send-ra
ipv6 nd prefix-advertisement 3ffe:305:1014::/48

Pour vérifier que l'annonce a bien produit son effet sur la machine Linux qui est à l'autre extrémité du tunnel on trouvera ci-dessous un extrait de la commande ifconfig donnée sur cette machine : 

testG6 Lien encap:IPv6-dans-IPv4
adr inet6: fe80::c06c:77bd/128 Scope:Lien
adr inet6: 3ffe:305:1014:1::2/0 Scope:Global
adr inet6: 3ffe:305:1014::c06c:77bd/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:333 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:1144 (1.1 Kb) TX bytes:41292 (40.3 Kb)

Configuration de routage dynamique

Une fois le processus maître configuré, il faut configurer les différents processus de routage dynamiques, un par protocole. Pour chaque processus (ripngd, ospf6d, bgpd) il faut d'abord créer un fichier de configuration propre, qui contient les règles d'annonce, d'import et d'export de routes, et les contrôles (mot de passe et filtres de telnet par exemple). Il faut bien entendu s'assurer que le démon pour RIPng (route6d) n'est pas lancé (ipv6_router_enable=NO). Une fois les fichiers de configuration créés, la commande zebractl restart lancera tous les démons.

Voici deux exemples de configuration minimales pour RIPng et pour OSPFv3 ; des prototypes sont fournis avec la distribution Zebra dans /usr/local/etc/zebra : 

>cat /usr/local/etc/zebra/ripng.conf
! Zebra ripngd configuration
!
hostname Router
password 8 xxxxxxxxx
enable password 8 xxxxxxxxxx
service password-encryption
!
router ripng
network xl0
network gif1
>cat /usr/local/etc/zebra/ospf6d.conf
! Zebra ospfv3 configuration
!
hostname Router
password zebra
!
router ospf6
router-id 0.0.0.1
interface xl0 area 200.1.0.0

Configuration BGP4+

Dans l'exemple figure Session BGP sous Zera, le routeur thieste appartenant à l'AS 65400 établi une session BGP4+ avec le routeur horace de l'AS 1938. Sur la machine thieste où le processus zebra a été activé lors des exemples précédents, il faut maintenant activer le processus bgpd après avoir installé son fichier de configuration (bgpd.conf). Cette opération est réalisée par la séquence de commandes suivante :

CS96.gif 

>cp /usr/local/etc/zebra/bgpd.conf.sample /usr/local/etc/zebra/bgpd.conf
>zebractl restart
>telnet localhost bgpd

La dernière commande permet de contacter le processus bgpd pour le configurer interactivement comme on le ferait avec un routeur dédié. La configuration correspondant à l'exemple ci-dessous est listée par la commande write : 

bgpd# write t
 
Current configuration:
!
hostname bgpd
password xxxxxx
log stdout
!
router bgp 65400
bgp router-id 192.108.119.167
ipv6 bgp neighbor 2001:660:281:8::1 remote-as 1938
!
line vty
!
end

On peut avoir un état sommaire des sessions BGP4+ par une commande show : 

bgpd# show ipv6 bgp summary
BGP router identifier 192.108.119.167, local AS number 65400
175 BGP AS-PATH entries
0 BGP community entries
 
Neighbor AS MsgRcvd MsgSent Up/Down State/PfxRcd
2001:660:281:8::1 1938 209 26 00:15:36 264
 
Total number of neighbors 1

Ou avoir plus d'informations sur les sessions BGP par : 

bgpd# show ipv6 bgp neighbors
BGP neighbor is 2001:660:281:8::1, remote AS 1938, external link
BGP version 4, remote router ID 131.254.200.10
BGP state = Established, up for 00:14:50
Last read 00:00:49, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old and new)
Address family IPv4 Unicast: advertised and received
Received 200 messages, 8 notifications, 0 in queue
Sent 25 messages, 0 notifications, 0 in queue
Route refresh request: received 0, sent 0
Minimum time between advertisement runs is 0 seconds
 
For address family: IPv6 Unicast
Community attribute sent to this neighbor
264 accepted prefixes
 
Connections established 1; dropped 0
Local host: 2001:660:281:8::2, Local port: 179
Foreign host: 2001:660:281:8::1, Foreign port: 11681
Nexthop: 192.108.119.167
Nexthop global: 2001:660:281:8::2
Nexthop local: ::
BGP connection: non shared network
Read thread: on Write thread: off

La liste des préfixes et leurs attributs est donnée par : 

bgpd# show ipv6 bgp
BGP table version is 0, local router ID is 192.108.119.167
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
 
Network Metric LocPrf Weight Path
*> ::194.182.135.0/120 0 1938 2200 1103 766 278 6435 6939 513 8933 2852 3263 i
2001:660:281:8::1(fe80::83fe:c80a)
*> 2001:200::/35 0 1938 2200 3425 2500 i
2001:660:281:8::1(fe80::83fe:c80a)
*> 2001:200:12a::/48 0 1938 2200 5511 3549 ?
2001:660:281:8::1(fe80::83fe:c80a)
*> 2001:200:600::/40 0 1938 2200 5511 7667 i
[....]
*> 3ffe:8240::/28 0 1938 2200 1103 8954 109 6342 i
2001:660:281:8::1(fe80::83fe:c80a)
 
Total number of prefixes 264

Filtrage d'annonce BGP4+

Pour terminer cet exemple de configuration Zebra, on installe trois filtres sur les annonces de préfixes reçus par thieste en provenance de son voisin BGP horace.

Le filtre nommé filtre_nlri porte sur les préfixes eux-même, et rejette les annonces de préfixes contenus dans 3ffe:305:1014::/48 ou dans 2002::/16.

Le filtre nommé filtre_as porte sur les chemins d'AS, il rejette les annonces de préfixes dont l'attribut as_path commence par la séquence d'AS : 1938 2200 5511.

Le filtre nommé filtre_map modifie l'attribut local_pre. Ce dernier prend la valeur 200 si l'attribut as_path du préfixe annoncé commence par la séquence d'AS : 1938 2200 1103. Dans tous les autres cas l'attribut local_pref prend la valeur 100.

La partie concernant BGP du fichier de configuration devient : 

router bgp 65400
bgp router-id 192.108.119.167
ipv6 bgp neighbor 2001:660:281:8::1 remote-as 1938
ipv6 bgp neighbor 2001:660:281:8::1 prefix-list filtre_nlri in
ipv6 bgp neighbor 2001:660:281:8::1 filter-list filtre_as in
ipv6 bgp neighbor 2001:660:281:8::1 route-map filtre_map in
!
ipv6 prefix-list filtre_nlri description on ne veut pas se faire annoncer son reseau ni le  2002::/16 
ipv6 prefix-list filtre_nlri seq 5 deny 3ffe:305:1014::/48 le 128
ipv6 prefix-list filtre_nlri seq 10 deny 2002::/16 le 128
ipv6 prefix-list filtre_nlri seq 15 permit any
!
ip as-path access-list filtre_as deny 1938 2200 5511 *
ip as-path access-list filtre_as permit .*
!
ip as-path access-list as_prefere permit 1938 2200 1103 *
ip as-path access-list as_prefere deny .*
!
route-map filtre_map permit 10
match as-path as_prefere
set local-preference 200
!
route-map filtre_map permit 20
set local-preference 100
Juniper Table des matières Routeur Solaris
Retrieved from "http://livre.g6.asso.fr/index.php?title=Utilisation_d%27un_ordinateur_comme_routeur&oldid=3251"
Personal tools