[FRnOG] [TECH] Compatibilité MPLS entre Juniper - Cisco

[Marc SALVI]

Bonjour,

J'ai quelques interrogations sur la compatibilité MPLS entre les
équipements Cisco-Juniper
Nous nous apprêtons à construire un réseau qui sera a priori constitué de:

- Routeurs d’agrégation client/LNS: Cisco Serie 1000
- Routeurs de cœur de réseau BB: Juniper MX80

Tout cela doit pouvoir faire du 10Giga

Dans cette architecture, nous souhaiterons fournir des VPN MPLS/BGP
(layer3) de Cisco à Cisco via Juniper.
Avez vous un feedback sur la compatibilité MPLS entre ces équipements.
J'imagine qu'en 2014, la question ne doit plus se poser, mais avant
d'investir, j'aimerais en etre sur !

Sinon, à votre avis, quel équipement cisco serait l'équivalent du MX80.

merci de vos expériences.
Marc

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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Pierre-Yves Maunier]

Le 28 août 2014 18:56, David Ponzone  a écrit :

>
> Le 28 août 2014 à 18:47, Pierre-Yves Maunier 
> a écrit :
> >
> > VRRP :
> > - les 2 routeurs doivent avoir leur pate vers le serveurs dans le même
> L2 donc probablement vers un switch qui peut faire SPOF (sauf si c'est un
> chassais)
>
> Doit y avoir un moyen de mettre 2 switchs en stack et de connecter le
> serveur en LAG, un lien sur chaque switch.
> Est-ce que les hyperviseurs supportent LAG, c’est peut-être là que ça
> bloque.
>

J'ai ça en prod :
2xEX3300 en v-chassis, des serveurs avec un LAG LACP 4x1G : 2G vers un
membre, 2G vers un autre : "Ca juste marche" ™ Pas besoin d'ECMP, le
serveur a une seule interface de 4 Gbits/s



>
> > ECMP :
> > - le serveur a 2 interfaces et 2 intercos L3 ; une vers chaque routeur
> (/30 ou /31). L'ECMP te permettra de load balancer et de pousser plus que
> la capa d'une seule interface. Ce que ne te permet pas VRRP sans
> bidouillage (genre 2 IP VRRP avec la machine ayant 2 default gw).
>
> Ok on est bien d’accord, mais on retombe sur un autre problème en IPv4,
> c’est un sacré gâchis d’IP!
> ECMP est supporté sur tous les OS et hyperviseurs du marché ?
>

Pas obligé, tu peux prendre des IP RFC1918 en interco et router du publique
dessus, c'est moche mais "Ca juste marche" ™
Tu prends un linux, tu lui mets 2 default gw et hop ça fait de l'ECMP, le
truc c'est qu'il faut des scripts pour retirer la default quand l'interface
physique tombe sinon tu blackhole la moitié de ton trafic et ça c'est pas
rigolo.



>
> > Mais pour du pure fail over, faire de l'ECMP évite d'avoir un étage L2
> entre tes routeurs.
>
> Tu veux dire que tu connectes ton serveur en direct sur le routeur ? Au
> niveau coût et « scalability », c’est pas l’idéal.
> Il me semblait que la problématique était de connecter un gros paquet de
> serveurs en évitant les problèmes de ARP.
>
>
Mes serveurs de streaming live peuvent pousser sans soucis 10 Gbits/s sur
une seule interface, autant les connecter sur le routeur ça m'évite de
transporter le traf sur x équipements d'agrégation et donc de consommer
cette capa sur plusieurs endroits. C'est un use case spécifique à mes
besoins donc oui en général j'essaie de ne connecter que des switches
d'aggregation sur un routeur car un port 10G sur une MX ça coute par le
même prix qu'un port 10G sur un QFX :-)

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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[David Ponzone]

On a tous des expériences différentes, mais depuis que je suis dans ce métier, 
j’ai globalement eu (beaucoup) moins de problèmes avec les équipements L2 
qu’avec le L3 :)

Le 28 août 2014 à 19:05, Frederic Dhieux  a écrit :

> 
> Le 28/08/14 18:56, David Ponzone a écrit :
>> Le 28 août 2014 à 18:47, Pierre-Yves Maunier  a 
>> écrit :
>>> VRRP :
>>> - les 2 routeurs doivent avoir leur pate vers le serveurs dans le même L2 
>>> donc probablement vers un switch qui peut faire SPOF (sauf si c'est un 
>>> chassais)
>> Doit y avoir un moyen de mettre 2 switchs en stack et de connecter le 
>> serveur en LAG, un lien sur chaque switch.
>> Est-ce que les hyperviseurs supportent LAG, c’est peut-être là que ça bloque.
>> 
> 
> vswitch, switchs en stack, même combat pour moi. Quand ton cluster/stack
> tombe, ta redondance fait une sale tête :/
> 
> /plus confiance, déjà vécu
> 
> Frédéric
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Frederic Dhieux]

Le 28/08/14 18:56, David Ponzone a écrit :
> Le 28 août 2014 à 18:47, Pierre-Yves Maunier  a 
> écrit :
>> VRRP :
>> - les 2 routeurs doivent avoir leur pate vers le serveurs dans le même L2 
>> donc probablement vers un switch qui peut faire SPOF (sauf si c'est un 
>> chassais)
> Doit y avoir un moyen de mettre 2 switchs en stack et de connecter le serveur 
> en LAG, un lien sur chaque switch.
> Est-ce que les hyperviseurs supportent LAG, c’est peut-être là que ça bloque.
>

vswitch, switchs en stack, même combat pour moi. Quand ton cluster/stack
tombe, ta redondance fait une sale tête :/

/plus confiance, déjà vécu

Frédéric


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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[David Ponzone]

Le 28 août 2014 à 18:47, Pierre-Yves Maunier  a 
écrit :
> 
> VRRP :
> - les 2 routeurs doivent avoir leur pate vers le serveurs dans le même L2 
> donc probablement vers un switch qui peut faire SPOF (sauf si c'est un 
> chassais)

Doit y avoir un moyen de mettre 2 switchs en stack et de connecter le serveur 
en LAG, un lien sur chaque switch.
Est-ce que les hyperviseurs supportent LAG, c’est peut-être là que ça bloque.

> ECMP :
> - le serveur a 2 interfaces et 2 intercos L3 ; une vers chaque routeur (/30 
> ou /31). L'ECMP te permettra de load balancer et de pousser plus que la capa 
> d'une seule interface. Ce que ne te permet pas VRRP sans bidouillage (genre 2 
> IP VRRP avec la machine ayant 2 default gw).

Ok on est bien d’accord, mais on retombe sur un autre problème en IPv4, c’est 
un sacré gâchis d’IP!
ECMP est supporté sur tous les OS et hyperviseurs du marché ?

> Mais pour du pure fail over, faire de l'ECMP évite d'avoir un étage L2 entre 
> tes routeurs.

Tu veux dire que tu connectes ton serveur en direct sur le routeur ? Au niveau 
coût et « scalability », c’est pas l’idéal.
Il me semblait que la problématique était de connecter un gros paquet de 
serveurs en évitant les problèmes de ARP.


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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Raphael Mazelier]

VRRP :
- les 2 routeurs doivent avoir leur pate vers le serveurs dans le même L2
donc probablement vers un switch qui peut faire SPOF (sauf si c'est un
vchassis)


C'est vrai, si tu es sur un vchassis ça peut faire SPLOUF à la place :)

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Pierre-Yves Maunier]

Le 28 août 2014 17:05, David Ponzone  a écrit :

> En fait, ma question était directement pour la phrase de  PY Maunier:
> "Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
> pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
> fail."
>
> en mettant de côté tout ce qui concernait l’annonce de VIP.
> En clair, pour du pur fail-over (sans répartition de charge), quel était
> l’intérêt de ECMP par rapport à VRRP pour la partie du réseau entre le
> routeur et le serveur.
>
> Ceci dit, c’est off-topic, donc passons.
>
>

VRRP :
- les 2 routeurs doivent avoir leur pate vers le serveurs dans le même L2
donc probablement vers un switch qui peut faire SPOF (sauf si c'est un
vchassis)

ECMP :
- le serveur a 2 interfaces et 2 intercos L3 ; une vers chaque routeur (/30
ou /31). L'ECMP te permettra de load balancer et de pousser plus que la
capa d'une seule interface. Ce que ne te permet pas VRRP sans bidouillage
(genre 2 IP VRRP avec la machine ayant 2 default gw).

Mais pour du pure fail over, faire de l'ECMP évite d'avoir un étage L2
entre tes routeurs.

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

[FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Stephane Bortzmeyer]

On Thu, Aug 28, 2014 at 04:39:19PM +0200,
 Pierre Colombier  wrote 
 a message of 30 lines which said:

> Est-ce qu'on peut définir ce que c'est qu'un réseau "large".

RFC 6820 http://www.bortzmeyer.org/6820.html
Il cite des réseaux de 100 kmachines physiques...

> Est-ce que quelqu'un à réellement éprouvé en pratique des problèmes
> liés à la charge ARP dans des réseaux de ce genre ?

Indication : regarder l'employeur des auteurs du RFC 7342 :-)


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

Re: [FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Raphaël Jacquot]

On 28.08.2014 15:57, Raphael Mazelier wrote:

Le 28/08/2014 15:35, Stephane Bortzmeyer a écrit :


Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
cela ?




Oui c'est assez courant d'annoncer des VIP en /32 dans le réseau, en
OSPF, ou plutôt en BGP (avec exabgp par exemple).


et si tu controles bien toutes les vm, tu dois bien pouvoir les faire 
causer BGP elles aussi



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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[marc celier]

Pourquoi ne pas mettre en place 1 ou 2 serveurs sur chaque segment pour assurer la resolution ARP.

 

Le poste client decouvre la presence des serveurs de resolution d'adresse MAC, il envoie dans ce cas une requete ARP en UNICAST pour connaitre l'adresse mac de la machine qu'il souhaite joindre.

 

si le serveur de resolution d'@mac tombe en panne ou est indisponible le poste client envoie une requete ARP en broadcast.

 

autrement on pourrait augmenter les timeout des requetes ARP et avoir un mecanisme de rafraichissement (UNICAST) des entree dans la table ARP 

 

Envoyé: jeudi 28 août 2014 à 15:35
De: "Stephane Bortzmeyer" 
À: "Vincent Bernat" 
Cc: frnog-t...@frnog.org
Objet: [FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

On Thu, Aug 28, 2014 at 03:30:36PM +0200,
Vincent Bernat  wrote
a message of 37 lines which said:

> Les IP des machines peuvent être annoncées dans un protocole de
> routage

Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
cela ?


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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[David Ponzone]

En fait, ma question était directement pour la phrase de  PY Maunier:
"Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
fail."

en mettant de côté tout ce qui concernait l’annonce de VIP.
En clair, pour du pur fail-over (sans répartition de charge), quel était 
l’intérêt de ECMP par rapport à VRRP pour la partie du réseau entre le routeur 
et le serveur.

Ceci dit, c’est off-topic, donc passons.

Le 28 août 2014 à 16:40, Olivier Benghozi  a écrit 
:

> VRRP ça n'annonce pas trop des VIPs, ça permet plutôt aux serveurs d'avoir un 
> nexthop qui marche tout le temps.
> 
> 
> Le 28 août 2014 à 16:26, David Ponzone  a écrit :
> 
>> Juste pour ma culture G, c’est quoi l’avantage par rapport à VRRP ?
>> 
>> Le 28 août 2014 à 16:20, Pierre-Yves Maunier  a 
>> écrit :
>> 
>>> Le 28 août 2014 15:35, Stephane Bortzmeyer  a écrit :
>>> 
 
 Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
 cela ?
 
>>> 
>>> On a mis ça en place chez Iguane quand j'y étais (en BGP) et chez Daily on
>>> utilise ça aussi.
>>> 
>>> Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
>>> pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
>>> fail.
>>> 
>>> Pierre-Yves
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Stéphane Diacquenod]

Bonjour,

sur les mainframes (z/OS), les systèmes ont toujours deux cartes réseaux 
et font tourner un routeurs OSPF qui annonce les VIP.


Cela permet de déplacer les systèmes d'une machine à une autre, et de 
gérer la perte du premier router ou d'une carte réseau.


Il ne me semble pas qu'une configuration en L2 (VRRP) soient possible 
sur mainframe.


--
Cordialement,
Stéphane Diacquenod



On 2014-08-28 15:35, Stephane Bortzmeyer wrote:

On Thu, Aug 28, 2014 at 03:30:36PM +0200,
 Vincent Bernat  wrote
 a message of 37 lines which said:


Les IP des machines peuvent être annoncées dans un protocole de
routage


Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
cela ?


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



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

Re: [FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Romain SIBILLE]

Moi, je le fais pour voir comment mettre en place de l'anycast (un lab
donc, je suis étudiant...). Sorti de ça, je ne vois pas en quoi c'est
bizarre de faire ça en prod' (si je raconte des bétises, merci de me
corriger ;) )


Le 28/08/2014 15:35, Stephane Bortzmeyer a écrit :
> On Thu, Aug 28, 2014 at 03:30:36PM +0200,
>  Vincent Bernat  wrote 
>  a message of 37 lines which said:
> 
>> Les IP des machines peuvent être annoncées dans un protocole de
>> routage
> 
> Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
> cela ?
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Pierre-Yves Kerembellec]

Le 28 août 2014 à 16:39, Pierre Colombier  a écrit :

> Tout à fait d'accord avec le problème théorique
> Cependant, je n'ai jamais vu en pratique.
> Est-ce qu'on peut définir ce que c'est qu'un réseau "large".
> 
> Pour moi un segment réseau "large" c'est entre /24 et /20.
> Au delà, j'appelle ça "anormalement large"
> Est-ce que quelqu'un à réellement éprouvé en pratique des problèmes liés à la 
> charge ARP dans des réseaux de ce genre ?

Y'en a : https://www.youtube.com/watch?v=XvQPo5gZ-F4

>> Dans le premier cas (réseau L3), c'est la section 4. Les réseaux
>> utilisant le routage mettent un routeur IP dans chaque baie, voire un
>> pour chaque machine physique. Gros avantage : la diffusion des messages
>> ARP ou ND, qui ne va pas au delà du premier routeur, est très limitée.
>> Le problème décrit dans le RFC 6820 disparait donc complètement.
>> Inconvénient : on n'a plus aucune souplesse. Changer une VM de baie,
>> voire de serveur physique dans la même baie, oblige à la changer
>> d'adresse IP, ce qui va casser les sessions en cours, nécessiter une
>> reconfiguration, etc. Cette architecture ne convient donc que lorsque
>> le "data center" est assez statique, ou bien lorsque les services qui y
>> tournent peuvent supporter ces changements d'adresses IP.

Cordialement,
Pierre-Yves





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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Olivier Benghozi]

VRRP ça n'annonce pas trop des VIPs, ça permet plutôt aux serveurs d'avoir un 
nexthop qui marche tout le temps.


Le 28 août 2014 à 16:26, David Ponzone  a écrit :

> Juste pour ma culture G, c’est quoi l’avantage par rapport à VRRP ?
> 
> Le 28 août 2014 à 16:20, Pierre-Yves Maunier  a 
> écrit :
> 
>> Le 28 août 2014 15:35, Stephane Bortzmeyer  a écrit :
>> 
>>> 
>>> Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
>>> cela ?
>>> 
>> 
>> On a mis ça en place chez Iguane quand j'y étais (en BGP) et chez Daily on
>> utilise ça aussi.
>> 
>> Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
>> pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
>> fail.
>> 
>> Pierre-Yves


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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Olivier Benghozi]

Pas mal d'OSPF v2/v3 par ici (NSSA nosummary), pour annoncer des VIPs.

Y compris pour faire de l'anycast + ECMP d'ailleurs (fermes de récurseurs DNS 
sans LB/haproxy).


Le 28 août 2014 à 16:20, Pierre-Yves Maunier  a 
écrit :

> Le 28 août 2014 15:35, Stephane Bortzmeyer  a écrit :
> 
>> 
>> Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
>> cela ?
>> 
> 
> On a mis ça en place chez Iguane quand j'y étais (en BGP) et chez Daily on
> utilise ça aussi.
> 
> Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
> pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
> fail.


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

Re: [FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[David Ponzone]

Ah ouais, pardon, j’avais oublié le topic de départ :)

Le 28 août 2014 à 16:32, Pierre-Yves Kerembellec  a 
écrit :

> Le 28 août 2014 à 16:26, David Ponzone  a écrit :
> 
>> Juste pour ma culture G, c’est quoi l’avantage par rapport à VRRP ?
> 
> L3  L3 everywhere  ;-)
> 
 Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
 cela ?
 
>>> 
>>> On a mis ça en place chez Iguane quand j'y étais (en BGP) et chez Daily on
>>> utilise ça aussi.
>>> 
>>> Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
>>> pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
>>> fail.
> 
> Cordialement,
> Pierre-Yves
> 
> 
> 
> 


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

Re: [FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Pierre-Yves Kerembellec]

Le 28 août 2014 à 16:26, David Ponzone  a écrit :

> Juste pour ma culture G, c’est quoi l’avantage par rapport à VRRP ?

L3  L3 everywhere  ;-)

>>> Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
>>> cela ?
>>> 
>> 
>> On a mis ça en place chez Iguane quand j'y étais (en BGP) et chez Daily on
>> utilise ça aussi.
>> 
>> Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
>> pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
>> fail.

Cordialement,
Pierre-Yves





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

Re: [FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[David Ponzone]

Juste pour ma culture G, c’est quoi l’avantage par rapport à VRRP ?

Le 28 août 2014 à 16:20, Pierre-Yves Maunier  a 
écrit :

> Le 28 août 2014 15:35, Stephane Bortzmeyer  a écrit :
> 
>> 
>> Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
>> cela ?
>> 
> 
> On a mis ça en place chez Iguane quand j'y étais (en BGP) et chez Daily on
> utilise ça aussi.
> 
> Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
> pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
> fail.
> 
> Pierre-Yves
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Pierre-Yves Maunier]

Le 28 août 2014 15:35, Stephane Bortzmeyer  a écrit :

>
> Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
> cela ?
>

On a mis ça en place chez Iguane quand j'y étais (en BGP) et chez Daily on
utilise ça aussi.

Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
fail.

Pierre-Yves

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

Re: [FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Raphael Mazelier]

Le 28/08/2014 15:35, Stephane Bortzmeyer a écrit :


Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
cela ?




Oui c'est assez courant d'annoncer des VIP en /32 dans le réseau, en 
OSPF, ou plutôt en BGP (avec exabgp par exemple).


--
Raphael Mazelier
AS39605


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

[FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Vincent Bernat]

 ❦ 28 août 2014 15:35 +0200, Stephane Bortzmeyer  :

>> Les IP des machines peuvent être annoncées dans un protocole de
>> routage
>
> Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
> cela ?

Plutôt en BGP qui permet de mieux compartimentaliser et filtrer. Je ne
pense pas que ce soit si inhabituel que ça. Je ne le fais pas encore de
mon côté, mais c'est dans les cartons.

De manière proche, j'avais fait ça :
 http://vincent.bernat.im/en/blog/2013-exabgp-highavailability.html

Cela me semble très proche de ce qu'il faudrait faire pour permettre à
des IP de migrer n'importe où sur un réseau L3.

Il faut ajouter côté client que le routeur ne change pas, chose qui est
très facile en IPv6 (fe80::1 en routeur pour tout le monde) mais qui est
moins évident en IPv4 si on veut de la configuration via DHCP (en
statique, pas de soucis, on indique que le routeur par défaut qui est le
même pour tout le monde est sur eth0).

C'est un peu du SDN avec les technos d'il y a 20 ans. ;-)
-- 
Document your data layouts.
- The Elements of Programming Style (Kernighan & Plauger)


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

[FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Stephane Bortzmeyer]

On Thu, Aug 28, 2014 at 03:30:36PM +0200,
 Vincent Bernat  wrote 
 a message of 37 lines which said:

> Les IP des machines peuvent être annoncées dans un protocole de
> routage

Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
cela ?


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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Vincent Bernat]

 ❦ 28 août 2014 14:23 +0200, Stephane Bortzmeyer  :

> Dans le premier cas (réseau L3), c'est la section 4. Les réseaux 
> utilisant le routage mettent un routeur IP dans chaque baie, voire un 
> pour chaque machine physique. Gros avantage : la diffusion des messages 
> ARP ou ND, qui ne va pas au delà du premier routeur, est très limitée. 
> Le problème décrit dans le RFC 6820 disparait donc complètement. 
> Inconvénient : on n'a plus aucune souplesse. Changer une VM de baie, 
> voire de serveur physique dans la même baie, oblige à la changer 
> d'adresse IP, ce qui va casser les sessions en cours, nécessiter une 
> reconfiguration, etc. Cette architecture ne convient donc que lorsque 
> le "data center" est assez statique, ou bien lorsque les services qui y 
> tournent peuvent supporter ces changements d'adresses IP.

C'est plutôt incorrect (la RFC est un peu plus nuancée et indique que
cela est possible avec une "reconfiguration" mais semble indiquer qu'il
s'agit d'une action humaine). Les IP des machines peuvent être
annoncées dans un protocole de routage permettant le déplacement de la
machine. L'hyperviseur qui a reçu la VM va se mettre à annoncer son
IP. La machine conserve son IP et son routeur.
-- 
 /*
  * For moronic filesystems that do not allow holes in file.
  * We may have to extend the file.
  */
2.4.0-test2 /usr/src/linux/fs/buffer.c


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

[FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Stephane Bortzmeyer]

Et vous, dans vos data centers, vous faites comment ?

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



Auteur(s) du RFC: L. Dunbar (Huawei), W. Kumari (Google), I. Gashinsky (Yahoo)






Les protocoles de résolution d'adresse IP en adresse MAC sur un réseau 
local, ARP pour IPv4 et ND pour IPv6, fonctionnent par diffusion. Le 
client crie à tout le monde « qui connait 2001:db8:376:ab::23:c0f ? » 
et la machine qui se reconnait répond. L'inconvénient de ce mécanisme 
est qu'il passe mal à l'échelle : lorsque des centaines de milliers de 
machines virtuelles sont sur le même réseau local dans un grand "data 
center", et crient toutes en même temps, le réseau va souffrir. Ce 
nouveau RFC ne propose pas de solution mais décrit les pratiques qui 
sont actuellement utilisées pour limiter les dégâts.

Le problème des protocoles ARP (RFC 826) et ND (RFC 4861) dans les 
grands "data centers" a été décrit en détail dans le RFC 6820. Le 
problème a toujours existé mais est devenu bien plus sérieux depuis 
qu'on pratique massivement la virtualisation et que le nombre de 
machines qui font de l'ARP ou du ND a explosé. Le désir de souplesse 
dans la gestion de ces machines fait qu'il est difficile 
d'architecturer le réseau en fonction de ce problème. Par exemple, 
faire de chaque machine physique un réseau limiterait la diffusion des 
requêtes ARP ou ND mais obligerait à changer l'adresse IP des machines 
virtuelles lorsqu'elles passent d'une machine physique à une autre, 
annulant ainsi cette souplesse que fournit la virtualisation.

Les trois principales conséquences de cette augmentation du trafic 
ARP/ND :
* Consommation de capacité réseau au détriment du trafic « utile » 
(bien sûr, avec les liens modernes à 10 Gb/s, c'est moins grave 
qu'avant),
* Augmentation de la charge de travail des routeurs, sans doute la 
conséquence la plus gênante aujourd'hui (cf. une étude de Merit 
),
* En IPv4 augmentation de la charge de *toutes* les machines car la 
diffusion est totale (IPv6 utilise le "multicast"). Là encore, 
l'augmentation des ressources de calcul des équipements réseau peut 
aider : un test en laboratoire indique que 2 000 messages ARP par 
seconde consomment 2 % du CPU d'un serveur.


Comme expliqué dans la section 3, le réseau interne d'un grand "data 
center" a en général une de ces trois architectures :
* Connectivité au niveau 3 (L3), c'est-à-dire qu'on fait du routage IP 
dans le "data center",
* Tout en niveau 2, le "data center" est un grand réseau L2,
* Virtualisation du réseau ("overlay").
Pour chacune de ces architectures, une section de notre RFC décrit les 
pratiques actuelles pour limiter l'effet des protocoles de résolution.

Dans le premier cas (réseau L3), c'est la section 4. Les réseaux 
utilisant le routage mettent un routeur IP dans chaque baie, voire un 
pour chaque machine physique. Gros avantage : la diffusion des messages 
ARP ou ND, qui ne va pas au delà du premier routeur, est très limitée. 
Le problème décrit dans le RFC 6820 disparait donc complètement. 
Inconvénient : on n'a plus aucune souplesse. Changer une VM de baie, 
voire de serveur physique dans la même baie, oblige à la changer 
d'adresse IP, ce qui va casser les sessions en cours, nécessiter une 
reconfiguration, etc. Cette architecture ne convient donc que lorsque 
le "data center" est assez statique, ou bien lorsque les services qui y 
tournent peuvent supporter ces changements d'adresses IP.

Deuxième architecture possible (section 5), le grand réseeau L2 où 
toute diffusion va frapper toutes les machines. Cette fois, le problème 
des messages de diffusion ARP ou ND va se poser en grand. Les routeurs 
qui vont faire communiquer ce réseau L2 avec l'extérieur vont souffrir. 
Comment diminuer cette souffrance ? D'abord, pour le cas où une machine 
cherche à communiquer avec une machine externe et doit donc résoudre 
l'adresse IP du routeur en adresse MAC. Si cette adresse MAC n'est pas 
dans le cache de la machine, elle envoie une requête, et le routeur 
doit la traiter, ce qui se fait en général via le CPU généraliste du 
routeur, pas dans les circuits spécialisés.

Première solution, pré-charger l'adresse MAC du routeur dans toutes les 
machines (options -s et -f de la commande arp sur Unix). Deuxième 
solution, plus souple, que le routeur envoie des réponses ARP ou ND 
spontanément, sans attendre les requêtes (cf. RFC 5227). Ainsi, son 
adresse MAC sera quasiment toujours dans les caches. Cela marche très 
bien pour IPv4. Mais cela ne résoud pas complètement le problème pour 
IPv6 : ce protocole impose l'envoi de requêtes au routeur, pour valider 
que la liaison avec celui-ci fonctionne (RFC 4861, section 7.3, 
notamment « "Receipt of other Neighbor Discovery messages, such as 
Router Advertisements and Neighbor Advertisement with the Solicited 
flag set to zero, MUST NOT be treated as a reachability confirmation. 
Rec

Re: [FRnOG] [TECH] OpenBGPD & vrf-lite

[Pierre Emeriaud]

Le 27 août 2014 11:10, David Ponzone  a écrit :
> Apparemment, d’autres ont eu le même problème:
>
> http://permalink.gmane.org/gmane.os.openbsd.misc/213031

En effet, ça ressemble beaucoup à mes soucis.

J'ai bien les routes en rib, mais elles ne sont jamais installée en
fib. Je pense que le problème que j'ai est toujours au niveau de la
validation du next-hop...

# bgpctl show nexthop
Flags: * = nexthop valid

  Nexthop Route  Prio Gateway Iface
  172.22.151.245

j'ai bien une route vers 172.22.151.245 dans la rtable 10, en connected.

D'après le man, cette route en connected pose peut-être problème :

 nexthop qualify via (bgp|default)
 If set to bgp, bgpd(8) may use BGP routes to verify nexthops.  If
 set to default, bgpd may use the default route to verify
 nexthops.  By default bgpd will only use static routes or routes
 added by other routing daemons like ospfd(8).

J'ai donc rajouté une route statique dans la rtable 10 vers une
loopback sur le peer, et établi le peering, mais le nexthop n'en reste
pas moins invalide...


Dès que j'aurais un peu de temps je vais mailer ça sur misc@, voir si
quelqu'un a une idée (si c'est possible déjà...)

Merci en tout cas de m'avoir proposé "route -T10 exec bgpd" en tout
cas, il ne reste ptet qu'à patcher rde :)

--
petrus


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