[FRnOG] [TECH] Redistribution de routes iBGP

[Aurélien]

Bonjour,

J’ai une question sur une situation toute bête que j’ai sur un AS:

Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en
l’occurence, mais ça importe peu) qui récupère les routes connectées
sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un
transit avec une full view sur chaque routeur. Chaque routeur a aussi
des sessions avec des clients (genre annonce de la route par défaut,
sur AS privé).

Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k
routes préférées via mon transit local, et donc de par le fait, R2 qui
m’annonce ~360k routes IPv4 (la full view moins les routes qu’il
préfère passer par R1).

Mon problème survient quand je coupe l’un de ces transits, mettons sur
R1. La session BGP est coupée, et je withdraw mes annonces de routes à
R2. R2 qui du coup va progressivement m’annoncer le reste de la full
view reçue via son transit.

Le problème, c’est que pendant cette période de convergence, je peux
facilement me retrouver avec des paquets qui m’arrivent de mes
downstreams sur R1, et pour lesquels du coup je n’ai plus de route de
sortie (plus de route par mon transitaire, et R2 ne m’a pas encore
annoncé la route obtenue via son transit).

Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas
très vite avec les routes, ce qui n’arrange pas le souci.

Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
des solutions de configuration pour contourner ou minimiser ce type de
problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
le routeur, on est d’accord).

Merci de vos lumières,

Cordialement,
-- 
Aurélien


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

Re: [FRnOG] [BIZ] Destockage de boitiers d'optimisation WAN Expand

[Jérôme Nicolle]

Le 18/01/2016 13:40, Guillaume Tournat a écrit :
> Expand n'existe plus, et il n'est donc plus possible d'avoir des licences.
> Et sans licence, aucune compression n'est possible...

Sauf que le hardware est quand même bon : Intel Core Mobile en 65 ou
45nm, deux slots de RAM, deux ports gigabit (ou 3 ?), ça doit pas être
bien compliqué de les basculer sous pfSense ou équivalent ;)

Du coup à 50€ pièce, ça peut servir :D

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


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

Re: [FRnOG] [TECH] Quelqu'un pour hoster mon AS ?

[Radu-Adrian Feurdean]

On Mon, Jan 18, 2016, at 23:03, frnog.kap...@antichef.net wrote:
> Ah bon? Moi qui pensait bêtement qu'un AS ça servait à annoncer des préfixes 
> pour permettre de leur faire parvenir des paquets.

Exact, mais pour ca tu n'as pas forcement besoin du tien.

> Si j'avais su que le but de l'AS c'était d'installer apache à la maison,

Pas trop a la maison, sauf si tu habites dans un endroit ou on peut
contenant assez d'infra pour valoir la peine d'avoir son propre ASn.


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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[David CHANIAL]

Bonjour,

> On 19 Jan 2016, at 10:11, Aurélien  wrote:
> 
> Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
> des solutions de configuration pour contourner ou minimiser ce type de
> problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
> le routeur, on est d’accord).

Une ou plusieurs routes par défaut ?
 - statique avec éventuellement du tracking icmp
 - apprise par BGP (les transitaires le proposent sans problème)

Cordialement,
-- 
David CHANIAL 


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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[David Ponzone]

Alors, Solution 1: un serveur genre Dell R610, ça va te coûter 700€ max en 
broke pour une belle conf
Solution 2: tu mets sur chaque routeur une route par défaut vers l’upstream


> Le 19 janv. 2016 à 10:11, Aurélien  a écrit :
> 
> Bonjour,
> 
> J’ai une question sur une situation toute bête que j’ai sur un AS:
> 
> Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en
> l’occurence, mais ça importe peu) qui récupère les routes connectées
> sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un
> transit avec une full view sur chaque routeur. Chaque routeur a aussi
> des sessions avec des clients (genre annonce de la route par défaut,
> sur AS privé).
> 
> Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k
> routes préférées via mon transit local, et donc de par le fait, R2 qui
> m’annonce ~360k routes IPv4 (la full view moins les routes qu’il
> préfère passer par R1).
> 
> Mon problème survient quand je coupe l’un de ces transits, mettons sur
> R1. La session BGP est coupée, et je withdraw mes annonces de routes à
> R2. R2 qui du coup va progressivement m’annoncer le reste de la full
> view reçue via son transit.
> 
> Le problème, c’est que pendant cette période de convergence, je peux
> facilement me retrouver avec des paquets qui m’arrivent de mes
> downstreams sur R1, et pour lesquels du coup je n’ai plus de route de
> sortie (plus de route par mon transitaire, et R2 ne m’a pas encore
> annoncé la route obtenue via son transit).
> 
> Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas
> très vite avec les routes, ce qui n’arrange pas le souci.
> 
> Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
> des solutions de configuration pour contourner ou minimiser ce type de
> problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
> le routeur, on est d’accord).
> 
> Merci de vos lumières,
> 
> Cordialement,
> -- 
> Aurélien
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Serveurs a récupérer.

[Xavier Beaudouin]

Hello,

Juste pour dire qu'ils sont tous partit.

Cordialement,
Xavier


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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[Raphael Mazelier]

Théoriquement chaqun de tes routeurs tu devrais avoir pour chaque pfx 
deux paths, le préféré vers TransitX et l'autre vers TransitY 
(possiblement via ton routeur voisin).
Si tu coupe une session de transit, chaque routeur devrait déjà avoir 
les chemins dans la RIB vers l'autre, pas la peine que ton autre routeur 
les ré annonce en IBGP.
En revanche ce qui peut se passer lors de gros changement de route de ce 
style, c'est des lenteur de changement RIB->FIB.


--
Raphael Mazelier


Le 19/01/16 10:11, Aurélien a écrit :

Bonjour,

J’ai une question sur une situation toute bête que j’ai sur un AS:

Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en
l’occurence, mais ça importe peu) qui récupère les routes connectées
sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un
transit avec une full view sur chaque routeur. Chaque routeur a aussi
des sessions avec des clients (genre annonce de la route par défaut,
sur AS privé).

Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k
routes préférées via mon transit local, et donc de par le fait, R2 qui
m’annonce ~360k routes IPv4 (la full view moins les routes qu’il
préfère passer par R1).

Mon problème survient quand je coupe l’un de ces transits, mettons sur
R1. La session BGP est coupée, et je withdraw mes annonces de routes à
R2. R2 qui du coup va progressivement m’annoncer le reste de la full
view reçue via son transit.

Le problème, c’est que pendant cette période de convergence, je peux
facilement me retrouver avec des paquets qui m’arrivent de mes
downstreams sur R1, et pour lesquels du coup je n’ai plus de route de
sortie (plus de route par mon transitaire, et R2 ne m’a pas encore
annoncé la route obtenue via son transit).

Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas
très vite avec les routes, ce qui n’arrange pas le souci.

Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
des solutions de configuration pour contourner ou minimiser ce type de
problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
le routeur, on est d’accord).

Merci de vos lumières,

Cordialement,




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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[Radu-Adrian Feurdean]

On Tue, Jan 19, 2016, at 16:19, Raphael Mazelier wrote:
> Et comme vous l'avez tous suggéré il existe plusieurs palliatifs :
> 
>   - faire en sorte de ré-annoncer dans IBGP les routes externes non  préférés,
>   - mettre des defaults statiques (et les annoncer dans IBGP), si l'on 
> est sur que le port flap en même temps que la session,
>   - se faire annoncer une default par les transitaires, ce qui reste le plus 
> propre.
>   - ou comme vous le remarquiez, si cela converge si lentement que cela, 
> il faut faire un choix entre la diversité des routes et la rapidité, aka 
> filtrer le nombre de route. As ton vraiment besoin d'une full ?

 - Internet dans un VRF, avec un RD different pour les deux routeurs.
 SUP720 s'abstenir.


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

RE: [FRnOG] [TECH] Redistribution de routes iBGP

[Michel Py]

> Aurélien a écrit :
> Le problème, c’est que pendant cette période de convergence, je peux 
> facilement me retrouver avec des
> paquets qui m’arrivent de mes downstreams sur R1, et pour lesquels du coup je 
> n’ai plus de route de
> sortie (plus de route par mon transitaire, et R2 ne m’a pas encore annoncé la 
> route obtenue via son transit).

IMHO : la meilleure des solutions est de recevoir une route par défaut de tes 2 
transitaires (s'ils t'envoient déjà un full-feed, çà ne devrait pas être trop 
compliqué).

Ce que tu peux aussi faire, c'est ce qu'on appelle chez cisco une route 
floating static : une route statique avec une distance administrative élevée, 
et qui tracke la disponibilité; c'est moins bien; suivant comment le tracking 
est fait il pourrait continuer à garder la route alors que le pair est 
indisponible.

Si c'est uniquement à des fins de maintenance, alors la solution est simple : 
tu mets une route par défaut en dur sur le routeur qui va rester up, tu la 
redistribues, et tu l'enlèves quand tu as fini.

Michel.


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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[Olivier Benghozi]

Ça a surtout du sens avec des Route Reflectors, je pense. Voire pour 
loadbalancer entre des PE dans un réseau.

Dans le cas d'espèce les routes externes ne sortiront de la VRF vers l'i-MP-BGP 
que si elles sont best, RD différent ou pas...

> Le 19 janv. 2016 à 19:54, Radu-Adrian Feurdean 
>  a écrit :
> 
> - Internet dans un VRF, avec un RD different pour les deux routeurs.
> SUP720 s'abstenir.


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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[Olivier Benghozi]

Je pense qu'une default static sur un transit, ce n'est pas forcément un bon 
plan. Tu ne sais jamais trop si tu es branché sur un port de routeur en direct 
ou via un switch intermédiaire (auquel cas le port ne tombe pas même s'il n'y a 
plus personne de l'autre coté), ou même simplement si le routeur d'en face a 
encore toute sa tête (son control place, quoi :) ).
Un plan à blackhole, je trouve :P

Se faire annoncer une default me semble plus pertinent.

> Le 19 janv. 2016 à 14:25, Pierre-Yves Maunier  a 
> écrit :
> 
> La solution la plus propre serait d'avoir au moins 2 transitaires sur
> chaque routeur pour éviter ce désagrément. (genre les 2 meme transitaires a
> chaque fois sur les 2 si tu ne veux pas les multiplier).
> 
> Sinon route par défaut. Eventuellement statique vers le transitaire local
> et annoncée en iBGP a son copain d'à côté.
> Comme ca chaque routeur aurait dans sa table de routage :
> 
> 
> 0.0.0.0/0 -> static/5 next-hop transitaire localement raccordé
>bgp/170 next-hop mon pote iBGP qui enverra vers son
> transit localement raccordé
> 
> quand tu coupes le BGP, ca utilisera la default statique.
> Si tu coupes l'interfaces, la statique tombe et ca utilisera celle apprise
> en iBGP.
> 
> Le 19 janvier 2016 à 10:11, Aurélien  a écrit :
> 
>> Bonjour,
>> 
>> J’ai une question sur une situation toute bête que j’ai sur un AS:
>> 
>> Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en
>> l’occurence, mais ça importe peu) qui récupère les routes connectées
>> sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un
>> transit avec une full view sur chaque routeur. Chaque routeur a aussi
>> des sessions avec des clients (genre annonce de la route par défaut,
>> sur AS privé).
>> 
>> Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k
>> routes préférées via mon transit local, et donc de par le fait, R2 qui
>> m’annonce ~360k routes IPv4 (la full view moins les routes qu’il
>> préfère passer par R1).
>> 
>> Mon problème survient quand je coupe l’un de ces transits, mettons sur
>> R1. La session BGP est coupée, et je withdraw mes annonces de routes à
>> R2. R2 qui du coup va progressivement m’annoncer le reste de la full
>> view reçue via son transit.
>> 
>> Le problème, c’est que pendant cette période de convergence, je peux
>> facilement me retrouver avec des paquets qui m’arrivent de mes
>> downstreams sur R1, et pour lesquels du coup je n’ai plus de route de
>> sortie (plus de route par mon transitaire, et R2 ne m’a pas encore
>> annoncé la route obtenue via son transit).
>> 
>> Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas
>> très vite avec les routes, ce qui n’arrange pas le souci.
>> 
>> Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
>> des solutions de configuration pour contourner ou minimiser ce type de
>> problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
>> le routeur, on est d’accord).
>> 
>> Merci de vos lumières,
>> 
>> Cordialement,
>> --
>> Aurélien
>> 
>> 
>> ---
>> 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] Redistribution de routes iBGP

[Pierre-Yves Maunier]

La solution la plus propre serait d'avoir au moins 2 transitaires sur
chaque routeur pour éviter ce désagrément. (genre les 2 meme transitaires a
chaque fois sur les 2 si tu ne veux pas les multiplier).

Sinon route par défaut. Eventuellement statique vers le transitaire local
et annoncée en iBGP a son copain d'à côté.
Comme ca chaque routeur aurait dans sa table de routage :


0.0.0.0/0 -> static/5 next-hop transitaire localement raccordé
bgp/170 next-hop mon pote iBGP qui enverra vers son
transit localement raccordé

quand tu coupes le BGP, ca utilisera la default statique.
Si tu coupes l'interfaces, la statique tombe et ca utilisera celle apprise
en iBGP.

Le 19 janvier 2016 à 10:11, Aurélien  a écrit :

> Bonjour,
>
> J’ai une question sur une situation toute bête que j’ai sur un AS:
>
> Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en
> l’occurence, mais ça importe peu) qui récupère les routes connectées
> sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un
> transit avec une full view sur chaque routeur. Chaque routeur a aussi
> des sessions avec des clients (genre annonce de la route par défaut,
> sur AS privé).
>
> Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k
> routes préférées via mon transit local, et donc de par le fait, R2 qui
> m’annonce ~360k routes IPv4 (la full view moins les routes qu’il
> préfère passer par R1).
>
> Mon problème survient quand je coupe l’un de ces transits, mettons sur
> R1. La session BGP est coupée, et je withdraw mes annonces de routes à
> R2. R2 qui du coup va progressivement m’annoncer le reste de la full
> view reçue via son transit.
>
> Le problème, c’est que pendant cette période de convergence, je peux
> facilement me retrouver avec des paquets qui m’arrivent de mes
> downstreams sur R1, et pour lesquels du coup je n’ai plus de route de
> sortie (plus de route par mon transitaire, et R2 ne m’a pas encore
> annoncé la route obtenue via son transit).
>
> Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas
> très vite avec les routes, ce qui n’arrange pas le souci.
>
> Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
> des solutions de configuration pour contourner ou minimiser ce type de
> problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
> le routeur, on est d’accord).
>
> Merci de vos lumières,
>
> Cordialement,
> --
> Aurélien
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[Aurélien]

2016-01-19 14:25 GMT+01:00 Pierre-Yves Maunier :
> La solution la plus propre serait d'avoir au moins 2 transitaires sur chaque
> routeur pour éviter ce désagrément. (genre les 2 meme transitaires a chaque
> fois sur les 2 si tu ne veux pas les multiplier).
>
> Sinon route par défaut. Eventuellement statique vers le transitaire local et
> annoncée en iBGP a son copain d'à côté.
> Comme ca chaque routeur aurait dans sa table de routage :
>
>
> 0.0.0.0/0 -> static/5 next-hop transitaire localement raccordé
> bgp/170 next-hop mon pote iBGP qui enverra vers son
> transit localement raccordé
>
> quand tu coupes le BGP, ca utilisera la default statique.
> Si tu coupes l'interfaces, la statique tombe et ca utilisera celle apprise
> en iBGP.
>

Je vais creuser ces pistes.

Merci !

Cordialement,
-- 
Aurélien Guillaume


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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[Olivier Benghozi]

C'est bien comme ça que ça marche. Les routes iBGP best font que la route eBGP 
correspondante (si elle existe) ne sera pas annoncée vers le peer iBGP (et ne 
sera pas celle poussée en FIB).

L'objectif serait de s'assurer que les deux routeurs ont toutes les routes des 
deux transits...
Dans ce cas, pour annoncer à coup sûr la best external aux peers (même si ce 
n'est pas la best "overall" du routeur) - et ainsi faire comme ce que la RFC 
prévoyait au départ (mais que personne ne fait par défaut parce que ça 
multiplie le nombre de routes échangées), il faut utiliser une commande pour 
modifier ces annonces coté iBGP:
- bgp advertise-best-external chez Cisco en IOS, advertise best-external en 
IOS-XR
- advertise-external + advertise-inactive chez Juniper
- advertise-external chez ALU

De cette façon les deux routeurs ont tous les deux toutes les routes des deux 
transits en RIB, en permanence (en RIB ou dans la table BGP qui va bien, 
d'ailleurs).

Quoi qu'il en soit, s'ils ont un CPU de tortue rhumatisante, best external ou 
bonne vieille default annoncée par chaque transit, ça sera quand même lent :)
En effet, on a beau advertiser la best external ou avoir une default external, 
si la best est en iBGP alors il faut bien attendre que le routeur d'à coté qui 
aurait perdu son transit envoie un withdraw pour invalider sa route, et qu'on 
puisse utiliser l'external coté FIB.
Par contre le routeur qui a perdu son transit aura déjà toutes les routes de 
son pote (ou une default) sans attendre que l'autre se décide à lui annoncer 
les routes manquantes, à la suite de son propre withdraw.

Mais comme au final, plus un routeur (moisi ou pas d'ailleurs) connait de 
routes et plus il est lent à converger, la default aurait tendance à être plus 
pertinente dans des conditions de CPU perrave...


Conclusion: si pas besoin d'avoir toutes les routes, fais-toi annoncer fullview 
+ default, et filtre à /22 voire /20 et plus large (ou bien filtre sur les 
communities placées par tes transits selon ce que tu veux, pourquoi pas); voire 
default seulement si pas de contre-indication pour ton usage.
Vu que les solutions miraculeuses, y en a pas trop.


> Le 19 janv. 2016 à 13:58, David Ponzone  a écrit :
> 
> Raphael,
> 
> Pour moi, si A reçoit une route de Transit1 (eBGP) et de B (iBGP), et que la 
> route venant de B est la meilleure, il ne redistribue pas la route qu’il a eu 
> de Transit1 à B.
> C’est peut-être variable en fonction des implémentations et/ou de la conf.
> 
>> Le 19 janv. 2016 à 12:42, Raphael Mazelier  a écrit :
>> 
>> 
>> Théoriquement chaqun de tes routeurs tu devrais avoir pour chaque pfx deux 
>> paths, le préféré vers TransitX et l'autre vers TransitY (possiblement via 
>> ton routeur voisin).
>> Si tu coupe une session de transit, chaque routeur devrait déjà avoir les 
>> chemins dans la RIB vers l'autre, pas la peine que ton autre routeur les ré 
>> annonce en IBGP.
>> En revanche ce qui peut se passer lors de gros changement de route de ce 
>> style, c'est des lenteur de changement RIB->FIB.
>> 
>> -- 
>> Raphael Mazelier
>> 
>> 
>> Le 19/01/16 10:11, Aurélien a écrit :
>>> Bonjour,
>>> 
>>> J’ai une question sur une situation toute bête que j’ai sur un AS:
>>> 
>>> Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en
>>> l’occurence, mais ça importe peu) qui récupère les routes connectées
>>> sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un
>>> transit avec une full view sur chaque routeur. Chaque routeur a aussi
>>> des sessions avec des clients (genre annonce de la route par défaut,
>>> sur AS privé).
>>> 
>>> Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k
>>> routes préférées via mon transit local, et donc de par le fait, R2 qui
>>> m’annonce ~360k routes IPv4 (la full view moins les routes qu’il
>>> préfère passer par R1).
>>> 
>>> Mon problème survient quand je coupe l’un de ces transits, mettons sur
>>> R1. La session BGP est coupée, et je withdraw mes annonces de routes à
>>> R2. R2 qui du coup va progressivement m’annoncer le reste de la full
>>> view reçue via son transit.
>>> 
>>> Le problème, c’est que pendant cette période de convergence, je peux
>>> facilement me retrouver avec des paquets qui m’arrivent de mes
>>> downstreams sur R1, et pour lesquels du coup je n’ai plus de route de
>>> sortie (plus de route par mon transitaire, et R2 ne m’a pas encore
>>> annoncé la route obtenue via son transit).
>>> 
>>> Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas
>>> très vite avec les routes, ce qui n’arrange pas le souci.
>>> 
>>> Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
>>> des solutions de configuration pour contourner ou minimiser ce type de
>>> problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
>>> le routeur, on est d’accord).
>>> 
>>> Merci de vos lumières,
>>> 
>>> Cordialement,
>>> 
>> 
>> 
>> 

[FRnOG] [BIZ] Cold Corridor complet 12 baies occasion

[MELLUL Julien]

Bonjour à tous, il n'était pas parti en octobre, je relance mon offre à un prix 
plus bas.

Nous cherchons à céder d'un cold corridor complet d'occasion, en bon état, 
composé de :

* 12 baies en 800* 1000 KNURR 46U
* Portes grillagées avant / arrière avec codes
* 6 PDU APC7553 + 10 PDU no name
* Double porte coulissante d'entrée
* Plaque de fond
* Plafond plexi
* Rails de passage de câbles en aérien

Prix :  3500 EUR

Photos disponibles sur demande

Il est à récupérer sur DRT à Saint Denis.

Si ça peut vous intéresser contactez moi par email.

Julien


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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[David Ponzone]

Raphael,

Pour moi, si A reçoit une route de Transit1 (eBGP) et de B (iBGP), et que la 
route venant de B est la meilleure, il ne redistribue pas la route qu’il a eu 
de Transit1 à B.
C’est peut-être variable en fonction des implémentations et/ou de la conf.

> Le 19 janv. 2016 à 12:42, Raphael Mazelier  a écrit :
> 
> 
> Théoriquement chaqun de tes routeurs tu devrais avoir pour chaque pfx deux 
> paths, le préféré vers TransitX et l'autre vers TransitY (possiblement via 
> ton routeur voisin).
> Si tu coupe une session de transit, chaque routeur devrait déjà avoir les 
> chemins dans la RIB vers l'autre, pas la peine que ton autre routeur les ré 
> annonce en IBGP.
> En revanche ce qui peut se passer lors de gros changement de route de ce 
> style, c'est des lenteur de changement RIB->FIB.
> 
> -- 
> Raphael Mazelier
> 
> 
> Le 19/01/16 10:11, Aurélien a écrit :
>> Bonjour,
>> 
>> J’ai une question sur une situation toute bête que j’ai sur un AS:
>> 
>> Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en
>> l’occurence, mais ça importe peu) qui récupère les routes connectées
>> sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un
>> transit avec une full view sur chaque routeur. Chaque routeur a aussi
>> des sessions avec des clients (genre annonce de la route par défaut,
>> sur AS privé).
>> 
>> Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k
>> routes préférées via mon transit local, et donc de par le fait, R2 qui
>> m’annonce ~360k routes IPv4 (la full view moins les routes qu’il
>> préfère passer par R1).
>> 
>> Mon problème survient quand je coupe l’un de ces transits, mettons sur
>> R1. La session BGP est coupée, et je withdraw mes annonces de routes à
>> R2. R2 qui du coup va progressivement m’annoncer le reste de la full
>> view reçue via son transit.
>> 
>> Le problème, c’est que pendant cette période de convergence, je peux
>> facilement me retrouver avec des paquets qui m’arrivent de mes
>> downstreams sur R1, et pour lesquels du coup je n’ai plus de route de
>> sortie (plus de route par mon transitaire, et R2 ne m’a pas encore
>> annoncé la route obtenue via son transit).
>> 
>> Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas
>> très vite avec les routes, ce qui n’arrange pas le souci.
>> 
>> Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
>> des solutions de configuration pour contourner ou minimiser ce type de
>> problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
>> le routeur, on est d’accord).
>> 
>> Merci de vos lumières,
>> 
>> Cordialement,
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[Pierre-Yves Maunier]

Oui effectivement,

la default apprise sur les transits en BGP que tu forces à être best sur le
routeur qui la reçoit en eBGP pour qu'il puisse la re-annoncer à son copain
(en iBGP) est encore une meilleure solution que la statique.

Le 19 janvier 2016 à 14:46, Olivier Benghozi 
a écrit :

> Je pense qu'une default static sur un transit, ce n'est pas forcément un
> bon plan. Tu ne sais jamais trop si tu es branché sur un port de routeur en
> direct ou via un switch intermédiaire (auquel cas le port ne tombe pas même
> s'il n'y a plus personne de l'autre coté), ou même simplement si le routeur
> d'en face a encore toute sa tête (son control place, quoi :) ).
> Un plan à blackhole, je trouve :P
>
> Se faire annoncer une default me semble plus pertinent.
>
> > Le 19 janv. 2016 à 14:25, Pierre-Yves Maunier 
> a écrit :
> >
> > La solution la plus propre serait d'avoir au moins 2 transitaires sur
> > chaque routeur pour éviter ce désagrément. (genre les 2 meme
> transitaires a
> > chaque fois sur les 2 si tu ne veux pas les multiplier).
> >
> > Sinon route par défaut. Eventuellement statique vers le transitaire local
> > et annoncée en iBGP a son copain d'à côté.
> > Comme ca chaque routeur aurait dans sa table de routage :
> >
> >
> > 0.0.0.0/0 -> static/5 next-hop transitaire localement raccordé
> >bgp/170 next-hop mon pote iBGP qui enverra vers son
> > transit localement raccordé
> >
> > quand tu coupes le BGP, ca utilisera la default statique.
> > Si tu coupes l'interfaces, la statique tombe et ca utilisera celle
> apprise
> > en iBGP.
> >
> > Le 19 janvier 2016 à 10:11, Aurélien  a écrit :
> >
> >> Bonjour,
> >>
> >> J’ai une question sur une situation toute bête que j’ai sur un AS:
> >>
> >> Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en
> >> l’occurence, mais ça importe peu) qui récupère les routes connectées
> >> sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un
> >> transit avec une full view sur chaque routeur. Chaque routeur a aussi
> >> des sessions avec des clients (genre annonce de la route par défaut,
> >> sur AS privé).
> >>
> >> Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k
> >> routes préférées via mon transit local, et donc de par le fait, R2 qui
> >> m’annonce ~360k routes IPv4 (la full view moins les routes qu’il
> >> préfère passer par R1).
> >>
> >> Mon problème survient quand je coupe l’un de ces transits, mettons sur
> >> R1. La session BGP est coupée, et je withdraw mes annonces de routes à
> >> R2. R2 qui du coup va progressivement m’annoncer le reste de la full
> >> view reçue via son transit.
> >>
> >> Le problème, c’est que pendant cette période de convergence, je peux
> >> facilement me retrouver avec des paquets qui m’arrivent de mes
> >> downstreams sur R1, et pour lesquels du coup je n’ai plus de route de
> >> sortie (plus de route par mon transitaire, et R2 ne m’a pas encore
> >> annoncé la route obtenue via son transit).
> >>
> >> Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas
> >> très vite avec les routes, ce qui n’arrange pas le souci.
> >>
> >> Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
> >> des solutions de configuration pour contourner ou minimiser ce type de
> >> problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
> >> le routeur, on est d’accord).
> >>
> >> Merci de vos lumières,
> >>
> >> Cordialement,
> >> --
> >> Aurélien
> >>
> >>
> >> ---
> >> 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] Redistribution de routes iBGP

[David Ponzone]

D’où l’idée d’une static avec tracking, donnée tantôt.
Ca reste un peu de l’arrache comme conf.

Encore une fois, vu le prix d’un serveur bi-pro quadcore avec 24Go de Ram, je 
pense qu’il doit commencer par faire en sorte que son temps de convergence soit 
en dessous de 20-30 secondes.
S’il a besoin de mieux que ça ou si les routeurs sont du soft propriétaire sur 
du hard propriétaire, et si les intercos sont en ethernet, il met un switch 
intermédiaire pour CHAQUE transitaire pour éclater l’interco en 2 VLAN vers 
chaque routeur, en évitant de tirer une autre interco jusqu’au transitaire, et 
il monte une session par VLAN.
Si le transitaire sait le faire bien sûr. S’il ne sait pas, il est moisi, 
change de transitaire au passage :)

> Le 19 janv. 2016 à 14:46, Olivier Benghozi  a 
> écrit :
> 
> Je pense qu'une default static sur un transit, ce n'est pas forcément un bon 
> plan. Tu ne sais jamais trop si tu es branché sur un port de routeur en 
> direct ou via un switch intermédiaire (auquel cas le port ne tombe pas même 
> s'il n'y a plus personne de l'autre coté), ou même simplement si le routeur 
> d'en face a encore toute sa tête (son control place, quoi :) ).
> Un plan à blackhole, je trouve :P
> 
> Se faire annoncer une default me semble plus pertinent.
> 
>> Le 19 janv. 2016 à 14:25, Pierre-Yves Maunier  a 
>> écrit :
>> 
>> La solution la plus propre serait d'avoir au moins 2 transitaires sur
>> chaque routeur pour éviter ce désagrément. (genre les 2 meme transitaires a
>> chaque fois sur les 2 si tu ne veux pas les multiplier).
>> 
>> Sinon route par défaut. Eventuellement statique vers le transitaire local
>> et annoncée en iBGP a son copain d'à côté.
>> Comme ca chaque routeur aurait dans sa table de routage :
>> 
>> 
>> 0.0.0.0/0 -> static/5 next-hop transitaire localement raccordé
>>   bgp/170 next-hop mon pote iBGP qui enverra vers son
>> transit localement raccordé
>> 
>> quand tu coupes le BGP, ca utilisera la default statique.
>> Si tu coupes l'interfaces, la statique tombe et ca utilisera celle apprise
>> en iBGP.
>> 
>> Le 19 janvier 2016 à 10:11, Aurélien  a écrit :
>> 
>>> Bonjour,
>>> 
>>> J’ai une question sur une situation toute bête que j’ai sur un AS:
>>> 
>>> Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en
>>> l’occurence, mais ça importe peu) qui récupère les routes connectées
>>> sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un
>>> transit avec une full view sur chaque routeur. Chaque routeur a aussi
>>> des sessions avec des clients (genre annonce de la route par défaut,
>>> sur AS privé).
>>> 
>>> Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k
>>> routes préférées via mon transit local, et donc de par le fait, R2 qui
>>> m’annonce ~360k routes IPv4 (la full view moins les routes qu’il
>>> préfère passer par R1).
>>> 
>>> Mon problème survient quand je coupe l’un de ces transits, mettons sur
>>> R1. La session BGP est coupée, et je withdraw mes annonces de routes à
>>> R2. R2 qui du coup va progressivement m’annoncer le reste de la full
>>> view reçue via son transit.
>>> 
>>> Le problème, c’est que pendant cette période de convergence, je peux
>>> facilement me retrouver avec des paquets qui m’arrivent de mes
>>> downstreams sur R1, et pour lesquels du coup je n’ai plus de route de
>>> sortie (plus de route par mon transitaire, et R2 ne m’a pas encore
>>> annoncé la route obtenue via son transit).
>>> 
>>> Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas
>>> très vite avec les routes, ce qui n’arrange pas le souci.
>>> 
>>> Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
>>> des solutions de configuration pour contourner ou minimiser ce type de
>>> problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
>>> le routeur, on est d’accord).
>>> 
>>> Merci de vos lumières,
>>> 
>>> Cordialement,
>>> --
>>> Aurélien
>>> 
>>> 
>>> ---
>>> 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] Redistribution de routes iBGP

[Aurélien]

2016-01-19 14:42 GMT+01:00 Olivier Benghozi :

> L'objectif serait de s'assurer que les deux routeurs ont toutes les routes 
> des deux transits...
> Dans ce cas, pour annoncer à coup sûr la best external aux peers (même si ce 
> n'est pas la best "overall" du routeur) - et ainsi faire comme ce que la RFC 
> prévoyait au départ (mais que personne ne fait par défaut parce que ça 
> multiplie le nombre de routes échangées), il faut utiliser une commande pour 
> modifier ces annonces coté iBGP:
> - bgp advertise-best-external chez Cisco en IOS, advertise best-external en 
> IOS-XR
> - advertise-external + advertise-inactive chez Juniper
> - advertise-external chez ALU
>
> De cette façon les deux routeurs ont tous les deux toutes les routes des deux 
> transits en RIB, en permanence (en RIB ou dans la table BGP qui va bien, 
> d'ailleurs).

Effectivement, ça serait la bonne solution, je ne connaissais pas
cette option. Il est vrai que ça rajoute du coup des routes. Mais, du
coup, chaque routeur dispose en permanence d’un hop crédible dans la
RIB, et quand le transit tombe, je peux réinstaller le bon hop en FIB
rapidement.

Dans mon cas, je veux pouvoir faire une maintenance absolument sans
impact quand je veux (ce qui revient à shut un transitaire ou bien
tous les transitaires d’un routeur).

>
> Quoi qu'il en soit, s'ils ont un CPU de tortue rhumatisante, best external ou 
> bonne vieille default annoncée par chaque transit, ça sera quand même lent :)
> En effet, on a beau advertiser la best external ou avoir une default 
> external, si la best est en iBGP alors il faut bien attendre que le routeur 
> d'à coté qui aurait perdu son transit envoie un withdraw pour invalider sa 
> route, et qu'on puisse utiliser l'external coté FIB.
> Par contre le routeur qui a perdu son transit aura déjà toutes les routes de 
> son pote (ou une default) sans attendre que l'autre se décide à lui annoncer 
> les routes manquantes, à la suite de son propre withdraw.
>
> Mais comme au final, plus un routeur (moisi ou pas d'ailleurs) connait de 
> routes et plus il est lent à converger, la default aurait tendance à être 
> plus pertinente dans des conditions de CPU perrave…
>

Effectivement, il y a peut-être quelque chose à faire en filtrant des préfixes.


Merci à tous pour vos retours :)

-- 
Aurélien Guillaume


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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[Raphael Mazelier]

Oui oui tout à fait.
J'avais mal interprété le problème.

Et comme vous l'avez tous suggéré il existe plusieurs palliatifs :

 - faire en sorte de ré-annoncer dans IBGP les routes externes non 
préférés,
 - mettre des defaults statiques (et les annoncer dans IBGP), si l'on 
est sur que le port flap en même temps que la session,
 - se faire annoncer une default par les transitaires, ce qui reste le 
plus propre.
 - ou comme vous le remarquiez, si cela converge si lentement que cela, 
il faut faire un choix entre la diversité des routes et la rapidité, aka 
filtrer le nombre de route. As ton vraiment besoin d'une full ?


Et au final dans ce genre de setup si on veut faire une maintenance 
programmé sur un routeur, ou un transit, le mieux est peut être 
d'assécher le trafic avant ? (alors évidement en cas d'incident...)




Le 19/01/16 13:58, David Ponzone a écrit :

Raphael,

Pour moi, si A reçoit une route de Transit1 (eBGP) et de B (iBGP), et que la 
route venant de B est la meilleure, il ne redistribue pas la route qu’il a eu 
de Transit1 à B.
C’est peut-être variable en fonction des implémentations et/ou de la conf.




--
Raphael Mazelier


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