[FRnOG] Re: [FRnOG] Re: [FRnOG] Questionnement d 'un administrateur système sur l'IPv6
Le 13 déc. 2010 à 21:46, Rémy Sanchez a écrit : > Tu passes ton réseau en IPv6 pur, sans IPv4. Pour ce qui est du > load-balancing HTTP, tu fais faire ça au proxy C'est une très bonne solution ça ! (Ou en tout cas bien plus applicable dans mon cas que des adresses PI + BGP) > Pour les autres applications, > soit tu considères qu'elles n'ont pas besoin de load-balancing, soit tu > les répartis équitablement Les répartir, équitablement tu penses, à quelle méthode ? Gérer "à la main" les routes par défauts des clients ? Une solution plus intéressante peut-être ?
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Questionnement d 'un administrateur système sur l'IPv6
On 12/12/2010 10:14 PM, Jérôme Nicolle wrote: > Le 12/12/10 21:07, Thomas Mangin a écrit : >> http://vh-net.fr/blog/ > > Cette solution marche quand tu as deux lignes aux carracteristiques très > proches (débit et latence). Sinon, le débit cumulé sera le nombre de > lignes * la vitesse de la plus lente, et une différence de latence > importante créera une jigue énorme. Je confirme, vu que les débits sont complètement différents sur chaque ligne (2 ADSL avec une atténuation différente et 1 SDSL), déjà quand on fait du routage en round-robin sur les 3 ça ralenti tout, alors j'veux même pas imaginer avec ce genre de solution... >> Ce n'est pas la bande passante qui va faire mal, c'est la limite sure le >> nombre de packet par seconde que le DSLAM donne a chaque ligne. >> Car plus de machines veut dire plus de requetes DNS et autres, cela compte >> rapidement pour beaucoup ... > > Il y a un resolver avec cache et un proxy en local, justement pour > limiter la casse à ce niveau. J'allais le dire :) On est pas fou non plus, et puis ça tourne comme ça depuis 5 ans... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] Re: [FRnOG] Questionnement d 'un administrateur système sur l'IPv6
Le 12 déc. 2010 à 20:54, Pierre Lagoutte a écrit : > Bonsoir à tous. > J'hallucine franchement que le cas (trivial) cité par Yohann suscite suscite > un thread aussi lourd (ce cas n'aurait-il pas été prévu ?) > En tout ca la question est visiblement TRES bonne. > Quand un flux sortant utilise un préfixe local ( fe80:: - c'est le plus > simple: pourquoi connaîtrait-il la part publique de son adresse v6) sur son > adresse source, le routeur de bordure (après sélection - load balancing - de > l'interface WAN de sortie) ne peut-il pas lui substituer le préfixe public de > cette interface ? plutôt que d'asséner la non-routabilité native de ce flux > sur l'Internet. > ... je sais c'est du NAT, et donc quelque part Kriminel pour la communauté v6. > mais ce serait tellement simple et transparent. > Pierre > > noter que les "A6 records" du bind9 des DNS avaient été construits pour > dissocier la part privative de la part publique des adresses v6, mais ils > n'ont eu qu'un succès (même académique) super-limité. En soi, le fait que l'on puisse à priori se passer du NAT me semble une bonne chose, surtout pour certains services. Mais j'avoue ne pas comprendre comment gérer simplement le multiWAN dans l'histoire. Même avec les éléments de réponses apportés je me vois mal gérer des blocs PI + BGP pour des entreprises de moins de 10 personnes qui ont deux pauvres ADSL. Or elles ont le besoin du multiWAN… Actuellement on rencontre un vrai problème de fiabilité de la connexion chez les clients qui ne peuvent pas dépasser la centaine d'euros par mois de frais de connexion.
[FRnOG] Re: [FRnOG] Re: [FRnOG] Questionnement d' un administrateur système sur l'IPv6
Le 12/12/10 18:48, Mathieu Goessens a écrit : > Tu as un lien ? De ce que j'ai vu, ça n'est ni normalisé, ni implémenté > (et pas forcément évident que ça le soit un jour). http://nat66.sourceforge.net/ J'ai pas testé, ça a l'air de marcher pour les conchoncetés de base. C'est inspiré de ça : http://www.ietf.org/proceedings/74/slides/6ai-3.pdf Qui évoque le draft le plus avancé de quand j'avais regardé, ya 3-4 mois. Techniquement pour faire du loadbalancing sur des liens de base, ce serait adapté. -- Jérôme Nicolle 06 19 31 27 14 signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Questionnement d 'un administrateur système sur l'IPv6
Le 12 déc. 2010 à 19:07, Mathieu Goessens a écrit : > On 12/12/2010 18:55, Yoann Gini wrote: >> >> Le 12 déc. 2010 à 17:44, Thomas Mangin a écrit : >>> Il n'est jamais announce. >> >> D'après les liens cités précédemment, il est possible de le générer et de >> l'enregistrer sur une base commune. Comment est-il configuré sur les postes >> s'il n'est pas annoncé ? (cf http://www.sixxs.net/tools/grh/ula/ ) >> >> Encore désolé avec mes questions de débutant sur le sujet, si vous avez une >> documentation "L'IPv6 pour les admin système" je suis preneur :-) >> > > Il y a un quiproquo de vocabulaire: > Annoncé = annoncé sur internet, donc routable etc. Les ULAs ne sont pas > routables (car elles sont destinées à un usage local uniquement). Donc > pas elles ne sont pas annoncées. > > La base commune n'est là que pour se prémunir d'éventuelles collisions > (même si peu probable, si le préfixe choisi est vraiment aléatoire). OK effectivement j'avais un problème de vocabulaire ici ! > Si tu parles de l'allocation des adresses locales, radv ou dhcpv6 feront > très bien le boulot :). Oki je comprend mieux l'histoire. J'ai la possibilité de gérer l'adresse local via un DHCP ou une autoconfig qui utilisera le préfixe fourni par radv. De la même manière, radv ou dhcpv6 peuvent en même temps gérer l'adresse globale ? Bien évidement je n'utilise que du DNS en interne, jamais d'IP ! C'est surtout pour savoir s'il y a un moyen de rendre le changement de préfixe transparent pour le DNS interne. Bien que ça n'arrive pas souvent et qu'il n'y a généralement pas beaucoup d'entrée dans le DNS, j'essaye toujours de prendre la solution qui nécessite le moins d'action de ma part :-) >>> >>> Tu peux utiliser les adresses de link-local - pour ca cela fait tres bien >>> l'affaire tant que rien n'est route. >> >> Est-ce que l'adresse de link local peut être fournie par DHCP ou être >> assignée en statique ? >> > > Non, elle est construite à partir de l'adresse MAC et configurée > automatiquement. En fait je parlais de l'adresse local et non du lien local, tu as répondu à ma question au dessus au final :-) > Pour plus d'infos, voir: http://livre.g6.asso.fr/index.php/Main_Page Je vais commencer par là ! Merci pour vos réponses !--- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Questionnement d' un administrateur système sur l'IPv6
On 12/12/2010 14:37, Jérôme Nicolle wrote: > Il est _possible_ de natter, en l'occurrence en NAT66 1:1, mais c'est > pas recommandé. Le dualstack est aussi possible, et souhaitable, car bon > nombre d'applications métier développées sous OS X on une gestion du > réseau absolument catastrophiques et ne passent pas en v6 (typiquement > les serveurs de licence Quark ou de vielles versions de 4D) > Tu as un lien ? De ce que j'ai vu, ça n'est ni normalisé, ni implémenté (et pas forcément évident que ça le soit un jour). -- Mathieu Goessens IT consultant. geb...@poolp.org + 33 6 07 91 54 87 http://gebura.eu.org --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Questionnement d 'un administrateur système sur l'IPv6
Merci pour vos réponses rapides ! Mes questions résultantes à chaque mail dans la suite. >> Pour un premier message sur cette liste je vais commencer par me présenter >> brièvement, je suis Yoann Gini, formateur et consultant Apple sur tout ce >> qui concerne Mac OS X et Mac OS X Server en entreprise ainsi que Xsan (donc >> consutling pour clients finaux et formations pour les certifs [inutile de >> relancer le débat sur les certifications]). > > Hmmm, vu la position d'Apple sur les produits serveurs, bon courage pour > la suite ;) Je fais de l'OS X Server car ça me permet de passer plus de temps sur les problématiques métier des entreprises (1h/1h30 de l'installation à la connexion des utilisateurs sur les principaux services, c'est confortable). Après s'ils continuent dans cette direction ce n’est pas un problème, un Mac n'est qu'un UNIX, je prendrais juste un jour de plus pour installer un BSD en tant que serveur pour la gestion des clients >> Ma première question concerne l'attitude à adopter quant à son utilisation >> de manière pérenne. Prenons un exemple avec mon client "type", à savoir du >> double WAN avec IP public fixe pour les deux liens Internet. Le routeur >> s'occupe de faire de la répartition de charge et un peu de QoS pour être >> certain que les services du type téléphonie ou services essentiels des >> serveurs passent dans tous les cas. > > Tu as deux types d'agrégation : les load balancers de niveau 5 à 7, qui > sont des bidouilles infâmes, et les vrais agrégations qui sont > transparentes (niveau 2 ou 3), ou tu as une plage d'adresse pour les > deux liens. Auriez-vous des liens à me recommander à ce sujet ? Concernant des produits de ce type et surtout la manière de les utiliser ? >> En stateless les 64 derniers bits sont créés à partir de l'@MAC, est-ce >> qu'on a moyen de jouer avec ça ? >> Il me semblait avoir lu qu'une IPv6 incomplète est recomposée à partir du >> préfixe actuel, est-ce le cas ? >> Est-il préférable de maintenir un IPv4 interne pour ne pas devenir fou ? >> (please pas ça) >> Va-t-il falloir revenir au NAT ? (please encore moins celle-là) > > Il est _possible_ de natter, en l'occurrence en NAT66 1:1, mais c'est > pas recommandé. Le dualstack est aussi possible, et souhaitable, car bon > nombre d'applications métier développées sous OS X on une gestion du > réseau absolument catastrophiques et ne passent pas en v6 (typiquement > les serveurs de licence Quark ou de vielles versions de 4D) Ouais, ça, je connais… Et pourtant il y a de très bonnes docs développeur fournies par Apple à ce niveau (je fais aussi du dev Mac à mes heures) Par contre vous n'êtes pas d'accord avec Rémy ç ce sujet : >> Est-il préférable de maintenir un IPv4 interne pour ne pas devenir fou ? >> (please pas ça) > > J'aurais tendance à dire qu'il serait préférable de ne pas mettre d'IPv4 > du tout dans le réseau et de maintenir la connectivité IPv4 avec du > NAT64/DNS64, m'enfin ça c'est du gros extrémisme qui ne marche pas dans > tous les cas. Abstraction faite des problèmes de logiciel interne, n'est-il pas mieux de faire du NAT64 en sortie de réseau plutôt que de gérer le dualstack sur les clients ? >> - Dans le cas plus spécifique du multiWAN. Comment est-il possible de gérer >> la répartition de charge sans faire de NAT ? > > Soit avec une vraie agrégation, soit en NAT66. Pas d'autre alternative, > puisque c'est une bidouille crade. Qu'est-ce que tu appelles une vraie agrégation ? (Ici se font sentir mes lacunes sur le réseau pur) > Si j'ai bien une préco dans ce genre de cas : dégager les load balancers > à pas cher, et prendre plutôt un vrai FAI. Oui, c'est pas le même budget > : de deux forfaits à 30€ tu passera probablement à un récurent mensuel > de plusieurs centaines d'euros. Mais si l'objectif est d'avoir un réseau > propre, c'est un passage obligatoire. Sur les clients auxquels je pense c'est plus ou moins le cas, fibre chez Completel (on fait ce qu'on peut) ou Orange dans le meilleur des cas et une ADSL au cas où. Dans ces cas-là, l'ADSL n'est qu'en failover, mais la problématique reste la même. > Une fois que le lien est propre, il te faut un routeur assumant les > services LAN. DHCP (v4 et v6), DNS et firewalling ne peuvent être gérés > avec assez de souplesse par un Mac OS X server sans mettre les mains > dans le camboui au point d'en faire une boite noire ressemblant plus à > FreeBSD. Ça, c'est mon affaire :-) Effectivement la GUI d'administration d'OS X Server est extrêmement limité, mais pas le service web qui permet son fonctionnement, il y a une étape intermédiaire avant de retomber sur FreeBSD Quoi qu'il en soit, il n'y a que le DNS que je gère réellement sur OS X Server, le firewall et le DHCP sont faits par les routeurs la plus part du temps. > Ensuite ton adresse locale est composée d'un préfixe pseudo unique (tu > peux le générer et le répertorier là par exemple : > http://www.sixxs.net/tools/grh/ula/ ). Ce préfi
