Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation

2011-06-30 Par sujet Guillaume Barrot 
De mon cote je comprends bien le gain de telles solutions mais je ne
comprends pas ce que ca rajoute comme fonctionnalite par rapport a un truc
comme lisp (lui aussi en draft) avec comme interet de ne pas rajouter
l'eternel probleme des ALG SIP.

Ca a l'air plus simple a implementer et ca doit probablement avoir un impact
faible sur les perfs des routeurs (ca a l'air codable en asic sans trop de
soucis, non). Vous voyez d'autres arguments ?

Bossant dans un des derniers bastions du 3GPP, si on pouvait se passer de la
partie ALG Sip et ne garder sur les sbc que le filtrage des messages L7 (un
proxy transparent quoi) ce serait la fete dans les chaumieres !
Le 1 juil. 2011 08:12, "Pierre Lagoutte"  a écrit :

Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation

2011-06-30 Par sujet Pierre Lagoutte 
Pourquoi diable tant d'animosité vis-à-vis cette solution simple ?
qui bouche un gros trou dans la raquette (il en reste d'autres
rassurez-vous)
après tant d'échecs, les NATs auraient-ils encore une si mauvaise odeur
dans le monde v6 ?
et en plus pratiquement sans inconvénients majeurs (voir le blog de
stephane)

  Pierre (enthousiaste de NAT66)

PS: quand on commence de faire de la "politique" dans une assemblée
technique, c'est que la fin en est proche


=
Le 01/07/2011 07:52, Michel Py a écrit :
>> Raphaël Jacquot a écrit:
>> chez moi ca s'appelle du routage...
>> Non; le terme "prefix translation" est correct. A l'origine, MHAP 
>> s'appellait MHTP (Multi Homing Translation Protocol); j'ai remplacé 
>> "translation" par "aliasing" pour des raisons uniquement politiques: ça 
>> sonnait trop comme NAT, qui à l'époque n'était pas envisageable pour v6.
>>
>> C'est du NAT de subnet, dont les avantages sont assez bien expliqués. Ca 
>> existe pour v4 depuis 15 ans, même si personne ou presque ne s'en sert.
>>
>> ils ont sorti leur truc pour le 1er avril ?
> En Anglais on dit "re-arrange desk chairs on the Titanic"; c'est bien plus 
> politiquement correct que "pisser dans un violon" et tout aussi efficace. 
> Quand à moi, comme tous les vieux rats qui se respectent, j'ai vu monter 
> l'eau et quitté le navire il y a longtemps.
>
> Michel.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
<>

RE: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation

2011-06-30 Par sujet Michel Py 
> Raphaël Jacquot a écrit:
> chez moi ca s'appelle du routage...

Non; le terme "prefix translation" est correct. A l'origine, MHAP s'appellait 
MHTP (Multi Homing Translation Protocol); j'ai remplacé "translation" par 
"aliasing" pour des raisons uniquement politiques: ça sonnait trop comme NAT, 
qui à l'époque n'était pas envisageable pour v6.

C'est du NAT de subnet, dont les avantages sont assez bien expliqués. Ca existe 
pour v4 depuis 15 ans, même si personne ou presque ne s'en sert.


> ils ont sorti leur truc pour le 1er avril ?

En Anglais on dit "re-arrange desk chairs on the Titanic"; c'est bien plus 
politiquement correct que "pisser dans un violon" et tout aussi efficace. Quand 
à moi, comme tous les vieux rats qui se respectent, j'ai vu monter l'eau et 
quitté le navire il y a longtemps.

Michel.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation

2011-06-30 Par sujet Raphaël Jacquot 

On 30 juin 2011, at 22:34, Stephane Bortzmeyer wrote:

> Personne ne veut mettre du NAT66 sur ses boxes ? :-)
> 
> http://www.bortzmeyer.org/6296.html
> 
> 
> 
> Auteur(s) du RFC: M. Wasserman (Painless Security), F. Baker (Cisco Systems)
> 
> 

chez moi ca s'appelle du routage...
ils ont sorti leur truc pour le 1er avril ?---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation

2011-06-30 Par sujet Michel Py 
> Stephane Bortzmeyer a écrit:
> Personne ne veut mettre du NAT66 sur ses boxes ? :-)
> http://www.bortzmeyer.org/6296.html

Ah mais c'est trolldi!

Ben ça va (très) bientôt faire 10 ans (le 6 Août) que j'ai décrit en détail ce 
mécanisme (soumis draft-py-multi6-mhtp-00.txt, qui a évolué en 
draft-py-mhap-01a.txt). Ce texte est une version simplifiée, pour ne pas dire 
simpliste.


Mais la partie qui m'a fait rire, c'est:
> URI: http://www.painless-security.com

"Painless Security". Voyons voir, ça ne serait pas un oxymore, des fois?

Michel.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] IPv6 Lab Day : Paris le 05 juillet 2011

2011-06-30 Par sujet Yoann Gini 

Le 30 juin 2011 à 22:14, Raphael MAUNIER a écrit :

> On pourrait, on a l'accès IP et un mac et une caméra. Je ne sais pas si on 
> aura le temps de monter la solution pour Mardi.
> 
> Bref on a la caf ( "capacité à faire" pour les intimes ), mais le temps, je 
> ne sais pas.
> 
> Si qqn se sent le courage de préparer tout ça, il est le bien entendue prié 
> de se dénoncer :)

Au pire si c’est fait à l’arrache c’est pas trop gênant. Le live c’est le pti’ 
truc classe mais l’important c’est d’avoir les vidéo dispo après coup. Donc un 
Mac, une caméra compatible QT et QT X et c’est dans la poche.

smime.p7s
Description: S/MIME cryptographic signature

[FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation

2011-06-30 Par sujet Stephane Bortzmeyer 
Personne ne veut mettre du NAT66 sur ses boxes ? :-)

http://www.bortzmeyer.org/6296.html



Auteur(s) du RFC: M. Wasserman (Painless Security), F. Baker (Cisco Systems)




Avec ce RFC, encore expérimental, IPv6 gagne la possibilité de faire de 
la *traduction d'adresses*, c'est-à-dire d'avoir dans un réseau local 
des adresses internes, qui seront dynamiquement traduites en adresses 
externes par le routeur de sortie, qui pourra également faire 
l'opération inverse (de l'extérieur vers l'intérieur).

Cette traduction est souvent nommée NAT ("Network Address Translation") 
mais ce terme n'est pas correct : la traduction habituelle en IPv4, 
celle que tout le monde doit supporter pour sa connexion Internet à la 
maison et pour son accès 3G, NAT44, ne traduit pas uniquement 
l'adresse. Pour faire face à la pénurie d'adresses IPv4, elle met en 
correspondance plusieurs adresses internes (typiquement du RFC 1918), 
avec une adresse externe, en utilisant les numéros de port pour 
démultiplexer les paquets entrants. Cette technique devrait donc 
s'appeler NAPT ("Network Address and Port Translation") et pas NAT. 
Elle a des tas d'inconvénients, décrits dans le RFC 6269.

En IPv6 au contraire, sujet de notre RFC, il n'y a pas de pénurie 
d'adresses et pas de raison de faire du NAPT. Le protocole de 
traduction proposé dans ce RFC 6296 mériterait donc, lui, de s'appeler 
NAT (ou peut-être NAT66), mais, comme ce terme est désormais très 
galvaudé, ses auteurs ont plutôt choisi *NPT* pour "Network Prefix 
Translation". NPTv6 permet une correspondance univoque (1:1) entre les 
adresses internes et les adresses externes, évitant ainsi le partage 
d'adresses dont le RFC 6269 décrit les défauts. Pour diverses raisons 
(cf. RFC 2993 et section 5 de notre RFC), l'IETF n'encourage pas les 
systèmes de traduction mais, si un utilisateur tient à en faire, ce RFC 
lui fournit un protocole bien étudié. Il n'évite pas tous les problèmes 
de la traduction (RFC 4864, RFC 5902) mais les limite.

N'utilisant pas les ports, NPTv6 fonctionne donc avec tous les 
protocoles de transport, contrairement au NAT44 traditionnel (cf. 
section 6). Il est *sans état* (chaque paquet est traduit 
indépendemment des autres) donc le routeur qui fait la traduction n'a 
pas de problèmes comme le remplissage de la table (fréquent avec 
NAT44). Ainsi, un réseau peut être servi par deux traducteurs (par 
exemple pour la redondance) sans qu'ils aient à partager un état. Mais 
ce caractère sans état a aussi d'autres conséquences :
* NPT est juste une technique de traduction, il ne fournit pas de 
filtrage, ce n'est pas un pare-feu (les routeurs NAT44 mélangent les 
deux fonctions de traducteur et de pare-feu avec état), si on veut un 
pare-feu, il faut donc le faire en plus (cf. RFC 6092),
* il permet le maintien du principe de la connexion de bout en bout, y 
compris pour les connexions « entrantes », mais, comme toute technique 
de traduction, NPT a des problèmes avec les applications qui incluent 
les adresses IP dans les données,
* même problème avec les services qui incluent l'adresse IP dans le 
calcul d'un MAC comme l'option d'authentification de TCP (RFC 5925).
Voilà pour un résumé très rapide des propriétés de NPT v6.

Mais pour quelles raisons peut-on avoir envie de déployer un système de 
traduction ? La section 1.1 de notre RFC propose de les résumer en un 
principe : indépendance vis-à-vis de l'adresse. Ce principe comprend 
plusieurs propriétés :
* Les adresses internes au réseau local étant distinctes de celles du 
réseau extérieur, aucune nécessité de renuméroter si on change de FAI 
(RFC 5887).
* Le site peut choisir son opérateur, sa connexion, ses opérateurs 
multiples, même ("multi-homing" sans BGP),
* Pas besoin d'obtenir des adresses PI pour avoir des adresses à soi,
* Et pour le FAI, pas besoin de BCP 38 (RFC 2827), les adresses 
annoncées étant traduites en ses adresses.
« Adresses internes + traduction » est donc potentiellement un « PI du 
pauvre ». En IPv4, beaucoup de sites utilisaient le NAT pour atteindre 
cette indépendance, même lorsqu'elles pouvaient obtenir suffisamment 
d'adresses IP. Le RFC 4864 décrit d'ailleurs un concept proche nommé 
« autonomie du réseau ».

NPTv6 est donc un mécanisme qui permet de réaliser cette indépendance 
du réseau. Meilleur que le NAT44 (pas de manipulation des ports, 
fonctionne donc avec tous les protocoles de transport, comme SCTP, 
permet les connexions entrantes, purement « algorithmique » donc sans 
état), il peut donc être un ajout intéressant à la boîte à outils de 
l'administrateur de réseaux IPv6.

Pour être tout à fait complet, il faut aussi rappeler ses inconvénients 
(RFC 2993) :
* Comme il modifie l'en-tête IP, il est incompatible avec les 
techniques de sécurisation de cet en-tête comme l'AH d'IPsec (RFC 
4302),
* Comme toute traduction d'adresses, il ne marche pas avec les 
protocoles qui transmettent des adresses IP d

Re: [FRnOG] IPv6 Lab Day : Paris le 05 juillet 2011

2011-06-30 Par sujet Raphael MAUNIER 
On pourrait, on a l'accès IP et un mac et une caméra. Je ne sais pas si on aura 
le temps de monter la solution pour Mardi.

Bref on a la caf ( "capacité à faire" pour les intimes ), mais le temps, je ne 
sais pas.

Si qqn se sent le courage de préparer tout ça, il est le bien entendue prié de 
se dénoncer :)

--
Raphaël Maunier
NEO TELECOMS


From: Yoann Gini mailto:yoann.g...@gmail.com>>
Date: Thu, 30 Jun 2011 22:08:28 +0200
To: Moi Maunier mailto:rmaun...@neotelecoms.com>>
Cc: "frnog@FRnOG.org FRnoG" 
mailto:frnog@frnog.org>>
Subject: Re: [FRnOG] IPv6 Lab Day : Paris le 05 juillet 2011


Le 30 juin 2011 à 21:42, Raphael MAUNIER a écrit :

La journée du 05 juillet se présente plutôt bien. Nous avons mis l'ensemble des 
informations sur le wiki ici : http://www.ipv6wg.org/

Question bête, les conf seront dispo en vidéo pour les absents ?

Re: [FRnOG] IPv6 Lab Day : Paris le 05 juillet 2011

2011-06-30 Par sujet Yoann Gini 

Le 30 juin 2011 à 21:42, Raphael MAUNIER a écrit :

> La journée du 05 juillet se présente plutôt bien. Nous avons mis l'ensemble 
> des informations sur le wiki ici : http://www.ipv6wg.org/

Question bête, les conf seront dispo en vidéo pour les absents ?

smime.p7s
Description: S/MIME cryptographic signature

Re: [FRnOG] IPv6 Lab Day : Paris le 05 juillet 2011

2011-06-30 Par sujet Raphael MAUNIER 
Bonsoir à tous,

La journée du 05 juillet se présente plutôt bien. Nous avons mis l'ensemble des 
informations sur le wiki ici : http://www.ipv6wg.org/

Si vous souhaitez venir et que votre nom n'est pas dans la liste, merci de nous 
envoyer un mail à meet...@ipv6wg.org

À mardi,
--
Raphaël Maunier
NEO TELECOMS


From: Moi Maunier mailto:rmaun...@neotelecoms.com>>
Reply-To: Moi Maunier 
mailto:rmaun...@neotelecoms.com>>
Date: Thu, 23 Jun 2011 10:56:28 +
To: "frnog@FRnOG.org FRnoG" 
mailto:frnog@frnog.org>>
Subject: [FRnOG] IPv6 Lab Day : Paris le 05 juillet 2011

Bonjour à tous,

Lors d'un précédent FRNOG, la mise place un IPV6 Working Group (avant même 
l'annonce du IPv6 DAY) avait été évoquée, mais depuis rien ne s'est vraiment 
passé faute de temps et de personnes pour prendre le sujet en main.

A la suite de l'AG de FranceIX, nous avons organisé en petit comité une 
première rencontre avec quelques membres et un constructeur ( Juniper ).

Le petit groupe présent a décidé de finalement créer ce Working Group. Nous 
avons donc contacté le G6 afin de travailler de concertavec eux.

Afin d'avancer, nous proposons une première journée qui se déroulerait le 05 
juillet sur Paris. Neo Telecoms se propose fournir la salle de présentation qui 
pourrait accueillir une cinquantaine de personnes.

L'idée générale est de travailler sur des cas concrets avec du lab en faisant 
venir les constructeurs. Pour cette première journée, Juniper, Netasq seront 
présents, et nous avons contacté Brocade également (Si Cisco ou autre est 
écoute et que vous voulez venir, c'est avec plaisir)

La journée sera probablement organisée en 3 parties :

- Matinée : présentations théoriques et pratiques

- 6PE, Jaguar Network,
- Collecte IPv6 & retours sur Redback, WiFirst,
- Adressage IPv6, Néo Télécoms,
- DNS64, Néo Télécoms
- G6 : BCP
- DS Lite, Juniper Networks ( pas commercial )
- TDB autour de la sécurité sur IPv6, Netasq ( pas commercial )


Toutes ces présentations contiendront une majorité d'informations « pratiques » 
plus que théoriques : des exemples de conf, les bugs rencontrés, les soucis de 
déploiement, etc.


- Midi - Début d'après-midi : Discussion avec les constructeurs présents et 
setup du LAB (on aura une baie avec du matériel de Juniper, Netasq et autre 
constructeurs d'ils se manifestent d'ici là) et un port Giga Neo Telecoms sur 
notre backbone.

Pour la deuxième partie de la journée, Juniper présentera un lab DS Lite, où 
chacun pourra consulter la conf, et faire des tests (on aura des CPE, des 
routeurs de Backbone, des cartes de service, etc.). Netasq et Juniper 
organiseront plusieurs sessions de configuration de fwl sur IPv6.
Nous aurons également Arbor qui viendra nous présenter les stats qu'ils ont pu 
avoir pendant le IPv6 day ainsi que des infos sur des eventuels DDOS en V6

- Après-midi : table ronde entre les différents acteurs / débrief du lab : ceux 
qui participent à la normalisation, les opérateurs, et les constructeurs.

Pour la dernière partie, ce sera l'occasion de discuter avec des gens de tous 
horizons du réseau, mais majoritairement des admins / ingé tournés vers la 
pratique.


En parallèle, nous avons déposé le nom de domaine 
ipv6wg.org. Nous allons mettre en place un wiki avec 
l'ensemble des informations / conf produites lors de ces réunions.
Il sera bien sur public et le but est de l'enrichir le plus possible.

Nous n'avons pas de budget, pas de sponsors, ce n'est pas une association donc 
pour le moment, le petit dej, dej / pause n'est pas compris. On va surement 
voir avec nos amis les constructeurs pour trouver de quoi
financer la mangeaille :)
La seule chose que le petit groupe de départ va financer est les tomates que 
nous pourrions balancer sur les constructeurs, s'ils tentent de nous faire du 
bullshit commercial :)

Afin d'avoir un minimum d'organisation, merci de vous inscrire en nous envoyant 
un mail sur meet...@ipv6wg.com.

Il faudra également penser à l'après-meeting et comment faire en sorte de 
garder un lab ouvert 24/7 dans un vrai datacenter avec possibilité de 
réservation de ressources. On verra qui se propose d'héberger le matériel et 
qui fera des donations :) ( Cisco pourrait donner des Juniper, Juniper des 
Cisco , Brocade des ... ) :)

Si vous avez des questions, merci de le faire sur 
meet...@ipv6wg.com.

A bientot,
--
Raphaël Maunier

Re: [FRnOG] 1 IP 2 modem

2011-06-30 Par sujet Greg VILLAIN 
Raahhh j'ai vu cette vidéo sur YouTube elle est abusée...
kr kr kr.
--
Greg - Sorry I lol'd.

On Jun 30, 2011, at 8:11 AM, SDL wrote:

> Bonsoir
> 
> Je suis de retour de déplacement. Et j'ai une question de curiosité d'ordre 
> technique. J'aimerais faire 2 réseaux l'un de données ( entreprise ) l'autre 
> multimédia ( TV, radio ). J'ai fait une tentative, mais j'ai fait sauter le 
> reseau. Je précise que j'ai 2 prise téléphonique . 
> 
> Merci de votre aide. 
> 
> Cordialement

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] 1 IP 2 modem

2011-06-30 Par sujet MM 
Cool, on est en WE ce soir !!!
(vendredi)

Le 30 juin 2011 à 17:11, SDL a écrit :

> Bonsoir
> 
> Je suis de retour de déplacement. Et j'ai une question de curiosité d'ordre 
> technique. J'aimerais faire 2 réseaux l'un de données ( entreprise ) l'autre 
> multimédia ( TV, radio ). J'ai fait une tentative, mais j'ai fait sauter le 
> reseau. Je précise que j'ai 2 prise téléphonique . 
> 
> Merci de votre aide. 
> 
> Cordialement

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] 1 IP 2 modem

2011-06-30 Par sujet SDL 
Bonsoir

Je suis de retour de déplacement. Et j'ai une question de curiosité d'ordre
technique. J'aimerais faire 2 réseaux l'un de données ( entreprise ) l'autre
multimédia ( TV, radio ). J'ai fait une tentative, mais j'ai fait sauter le
reseau. Je précise que j'ai 2 prise téléphonique .

Merci de votre aide.

Cordialement

Re: [FRnOG] Routeur Haute dispo IPv6

2011-06-30 Par sujet Ludovic BOUÉ 
Merci pour toutes ces possibilités.

Le 30/06/2011 15:31, Mathieu Goessens a écrit :
> On 22/05/2011 19:00, Pierre Emeriaud wrote:
>> Le 22 mai 2011 18:35, Olivier Benghozi
>>   a écrit :
>>> Pas forcément la peine de faire du FHRP "avancé" en IPv6: du RA avec
>>> un timing judicieusement paramétré sur les routeurs peut faire
>>> l'affaire, ce sont les hosts eux-mêmes qui changeront de route par
>>> défaut si le meilleur RA n'est plus reçu.
>>
>>
>> Dans son article
>> ,
>>
>> Jeremy stretch montre en effet qu'une bascule en 1seconde est possible
>> juste avec les RA, sans fhrp.
>
> Bonjour,
>
> Une autre méthode est également possible:
> - 2 routeurs qui émettent des RA avec des lifetime classiques
> - les hôte utilisent le neighboor discovery pour choisir le routeur:
> si le routeur est dans un état reachable il sera utilisé, sinon, c'est
> l'autre routeur qui sera pris.
>
> Il faut par contre changer sur tous les hôtes, les valeurs de
> configuration utilisés pour le neighboor discovery. Par défaut un hôte
> n'est plus joignable après 30 secondes:
> http://tools.ietf.org/html/rfc4861 , sections 6.3.1 et 10.
>
> Sous linux, un systcl net.ipv6.neigh.eth0.base_reachable_time_ms
> devrait faire le boulot.
>
> Cela évite le flood de RA et permet éventuellement une reprise de
> service plus rapide.
>
> Cdlt,
>

-- 
Ludovic BOUÉ

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Routeur Haute dispo IPv6

2011-06-30 Par sujet Mathieu Goessens 

On 22/05/2011 19:00, Pierre Emeriaud wrote:

Le 22 mai 2011 18:35, Olivier Benghozi
  a écrit :

Pas forcément la peine de faire du FHRP "avancé" en IPv6: du RA avec un timing 
judicieusement paramétré sur les routeurs peut faire l'affaire, ce sont les hosts 
eux-mêmes qui changeront de route par défaut si le meilleur RA n'est plus reçu.



Dans son article
,
Jeremy stretch montre en effet qu'une bascule en 1seconde est possible
juste avec les RA, sans fhrp.


Bonjour,

Une autre méthode est également possible:
- 2 routeurs qui émettent des RA avec des lifetime classiques
- les hôte utilisent le neighboor discovery pour choisir le routeur: si 
le routeur est dans un état reachable il sera utilisé, sinon, c'est 
l'autre routeur qui sera pris.


Il faut par contre changer sur tous les hôtes, les valeurs de 
configuration utilisés pour le neighboor discovery. Par défaut un hôte 
n'est plus joignable après 30 secondes: 
http://tools.ietf.org/html/rfc4861 , sections 6.3.1 et 10.


Sous linux, un systcl net.ipv6.neigh.eth0.base_reachable_time_ms devrait 
faire le boulot.


Cela évite le flood de RA et permet éventuellement une reprise de 
service plus rapide.


Cdlt,

--
Mathieu Goessens,
IRISA, Campus de Beaulieu, 35042 Rennes cedex, France
Tel: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Routeur Haute dispo IPv6

2011-06-30 Par sujet Guillaume Barrot 
Déployé sur le labo, sur 6500 / 12.2.33SXJ, la conf est un peu différente
mais fonctionne bien :

ipv6 unicast-routing
ipv6 cef
mls ipv6 vrf
# activation du support d'ipv6 / vrf

vrf definition INFRA
 rd 666:200
 route-target export 666:200
 route-target import 666:200
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family

interface Vlan301
 vrf forwarding INFRA
 ip address  
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ipv6 address /64
 ipv6 nd dad attempts 10
 ipv6 nd prefix default no-advertise
 ipv6 nd router-preference High
 ipv6 nd ra interval msec 500
 ipv6 nd ra lifetime 10

Temps de convergence observée : ~1sec
Sur un VSS, j'ai réduit les timers pour ne pas polluer avec des messages
inutiles, mais la mise en place de la gw/def se fait bien sur différents
types d'OS (Win2003 / 2008, Linux 2.6.x, Solaris 10).


Le 22 mai 2011 19:13, Olivier Benghozi  a
écrit :

> Pas forcément la peine de faire du FHRP "avancé" en IPv6: du RA avec un
> timing judicieusement paramétré sur les routeurs peut faire l'affaire, ce
> sont les hosts eux-mêmes qui changeront de route par défaut si le meilleur
> RA n'est plus reçu.
>
>
> Dans son article
> <
> http://packetlife.net/blog/2011/apr/18/ipv6-neighbor-discovery-high-availability/
> >,
> Jeremy stretch montre en effet qu'une bascule en 1seconde est possible
> juste avec les RA, sans fhrp.
>
>
> On n'est d'ailleurs pas obligé de faire du SLAAC (ce qui n'est probablement
> pas une bonne idée pour des serveurs); on peut configurer des IPv6 fixes, et
> balancer des RA n'advertisant aucun préfixe, juste pour traiter la route par
> défaut.
>
> Par exemple pour une interface Cisco, pour répliquer le timing par défaut
> du HSRP (10 secondes):
>  no ipv6 nd ra suppress
>  ipv6 nd advertisement-interval
>  ipv6 nd ra lifetime 10
>  ipv6 nd ra interval msec 3000
>  ipv6 nd router-preference high (pour le routeur actif par défaut)
>  ipv6 nd prefix default no-advertise
>
>
>


-- 
Cordialement,

Guillaume BARROT