Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet David Ponzone
redistribute static

Attention à filtrer vers tes transitaires pour ne pas leur renvoyer tes /32 :)


> Le 2 nov. 2015 à 16:11, Fabien H  a écrit :
> 
> Une question qui reste en suspend :
> 
> Nous avons donc 2 routeurs BGP avec un prefixe "localisé" sur chaque
> routeur + session iBGP entre les 2 : sur chaque routeur, pas mal de routes
> en /32 vers nos différents équipements.
> 
> Je voudrais que toutes les routes en /32 du routeur 1 soient annoncées en
> iBGP sur le routeur 2, et inversement.
> 
> Actuellement cela ne se fait pas. Les routes-map in et out sont OK.  J'ai
> des directives network pour mes prefixes mais pas pour mes routes en /32.
> Je suppose qu'il faut une directive network pour chaque route en /32 ?
> 
> router bgp 1234
> address-family ipv4
>  network 1.2.3.4 mask 255.255.255.255
>  network 3.4.5.6 mask 255.255.255.255
>  
> 
> Ca me parait lourd à gérer et pas très clean. Comment faire les choses dans
> les règles de l'art ?
> 
> Merci pour vos lumières !
> 
> 
> 
> Le 2 novembre 2015 11:11, Fabien H  a écrit :
> 
>> Bonjour Raphael,
>> 
>> Tout à fait, ça parait logique ! D'ailleurs pour les basiques et la mise
>> en place y'a pas mal de ressources bien faites sur le net notamment les
>> présentations Workshop d'Arnaud Fernioux. Ca permet de voir si globalement
>> on est dans les clous ou pas !
>> 
>> Bonne journée !
>> 
>> Le 2 novembre 2015 10:36, Raphael Mazelier  a écrit :
>> 
>>> Back to basic.
>>> 
>>> Ton AS ne devrait jamais être disjoint.
>>> Dépendant de ta localisation de tes deux datacenters, le mieux c'est
>>> quand même de prendre une dark. Si tu ne peux pas tu utilise deux l2l, voir
>>> un l2l avec backup sur Gre.
>>> 
>>> 2eme point : on redit, tu fait tourner un IGP entre des deux routeurs
>>> (Ospf, Isis) juste pour les loopbacks de tes routeurs (et les intercos si
>>> tu veux). Et tu montes tes sessions Ibgp entre ces loopbacks de sortes que
>>> te sessions IBGP ne doivent jamais tombés (sauf si faillure du routeur,
>>> mais faillure de path). Et dans ton IBGP tu mets ce que tu veux, tes mores
>>> specifics (dans ton cas tes /32).
>>> 
>>> 
>>> 
>>> Le 02/11/15 10:23, Fabien H a écrit :
>>> 
 Mais d'ailleurs, 2 lan2lan de 2 fournisseurs différents en place sur le
 même SW de part et d'autre ne risquent pas de mal fonctionner ? C'est
 transparent ?
 
 Le 2 novembre 2015 09:50, Clement Cavadore  a
 écrit :
 
 On Mon, 2015-11-02 at 09:41 +0100, Oceanet - Cédric BASSAGET wrote:
> 
>> Ça c'est la solution quand y'a des sous ;)
>> 
> 
> Faut se donner les moyens de ses ambitions...  Surtout vu les prix
> moyens des lan2lan datacenter-datacenter, de nos jours :-)
> 
> --
> Clément Cavadore
> 
> 
> 
 ---
 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/


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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Fabien H
Une question qui reste en suspend :

Nous avons donc 2 routeurs BGP avec un prefixe "localisé" sur chaque
routeur + session iBGP entre les 2 : sur chaque routeur, pas mal de routes
en /32 vers nos différents équipements.

Je voudrais que toutes les routes en /32 du routeur 1 soient annoncées en
iBGP sur le routeur 2, et inversement.

Actuellement cela ne se fait pas. Les routes-map in et out sont OK.  J'ai
des directives network pour mes prefixes mais pas pour mes routes en /32.
Je suppose qu'il faut une directive network pour chaque route en /32 ?

router bgp 1234
 address-family ipv4
  network 1.2.3.4 mask 255.255.255.255
  network 3.4.5.6 mask 255.255.255.255
  

Ca me parait lourd à gérer et pas très clean. Comment faire les choses dans
les règles de l'art ?

Merci pour vos lumières !



Le 2 novembre 2015 11:11, Fabien H  a écrit :

> Bonjour Raphael,
>
> Tout à fait, ça parait logique ! D'ailleurs pour les basiques et la mise
> en place y'a pas mal de ressources bien faites sur le net notamment les
> présentations Workshop d'Arnaud Fernioux. Ca permet de voir si globalement
> on est dans les clous ou pas !
>
> Bonne journée !
>
> Le 2 novembre 2015 10:36, Raphael Mazelier  a écrit :
>
>> Back to basic.
>>
>> Ton AS ne devrait jamais être disjoint.
>> Dépendant de ta localisation de tes deux datacenters, le mieux c'est
>> quand même de prendre une dark. Si tu ne peux pas tu utilise deux l2l, voir
>> un l2l avec backup sur Gre.
>>
>> 2eme point : on redit, tu fait tourner un IGP entre des deux routeurs
>> (Ospf, Isis) juste pour les loopbacks de tes routeurs (et les intercos si
>> tu veux). Et tu montes tes sessions Ibgp entre ces loopbacks de sortes que
>> te sessions IBGP ne doivent jamais tombés (sauf si faillure du routeur,
>> mais faillure de path). Et dans ton IBGP tu mets ce que tu veux, tes mores
>> specifics (dans ton cas tes /32).
>>
>>
>>
>> Le 02/11/15 10:23, Fabien H a écrit :
>>
>>> Mais d'ailleurs, 2 lan2lan de 2 fournisseurs différents en place sur le
>>> même SW de part et d'autre ne risquent pas de mal fonctionner ? C'est
>>> transparent ?
>>>
>>> Le 2 novembre 2015 09:50, Clement Cavadore  a
>>> écrit :
>>>
>>> On Mon, 2015-11-02 at 09:41 +0100, Oceanet - Cédric BASSAGET wrote:

> Ça c'est la solution quand y'a des sous ;)
>

 Faut se donner les moyens de ses ambitions...  Surtout vu les prix
 moyens des lan2lan datacenter-datacenter, de nos jours :-)

 --
 Clément Cavadore



>>> ---
>>> 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/


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Raphael Mazelier
D'une maniéré générale il est considéré comme bonne pratique, que les 
routes présentes dans les protocoles de routage dynamique le soit par 
redistribution (soit de statique, soit de connected).



Le 02/11/15 16:23, David Ponzone a écrit :

redistribute static

Attention à filtrer vers tes transitaires pour ne pas leur renvoyer tes /32 :)



--
Raphael Mazelier


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


RE: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Michel Py
>> Fabien H a écrit :
>> Ca me parait lourd à gérer et pas très clean. Comment faire les choses dans 
>> les règles de l'art ?

> David Ponzone a écrit :
> redistribute static
> Attention à filtrer vers tes transitaires pour ne pas leur renvoyer tes /32 :)

> Raphael Mazelier a écrit :
> D'une maniéré générale il est considéré comme bonne pratique, que les routes 
> présentes dans les
> protocoles de routage dynamique le soit par redistribution (soit de statique, 
> soit de connected).

Je plussoie David et Raphael pour la redistribution. J'irais plus loin : les 
routes statiques il faut les éliminer complètement, les garder çà reviendra te 
mordre un jour ou l'autre.

Tes /32, ils faut qu'ils soient annoncés par un IGP (probablement OSPF, tes 
autres choix étant EIGRP (propriétaire Cisco) et ISIS (très peu répandu, et pas 
pour ta taille). Redistribute connected dans ton IGP, et redistribute ton IGP 
dans BGP avec les route-map qui vont bien.

C'est technique comme configuration, mais ç'est plus robuste.

Michel.


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


Re: [FRnOG] [TECH] Gestion boucle L2

2015-11-02 Par sujet Julien OHAYON
Bonjour,

Jamais testé mais le MLAG fonctionnerait non ?

Julien OHAYON

Le 2 nov. 2015 à 18:16, Nicolas V  a écrit :

Bonjour,

Je cherche à interconnecter plusieurs sites (3 au minima) via une boucle
(de 1 à x*10G entre chaque site avec possibilité éventuelle d'ajout de
liens 1G). Le but étant de pouvoir faire transiter du L2 de manière
transparente.

J'ai suivi le mail de Jérémy Martin "Design réseau L2", mais j'ai quelques
contraintes / une architecture un peu différente :
- Des routeurs ASR9k sur chaque POP => evpn / mpls possible
- Des nexus sur chaque POP => fabricpath possible (mais licence nécessaire)

Je ne suis pas fermé aux autres techno, mais je recherche dans la mesure du
possible, une techno tirant profit du matériel déjà en place pour un coût
raisonnable. Si vous avez d'autres idées qui valent le coup, je reste tout
de même preneur :)

Certains d'entre vous ont il déjà déployés l'une de ces techno
(particulièrement EVPN... peu de docs trouvés là-dessus) et quels en sont
les avantages / inconvénients?

Pouvez vous nous faire partager votre retour d'expérience sur le sujet ?

Merci

-- 
Nicolas V

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


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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Jérôme Nicolle
Plop,

Le 02/11/2015 10:46, Christophe Lucas a écrit :
> Tu peux pas jouer avec du conditional advertisement en désagrégeant le cas 
> échéant en fonctions des
> subnets locaux ?

Alors, c'est pas parce que la plupart des implémentations de BGP sont
Turing-Complete (http://vanbever.eu/pdfs/vanbever_turing_icnp_2013.pdf)
qu'en explorer les aspects programmatiques aboutira à un bon design.

Clairement dans ce cas précis, le tuneling GRE via les transits, avec un
métrique faible sur l'IGP sans toucher à l'iBGP, devrait suffire à
résoudre la plupart des problématiques opérationnelles, faite de
redondance sur le L2L.

Après si on veut enculer des mouches, la redistributions conditionnelle
peut aider à optimiser certains flux, mais c'est à mon avis marginal
dans la très grande majorité des cas.

Donc option 1 : redonder le L2L pour éviter le split-brain, option 2
tunneling GRE (ou autre) signalisé par l'IGP. Les deux ne sont pas
mutuellement exclusifs.

@+

-- 
Jérôme Nicolle
06 19 31 27 14


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


Re: [FRnOG] [TECH] Gestion boucle L2

2015-11-02 Par sujet Jérôme Nicolle
Salut Nicolas,

Est ce que le transport L2 est vraiment un prérequis indispensable ? Ne
peux tu pas régler en niveau 3, avec des protocoles éprouvés, ce que le
L2 a toujours du mal à faire, parce que pas fait pour ?

Si tu dois maintenir du L2, s'agirait-il de pseudo-wires (donc point à
point) ou de VPLS / E-VPN pour propager du "single domain of failure"
sur l'ensemble des sites à chaque fois ?

Dans le cas ou tu doive impérativement composer avec les deux types de
services, tu as clairement deux approches : full-MPLS, avec des L2VPN et
L3VPN cote à cote, ou des tunnels entre switchs virtuels et VRF,
idéalement sur un backbone ECMP en IPv6.

Sur la seconde approche, du mikrotik fera un boulot au moins aussi bon
que des ASR9k au vingtième du prix (jusqu'à 20-30Gbps par ring).
Ensuite, entre NFV et ASR1k, tu as plusieurs approches possibles.

Si tu veux le faire en MPLS, alors peu importe le constructeur, celui
sur le quel tu as le plus de staff opérationnel sera forcement le moins
complexe à gérer. Mais mieux vaut un design homogène pour ne pas avoir à
traiter la bug-compatibility entre constructeurs, ils ont tendance à
régresser ces temps-ci.

@+

-- 
Jérôme Nicolle
06 19 31 27 14


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


[FRnOG] [TECH] Interxion PAR7 : fin du FUD.

2015-11-02 Par sujet Jérôme Nicolle
Bonsoir,

TL/DR : La nouvelle est tombée aujourd'hui : un arrêté préfectoral
autorise Interxion France à continuer l'exploitation du site PAR7 (0)
d'ici à l'aboutissement d'une nouvelle procédure d'autorisation. Dormez
tranquilles.

Le fond :

Comme rapporté par plusieurs articles dont (1), le tribunal
administratif de Montreuil a annulé l'arrêté préfectoral d'autorisation
d'exploitation du datacenter Interxion PAR7 par un jugement du 15
octobre (2).

L'arrêté d'autorisation d'exploitation concerne le régime des
Installations Classées pour la Protection de l’Environnement, un
ensemble de rubriques classant les installations industrielles en
fonction des risques environnementaux potentiels. La liste des rubriques
concernant PAR7 est disponible en (3).

Il s'agit avant tout d'un outil permettant aux autorités d'organiser les
mesures de prévention des risques, et en fonction des seuils
applicables, les installations concernées sont soumises à un régime soit
déclaratif, soit d'autorisation. Dans le cas de PAR7, c'est la puissance
des groupes installés et/ou le volume de carburant stocké (précision non
trouvée, l'un des points attaqués dépend à priori des groupes, l'autre
du stockage…) qui déclenchait le seuil passant le site au régime
d'autorisation.

Le non-événement :

Lors de l'annonce de l'annulation de l'autorisation d'exploitation, et
comme on est presque tous ici plutôt étrangers à ces considérations
administratives kafk^Wfrançaises, ça a pu faire jaser et ça a en tout
cas alimenté le FUD de certains commerciaux de concurrents d'Interxion.

On a craint en première lecture un arrêt brutal du site, avec la
possibilité d'un maintient sous les seuils de puissance installée (soit
8MWe secourus max), afin de rester en régime déclaratif, d'ici à ce que
la procédure d'autorisation soit refaite. Ça aurait été un coup de
massue sur le business IT/housing en France, mais il n'a finalement pas
été nécessaire de poursuivre l'exploration des scénarios catastrophe.

Il reste un peu de boulot aux juristes impliqués pour consolider une
jurisprudence qui n'induise pas un risque administratif en plus des
risques techniques qu'on a à gérer au quotidien. Pas de conclusion pour
l'instant, mais on est quand même soulagés par la tournure que ça prend.

Ce qu'on peut en tirer :

* Construire et exploiter un DC est autrement plus complexe qu'on ne
peut le croire au premier abord, en plus de la technique il faut un
moral d'acier pour affronter l'administration. Ce genre de dossiers est
généralement le plus gros contributeur aux retards de livraison
d'installations techniques.

* Pas de panique ! Ils n'ont pas osé fermer un site non-historique, donc
les prochains dans le collimateur d'associations de riverains (ou
autres) n'ont à priori pas plus de souci que ça à se faire. Restons
vigilants, mais après tout, nos infras et liens critiques sont toutes
redondées, n'est ce pas ? ;-)


Un grand merci à Arnaud de Bermingham qui a pris le temps de nous
expliquer, sur le canal IRC #FRnOG, la nature des dossiers d'ICPE. Un
autre merci à la fédération FDN, dont les nombreuses actions récentes en
droit administratif ont permis de déniaiser certains d'entre nous à la
compréhension des procédures et actes de cette nature.

@+


(0)
http://www.silicon.fr/datacenter-interxion-par7-poursuivre-activites-a-courneuve-130454.html

(1)
http://www.silicon.fr/affaire-interxion-datacenters-urbains-menaces-129461.html

(2)
https://www.scribd.com/doc/286064594/Jugement-tribunal-administratif-de-Montreuil-93-affaire-Interxion

(3)
http://www.installationsclassees.developpement-durable.gouv.fr/ficheEtablissement.php?selectRegion=15=93=la+courneuve==-1=-1=-1=-1=-1===65=14850==26=0=20


-- 
Jérôme Nicolle
06 19 31 27 14


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


Re: [FRnOG] [TECH] Gestion boucle L2

2015-11-02 Par sujet Nicolas V
Bonsoir à tous,

@Laurent & @David

J'aurais du le préciser, le besoin est bien d’agréger des liens L2 de
différents opérateurs.


@Jérôme,

Le transport du L2 est indispensable (même si le L3 uniquement serait
nettement plus simple à gérer..)

Il est question de propager le L2 sur l'ensemble des sites. Je te remercie
pour les différentes approches, je vais rechercher un peu d'infos sur
certains points que tu cites.


Personne n'est fan de fabricpath / trop propriétaire pour que quelqu'un s'y
soit risqué ?


Merci à vous
Nicolas


Le 2 novembre 2015 20:28, Jérôme Nicolle  a écrit :

> Salut Nicolas,
>
> Est ce que le transport L2 est vraiment un prérequis indispensable ? Ne
> peux tu pas régler en niveau 3, avec des protocoles éprouvés, ce que le
> L2 a toujours du mal à faire, parce que pas fait pour ?
>
> Si tu dois maintenir du L2, s'agirait-il de pseudo-wires (donc point à
> point) ou de VPLS / E-VPN pour propager du "single domain of failure"
> sur l'ensemble des sites à chaque fois ?
>
> Dans le cas ou tu doive impérativement composer avec les deux types de
> services, tu as clairement deux approches : full-MPLS, avec des L2VPN et
> L3VPN cote à cote, ou des tunnels entre switchs virtuels et VRF,
> idéalement sur un backbone ECMP en IPv6.
>
> Sur la seconde approche, du mikrotik fera un boulot au moins aussi bon
> que des ASR9k au vingtième du prix (jusqu'à 20-30Gbps par ring).
> Ensuite, entre NFV et ASR1k, tu as plusieurs approches possibles.
>
> Si tu veux le faire en MPLS, alors peu importe le constructeur, celui
> sur le quel tu as le plus de staff opérationnel sera forcement le moins
> complexe à gérer. Mais mieux vaut un design homogène pour ne pas avoir à
> traiter la bug-compatibility entre constructeurs, ils ont tendance à
> régresser ces temps-ci.
>
> @+
>
> --
> Jérôme Nicolle
> 06 19 31 27 14
>



-- 
Nicolas V

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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Fabien H
OK, je vais étudier tout ça en reprenant tous les points dans l'ordre.

Ce qui est assez étonnant, c'est que c'est déjà arrivé que le L2L tombe en
journée, et donc la session iBGP tombe rapidement (j'ai mis un SLA icmp qui
ping le loopback d'en face),

Le BGP a bien joué son rôle et chaque routeur fonctionnait de manière
autonome avec son transitaire : Impact minime. C'est pour ça que je
sous-estimait le risque d'un split-brain : pour moi, c'était 40 secondes à
2 minutes de coupure uniquement.

Et là les routes statiques dans ce cas ont bien joué leur rôle (elles ne
disparaissent pas lors de la perte de l'iBGP).

Mais je comprend maintenant que la logique est mauvaise..







Le 2 novembre 2015 20:43, Jérôme Nicolle  a écrit :

> Plop,
>
> Le 02/11/2015 10:46, Christophe Lucas a écrit :
> > Tu peux pas jouer avec du conditional advertisement en désagrégeant le
> cas échéant en fonctions des
> > subnets locaux ?
>
> Alors, c'est pas parce que la plupart des implémentations de BGP sont
> Turing-Complete (http://vanbever.eu/pdfs/vanbever_turing_icnp_2013.pdf)
> qu'en explorer les aspects programmatiques aboutira à un bon design.
>
> Clairement dans ce cas précis, le tuneling GRE via les transits, avec un
> métrique faible sur l'IGP sans toucher à l'iBGP, devrait suffire à
> résoudre la plupart des problématiques opérationnelles, faite de
> redondance sur le L2L.
>
> Après si on veut enculer des mouches, la redistributions conditionnelle
> peut aider à optimiser certains flux, mais c'est à mon avis marginal
> dans la très grande majorité des cas.
>
> Donc option 1 : redonder le L2L pour éviter le split-brain, option 2
> tunneling GRE (ou autre) signalisé par l'IGP. Les deux ne sont pas
> mutuellement exclusifs.
>
> @+
>
> --
> Jérôme Nicolle
> 06 19 31 27 14
>

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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Clement Cavadore
On Mon, 2015-11-02 at 09:16 +0100, Fabien H wrote:
> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
> solution à ce problème ?

La bonne démarche, c'est de sécuriser le L2L avec un autre, afin de ne
jamais te retrouver en split brain sur ton ASN :-)

-- 
Clément Cavadore


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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet David Ponzone
Il manque quelques infos je pense.
Sur chaque site, il y a quoi à part les routeurs BGP ?
Un LAN avec du hosting ou autre ? J’imagine que oui.
Le L2L, il relie pas les routeurs directement, mais des switch L2 qui sont 
derrière les routeurs, je suppose ?
Autre point qui n’est pas clair: tu as bien un /24 minimum dédié au LAN de 
chaque site ?

Ta problématique est donc simple, si je résume:
Le L2L tombe, mais les 2 routeurs sont OK.
Chacun annonce les 2 préfixes et donc si le site A reçoit un paquet pour B, 
c’est mort.

Cas 1: tu as bien des subnets séparés pour le LAN de chaque site.
Il faut juste utiliser IP SLA (chez Cisco) sur chaque routeur pour détecter que 
le L2L est mort, et faire tomber l’annonce du BGP du préfixe de l’autre site.

Cas 2: les 2 sites partagent le même subnet pour le LAN
Tunnel GRE entre les 2 routeurs qui passent par leur transit respectif et iBGP 
dessus, avec un localpref défavorable par rapport à la session iBGP du L2L.


> Le 2 nov. 2015 à 09:16, Fabien H  a écrit :
> 
> Bonjour la liste,
> 
> J'ai une question BGP à vous soumettre :
> 
> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
> avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
> Sur chaque routeur BGP, nous avons au moins un transitaire.
> 
> Tout fonctionne parfaitement !
> 
> Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
> utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
> route Null0).
> Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
> sur le routeur BGP concerné.
> 
> - Ma question : Nous aimerions mettre en place un failover BGP automatique
> en cas de défaillance matérielle totale d'un des routeurs BGP.
> 
> La solution que j'imaginais est de mettre en place, pour un même prefixe,
> une route Null0 sur les 2 routeurs en même temps.
> 
> Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
> les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
> => Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
> problème.
> 
> Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
> mais que le L2L tombe.
> 
> Dans ce cas, un paquet va continuer à arriver par le transit sur le routeur
> BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
> mais l'IP de GW étant normalement accessible via le L2L sur un VLAN donné,
> le routage ne fonctionnera pas car le L2L est tombé.
> 
> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une solution à
> ce problème ?
> 
> Merci,
> Bonne journée,
> Fabien
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Oceanet - Cédric BASSAGET

Ça c'est la solution quand y'a des sous ;)

Cédric

OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00

On 02/11/2015 09:29, Clement Cavadore wrote:

On Mon, 2015-11-02 at 09:16 +0100, Fabien H wrote:

Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
solution à ce problème ?

La bonne démarche, c'est de sécuriser le L2L avec un autre, afin de ne
jamais te retrouver en split brain sur ton ASN :-)




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


[FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Fabien H
Bonjour la liste,

J'ai une question BGP à vous soumettre :

En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
Sur chaque routeur BGP, nous avons au moins un transitaire.

Tout fonctionne parfaitement !

Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
route Null0).
Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
sur le routeur BGP concerné.

- Ma question : Nous aimerions mettre en place un failover BGP automatique
en cas de défaillance matérielle totale d'un des routeurs BGP.

La solution que j'imaginais est de mettre en place, pour un même prefixe,
une route Null0 sur les 2 routeurs en même temps.

Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
=> Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
problème.

Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
mais que le L2L tombe.

Dans ce cas, un paquet va continuer à arriver par le transit sur le routeur
BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
mais l'IP de GW étant normalement accessible via le L2L sur un VLAN donné,
le routage ne fonctionnera pas car le L2L est tombé.

Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une solution à
ce problème ?

Merci,
Bonne journée,
Fabien

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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Fabien H
Bonjour Cedric,
merci pour la réponse, intéressant !

Malgré tout, comme j'ai des routes statiques et spécifiques vers des IP en
/32 dupliquées sur chaque routeur BGP, elles seront toujours prioritaires
sur les routes apprises en iBGP .. Ca doit être le fond du problème je
pense ..

Le 2 novembre 2015 09:28, Oceanet - Cédric BASSAGET  a
écrit :

> Bonjour Fabien,
>
> Un tunnel GRE entre tes deux routeurs via du transit, et une session iBGP
> sur ce GRE ?
> Cédric
>
> OCEANET
> ---
> [AGENCE DU MANS]
> 7, rue des Frênes
> ZAC de la Pointe
> 72190 SARGE LES LE MANS
> [t] +33 (0)2.43.50.26.50
> [f] +33 (0)2.43.72.21.14
>
> [AGENCE D'ANGERS]
> 5, rue Fleming
> Angers Technopole
> 49066 ANGERS
> [t] +33 (0)2.41.19.28.65
> [f] +33 (0)2.52.19.22.00
>
>
> On 02/11/2015 09:16, Fabien H wrote:
>
>> Bonjour la liste,
>>
>> J'ai une question BGP à vous soumettre :
>>
>> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
>> avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
>> Sur chaque routeur BGP, nous avons au moins un transitaire.
>>
>> Tout fonctionne parfaitement !
>>
>> Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
>> utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
>> route Null0).
>> Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
>> sur le routeur BGP concerné.
>>
>> - Ma question : Nous aimerions mettre en place un failover BGP automatique
>> en cas de défaillance matérielle totale d'un des routeurs BGP.
>>
>> La solution que j'imaginais est de mettre en place, pour un même prefixe,
>> une route Null0 sur les 2 routeurs en même temps.
>>
>> Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
>> les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
>> => Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
>> problème.
>>
>> Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
>> mais que le L2L tombe.
>>
>> Dans ce cas, un paquet va continuer à arriver par le transit sur le
>> routeur
>> BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
>> mais l'IP de GW étant normalement accessible via le L2L sur un VLAN donné,
>> le routage ne fonctionnera pas car le L2L est tombé.
>>
>> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une solution
>> à
>> ce problème ?
>>
>> Merci,
>> Bonne journée,
>> Fabien
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Oceanet - Cédric BASSAGET

Bonjour Fabien,

Un tunnel GRE entre tes deux routeurs via du transit, et une session 
iBGP sur ce GRE ?

Cédric

OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00

On 02/11/2015 09:16, Fabien H wrote:

Bonjour la liste,

J'ai une question BGP à vous soumettre :

En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
Sur chaque routeur BGP, nous avons au moins un transitaire.

Tout fonctionne parfaitement !

Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
route Null0).
Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
sur le routeur BGP concerné.

- Ma question : Nous aimerions mettre en place un failover BGP automatique
en cas de défaillance matérielle totale d'un des routeurs BGP.

La solution que j'imaginais est de mettre en place, pour un même prefixe,
une route Null0 sur les 2 routeurs en même temps.

Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
=> Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
problème.

Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
mais que le L2L tombe.

Dans ce cas, un paquet va continuer à arriver par le transit sur le routeur
BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
mais l'IP de GW étant normalement accessible via le L2L sur un VLAN donné,
le routage ne fonctionnera pas car le L2L est tombé.

Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une solution à
ce problème ?

Merci,
Bonne journée,
Fabien

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



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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Fabien H
Bonjour Clement,

effectivement ... J'avais l'impression pourtant que je n'étais pas loin du
but. Il y'a juste ce problème de L2L. BGP est très flexible, je pensais
qu'il y'avait une solution pour chaque défaillance ..

Le 2 novembre 2015 09:29, Clement Cavadore  a écrit :

> On Mon, 2015-11-02 at 09:16 +0100, Fabien H wrote:
> > Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
> > solution à ce problème ?
>
> La bonne démarche, c'est de sécuriser le L2L avec un autre, afin de ne
> jamais te retrouver en split brain sur ton ASN :-)
>
> --
> Clément Cavadore
>
>

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


RE: [FRnOG] [TECH] test de débit.

2015-11-02 Par sujet Michel Py
> Choukou Moun a écrit :
> Mon objectif et de pouvoir monter "THE" process qui permet de faire le max de 
> test quand on livre un lien.

BitTorrent sur un torrent populaire. Au hasard : -= Les Profs 2 French DVDRip 
2015 - DeGun TPB =-
13422 seeders, t'auras aucun problème à saturer le lien.

Michel.


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


Re: [FRnOG] [TECH] Gestion boucle L2

2015-11-02 Par sujet Ducassou Laurent

Hello,

Et pourquoi pas tout simplement CWDM (voir DWDM si besoin >16canaux) ?

Si les sites de la boucle sont tes POP c'est de l'actif qu'il faut 
mettre, si c'est des sites clients, à éviter.


Plus transparent que ça coté L2 tu crève ! :)

Laurent

Le 02/11/2015 18:15, Nicolas V a écrit :

Bonjour,

Je cherche à interconnecter plusieurs sites (3 au minima) via une boucle
(de 1 à x*10G entre chaque site avec possibilité éventuelle d'ajout de
liens 1G). Le but étant de pouvoir faire transiter du L2 de manière
transparente.

J'ai suivi le mail de Jérémy Martin "Design réseau L2", mais j'ai quelques
contraintes / une architecture un peu différente :
- Des routeurs ASR9k sur chaque POP => evpn / mpls possible
- Des nexus sur chaque POP => fabricpath possible (mais licence nécessaire)

Je ne suis pas fermé aux autres techno, mais je recherche dans la mesure du
possible, une techno tirant profit du matériel déjà en place pour un coût
raisonnable. Si vous avez d'autres idées qui valent le coup, je reste tout
de même preneur :)

Certains d'entre vous ont il déjà déployés l'une de ces techno
(particulièrement EVPN... peu de docs trouvés là-dessus) et quels en sont
les avantages / inconvénients?

Pouvez vous nous faire partager votre retour d'expérience sur le sujet ?

Merci




--
Laurent DUCASSOU
Opérateur ARCEP L33.1 : UNBO
Cellule Gestion et Exploitation du Réseau REAUMUR
Département Technologies de l'Information et de la Communication
Domaine du Haut-Carré - Bât. C4 - 2nd étage - bureau 214
43 rue Pierre Noailles - 33400 TALENCE
M +33 (0)6 62 91 61 97


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


Re: [FRnOG] [TECH] test de débit.

2015-11-02 Par sujet Choukou Moun
Mon objectif et de pouvoir monter "THE" process qui permet de faire le max
de test quand on livre un lien.

Quel sont les procédures que vous utilisez ?

Merci.
Le 27 oct. 2015 09:53, "Choukou Moun"  a écrit :

> Good morming!
>
> Nice merci pour l'information je vais tester sa.
> Le 27 oct. 2015 09:37, "Pierre DOLIDON"  a écrit :
>
>> Salut.
>>
>> Il y a aussi http://proof.ovh.net/  et pratique,
>> iperf.ovh.net 
>>
>> PIerre.
>>
>>
>> > Le 26 oct. 2015 à 19:45, frnog.kap...@antichef.net a écrit :
>> >
>> > On Monday, October 26, 2015 06:30:28 PM Choukou Moun -
>> choukoum...@gmail.com
>> > wrote:
>> >> Bonjour
>> >>
>> >> Je souhaiterais poser une petite question à la communauté.
>> >>
>> >> Je voudrais savoir si utiliser le site speedtest ou leur technologie
>> >> est-elle fiable pour pouvoir présenter des débits ad client ?
>> >
>> > Même si le test est fiable, un test de débit ne sera pas representatif
>> de la
>> > qualité de la connexion, un client qui a 10Mo/s de débit ne sera pas
>> satisfait
>> > si il y a 1000ms de latence.
>> >
>> > Tu peux tester https://testdebit.info/ qui propose de tester des débits
>> > jusqu'à 10Gb/s, propose l'ipv6 et de faire un test basique de
>> neutralité.
>> >
>> > Et pour avoir la main sur ton test de débit, tu peux le faire toi même
>> avec
>> > iperf
>> >
>> >> Sinon, si vous connaissez une autre façon fiable de tester des débit
>> sur
>> >> internet je suis totalement preneur.
>> >>
>> >> Merci
>> >>
>> >> ---
>> >> 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/
>>
>

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


[FRnOG] [TECH] Gestion boucle L2

2015-11-02 Par sujet Nicolas V
Bonjour,

Je cherche à interconnecter plusieurs sites (3 au minima) via une boucle
(de 1 à x*10G entre chaque site avec possibilité éventuelle d'ajout de
liens 1G). Le but étant de pouvoir faire transiter du L2 de manière
transparente.

J'ai suivi le mail de Jérémy Martin "Design réseau L2", mais j'ai quelques
contraintes / une architecture un peu différente :
- Des routeurs ASR9k sur chaque POP => evpn / mpls possible
- Des nexus sur chaque POP => fabricpath possible (mais licence nécessaire)

Je ne suis pas fermé aux autres techno, mais je recherche dans la mesure du
possible, une techno tirant profit du matériel déjà en place pour un coût
raisonnable. Si vous avez d'autres idées qui valent le coup, je reste tout
de même preneur :)

Certains d'entre vous ont il déjà déployés l'une de ces techno
(particulièrement EVPN... peu de docs trouvés là-dessus) et quels en sont
les avantages / inconvénients?

Pouvez vous nous faire partager votre retour d'expérience sur le sujet ?

Merci

-- 
Nicolas V

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


Re: [FRnOG] [TECH] Gestion boucle L2

2015-11-02 Par sujet David Ponzone
Je pense que son besoin est d’agréger plusieurs liens L2 non ?

> Le 2 nov. 2015 à 18:28, Ducassou Laurent  a 
> écrit :
> 
> Hello,
> 
> Et pourquoi pas tout simplement CWDM (voir DWDM si besoin >16canaux) ?
> 
> Si les sites de la boucle sont tes POP c'est de l'actif qu'il faut mettre, si 
> c'est des sites clients, à éviter.
> 
> Plus transparent que ça coté L2 tu crève ! :)
> 
> Laurent
> 
> Le 02/11/2015 18:15, Nicolas V a écrit :
>> Bonjour,
>> 
>> Je cherche à interconnecter plusieurs sites (3 au minima) via une boucle
>> (de 1 à x*10G entre chaque site avec possibilité éventuelle d'ajout de
>> liens 1G). Le but étant de pouvoir faire transiter du L2 de manière
>> transparente.
>> 
>> J'ai suivi le mail de Jérémy Martin "Design réseau L2", mais j'ai quelques
>> contraintes / une architecture un peu différente :
>> - Des routeurs ASR9k sur chaque POP => evpn / mpls possible
>> - Des nexus sur chaque POP => fabricpath possible (mais licence nécessaire)
>> 
>> Je ne suis pas fermé aux autres techno, mais je recherche dans la mesure du
>> possible, une techno tirant profit du matériel déjà en place pour un coût
>> raisonnable. Si vous avez d'autres idées qui valent le coup, je reste tout
>> de même preneur :)
>> 
>> Certains d'entre vous ont il déjà déployés l'une de ces techno
>> (particulièrement EVPN... peu de docs trouvés là-dessus) et quels en sont
>> les avantages / inconvénients?
>> 
>> Pouvez vous nous faire partager votre retour d'expérience sur le sujet ?
>> 
>> Merci
>> 
> 
> 
> -- 
> Laurent DUCASSOU
> Opérateur ARCEP L33.1 : UNBO
> Cellule Gestion et Exploitation du Réseau REAUMUR
> Département Technologies de l'Information et de la Communication
> Domaine du Haut-Carré - Bât. C4 - 2nd étage - bureau 214
> 43 rue Pierre Noailles - 33400 TALENCE
> M +33 (0)6 62 91 61 97
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet David Ponzone
Oui effectivement, il faut forcer le routage de l’autre extrémité du tunnel GRE 
par le transit, alors que le routeur doit recevoir une route connected 
redistribuée par iBGP.
C’est un peu sioux, mais une route statique en /32 vers le transit doit 
suffire, sans effets de bord à priori.
Attention, route pas le /30 entier car tu dois recevoir des annonces iBGP qui 
viennent du transitaire de l’autre site qui ont l’autre IP dans ce /30 comme 
next-hop.
Ou alors tu fais du next-hop-self sur les sessions iBGP pour ne plus avoir de 
trace du next-hop du transitaire quand tu arrives sur l’autre routeur.

Désolé si c’est pas très clair :)

> Le 2 nov. 2015 à 10:11, Fabien H  a écrit :
> 
> Bonjour David,
> 
> sur chaque site, des SW niveau 2, LNS et serveurs. Donc effectivement un LAN 
> en /24 est dédié pour le routage entre le BGP et les LNS ou Firewalls ou 
> autre. Par contre ce LAN est le même sur les 2 sites (même VLAN, même /24)
> 
> Je suis donc dans le cas 2 : OK même solution que Cédric : 
> 
> Je crois que j'ai compris ce qui ne va pas dans notre archi : Nous filtrons 
> les préfixes plus restreints que /24 en iBGP. 
> Dans le cas 2, vous sous-entendez que même les routes /32 sont échangées en 
> iBGP ? Et donc logiquement pas besoin de  dupliquer les routes /32 sur chaque 
> routeur... Tant qu'une des sessions iBGP est UP, ça fonctionne ! 
> 
> 
> Y'a juste une chose qui me chiffonne un peu , c'est quelles IP publiques 
> utiliser pour le tunnel GRE car il faut que ces IP ne soient pas routées par 
> l'iBGP (actuellement on annonce tous les préfixes des 2 côtés) mais ça je 
> vais étudier..
> 
> Merci beaucoup pour vous retours !
> 
> 
> Le 2 novembre 2015 09:34, David Ponzone  > a écrit :
> Il manque quelques infos je pense.
> Sur chaque site, il y a quoi à part les routeurs BGP ?
> Un LAN avec du hosting ou autre ? J’imagine que oui.
> Le L2L, il relie pas les routeurs directement, mais des switch L2 qui sont 
> derrière les routeurs, je suppose ?
> Autre point qui n’est pas clair: tu as bien un /24 minimum dédié au LAN de 
> chaque site ?
> 
> Ta problématique est donc simple, si je résume:
> Le L2L tombe, mais les 2 routeurs sont OK.
> Chacun annonce les 2 préfixes et donc si le site A reçoit un paquet pour B, 
> c’est mort.
> 
> Cas 1: tu as bien des subnets séparés pour le LAN de chaque site.
> Il faut juste utiliser IP SLA (chez Cisco) sur chaque routeur pour détecter 
> que le L2L est mort, et faire tomber l’annonce du BGP du préfixe de l’autre 
> site.
> 
> Cas 2: les 2 sites partagent le même subnet pour le LAN
> Tunnel GRE entre les 2 routeurs qui passent par leur transit respectif et 
> iBGP dessus, avec un localpref défavorable par rapport à la session iBGP du 
> L2L.
> 
> 
> > Le 2 nov. 2015 à 09:16, Fabien H  > > a écrit :
> >
> > Bonjour la liste,
> >
> > J'ai une question BGP à vous soumettre :
> >
> > En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
> > avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
> > Sur chaque routeur BGP, nous avons au moins un transitaire.
> >
> > Tout fonctionne parfaitement !
> >
> > Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
> > utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
> > route Null0).
> > Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
> > sur le routeur BGP concerné.
> >
> > - Ma question : Nous aimerions mettre en place un failover BGP automatique
> > en cas de défaillance matérielle totale d'un des routeurs BGP.
> >
> > La solution que j'imaginais est de mettre en place, pour un même prefixe,
> > une route Null0 sur les 2 routeurs en même temps.
> >
> > Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
> > les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
> > => Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
> > problème.
> >
> > Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
> > mais que le L2L tombe.
> >
> > Dans ce cas, un paquet va continuer à arriver par le transit sur le routeur
> > BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
> > mais l'IP de GW étant normalement accessible via le L2L sur un VLAN donné,
> > le routage ne fonctionnera pas car le L2L est tombé.
> >
> > Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une solution à
> > ce problème ?
> >
> > Merci,
> > Bonne journée,
> > Fabien
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/ 
> 
> 


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


[FRnOG] [MISC] Contact chez OGM

2015-11-02 Par sujet Arnaud
Salut la liste,

On a un déploiement de fibre interbatiment dans Paris qui est bloqué on ne
sait pas trop pourquoi.
Le prestataire s'appelle OGM, mandaté par OVH à priori. Ils sont basé à
Grands Boulevards à Paris.

Quelqu'un aurait un contact pour faire avancer tout ca ?

Merci et désolé pour le bruit. Je sais qu'avec un nom pareil, ca devrait en
générer :)

Arnaud

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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Fabien H
Oui c'est relativement clair :-)
Je vais étudier ça merci

Le 2 novembre 2015 10:17, David Ponzone  a écrit :

> Oui effectivement, il faut forcer le routage de l’autre extrémité du
> tunnel GRE par le transit, alors que le routeur doit recevoir une route
> connected redistribuée par iBGP.
> C’est un peu sioux, mais une route statique en /32 vers le transit doit
> suffire, sans effets de bord à priori.
> Attention, route pas le /30 entier car tu dois recevoir des annonces iBGP
> qui viennent du transitaire de l’autre site qui ont l’autre IP dans ce /30
> comme next-hop.
> Ou alors tu fais du next-hop-self sur les sessions iBGP pour ne plus avoir
> de trace du next-hop du transitaire quand tu arrives sur l’autre routeur.
>
> Désolé si c’est pas très clair :)
>
> Le 2 nov. 2015 à 10:11, Fabien H  a écrit :
>
> Bonjour David,
>
> sur chaque site, des SW niveau 2, LNS et serveurs. Donc effectivement un
> LAN en /24 est dédié pour le routage entre le BGP et les LNS ou Firewalls
> ou autre. Par contre ce LAN est le même sur les 2 sites (même VLAN, même
> /24)
>
> Je suis donc dans le cas 2 : OK même solution que Cédric :
>
> Je crois que j'ai compris ce qui ne va pas dans notre archi : Nous
> filtrons les préfixes plus restreints que /24 en iBGP.
> Dans le cas 2, vous sous-entendez que même les routes /32 sont échangées
> en iBGP ? Et donc logiquement pas besoin de  dupliquer les routes /32 sur
> chaque routeur... Tant qu'une des sessions iBGP est UP, ça fonctionne !
>
>
> Y'a juste une chose qui me chiffonne un peu , c'est quelles IP publiques
> utiliser pour le tunnel GRE car il faut que ces IP ne soient pas routées
> par l'iBGP (actuellement on annonce tous les préfixes des 2 côtés) mais ça
> je vais étudier..
>
> Merci beaucoup pour vous retours !
>
>
> Le 2 novembre 2015 09:34, David Ponzone  a écrit
> :
>
>> Il manque quelques infos je pense.
>> Sur chaque site, il y a quoi à part les routeurs BGP ?
>> Un LAN avec du hosting ou autre ? J’imagine que oui.
>> Le L2L, il relie pas les routeurs directement, mais des switch L2 qui
>> sont derrière les routeurs, je suppose ?
>> Autre point qui n’est pas clair: tu as bien un /24 minimum dédié au LAN
>> de chaque site ?
>>
>> Ta problématique est donc simple, si je résume:
>> Le L2L tombe, mais les 2 routeurs sont OK.
>> Chacun annonce les 2 préfixes et donc si le site A reçoit un paquet pour
>> B, c’est mort.
>>
>> Cas 1: tu as bien des subnets séparés pour le LAN de chaque site.
>> Il faut juste utiliser IP SLA (chez Cisco) sur chaque routeur pour
>> détecter que le L2L est mort, et faire tomber l’annonce du BGP du préfixe
>> de l’autre site.
>>
>> Cas 2: les 2 sites partagent le même subnet pour le LAN
>> Tunnel GRE entre les 2 routeurs qui passent par leur transit respectif et
>> iBGP dessus, avec un localpref défavorable par rapport à la session iBGP du
>> L2L.
>>
>>
>> > Le 2 nov. 2015 à 09:16, Fabien H  a écrit :
>> >
>> > Bonjour la liste,
>> >
>> > J'ai une question BGP à vous soumettre :
>> >
>> > En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
>> > avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
>> > Sur chaque routeur BGP, nous avons au moins un transitaire.
>> >
>> > Tout fonctionne parfaitement !
>> >
>> > Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
>> > utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
>> > route Null0).
>> > Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
>> > sur le routeur BGP concerné.
>> >
>> > - Ma question : Nous aimerions mettre en place un failover BGP
>> automatique
>> > en cas de défaillance matérielle totale d'un des routeurs BGP.
>> >
>> > La solution que j'imaginais est de mettre en place, pour un même
>> prefixe,
>> > une route Null0 sur les 2 routeurs en même temps.
>> >
>> > Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
>> > les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
>> > => Si un routeur BGP tombe, l'autre va normalement prendre le relais
>> sans
>> > problème.
>> >
>> > Le seul cas qui pose problème, c'est si les 2 routeurs BGP
>> fonctionnement
>> > mais que le L2L tombe.
>> >
>> > Dans ce cas, un paquet va continuer à arriver par le transit sur le
>> routeur
>> > BGP concerné, puis la route statique correspondant à l'IP sera
>> appliquée,
>> > mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
>> donné,
>> > le routage ne fonctionnera pas car le L2L est tombé.
>> >
>> > Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
>> solution à
>> > ce problème ?
>> >
>> > Merci,
>> > Bonne journée,
>> > Fabien
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>>
>
>

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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Raphael Mazelier

Back to basic.

Ton AS ne devrait jamais être disjoint.
Dépendant de ta localisation de tes deux datacenters, le mieux c'est 
quand même de prendre une dark. Si tu ne peux pas tu utilise deux l2l, 
voir un l2l avec backup sur Gre.


2eme point : on redit, tu fait tourner un IGP entre des deux routeurs 
(Ospf, Isis) juste pour les loopbacks de tes routeurs (et les intercos 
si tu veux). Et tu montes tes sessions Ibgp entre ces loopbacks de 
sortes que te sessions IBGP ne doivent jamais tombés (sauf si faillure 
du routeur, mais faillure de path). Et dans ton IBGP tu mets ce que tu 
veux, tes mores specifics (dans ton cas tes /32).




Le 02/11/15 10:23, Fabien H a écrit :

Mais d'ailleurs, 2 lan2lan de 2 fournisseurs différents en place sur le
même SW de part et d'autre ne risquent pas de mal fonctionner ? C'est
transparent ?

Le 2 novembre 2015 09:50, Clement Cavadore  a écrit :


On Mon, 2015-11-02 at 09:41 +0100, Oceanet - Cédric BASSAGET wrote:

Ça c'est la solution quand y'a des sous ;)


Faut se donner les moyens de ses ambitions...  Surtout vu les prix
moyens des lan2lan datacenter-datacenter, de nos jours :-)

--
Clément Cavadore




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




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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Christophe Lucas
Bonjour,

Tu peux pas jouer avec du conditional advertisement en désagrégeant le cas 
échéant en fonctions des
subnets locaux ?
Genre : ton /23, tu l'annonces en temps normal et en cas de coupure tu annonces 
uniquement le /24
local au PE1 et l'autre /24 local au PE2 et ceci si tu reçois en iBGP des 
subnet particulier.

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/16137-cond-adv.html

Cdt
Christophe

2 novembre 2015 10:31 "Fabien H"  a écrit:

> Oui c'est relativement clair :-)
> Je vais étudier ça merci
> 
> Le 2 novembre 2015 10:17, David Ponzone  a écrit :
> 
>> Oui effectivement, il faut forcer le routage de l’autre extrémité du
>> tunnel GRE par le transit, alors que le routeur doit recevoir une route
>> connected redistribuée par iBGP.
>> C’est un peu sioux, mais une route statique en /32 vers le transit doit
>> suffire, sans effets de bord à priori.
>> Attention, route pas le /30 entier car tu dois recevoir des annonces iBGP
>> qui viennent du transitaire de l’autre site qui ont l’autre IP dans ce /30
>> comme next-hop.
>> Ou alors tu fais du next-hop-self sur les sessions iBGP pour ne plus avoir
>> de trace du next-hop du transitaire quand tu arrives sur l’autre routeur.
>> 
>> Désolé si c’est pas très clair :)
>> 
>> Le 2 nov. 2015 à 10:11, Fabien H  a écrit :
>> 
>> Bonjour David,
>> 
>> sur chaque site, des SW niveau 2, LNS et serveurs. Donc effectivement un
>> LAN en /24 est dédié pour le routage entre le BGP et les LNS ou Firewalls
>> ou autre. Par contre ce LAN est le même sur les 2 sites (même VLAN, même
>> /24)
>> 
>> Je suis donc dans le cas 2 : OK même solution que Cédric :
>> 
>> Je crois que j'ai compris ce qui ne va pas dans notre archi : Nous
>> filtrons les préfixes plus restreints que /24 en iBGP.
>> Dans le cas 2, vous sous-entendez que même les routes /32 sont échangées
>> en iBGP ? Et donc logiquement pas besoin de dupliquer les routes /32 sur
>> chaque routeur... Tant qu'une des sessions iBGP est UP, ça fonctionne !
>> 
>> Y'a juste une chose qui me chiffonne un peu , c'est quelles IP publiques
>> utiliser pour le tunnel GRE car il faut que ces IP ne soient pas routées
>> par l'iBGP (actuellement on annonce tous les préfixes des 2 côtés) mais ça
>> je vais étudier..
>> 
>> Merci beaucoup pour vous retours !
>> 
>> Le 2 novembre 2015 09:34, David Ponzone  a écrit
>> :
>> 
>>> Il manque quelques infos je pense.
>>> Sur chaque site, il y a quoi à part les routeurs BGP ?
>>> Un LAN avec du hosting ou autre ? J’imagine que oui.
>>> Le L2L, il relie pas les routeurs directement, mais des switch L2 qui
>>> sont derrière les routeurs, je suppose ?
>>> Autre point qui n’est pas clair: tu as bien un /24 minimum dédié au LAN
>>> de chaque site ?
>>> 
>>> Ta problématique est donc simple, si je résume:
>>> Le L2L tombe, mais les 2 routeurs sont OK.
>>> Chacun annonce les 2 préfixes et donc si le site A reçoit un paquet pour
>>> B, c’est mort.
>>> 
>>> Cas 1: tu as bien des subnets séparés pour le LAN de chaque site.
>>> Il faut juste utiliser IP SLA (chez Cisco) sur chaque routeur pour
>>> détecter que le L2L est mort, et faire tomber l’annonce du BGP du préfixe
>>> de l’autre site.
>>> 
>>> Cas 2: les 2 sites partagent le même subnet pour le LAN
>>> Tunnel GRE entre les 2 routeurs qui passent par leur transit respectif et
>>> iBGP dessus, avec un localpref défavorable par rapport à la session iBGP du
>>> L2L.
>>> 
 Le 2 nov. 2015 à 09:16, Fabien H  a écrit :
 
 Bonjour la liste,
 
 J'ai une question BGP à vous soumettre :
 
 En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
 avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
 Sur chaque routeur BGP, nous avons au moins un transitaire.
 
 Tout fonctionne parfaitement !
 
 Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
 utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
 route Null0).
 Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
 sur le routeur BGP concerné.
 
 - Ma question : Nous aimerions mettre en place un failover BGP
>>> 
>>> automatique
 en cas de défaillance matérielle totale d'un des routeurs BGP.
 
 La solution que j'imaginais est de mettre en place, pour un même
>>> 
>>> prefixe,
 une route Null0 sur les 2 routeurs en même temps.
 
 Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
 les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
 => Si un routeur BGP tombe, l'autre va normalement prendre le relais
>>> 
>>> sans
 problème.
 
 Le seul cas qui pose problème, c'est si les 2 routeurs BGP
>>> 
>>> fonctionnement
 mais que le L2L tombe.
 
 Dans ce cas, un paquet va continuer à arriver par le transit sur le
>>> 

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Fabien H
Bonjour Christophe,
oui intéressant aussi, à creuser. Merci !

Le 2 novembre 2015 10:46, Christophe Lucas  a écrit :

> Bonjour,
>
> Tu peux pas jouer avec du conditional advertisement en désagrégeant le cas
> échéant en fonctions des
> subnets locaux ?
> Genre : ton /23, tu l'annonces en temps normal et en cas de coupure tu
> annonces uniquement le /24
> local au PE1 et l'autre /24 local au PE2 et ceci si tu reçois en iBGP des
> subnet particulier.
>
>
> http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/16137-cond-adv.html
>
> Cdt
> Christophe
>
> 2 novembre 2015 10:31 "Fabien H"  a écrit:
>
> > Oui c'est relativement clair :-)
> > Je vais étudier ça merci
> >
> > Le 2 novembre 2015 10:17, David Ponzone  a
> écrit :
> >
> >> Oui effectivement, il faut forcer le routage de l’autre extrémité du
> >> tunnel GRE par le transit, alors que le routeur doit recevoir une route
> >> connected redistribuée par iBGP.
> >> C’est un peu sioux, mais une route statique en /32 vers le transit doit
> >> suffire, sans effets de bord à priori.
> >> Attention, route pas le /30 entier car tu dois recevoir des annonces
> iBGP
> >> qui viennent du transitaire de l’autre site qui ont l’autre IP dans ce
> /30
> >> comme next-hop.
> >> Ou alors tu fais du next-hop-self sur les sessions iBGP pour ne plus
> avoir
> >> de trace du next-hop du transitaire quand tu arrives sur l’autre
> routeur.
> >>
> >> Désolé si c’est pas très clair :)
> >>
> >> Le 2 nov. 2015 à 10:11, Fabien H  a écrit :
> >>
> >> Bonjour David,
> >>
> >> sur chaque site, des SW niveau 2, LNS et serveurs. Donc effectivement un
> >> LAN en /24 est dédié pour le routage entre le BGP et les LNS ou
> Firewalls
> >> ou autre. Par contre ce LAN est le même sur les 2 sites (même VLAN, même
> >> /24)
> >>
> >> Je suis donc dans le cas 2 : OK même solution que Cédric :
> >>
> >> Je crois que j'ai compris ce qui ne va pas dans notre archi : Nous
> >> filtrons les préfixes plus restreints que /24 en iBGP.
> >> Dans le cas 2, vous sous-entendez que même les routes /32 sont échangées
> >> en iBGP ? Et donc logiquement pas besoin de dupliquer les routes /32 sur
> >> chaque routeur... Tant qu'une des sessions iBGP est UP, ça fonctionne !
> >>
> >> Y'a juste une chose qui me chiffonne un peu , c'est quelles IP publiques
> >> utiliser pour le tunnel GRE car il faut que ces IP ne soient pas routées
> >> par l'iBGP (actuellement on annonce tous les préfixes des 2 côtés) mais
> ça
> >> je vais étudier..
> >>
> >> Merci beaucoup pour vous retours !
> >>
> >> Le 2 novembre 2015 09:34, David Ponzone  a
> écrit
> >> :
> >>
> >>> Il manque quelques infos je pense.
> >>> Sur chaque site, il y a quoi à part les routeurs BGP ?
> >>> Un LAN avec du hosting ou autre ? J’imagine que oui.
> >>> Le L2L, il relie pas les routeurs directement, mais des switch L2 qui
> >>> sont derrière les routeurs, je suppose ?
> >>> Autre point qui n’est pas clair: tu as bien un /24 minimum dédié au LAN
> >>> de chaque site ?
> >>>
> >>> Ta problématique est donc simple, si je résume:
> >>> Le L2L tombe, mais les 2 routeurs sont OK.
> >>> Chacun annonce les 2 préfixes et donc si le site A reçoit un paquet
> pour
> >>> B, c’est mort.
> >>>
> >>> Cas 1: tu as bien des subnets séparés pour le LAN de chaque site.
> >>> Il faut juste utiliser IP SLA (chez Cisco) sur chaque routeur pour
> >>> détecter que le L2L est mort, et faire tomber l’annonce du BGP du
> préfixe
> >>> de l’autre site.
> >>>
> >>> Cas 2: les 2 sites partagent le même subnet pour le LAN
> >>> Tunnel GRE entre les 2 routeurs qui passent par leur transit respectif
> et
> >>> iBGP dessus, avec un localpref défavorable par rapport à la session
> iBGP du
> >>> L2L.
> >>>
>  Le 2 nov. 2015 à 09:16, Fabien H  a écrit :
> 
>  Bonjour la liste,
> 
>  J'ai une question BGP à vous soumettre :
> 
>  En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
>  avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
>  Sur chaque routeur BGP, nous avons au moins un transitaire.
> 
>  Tout fonctionne parfaitement !
> 
>  Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
>  utilisant une route Null0) et un préfixe localisé sur le routeur 2
> (idem
>  route Null0).
>  Puis pour chaque IP /32 dans le prefixe, nous avons des routes
> statiques
>  sur le routeur BGP concerné.
> 
>  - Ma question : Nous aimerions mettre en place un failover BGP
> >>>
> >>> automatique
>  en cas de défaillance matérielle totale d'un des routeurs BGP.
> 
>  La solution que j'imaginais est de mettre en place, pour un même
> >>>
> >>> prefixe,
>  une route Null0 sur les 2 routeurs en même temps.
> 
>  Sur les tests que j'ai fait, ça marche si on duplique la route Null0
> sur
>  les 2 routeurs 

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Oceanet - Cédric BASSAGET
Peut être coupler ton ibgp avec un autre IGP, style OSPF ? Mais ça 
risque d'être assez lourd à faire sur de la prod...

Cédric

OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00

On 02/11/2015 09:33, Fabien H wrote:

Bonjour Cedric,
merci pour la réponse, intéressant !

Malgré tout, comme j'ai des routes statiques et spécifiques vers des 
IP en /32 dupliquées sur chaque routeur BGP, elles seront toujours 
prioritaires sur les routes apprises en iBGP .. Ca doit être le fond 
du problème je pense ..


Le 2 novembre 2015 09:28, Oceanet - Cédric BASSAGET 
> a écrit :


Bonjour Fabien,

Un tunnel GRE entre tes deux routeurs via du transit, et une
session iBGP sur ce GRE ?
Cédric

OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50 
[f] +33 (0)2.43.72.21.14 

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65 
[f] +33 (0)2.52.19.22.00 


On 02/11/2015 09:16, Fabien H wrote:

Bonjour la liste,

J'ai une question BGP à vous soumettre :

En 2 mots : Nous sommes opérateur internet avec 2
localisations : Nous
avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
Sur chaque routeur BGP, nous avons au moins un transitaire.

Tout fonctionne parfaitement !

Actuellement, nous avons un prefixe "localisé" sur le routeur
1 (en
utilisant une route Null0) et un préfixe localisé sur le
routeur 2 (idem
route Null0).
Puis pour chaque IP /32 dans le prefixe, nous avons des routes
statiques
sur le routeur BGP concerné.

- Ma question : Nous aimerions mettre en place un failover BGP
automatique
en cas de défaillance matérielle totale d'un des routeurs BGP.

La solution que j'imaginais est de mettre en place, pour un
même prefixe,
une route Null0 sur les 2 routeurs en même temps.

Sur les tests que j'ai fait, ça marche si on duplique la route
Null0 sur
les 2 routeurs et si on duplique aussi les routes statiques
des IP/32.
=> Si un routeur BGP tombe, l'autre va normalement prendre le
relais sans
problème.

Le seul cas qui pose problème, c'est si les 2 routeurs BGP
fonctionnement
mais que le L2L tombe.

Dans ce cas, un paquet va continuer à arriver par le transit
sur le routeur
BGP concerné, puis la route statique correspondant à l'IP sera
appliquée,
mais l'IP de GW étant normalement accessible via le L2L sur un
VLAN donné,
le routage ne fonctionnera pas car le L2L est tombé.

Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous
une solution à
ce problème ?

Merci,
Bonne journée,
Fabien

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






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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Clement Cavadore
On Mon, 2015-11-02 at 09:41 +0100, Oceanet - Cédric BASSAGET wrote:
> Ça c'est la solution quand y'a des sous ;)

Faut se donner les moyens de ses ambitions...  Surtout vu les prix
moyens des lan2lan datacenter-datacenter, de nos jours :-)

-- 
Clément Cavadore


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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Fabien H
Bonjour David,

sur chaque site, des SW niveau 2, LNS et serveurs. Donc effectivement un
LAN en /24 est dédié pour le routage entre le BGP et les LNS ou Firewalls
ou autre. Par contre ce LAN est le même sur les 2 sites (même VLAN, même
/24)

Je suis donc dans le cas 2 : OK même solution que Cédric :

Je crois que j'ai compris ce qui ne va pas dans notre archi : Nous filtrons
les préfixes plus restreints que /24 en iBGP.
Dans le cas 2, vous sous-entendez que même les routes /32 sont échangées en
iBGP ? Et donc logiquement pas besoin de  dupliquer les routes /32 sur
chaque routeur... Tant qu'une des sessions iBGP est UP, ça fonctionne !


Y'a juste une chose qui me chiffonne un peu , c'est quelles IP publiques
utiliser pour le tunnel GRE car il faut que ces IP ne soient pas routées
par l'iBGP (actuellement on annonce tous les préfixes des 2 côtés) mais ça
je vais étudier..

Merci beaucoup pour vous retours !


Le 2 novembre 2015 09:34, David Ponzone  a écrit :

> Il manque quelques infos je pense.
> Sur chaque site, il y a quoi à part les routeurs BGP ?
> Un LAN avec du hosting ou autre ? J’imagine que oui.
> Le L2L, il relie pas les routeurs directement, mais des switch L2 qui sont
> derrière les routeurs, je suppose ?
> Autre point qui n’est pas clair: tu as bien un /24 minimum dédié au LAN de
> chaque site ?
>
> Ta problématique est donc simple, si je résume:
> Le L2L tombe, mais les 2 routeurs sont OK.
> Chacun annonce les 2 préfixes et donc si le site A reçoit un paquet pour
> B, c’est mort.
>
> Cas 1: tu as bien des subnets séparés pour le LAN de chaque site.
> Il faut juste utiliser IP SLA (chez Cisco) sur chaque routeur pour
> détecter que le L2L est mort, et faire tomber l’annonce du BGP du préfixe
> de l’autre site.
>
> Cas 2: les 2 sites partagent le même subnet pour le LAN
> Tunnel GRE entre les 2 routeurs qui passent par leur transit respectif et
> iBGP dessus, avec un localpref défavorable par rapport à la session iBGP du
> L2L.
>
>
> > Le 2 nov. 2015 à 09:16, Fabien H  a écrit :
> >
> > Bonjour la liste,
> >
> > J'ai une question BGP à vous soumettre :
> >
> > En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
> > avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
> > Sur chaque routeur BGP, nous avons au moins un transitaire.
> >
> > Tout fonctionne parfaitement !
> >
> > Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
> > utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
> > route Null0).
> > Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
> > sur le routeur BGP concerné.
> >
> > - Ma question : Nous aimerions mettre en place un failover BGP
> automatique
> > en cas de défaillance matérielle totale d'un des routeurs BGP.
> >
> > La solution que j'imaginais est de mettre en place, pour un même prefixe,
> > une route Null0 sur les 2 routeurs en même temps.
> >
> > Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
> > les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
> > => Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
> > problème.
> >
> > Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
> > mais que le L2L tombe.
> >
> > Dans ce cas, un paquet va continuer à arriver par le transit sur le
> routeur
> > BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
> > mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
> donné,
> > le routage ne fonctionnera pas car le L2L est tombé.
> >
> > Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
> solution à
> > ce problème ?
> >
> > Merci,
> > Bonne journée,
> > Fabien
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Fabien H
Mais d'ailleurs, 2 lan2lan de 2 fournisseurs différents en place sur le
même SW de part et d'autre ne risquent pas de mal fonctionner ? C'est
transparent ?

Le 2 novembre 2015 09:50, Clement Cavadore  a écrit :

> On Mon, 2015-11-02 at 09:41 +0100, Oceanet - Cédric BASSAGET wrote:
> > Ça c'est la solution quand y'a des sous ;)
>
> Faut se donner les moyens de ses ambitions...  Surtout vu les prix
> moyens des lan2lan datacenter-datacenter, de nos jours :-)
>
> --
> Clément Cavadore
>
>

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


Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

2015-11-02 Par sujet Fabien H
Bonjour Raphael,

Tout à fait, ça parait logique ! D'ailleurs pour les basiques et la mise en
place y'a pas mal de ressources bien faites sur le net notamment les
présentations Workshop d'Arnaud Fernioux. Ca permet de voir si globalement
on est dans les clous ou pas !

Bonne journée !

Le 2 novembre 2015 10:36, Raphael Mazelier  a écrit :

> Back to basic.
>
> Ton AS ne devrait jamais être disjoint.
> Dépendant de ta localisation de tes deux datacenters, le mieux c'est quand
> même de prendre une dark. Si tu ne peux pas tu utilise deux l2l, voir un
> l2l avec backup sur Gre.
>
> 2eme point : on redit, tu fait tourner un IGP entre des deux routeurs
> (Ospf, Isis) juste pour les loopbacks de tes routeurs (et les intercos si
> tu veux). Et tu montes tes sessions Ibgp entre ces loopbacks de sortes que
> te sessions IBGP ne doivent jamais tombés (sauf si faillure du routeur,
> mais faillure de path). Et dans ton IBGP tu mets ce que tu veux, tes mores
> specifics (dans ton cas tes /32).
>
>
>
> Le 02/11/15 10:23, Fabien H a écrit :
>
>> Mais d'ailleurs, 2 lan2lan de 2 fournisseurs différents en place sur le
>> même SW de part et d'autre ne risquent pas de mal fonctionner ? C'est
>> transparent ?
>>
>> Le 2 novembre 2015 09:50, Clement Cavadore  a
>> écrit :
>>
>> On Mon, 2015-11-02 at 09:41 +0100, Oceanet - Cédric BASSAGET wrote:
>>>
 Ça c'est la solution quand y'a des sous ;)

>>>
>>> Faut se donner les moyens de ses ambitions...  Surtout vu les prix
>>> moyens des lan2lan datacenter-datacenter, de nos jours :-)
>>>
>>> --
>>> Clément Cavadore
>>>
>>>
>>>
>> ---
>> 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/


Re: [FRnOG] [TECH] QOS voix switch cisco

2015-11-02 Par sujet Ducassou Laurent

les deux !

* Uplink avec routeur pour priorité sur le trafique sortant surtout 
(vital, ça sera ton principal point de problème !)
* Uplink avec les switchs pour limiter la catastrophe lors de transfert 
entre poste/serveur locaux pour ne pas impacter la téléphonie.


Plus simplement : VOIP = QoS à tous les étages au sens propre ! Dans 
l'idéal, une petite connexion dédié à la VOIP


Laurent

Le 29/10/2015 13:27, Antoine Durant a écrit :

Hello,
Que me conseillez-vous comme orientation sur le choix de la configuration ?
QOS sur le routeur ou QOS sur les uplink du switch ?
A++



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


Re: [FRnOG] [TECH] Gestion boucle L2

2015-11-02 Par sujet Guillaume Barrot
Tu es le client ideal pour
http://www.cisco.com/c/en/us/solutions/data-center-virtualization/data-center-interconnect/index.html
.

FabricPath etant un control plane pour du L2, il ne t'aidera pas a
construire ton forwarding.
Ensuite, en admettant que ta couche de forwarding soit en place (FON ou
xWDM ou EoMPLS), Fabricpath te permettra de faire une interco loopfree.
Le spanningtree marcherait aussi bien sans la possibilité d'avoir tous tes
liens actifs. Point barre.

Donc
 1) choisit ton forwarder :
- FON, pFON
- xWDM
- EoMPLS, Vpls, evpn, pbb-evpn
- OTV
- voire meme, pour le bullshit bingo, VXLAN

2) choisit a quel endroit tu places ton control plane
- toutes les technos d'encaps L3 vont te permettre de t'en affranchir a
l'interieur de l'Overlay (typiquement, evpn "routant" les macs via BGP,
t'assure un design theoriquement loopfree, OTV te le fera via ISIS etc)
- sur du L2 natif (Fon, pFon, Wdm) ou une encapsulation port mode (EoMPLS
port mode), tu peux vouloir un control plane DANS l'overlay. FabricPath
pourra alors te rendre service. (Soyons clair, du MSTP fonctionnera aussi,
mais sans la possibilite d'avoir des liens actifs actifs)

Deux points de vigilance :
- redondance des nPE (comment tu geres le "double attachement" sur un meme
site). Le genre de truc qui a amene le VSS, VPC ou cluster nv sur ASR, pour
resoudre simplement le probleme. Sinon ca sera a base d'ICCP, voir de
scripts EEM (du "SDN" du pauvre quoi)
- quel type de traf tu veux faire passer (l'encaps L2 over L3 ayant
tendance a poser probleme pour du broadcast avec ethertype particuliers,
multicast L2).

Regle de dimensionnement fondamentale : combien de mac tiennent tes
equipements a chaque extremite (le genre de problemes ayant pousse PBB
devant EVPN). Meme remarque sur l'ARP, pour savoir qui pourra jouer le role
de gateway entre autre.

Et un point fondamental si tu etends de vlans avec BVI : ou place tu la
gateway, est-ce que c'est supporte avec ton L2 etendu, comment tu geres le
traf sud-nord (FHRP) et le trafic nord-sud (du simple "actif-passif" au
truc complexe a base de LISP).

Une saine lecture qui date un peu, mais toujours une reference :
http://www.amazon.com/Interconnecting-Continuance-Virtualized-Implementing-Connectivity/dp/1587059924

Un des auteurs est Francais et responsable de la team DCI Cisco a Sophia
Antipolis, autant dire qu'il maitrise le sujet.

Et apres tout ca, bon courage, tu vas en avoir besoin...



Le lundi 2 novembre 2015, Nicolas V  a écrit :

> Bonsoir à tous,
>
> @Laurent & @David
>
> J'aurais du le préciser, le besoin est bien d’agréger des liens L2 de
> différents opérateurs.
>
>
> @Jérôme,
>
> Le transport du L2 est indispensable (même si le L3 uniquement serait
> nettement plus simple à gérer..)
>
> Il est question de propager le L2 sur l'ensemble des sites. Je te remercie
> pour les différentes approches, je vais rechercher un peu d'infos sur
> certains points que tu cites.
>
>
> Personne n'est fan de fabricpath / trop propriétaire pour que quelqu'un s'y
> soit risqué ?
>
>
> Merci à vous
> Nicolas
>
>
> Le 2 novembre 2015 20:28, Jérôme Nicolle >
> a écrit :
>
> > Salut Nicolas,
> >
> > Est ce que le transport L2 est vraiment un prérequis indispensable ? Ne
> > peux tu pas régler en niveau 3, avec des protocoles éprouvés, ce que le
> > L2 a toujours du mal à faire, parce que pas fait pour ?
> >
> > Si tu dois maintenir du L2, s'agirait-il de pseudo-wires (donc point à
> > point) ou de VPLS / E-VPN pour propager du "single domain of failure"
> > sur l'ensemble des sites à chaque fois ?
> >
> > Dans le cas ou tu doive impérativement composer avec les deux types de
> > services, tu as clairement deux approches : full-MPLS, avec des L2VPN et
> > L3VPN cote à cote, ou des tunnels entre switchs virtuels et VRF,
> > idéalement sur un backbone ECMP en IPv6.
> >
> > Sur la seconde approche, du mikrotik fera un boulot au moins aussi bon
> > que des ASR9k au vingtième du prix (jusqu'à 20-30Gbps par ring).
> > Ensuite, entre NFV et ASR1k, tu as plusieurs approches possibles.
> >
> > Si tu veux le faire en MPLS, alors peu importe le constructeur, celui
> > sur le quel tu as le plus de staff opérationnel sera forcement le moins
> > complexe à gérer. Mais mieux vaut un design homogène pour ne pas avoir à
> > traiter la bug-compatibility entre constructeurs, ils ont tendance à
> > régresser ces temps-ci.
> >
> > @+
> >
> > --
> > Jérôme Nicolle
> > 06 19 31 27 14
> >
>
>
>
> --
> Nicolas V
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Cordialement,

Guillaume BARROT

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