Le 03/11/15 09:58, Jérôme BERTHIER a écrit :
BFD ne serait pas plus adapté pour faire ça ?
BFD aide a une détection ultra rapide, mais en général ta session IBGP
doit tomber car ta loopback a disparu de ton IGP. Donc un IGP bien tuné
est le premier truc à faire.
--
Raphael Mazelier
Bonjour,
Le 02/11/2015 21:05, Fabien H a écrit :
la session iBGP tombe rapidement (j'ai mis un SLA icmp qui
ping le loopback d'en face),
BFD ne serait pas plus adapté pour faire ça ?
Cdt,
--
Jérôme BERTHIER
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Bonjour,
merci, si j'ai bien compris, cette solution s'approche un peu du
redistribute en EIGRP mais en BGP. C'est effectivement à tester.
Mais je bloque toujours sur le besoin de failover Routeur BGP.
Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2 ne
pourra pas assurer
Bonjour,
Est-ce que vous avez pensé à mettre une solution avec du "redistribute
static route-map" pour éviter d'annoncer les /32 et du prepend sur les
prefix a backuper ?
Du style :
ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
ip route 5.6.7.8 255.255.255.0 4.4.4.4 name
Le 03/11/2015 10:12, Raphael Mazelier a écrit :
Le 03/11/15 09:58, Jérôme BERTHIER a écrit :
BFD ne serait pas plus adapté pour faire ça ?
BFD aide a une détection ultra rapide, mais en général ta session IBGP
doit tomber car ta loopback a disparu de ton IGP. Donc un IGP bien
tuné est
Le 03/11/15 15:18, Fabien H a écrit :
@Raphael
Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
puis par exemple sur le LNS, il y'a une interface avec un masque en /31
Dans ce cas le mieux c'est que tes équipements FW/LNS annoncent leurs
préfixes aux deux
Le 03/11/2015 17:38, Raphael Mazelier a écrit :
> Oui ça va mieux en le disant :)
Ou en suggérant que ces routeurs soient en plus configurés comme
route-reflectors, pourvu que plusieurs FW s'y mettent ;)
--
Jérôme Nicolle
06 19 31 27 14
---
Liste de diffusion du
Il faudra sans doute dupliquer les routes sur les deux routeurs, mais en
ajoutant du tracking ip sla pour etre sur de les mettre dans la table
uniquement en cas de failover.
Sur R1 :
ip sla 123
icmp-echo IP_LAN_R2 source-ip IP_LAN_R1
frequency 5
ip sla schedule 123 life forever start-time now
Oui, c'est tout à fait ça !
Peut-être juste inverser la condition c'est à dire installer la route quand
R2 n'est pas reachable plutot que quand il est reachable mais apparemment
c'est faisable :
track 456 list boolean and
object 123 not
Ca commence à être tiré par les cheveux .. ! A voir
Le
Exact ! Il faut inverser la condition ;)
2015-11-03 15:01 GMT+01:00 Fabien H :
> Oui, c'est tout à fait ça !
>
> Peut-être juste inverser la condition c'est à dire installer la route
> quand R2 n'est pas reachable plutot que quand il est reachable mais
> apparemment c'est
Tout a fait d'accord avec Raphael !
BGP / OSPF ... c'est pas les proto qui manquent ;)
2015-11-03 16:30 GMT+01:00 Raphael Mazelier :
>
>
> Le 03/11/15 15:18, Fabien H a écrit :
>
>>
>> @Raphael
>>
>> Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
>>
OK d'où les redistribute des routes connected vs routes statiques etc etc
.. C'est très clair maintenant merci !
Le 3 novembre 2015 17:26, Montgomery SIMONPIETRI a écrit :
> Tout a fait d'accord avec Raphael !
> BGP / OSPF ... c'est pas les proto qui manquent ;)
>
Hmmm l'autre option peut être encore plus simple serait simplement de
mettre un poids supérieur à BGP dans la route.
Sur R1 :
ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 250
Si la route BGP disparait (poids de 20 par défaut je crois) alors cest la
statique qui prendrait le
Question : tes /32 correspondent a quoi ? des IPs de services sur des
serveurs ?
Et sinon oui tu mes les /32 sur tes deux routeurs avec des poids différents.
Le 03/11/15 15:06, Montgomery SIMONPIETRI a écrit :
Hmmm l'autre option peut être encore plus simple serait simplement de
mettre un
@Montgomery
Oui, c'est beaucoup plus propre et c'est compatible avec le redistribute,
merci !
@Raphael
Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
puis par exemple sur le LNS, il y'a une interface avec un masque en /31
Le 3 novembre 2015 15:09, Raphael Mazelier
Il vaut mieux que tes équipmentsLNS and Co i annoncent dynamiquement leurs
IP/prefix plutot que de redist des connected du routeur, car tu ne resouds
pas ton probleme d'annonce si un service tombe sur ton LAN
Le mar. 3 nov. 2015 à 17:31, Fabien H a écrit :
> OK d'où les
Si tu optes pour iBGP, oublie pas de bien monter tes sessions de tous tes
LNS/FW/… vers tes 2 routeurs!
> Le 3 nov. 2015 à 17:30, Fabien H a écrit :
>
> OK d'où les redistribute des routes connected vs routes statiques etc etc
> .. C'est très clair maintenant merci !
>
Le 03/11/15 17:35, David Ponzone a écrit :
Si tu optes pour iBGP, oublie pas de bien monter tes sessions de tous tes
LNS/FW/… vers tes 2 routeurs!
Oui ça va mieux en le disant :)
--
Raphael Mazelier
---
Liste de diffusion du FRnOG
http://www.frnog.org/
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 +
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
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
>> 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
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
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
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
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
Ç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
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,
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
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
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 :
>
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,
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
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
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
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
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
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
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
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
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
41 matches
Mail list logo