Re: Fwd: Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[Vincent Bernat]

 ❦ 21 juillet 2016 16:11 CEST, William VINCENT  :

> 16:00:50 root@ldaptest2 ~ >   tshark -i eno16777984 multicast
> Running as user "root" and group "root". This could be dangerous.
> Capturing on 'eno16777984'
>   1 0.0  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
>   2 10.001008912  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
>   3 20.002060373  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
>   4 30.002706144  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
>   5 40.003754734  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
>
>
> 16:00:52 root@ldaptest1:~ > tshark -i eno16777984 multicast
> Running as user "root" and group "root". This could be dangerous.
> Capturing on 'eno16777984'
>   1 0.0 ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
>   2 10.000906764  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
>   3 20.002005544  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
>   4 30.002651402  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
>   5 40.003705995  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
>
> étonnant d'avoir des requêtes du backup uniquement et avec deux
> résultats différents en fonction d'où on capture les trames

Le fait que seul le master envoie des requêtes est normal. La différence
de VRID ne l'est pas. Peut-être que l'inspection des adresses MAC
donnerait quelques billes.
-- 
He is now rising from affluence to poverty.
-- Mark Twain


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

Re: Fwd: Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[William VINCENT]

Alors effectivement j'ai lu quelque part que le virtual_router_id devait 
être différent mais ce n'est pas le cas, je retrouve bien désormais mon 
ip sur un nœud et le status backup sur l'autre


Mais le résultat est identique, la 4eme requête qui ne passe toujours pas.


16:00:50 root@ldaptest2 ~ >   tshark -i eno16777984 multicast
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eno16777984'
  1 0.0  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
  2 10.001008912  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
  3 20.002060373  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
  4 30.002706144  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
  5 40.003754734  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)


16:00:52 root@ldaptest1:~ > tshark -i eno16777984 multicast
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eno16777984'
  1 0.0 ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
  2 10.000906764  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
  3 20.002005544  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
  4 30.002651402  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
  5 40.003705995  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)

étonnant d'avoir des requêtes du backup uniquement et avec deux 
résultats différents en fonction d'où on capture les trames




Le 21/07/2016 à 15:23, Vincent Bernat a écrit :

  ❦ 21 juillet 2016 15:01 CEST, William VINCENT  :


Est ce que c'est normale que la VIP se mette sur les deux serveurs ?

Les deux keepalived ne se voient pas. Vérifie avec tcpdump sur
eno16777984 que tu vois bien les paquets multicast pour 224.0.0.18
(arriver et partir si les deux sont masters) ?



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

Re: Fwd: Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[Vincent Bernat]

 ❦ 21 juillet 2016 15:01 CEST, William VINCENT  :

> Est ce que c'est normale que la VIP se mette sur les deux serveurs ?

Les deux keepalived ne se voient pas. Vérifie avec tcpdump sur
eno16777984 que tu vois bien les paquets multicast pour 224.0.0.18
(arriver et partir si les deux sont masters) ?
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


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

Fwd: Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[William VINCENT]

 Message transféré 
Sujet : Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP
Date :  Thu, 21 Jul 2016 14:40:37 +0200
De :William VINCENT 
Organisation :  IRIT - Université Paul Sabatier
Pour :  Vincent Bernat 



Alors merci à tous,

Pour ce qui est du NAT, j'ai essayé de reprendre avec deux interfaces 
par machine pour faire un vrai routage mais pareil j'ai des pertes de 
paquets.


Je suis donc revenu sur le DR, dons sans NAT pas besoin de passer par 
les notify non ? Sinon j'avais déjà essayer de mettre la VIP sur 
l'interface lo mais c'est pareil. Je l'ai remise quand même.


Quand je fais un ldapsearch :

1er requête : ldap2

2eme requête : ldap1

3eme requête : ldap2

4eme requête : n'arrive pas à ldap1


Est ce que c'est normale que la VIP se mette sur les deux serveurs ?

logs ldap1 :

juil. 21 14:16:46 ldaptest1 Keepalived_vrrp[1354]: 
VRRP_Instance(VI-LDAP1) Transition to MASTER STATE
juil. 21 14:16:56 ldaptest1 Keepalived_vrrp[1354]: 
VRRP_Instance(VI-LDAP1) Entering MASTER STATE
juil. 21 14:16:56 ldaptest1 Keepalived_vrrp[1354]: 
VRRP_Instance(VI-LDAP1) setting protocol VIPs.
juil. 21 14:16:56 ldaptest1 Keepalived_vrrp[1354]: 
VRRP_Instance(VI-LDAP1) Sending gratuitous ARPs on eno16777984 for


logs ldap2 :

juil. 21 14:17:09 ldaptest2 Keepalived_vrrp[1355]: 
VRRP_Instance(VI-LDAP1) Transition to MASTER STATE
juil. 21 14:17:19 ldaptest2 Keepalived_vrrp[1355]: 
VRRP_Instance(VI-LDAP1) Entering MASTER STATE
juil. 21 14:17:19 ldaptest2 Keepalived_vrrp[1355]: 
VRRP_Instance(VI-LDAP1) setting protocol VIPs.
juil. 21 14:17:19 ldaptest2 Keepalived_vrrp[1355]: 
VRRP_Instance(VI-LDAP1) Sending gratuitous ARPs on eno16777984 for


Est ce normale que les deux passent en MASTER maintenant ? J'ai bien 
dans leur conf LDAP1 en master(priorité 100) et LDAP2 en backup 
(priorité 100), j'ai tenté d'inverser les priorités mais idem






Le 21/07/2016 à 13:45, Vincent Bernat a écrit :

  ❦ 21 juillet 2016 11:27 CEST, Vincent Bernat  :


Hum c'est encore pire, je passe à un taux d'erreur de 50%, le slave
répond aux requêtes au MASTER mais celui ci ne semble pas les
retransmettre au client.

Un taux d'erreur de 50% avec du rr, ça ressemble du coup beaucoup à un
problème sur l'un des deux frontaux. Genre, sa route par défaut ne
repasse pas par le LB. Maintenant que tout est symétrique, cela devrait
être assez simple de débugguer avec tcpdump.

Je n'avais pas bien lu le post d'origine. Je pensais que tu avais deux
LB séparés. Il faut bien garder DR dans ce cas.

Il faut de plus s'assurer que la VIP est présente de manière
inconditionnelle sur lo en /32 (en plus de eth0 en /24, gérée par
keepalived).


--
William VINCENT
Administrateur systèmes et réseaux
IRIT - UMR5505
Université Paul Sabatier
118 route de Narbonne
31062 TOULOUSE cedex 9

Tel : 05.61.55.69.38


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

Re: ***MAYBE-SPAM*** Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside

[Antoine Durant]

J'ai bien oublié de coller la routemap ! Merci pour ton retour Thibaut ;)
  De : GAGNAIRE Thibaut 
 À : Frnog-tech  
 Envoyé le : Jeudi 21 juillet 2016 13h18
 Objet : RE: ***MAYBE-SPAM*** Re: [FRnOG] [TECH] Comportement étrange avec ip 
nat inside
   
Il manque la route-map dans ton mail.


route-map NO_Private_SNAT permit 10

match ip address NO_Private_SNAT





Thibaut GAGNAIRE

Ingénieur Système et Reseaux



tgagna...@novenci.fr

www.idline.fr





[cid:image001.jpg@01D03BAF.8148ECA0]



De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Antoine Durant
Envoyé : jeudi 21 juillet 2016 13:07
À : Frnog-tech 
Objet : ***MAYBE-SPAM*** Re: [FRnOG] [TECH] Comportement étrange avec ip nat 
inside

Bonjour,

Bon... J'ai avancé et je sais quel est le problème mais je n'arrive pas à le 
résoudre... Cela est à cause du VPN :/
Par le VPN tout fonctionne sauf dès que je rajoute une règle ip nat Inside sur 
le site distant.

En gros hier j'étais à l'ouest complet croyant que le problème était ailleurs 
et pas en passant par le vpn.

Sur le site 1 (172.16.1.x) pas de soucis j'accède bien au serveur en lan 
interne même avec la regle ip nat
Le problème est depuis le site 2 (172.16.2.x) lorsque j'active la règle ip nat 
je ne peux pas utiliser le service web (172.16.1.33).

J'ai essayé de rajouter une regle comme ça sur le site 1 mais ça fonctionne pas 
mieux depuis le site 2 :

ip nat inside source static tcp 172.16.1.33 80 X.Y.Z.1 80 route-map RM1 
extendable

ip access-list extended RM1
 deny  ip 172.16.0.0 0.0.255.255 any
 permit ip any any


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


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

Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside

[Jérôme BERTHIER]

Salut,

Sans les confs difficiles d'être précis mais...

Le 21/07/2016 à 13:06, Antoine Durant a écrit :

Bonjour,
Bon... J'ai avancé et je sais quel est le problème mais je n'arrive pas à le 
résoudre... Cela est à cause du VPN :/Par le VPN tout fonctionne sauf dès que 
je rajoute une règle ip nat Inside sur le site distant.
Ton NAT sur site 2, c'est du PAT sur l'interface outside pour le trafic 
Web ?


Le VPN est traité par crypto map ou via interface VTI ?

Sauf erreur, avec des crypto map, le NAT in->out s'applique avant le 
tunneling :

http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/6209-5.html
=> tu dois exclure du NAT le trafic qui est sensé passer par le tunnel.

Tu le fais sur site 1 mais il faut aussi le faire sur site 2 je pense. 
Dans l'idée à minima :

ip access-list extended RM2
 deny   ip 172.16.2.0 0.0.0.255 172.16.1.0 0.0.0.255
 permit ip any any

A+


En gros hier j'étais à l'ouest complet croyant que le problème était ailleurs 
et pas en passant par le vpn.
Sur le site 1 (172.16.1.x) pas de soucis j'accède bien au serveur en lan 
interne même avec la regle ip natLe problème est depuis le site 2 (172.16.2.x) 
lorsque j'active la règle ip nat je ne peux pas utiliser le service web 
(172.16.1.33).
J'ai essayé de rajouter une regle comme ça sur le site 1 mais ça fonctionne pas 
mieux depuis le site 2 :
ip nat inside source static tcp 172.16.1.33 80 X.Y.Z.1 80 route-map RM1 
extendable
ip access-list extended RM1
  deny   ip 172.16.0.0 0.0.255.255 any
  permit ip any any


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



--
Jérôme BERTHIER


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

[FRnOG] [TECH] RFC 7920: Problem Statement for the Interface to the Routing System

[Stephane Bortzmeyer]

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



Auteur(s) du RFC: A. Atlas (Juniper), T. Nadeau
  (Brocade), D. Ward (Cisco)






Autrefois, la configuration des routeurs était relativement statique. 
On indiquait la politique de routage (le coût de tel ou tel lien, par 
exemple), les préfixes IP, les pairs BGP, parfois des routes statiques, 
et le routeur parlait avec ses copains routeurs, construisant ses 
tables qu'il allait ensuite utiliser pour la transmission des paquets. 
La configuration n'était pas modifiée tous les jours et quand c'était 
nécessaire, on se connectait à tous les routeurs qu'il fallait changer 
et on modifiait la config. Dans les organisations plus modernes, on 
édite la config, on la "commite" dans un VCS et on la "pushe" vers les 
routeurs avec Ansible ou un truc équivalent. Aujourd'hui, même cela ne 
suffit pas, on voudrait être plus agile. On voudrait modifier la 
configuration des routeurs à peu près en temps réel, pour répondre à 
des considérations de business (créer un nouveau service pour un 
client, profiter de variations de prix chez les transitaires...) ou à 
des problèmes de sécurité (déployer des filtres subtils). Cette 
exigence nécessite une interface vers le routeur, utilisable par des 
programmes. C'est le projet *I2RS*, "Interface To the Routing System". 
Ce premier RFC du groupe de travail  
décrit précisement le problème qu'on essaie de résoudre. (Notez que le 
"buzzword" SDN n'apparait pas une seule fois dans ce RFC...)

C'est que les réseaux modernes sont grands et complexes : il n'est plus 
possible de faire les choses à la main en se connectant sur chaque 
routeur isolément. Il faut donc automatiser, et il faut donc qu'un 
programme puisse se connecter aux routeurs et changer leurs 
configurations. Cela se fait bien sûr depuis longtemps (cf. Rancid et 
l'exposé de Joe Abley à NANOG 
 et 
l'annexe A de notre RFC qui liste les solutions existantes), mais, en 
l'absence d'interface normalisée, c'était assez pénible à programmer et 
maintenir. Il s'agit donc de standardiser ce qui existe déjà, ce qui ne 
devrait pas être une tâche insurmontable.

La terminologie utilisée par I2RS est décrite dans un autre RFC, le RFC 
7921. Pour le résumer (section 2 du RFC) : le routeur contient un 
*agent I2RS*, qui sait parler aux différents composants du routeur (sa 
base de données indiquant les différents liens connectés, son système 
de gestion de la configuration, sa base de routes - RIB, etc). Le 
logiciel qui pilote les changements est le *client I2RS*. Il y aura 
sans doute un seul client pour beaucoup d'agents, installé dans le 
système de gestion du réseau. Entre le client et l'agent, le protocole 
I2RS, qui sera normalisé dans les futurs RFC du groupe de travail I2RS 
. A priori, le client sera juste un 
intermédiaire pour des *applications* qui piloteront le routage (le but 
du découplage client/application étant d'éviter que chaque application 
doive parler I2RS : elles pourront interagir avec le client au dessus 
d'un protocole plus classique comme REST).

Pour que le client puisse parler intelligemment à l'agent, il devra 
avoir en tête un *modèle de données* décrivant le routeur, ce qu'il 
sait faire, ce qu'on peut lui demander.

La section 3 de notre RFC présente la nécessité de ce modèle de 
données. Un tel modèle avait déjà été développé pour le projet ForCES 
(RFC 3746), en se focalisant sur la transmission, alors que I2RS est 
surtout intéressé par le routage (le plan de contrôle, accès à la RIB, 
etc).

Comme le note la section 4, un logiciel qui voudrait vraiment donner 
des instructions au routeur devrait apprendre la topologie du réseau, 
quels sont les liens physiques ou virtuels auxquels le routeur est 
connecté, leur état, etc. C'est évidemment le routeur qui connait le 
mieux cette information et il est donc nécessaire de lui demander.

L'application aura souvent besoin de connaitre en outre le trafic 
réellement échangé. IPFIX (RFC 5470) est certainement utilisable pour 
cela, si l'application peut le configurer dynamiquement.

Enfin, la section 5 rassemble les « points divers ». Elle rappelle 
qu'I2RS n'impose pas forcément le développement d'un nouveau 
protocole ; si un protocole, ou un ensemble de protocoles existant(s) 
suffit, c'est parfait (l'annexe A du RFC propose des pistes en ce 
sens). Mais la solution doit penser à :
* Permettre des opérations asynchrones : pas question d'attendre la fin 
d'une opération avant de commencer la suivante.
* Bonne granularité des opérations ; si on veut changer la 
configuration pour *un* préfixe IP, il ne faut pas verrouiller tout le 
routeur.
* Possibilité que plusieurs clients parlent au routeur en même temps, 
avec le minimum de coordination entre eux.
* Débit maximum élevé ; 10 000 

Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside

[Antoine Durant]

David, j'ai droit au fouet oui oui... Hier je bricolais avec site1 et ca merdé 
grave ! 
J'ai tout rebranché correctement sur un joli switch des deux côtés avec maj ios 
+ formatage de la config et c'est là... non pas la tête que j'ai vu "arf ya oun 
vpn"
Bon je pense que la bonne route map doit être :
ip access-list extended RM1
deny  ip 172.16.1.0 0.0.255.255 anydeny  ip 172.16.2.0 0.0.255.255 any
permit ip any any

  De : David Ponzone 
 À : Antoine Durant  
Cc : Frnog-tech 
 Envoyé le : Jeudi 21 juillet 2016 13h17
 Objet : Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside
   
Euh à quel moment tu as pensé que ma question « est-ce qu’il y a une 
subtilité/un détail sur la conf que tu n’omets pas de nous donner ? »  n’était 
pas concerné par un VPN ? :)


> Le 21 juil. 2016 à 13:06, Antoine Durant  a écrit :
> 
> Bonjour,
> Bon... J'ai avancé et je sais quel est le problème mais je n'arrive pas à le 
> résoudre... Cela est à cause du VPN :/Par le VPN tout fonctionne sauf dès que 
> je rajoute une règle ip nat Inside sur le site distant.
> En gros hier j'étais à l'ouest complet croyant que le problème était ailleurs 
> et pas en passant par le vpn.
> Sur le site 1 (172.16.1.x) pas de soucis j'accède bien au serveur en lan 
> interne même avec la regle ip natLe problème est depuis le site 2 
> (172.16.2.x) lorsque j'active la règle ip nat je ne peux pas utiliser le 
> service web (172.16.1.33).
> J'ai essayé de rajouter une regle comme ça sur le site 1 mais ça fonctionne 
> pas mieux depuis le site 2 :
> ip nat inside source static tcp 172.16.1.33 80 X.Y.Z.1 80 route-map RM1 
> extendable
> ip access-list extended RM1
>  deny  ip 172.16.0.0 0.0.255.255 any
>  permit ip any any
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

RE: ***MAYBE-SPAM*** Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside

[GAGNAIRE Thibaut]

Il manque la route-map dans ton mail.


route-map NO_Private_SNAT permit 10

match ip address NO_Private_SNAT





Thibaut GAGNAIRE

Ingénieur Système et Reseaux



tgagna...@novenci.fr

www.idline.fr





[cid:image001.jpg@01D03BAF.8148ECA0]



De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Antoine Durant
Envoyé : jeudi 21 juillet 2016 13:07
À : Frnog-tech 
Objet : ***MAYBE-SPAM*** Re: [FRnOG] [TECH] Comportement étrange avec ip nat 
inside

Bonjour,

Bon... J'ai avancé et je sais quel est le problème mais je n'arrive pas à le 
résoudre... Cela est à cause du VPN :/
Par le VPN tout fonctionne sauf dès que je rajoute une règle ip nat Inside sur 
le site distant.

En gros hier j'étais à l'ouest complet croyant que le problème était ailleurs 
et pas en passant par le vpn.

Sur le site 1 (172.16.1.x) pas de soucis j'accède bien au serveur en lan 
interne même avec la regle ip nat
Le problème est depuis le site 2 (172.16.2.x) lorsque j'active la règle ip nat 
je ne peux pas utiliser le service web (172.16.1.33).

J'ai essayé de rajouter une regle comme ça sur le site 1 mais ça fonctionne pas 
mieux depuis le site 2 :

ip nat inside source static tcp 172.16.1.33 80 X.Y.Z.1 80 route-map RM1 
extendable

ip access-list extended RM1
 deny   ip 172.16.0.0 0.0.255.255 any
 permit ip any any


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

Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside

[David Ponzone]

Euh à quel moment tu as pensé que ma question « est-ce qu’il y a une 
subtilité/un détail sur la conf que tu n’omets pas de nous donner ? »  n’était 
pas concerné par un VPN ? :)


> Le 21 juil. 2016 à 13:06, Antoine Durant  a écrit :
> 
> Bonjour,
> Bon... J'ai avancé et je sais quel est le problème mais je n'arrive pas à le 
> résoudre... Cela est à cause du VPN :/Par le VPN tout fonctionne sauf dès que 
> je rajoute une règle ip nat Inside sur le site distant.
> En gros hier j'étais à l'ouest complet croyant que le problème était ailleurs 
> et pas en passant par le vpn.
> Sur le site 1 (172.16.1.x) pas de soucis j'accède bien au serveur en lan 
> interne même avec la regle ip natLe problème est depuis le site 2 
> (172.16.2.x) lorsque j'active la règle ip nat je ne peux pas utiliser le 
> service web (172.16.1.33).
> J'ai essayé de rajouter une regle comme ça sur le site 1 mais ça fonctionne 
> pas mieux depuis le site 2 :
> ip nat inside source static tcp 172.16.1.33 80 X.Y.Z.1 80 route-map RM1 
> extendable
> ip access-list extended RM1
>  deny   ip 172.16.0.0 0.0.255.255 any
>  permit ip any any
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside

[Antoine Durant]

Bonjour,
Bon... J'ai avancé et je sais quel est le problème mais je n'arrive pas à le 
résoudre... Cela est à cause du VPN :/Par le VPN tout fonctionne sauf dès que 
je rajoute une règle ip nat Inside sur le site distant.
En gros hier j'étais à l'ouest complet croyant que le problème était ailleurs 
et pas en passant par le vpn.
Sur le site 1 (172.16.1.x) pas de soucis j'accède bien au serveur en lan 
interne même avec la regle ip natLe problème est depuis le site 2 (172.16.2.x) 
lorsque j'active la règle ip nat je ne peux pas utiliser le service web 
(172.16.1.33).
J'ai essayé de rajouter une regle comme ça sur le site 1 mais ça fonctionne pas 
mieux depuis le site 2 :
ip nat inside source static tcp 172.16.1.33 80 X.Y.Z.1 80 route-map RM1 
extendable
ip access-list extended RM1
 deny   ip 172.16.0.0 0.0.255.255 any
 permit ip any any


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

Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[julien soula]

On Thu, Jul 21, 2016 at 11:47:16AM +0200, Richard DEMONGEOT wrote:
> Hello,

salut,

> 
> Ça ressemble à un cas vecu; est-ce que la partie loader balancing est 
> identique sur tes deux serveurs?
> 
> Dans la positive, tu a le lb1 qui loader balance :
> - 50% du trafic sur lui; (Trafic ok)
> - 50% du trafic sur son copain. (Blague)
> 
> Le lb2 recherche loadbalance :
> - 50% sur lui (donc 25% du trafic originel :ok)
> - 50% sur son copain (erreur). En effet, cette partie là est flaguee par les 
> deux lb comme étant à traiter par l'autre, donc boucle et trafic perdu.
> 
> Pour corriger, sur le lb2 il suffit de ne pas configurer la note 1 dans les 
> slaves. 

pour eviter de trop differencier les fichiers de config et pour que
les backups puissent devenir master en cas de defaillance, on a adopte
une autre strategie.

Sur les backups, on a la regle "iptables -t nat -A PREROUTING -s
0.0.0.0/0 -d  -j REDIRECT". Ca permet de transformer l'IP
destination en celle du noeud lui-meme et donc d'eviter le lb.

Pour creer et supprimer la regle en fonction de l'etat maitre/escalve,
on utilise les parametres notify_master, notify_backup, notify_fault.

a+,
-- 
Julien
<< Vous n'avez rien a dire... Parlons-en! >>


signature.asc
Description: PGP signature

Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[Richard DEMONGEOT]

Hello,

Ça ressemble à un cas vecu; est-ce que la partie loader balancing est identique 
sur tes deux serveurs?

Dans la positive, tu a le lb1 qui loader balance :
- 50% du trafic sur lui; (Trafic ok)
- 50% du trafic sur son copain. (Blague)

Le lb2 recherche loadbalance :
- 50% sur lui (donc 25% du trafic originel :ok)
- 50% sur son copain (erreur). En effet, cette partie là est flaguee par les 
deux lb comme étant à traiter par l'autre, donc boucle et trafic perdu.

Pour corriger, sur le lb2 il suffit de ne pas configurer la note 1 dans les 
slaves. 

Cordialement,


Le 21 juillet 2016 11:27:31 GMT+02:00, Vincent Bernat  a écrit 
:
>❦ 21 juillet 2016 10:00 CEST, William VINCENT
> :
>
>> Hum c'est encore pire, je passe à un taux d'erreur de 50%, le slave
>> répond aux requêtes au MASTER mais celui ci ne semble pas les
>> retransmettre au client.
>
>Un taux d'erreur de 50% avec du rr, ça ressemble du coup beaucoup à un
>problème sur l'un des deux frontaux. Genre, sa route par défaut ne
>repasse pas par le LB. Maintenant que tout est symétrique, cela devrait
>être assez simple de débugguer avec tcpdump.
>
>> Mais si on passe par du NAT, du coup ça ne créerait pas une surcharge
>> du MASTER ? Ou est-ce vraiment négligeable ?
>
>En IPVS, tu peux t'attendre à 100k nouvelles transactions par seconde
>par cœur ou 500k paquets/s par cœur en régime établi sur un banal
>Xeon. Le LDAP va sans doute flancher avant.
>-- 
>It is often the case that the man who can't tell a lie thinks he is the
>best
>judge of one.
>   -- Mark Twain, "Pudd'nhead Wilson's Calendar"
>
>
>---
>Liste de diffusion du FRnOG
>http://www.frnog.org/

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[Vincent Bernat]

 ❦ 21 juillet 2016 10:00 CEST, William VINCENT  :

> Hum c'est encore pire, je passe à un taux d'erreur de 50%, le slave
> répond aux requêtes au MASTER mais celui ci ne semble pas les
> retransmettre au client.

Un taux d'erreur de 50% avec du rr, ça ressemble du coup beaucoup à un
problème sur l'un des deux frontaux. Genre, sa route par défaut ne
repasse pas par le LB. Maintenant que tout est symétrique, cela devrait
être assez simple de débugguer avec tcpdump.

> Mais si on passe par du NAT, du coup ça ne créerait pas une surcharge
> du MASTER ? Ou est-ce vraiment négligeable ?

En IPVS, tu peux t'attendre à 100k nouvelles transactions par seconde
par cœur ou 500k paquets/s par cœur en régime établi sur un banal
Xeon. Le LDAP va sans doute flancher avant.
-- 
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


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

[FRnOG] [BIZ] Offre de Présélection sur réseau anciennement VZB

[sebastien . lesimple]

Hello Chers tous!

Pour celles et ceux qui ont encore quelques client Présélection et/ou 
qui cherchez une solution de replis à Completel/SFR en attendant de 
migrer vers autres choses;
Verizon a cédé son activité de Wholesale Voix à Viatel, qui m'en a 
confié la gestion en France.


Dans l'immédiat, nous serons en mesure de fournir de la présélection et 
du Trunck SIP en OTT ou en direct chez TH2.
Les autres services seront déployés progressivement cette année en 
fonction des besoins clients.


Les choses vont se structurer dans les prochaines semaines mais pour 
celles et ceux qui ont dors et déjà des questions, vous pouvez me 
contacter en privé à cette adresse (mon adresse mail Viatel devrait etre 
disponible dans les prochains jours).


Cdt,
Sébastien LESIMPLE
0662068369



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

Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[Vincent Bernat]

 ❦ 21 juillet 2016 09:24 CEST, William VINCENT  :

>   lb_algo rr
>   lb_kind DR

Pour du LDAP, c'est un peu luxueux de faire du DR. Que se passe-t'il
avec lb_kind NAT ?
-- 
I dote on his very absence.
-- William Shakespeare, "The Merchant of Venice"


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

[FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[William VINCENT]

Bonjour à tous

Premier message sur la liste, je viens vers vous pour un problème de 
load balancing avec Keepalived. Dès que je commence à charger légèrement 
le cluster, j'ai des pertes de paquets  (time out).



Je suis sur la configuration suivante : Deux serveurs openldap, qui ont 
eux même leur keepalived, la partie failover fonctionne correctement.


Avec Wireshark sur le client, j'ai des paquets en erreur de type ' TCP 
ACKed unseen segment' et 'TCP Previous segment not captured'.


Lors de mes essais avec Jmeter, les résultats des tests sont toujours 
identiques,


- Pour 10 utilisateurs et 10 boucles, j'ai les 12 premières 
requêtes sans erreurs et après certaines qui passent pas. Pour 100 
échantillons, j'ai 25% de taux d'erreur.


- Pour 1 utilisateur et 10 boucles, j'ai les 2 premières requêtes 
sans erreurs et après certaines qui passent pas. Pour 10 échantillons, 
j'ai 20% de taux d'erreur.



Pour info, le problème ce fait aussi lorsque j'envoie des requêtes 
ldapsearch depuis mon shell.


Dans les logs des nœuds, je vois bien les requêtes passer sur mes deux 
serveurs openldap.



Voici ma configuration, j'ai désactivé la partie auth et ldaps 636 pour 
limiter le nombre de problèmes durant mes tests:



vrrp_instance VI-LDAP1 {
  state MASTER #noeud2 :BACKUP
  virtual_router_id 25
  priority 150 #noeud2 :100
  interface eno16777984
  protocol TCP
  virtual_ipaddress {
ip.ldap/24 brd masq.ldap.255 dev eno16777984
  }
  smtp_alert
  advert_int 100
}

virtual_server ip.ldap 389 {
  delay_loop 100
  lb_algo rr
  lb_kind DR
  protocol TCP

real_server ip.ldap.1 389 {
weight 1
MISC_CHECK {
misc_path "/etc/keepalived/script_check_ldap.sh ip.ldap.1"
}
}
real_server ip.ldap.2 389 {
weight 1
MISC_CHECK {
misc_path "/etc/keepalived/script_check_ldap.sh ip.ldap.2"
}
}
}


Ayant douté de la partie MISC_CHECK (mon script est une simple requête 
ldap) , j'ai tenté un TCP_CHECK sur le port 389 mais le résultat était 
le même.



J'ai mis les paramètres systèmes suivant
net.ipv4.ip_forward=1 # certain conseil à 0, mais résultat identique, de 
toute façon s'il y a bien du routage de paquet je pense qu'il faut 
l'activer

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.eno16777984.arp_ignore=1
net.ipv4.conf.eno16777984.arp_announce=2
net.ipv4.conf.lo.arp_ignore=1
net.ipv4.conf.lo.arp_announce=2


Merci d'avance

--
William VINCENT


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

RE: ***MAYBE-SPAM*** Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside

[GAGNAIRE Thibaut]

Salut,

Essaye en mettant un route-map pour empêcher le NAT venant des IP RFC1918 (ce 
qu'on fait lorsqu'il y a des tunnels IPSEC sur l'interface externe):

ip access-list extended NO_Private_SNAT
 deny   ip 192.168.0.0 0.0.255.255 any
 deny   ip 172.16.0.0 0.15.255.255 any
 deny   ip 10.0.0.0 0.255.255.255 any
 permit ip any any

route-map NO_Private_SNAT permit 10
 match ip address NO_Private_SNAT

ip nat inside source static tcp x.x.x.x 3389 x.x.x.x 3394 route-map 
NO_Private_SNAT extendable



Thibaut GAGNAIRE
Ingénieur Système et Reseaux


tgagna...@novenci.fr
www.idline.fr








-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Eric Mognat
Envoyé : jeudi 21 juillet 2016 07:42
À : Frnog-tech 
Objet : ***MAYBE-SPAM*** Re: [FRnOG] [TECH] Comportement étrange avec ip nat 
inside

Salut,

deux tests a faire :
--> règles désactivées, accès port 80 puis arp -a même chose règles 
--> activées
contrôle que la mac est la bonne.

A+

Le 20 juillet 2016 à 18:14, Michel Py
 a écrit :
>> Antoine Durant a écrit :
>> [..]
>
> En plus, quelque chose qui marche avec la même syntaxe sur plein de bécanes, 
> Windows et Unix :
>
> "netstat -r"  ??
>
> Le tech support sur la liste du FRnOG, c'est gratuit sauf quand David 
> et Michel commencent à vendre des tickets :P Philippe Bourcier, ne 
> t'inquiètes pas. Tes 15% font partie des tickets.
>
>
> Michel.
>
> David, 50/50 moins les frais et ce qu'on donne à Philippe ?
> Philippe, quand c'est pas trolldi on te donne 20% au lieu de 15% ?
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

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