On Thu, Jun 21, 2012 at 05:10:26PM +0200,
Laurent Cheylus f...@free.fr wrote
a message of 18 lines which said:
Revoir la RFC 2338 http://www.faqs.org/rfcs/rfc2338.html
Deux RFC de retard :-) La 2338 avait été remplacée par la 3768,
l'actuelle étant la 5798.
---
Le 25 juin 2012 à 14:00, Stephane Bortzmeyer a écrit :
Revoir la RFC 2338 http://www.faqs.org/rfcs/rfc2338.html
Deux RFC de retard :-) La 2338 avait été remplacée par la 3768,
l'actuelle étant la 5798.
Bon, enfin pas si en retard que ça, quand tu vois que la RFC 5798 est signée
par un gars
Stuck in ze process, c'est pas les mêmes équipes qui réfléchissent et qui
développent :D
Le 25 juin 2012 15:06, Olivier Benghozi olivier.bengh...@wifirst.fr a
écrit :
Le 25 juin 2012 à 14:00, Stephane Bortzmeyer a écrit :
Revoir la RFC 2338 http://www.faqs.org/rfcs/rfc2338.html
Deux RFC
❦ 21 juin 2012 17:18 CEST, Baptiste bed...@gmail.com :
L'IP virtuelle est associée à l'adresse MAC hébergeant l'interface et
est annoncées au switch et aux autres hosts sur le LAN via le
gratuitious.
C'est une spécificité de certaines implémentations (dont Keepalived)
quand il est difficile
Salut tout le monde,
J'ai une baie avec un transit IP sur un lien actif/passif moyennant
l'utilisation de 2 switchs + du HSRP, ça fonctionne bien, pas de souci.
J'aimerais sur cette infra pouvoir mettre en place du 2 HAproxy avec du VRRP
entre les deux.
Est-ce que la cohabitation des 2 normes
Salut,
Aucun souci pour faire cohabiter les deux.
HSRP utilise UDP (port 1935) alors que VRRP utilise le protocole IP 112.
Bien sur les deux utilisent du multicast.
Salim
Le 21/06/2012 11:36, Germain Maurice a écrit :
Salut tout le monde,
J'ai une baie avec un transit IP sur un lien
Marci, ça confirme bien ce que j'avais déduis en lisant les specs.
J'avais posé la question à mon hébergeur qui me conseillait de mettre en place
un VLAN. (ou alors j'ai mal compris sa réponse)
Bref, je vais pouvoir tester sans trop risquer de tout mettre en l'air.
Le 21 juin 2012 à 11:45, Salim
Le 21 juin 2012 à 12:27, Damien Fleuriot a écrit :
On 6/21/12 11:36 AM, Germain Maurice wrote:
Salut tout le monde,
J'ai une baie avec un transit IP sur un lien actif/passif moyennant
l'utilisation de 2 switchs + du HSRP, ça fonctionne bien, pas de souci.
J'aimerais sur cette infra
On 6/21/12 1:56 PM, Germain Maurice wrote:
Le 21 juin 2012 à 12:27, Damien Fleuriot a écrit :
On 6/21/12 11:36 AM, Germain Maurice wrote:
Salut tout le monde,
J'ai une baie avec un transit IP sur un lien actif/passif moyennant
l'utilisation de 2 switchs + du HSRP, ça fonctionne bien,
Tu fais du uCARP entre tes 2 HAP ?
Non, j'utilise ça :
http://www.exceliance.fr/fra/haproxy-edition-entreprise-hapee
Hmmm connaissais pas.
A titre d'information on est très contents de ucarp + haproxy ici
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Le 21 juin 2012 à 15:23, Thomas Mangin a écrit :
Tout marche bien tant que tes deux routers acceptent les packets gratuitous
arp des serveurs quand l'IP de service bouge.
De mémoire sur les équipements que j'ai vu, le default chez Juniper est
bloque, Cisco accepte. De plus l'option est
Bonjour,
On Thu, Jun 21, 2012 at 03:35:14PM +0100, Surya ARBY wrote:
Il n'y a pas de garp en VRRP / HSRP puisque ça utilise une mac
virtuelle.
Erreur, en utilisant VRRP, on envoye bien des gratuitous ARP lors du
choix d'un nouveau Master (entre autres).
Revoir la RFC 2338
L'IP virtuelle est associée à l'adresse MAC hébergeant l'interface et
est annoncées au switch et aux autres hosts sur le LAN via le
gratuitious.
a+
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Le seul moyen - a ma connaissance - de faire bouger une IP sans gratuitious ARP
est via la table de routage en changent le next-hop vers des IPs avec des ARP
différentes, puis en acceptant la paquet sur la machine hôte (avec l'IP sur
l'interface lo0 par exemple ou une règle sur le pare-feu).
Le
Bonjour,
L'IP virtuelle est associée à l'adresse MAC hébergeant l'interface et
La RFC dit exactement le contraire.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
La Mac virtuelle est là pour ça.
S'il y a des Garp éventuels c'est pour forcer la convergence L2 des
switchs adjacents et en aucun cas pour mettre à jour de force une
association IP/Mac puisque celle-ci ne change pas.
Que les équipements L3 adjacents interprêtent les Garp ou pas ne change
Hello,
Par contre, avec uCARP, point de vMAC. C'est la MAC native de
l'interface qui est utilisée, donc changement dans les tables ARP IP/MAC
des équipements L3 concernés.
J'ai fait mettre en place du uCARP, et finalement, je le regrette. C'est
super bien fait dans un contexte BSD (du vrai
Le 21/06/12 18:21, Baptiste Malguy a écrit :
J'ai fait mettre en place du uCARP,., mais c'est
pas terrible sur Linux
Bonsoir,
Même constat sur ucarp. Tout dépend comment meure la machine d'à côté.
Et c'est pas toujours proprement; du coup les bascules ne se font pas,
ou pas du tout
On 21 Jun 2012, at 21:49, Eric ROLLAND roll...@artefact.fr wrote:
Le 21/06/12 18:21, Baptiste Malguy a écrit :
J'ai fait mettre en place du uCARP,., mais c'est
pas terrible sur Linux
Bonsoir,
Même constat sur ucarp. Tout dépend comment meure la machine d'à côté.
Et c'est pas
Velu le troll ! Il a hiberné jusqu'en juin ? Parce que là, même pas
envie de relever ...
Le 21/06/12 23:10, Damien Fleuriot a écrit :
Sans troller, sérieux.
CARP sous freebsd, c'est géré direct niveau kernel, ça a rien à voir avec un
vieux ucarp moisi.
Mais bon voilà après faut savoir ce
Hello,
Le 22 juin 2012 à 00:10, Damien Fleuriot a écrit :
[...]
Sans troller, sérieux.
CARP sous freebsd, c'est géré direct niveau kernel, ça a rien à voir avec un
vieux ucarp moisi.
Mais bon voilà après faut savoir ce qu'on veut.
Après sous OpenBSD (créateur de Carp) y a relayd...
Après sous OpenBSD (créateur de Carp) y a relayd... Qui fait a peut-prêt ce
que fait HAproxy...
Trop gros, passera pas
Relayd face à LVS car niveau 3/4, et encore.
HAProxy est un reverse proxy avec pleins de fonctionnalités niveau 7
(HTTP notemment).
a+
---
22 matches
Mail list logo
