Re: [FRnOG] BGP announces & RFC1918

[Pierre-Yves Maunier]

On 14/11/2007 08:16, David Ramahefason wrote:

Ben on dit la même chose non ?
Ok je n'ai pas précisé que pour les "gros peers"/Transit on étaient obligé
de faire du max-préfix, mais en général les problèmes ne viennent pas d'eux,
quoi que :p
Le client A peut créer une AS-Macro non ?? ca sert a ca par exemple, mais je
suis d'accord avec toi sur le fait que c'est très restrictif car beaucoup de
peer n'ont pas leur RIPE objects à jour.

David R.
  

Oui effectivement ;-)
Le point sur lequel je suis d'accord et sur lequel je fait la même chose 
que toi : je force...euh...non, plutôt je suggère mes clients de créer 
leurs objets routes (si ce n'est déjà fait) avant que je mette à jour ma 
prefix-list. Tant que l'objet route n'existe pas, je filtre et ne 
l'annonce pas la route. (Valable pour les clients directs voulant 
annoncer un nouveau prefix sur leur AS).


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

Re: [FRnOG] BGP announces & RFC1918

[David Ramahefason]

Ben on dit la même chose non ?
Ok je n'ai pas précisé que pour les "gros peers"/Transit on étaient obligé
de faire du max-préfix, mais en général les problèmes ne viennent pas d'eux,
quoi que :p
Le client A peut créer une AS-Macro non ?? ca sert a ca par exemple, mais je
suis d'accord avec toi sur le fait que c'est très restrictif car beaucoup de
peer n'ont pas leur RIPE objects à jour.

David R.

Le 14/11/07, Pierre-Yves Maunier <[EMAIL PROTECTED]> a écrit :
>
> On 13/11/2007 19:39, David Ramahefason wrote:
> > Ben tu as donné la réponse :)
> > C'est non ce n'est pas normal, mais comme tout le monde ne fait pas
> > forcement attention ben faut filtrer ce que tu reçois, pour cela que je
> > n'aime pas trop les "max-prefix" comme "securité" en peering.
> > Je suis/étais assez partisan des filter-list basées sur les objet RIPE
> mais
> > par chez nous ça ne fonctionne pas très bien (fonctionne trop bien
> plutôt
> > :)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects,
> le
> > truc est peut être de filtrer et forcer les personnes à mettre à jour
> leur
> > records RIPE, ce que j'ai fais un temps.
> > J'ai une moulinette sous la main pour ceux qui veulent pour la
> construction
> > de filter list.
> Le problème est le suivant :
>
> tu as un client transit BGP (client A) qui lui à plusieurs clients
> transit BGP également (clients 1, 2 et 3).
> Les clients 1, 2 et 3 ont leurs objets route à jour.
> Le client A recoit donc les routes de ces clients.
> Le client A va t'annoncer les routes des clients 1, 2 et 3 de façon
> légitime alors qu'il n'y aura pas d'objet route dans la base du ripe
> ayant comme origin AS-clientA pour les routes des clients 1, 2 et 3.
> Donc ce genre de filtre  c'est bien mais un peu restrictif. Il faudrait
> à chaque fois aller plus loin en regardant :
> s'il n'y a pas d'objet route pour cet AS il faut regarder qui annonce
> cette route, si c'est l'AS en question : il faut que l'objet route soit
> créé.
> si c'est un autre AS, il faut vérifier que l'autre AS en question soit
> client transit de ton client, bref c'est gérable manuellement, mais
> automatiquement, bonjour le dev :-)
>
> Surtout que la base du ripe est une base déclarative pas super fiable
> parfois.
>
> Pour ta remarque sur le fait que tu n'aimes pas trop un max-prefix comme
> sécurité sur un peering, tu fais comment si t'as un gros peer qui
> t'envoie 3000 routes et qui peut varier assez régulièrement ? Bon
> généralement faut dire que les gens envoyant un nombre de route dans ces
> environs ne sont pas des boulets et n'envoient pas n'importe quoi non
> plus, je pense qu'on peut les faire confiance avec un max-prefix
> uniquement comme sécurité.
>
> --
> Pierre-Yves
>



-- 
David Ramahefason - [EMAIL PROTECTED]

Re: [FRnOG] BGP announces & RFC1918

[Pierre-Yves Maunier]

On 13/11/2007 20:53, David Ramahefason wrote:

http://www.netfacile.net/cgi-bin/bgp.cgi
  

Ou bien de façon plus conventionnelle ;-)

07:50:12 [EMAIL PROTECTED]:~ {508}
$ grep rroute .bashrc
alias rroute='whois -h whois.ripe.net -i origin -T route'
(traduire : je veux les objets route ayant pour origin le paramètre)
avec un grep route par derrière on obtient juste la liste des routes
Sinon sympa l'outil ;-)

07:50:22 [EMAIL PROTECTED]:~ {509}
$ rroute as
% This is the RIPE Whois query server #1.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.
%   To receive output for a database update, use the "-B" flag.

% Information related to '193.0.0.0/21AS'

route:193.0.0.0/21
descr:RIPE-NCC
origin:   AS
mnt-by:   RIPE-NCC-MNT
source:   RIPE # Filtered

% Information related to '193.0.12.0/23AS'

route:193.0.12.0/23
descr:RIPE-NCC
descr:Specific range for nameserver operations.
origin:   AS
mnt-by:   RIPE-NCC-MNT
source:   RIPE # Filtered

% Information related to '193.0.18.0/23AS'

route:  193.0.18.0/23
descr:  RIPE-NCC
origin: AS
mnt-by: RIPE-NCC-MNT
source: RIPE # Filtered

--
Pierre-Yves Maunier


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

Re: [FRnOG] BGP announces & RFC1918

[Pierre-Yves Maunier]

On 13/11/2007 19:39, David Ramahefason wrote:

Ben tu as donné la réponse :)
C'est non ce n'est pas normal, mais comme tout le monde ne fait pas
forcement attention ben faut filtrer ce que tu reçois, pour cela que je
n'aime pas trop les "max-prefix" comme "securité" en peering.
Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais
par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt
:)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le
truc est peut être de filtrer et forcer les personnes à mettre à jour leur
records RIPE, ce que j'ai fais un temps.
J'ai une moulinette sous la main pour ceux qui veulent pour la construction
de filter list.

Le problème est le suivant :

tu as un client transit BGP (client A) qui lui à plusieurs clients 
transit BGP également (clients 1, 2 et 3).

Les clients 1, 2 et 3 ont leurs objets route à jour.
Le client A recoit donc les routes de ces clients.
Le client A va t'annoncer les routes des clients 1, 2 et 3 de façon 
légitime alors qu'il n'y aura pas d'objet route dans la base du ripe 
ayant comme origin AS-clientA pour les routes des clients 1, 2 et 3.
Donc ce genre de filtre  c'est bien mais un peu restrictif. Il faudrait 
à chaque fois aller plus loin en regardant :
s'il n'y a pas d'objet route pour cet AS il faut regarder qui annonce 
cette route, si c'est l'AS en question : il faut que l'objet route soit 
créé.
si c'est un autre AS, il faut vérifier que l'autre AS en question soit 
client transit de ton client, bref c'est gérable manuellement, mais 
automatiquement, bonjour le dev :-)


Surtout que la base du ripe est une base déclarative pas super fiable 
parfois.


Pour ta remarque sur le fait que tu n'aimes pas trop un max-prefix comme 
sécurité sur un peering, tu fais comment si t'as un gros peer qui 
t'envoie 3000 routes et qui peut varier assez régulièrement ? Bon 
généralement faut dire que les gens envoyant un nombre de route dans ces 
environs ne sont pas des boulets et n'envoient pas n'importe quoi non 
plus, je pense qu'on peut les faire confiance avec un max-prefix 
uniquement comme sécurité.


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

Re: [FRnOG] redondance réseau sur plusieurs sites

[ポール・ ロラン]

Hello,

On Tue, 13 Nov 2007 14:55:18 +0100
Jerome Fleury <[EMAIL PROTECTED]> wrote:

> Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu ne 
> fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi monter 
> une interco IGP entre tes routeurs via un tunnel GRE en forcant 
> l'établissement du tunnel par tes transits (annonce d'un plus spécifique 
> sur chaque transit par exemple).
> Tu mets une bonne grosse métrique sur l'interface Tunnel pour t'assurer 
> qu'elle sert de backup et le tour est joué.
> 
> Pas très propre mais ca devrait fonctionner.
Plus precisement, je dirai que "ca fonctionne", puisque j'ai deja utilise
cette solution ;)

Dans la pratique, c'est un peu plus complexe, car si je reprends un schema que
j'ai vu circule, avec deux operateurs sur le site 1, et deux operateurs sur
le site 2, ca fait potentiellement 4 tunnels differents que l'on peut monter
(Oui, on est redondant "serieux" ou bien on se la joue "petit bras" ;).
 
Il faut ensuite reflechir sur les IP de depart/fin des tunnels (soit elles
font partie des blocs annonces sur chaque site, soit ce soit les IPs
d'interco avec l'uplink de chaque site - mais attention, certains filtres les
annonces des blocs d'interco).
Ensuite, il faut choisir le protocole que l'on passe la dedans (IGP,
BGP, ...). 

Mais surtout : ne pas hesiter a tester tous les cas de pannes possibles !!!
Sur certaines installations faites, nous avons passe plus de temps a definir
tous les cas de ruptures possibles (liens, equipements), les comportements
attendus theoriques, et les comportements reels observes pour la recette,
par rapport au temps necessaire a la mise en place de la solution.

Une chose que je n'ai pas testee, mais je ne crois pas que le constructeur C*
la permette, c'est de monter le tunnel entre les deux sites sur des adresses
IP virtuelles (HSRP/VRRP), ce qui simplifie largement la problematique
des 4 tunnels mentionnes ci-dessus... Qq'un a une idee la-dessus ?

Paul

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

RE: [FRnOG] BGP announces & RFC1918

[Michael Hallgren]

Suis d'accord, sauf que parfois (avec des peers tres riches en cust-routes)
il est doulereux de filtrer par pfx et AS_PATH (AS-Set). Comme on le sais
bien,
le nombre de faux negatifs est parfois assez large quand on se base sur
l'IRR... "max-prefix" a eviter si possible, je suis d'accord en principe
pour des raisons
operationelles. Il y a des schemes alternatifs : age d'un prefix ; avoir
confiance d'un nouveau prefix avec un certain origin en fonction de son age
et out-of-band 
info ; on peut imaginer un "trust rating" via LOCAL_PREF... Si cela
interesse notre liste, discutons ?
 
mh   


  _  

De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de
David Ramahefason
Envoyé : mardi 13 novembre 2007 19:39
À : Greg VILLAIN
Cc : frnog@frnog.org
Objet : Re: [FRnOG] BGP announces & RFC1918


Ben tu as donné la réponse :)
C'est non ce n'est pas normal, mais comme tout le monde ne fait pas
forcement attention ben faut filtrer ce que tu reçois, pour cela que je
n'aime pas trop les "max-prefix" comme "securité" en peering. 
Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais
par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt
:)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le
truc est peut être de filtrer et forcer les personnes à mettre à jour leur
records RIPE, ce que j'ai fais un temps. 
J'ai une moulinette sous la main pour ceux qui veulent pour la construction
de filter list.


Le 13/11/07, Greg VILLAIN <  
[EMAIL PROTECTED]> a écrit : 

On Nov 13, 2007, at 6:56 PM, Greg VILLAIN wrote: 

> Hello, j'en profite que la liste soit bien en éveil en ce moment.
>
> C'est probablement off-topic, mais y'a une discussion NANOG en cours
> sur le theme de "est-ce normal que je reçoive des annonces de type 
> RFC1918" sur nos upstreams.
> La réponse bien évidemment est NON, mais une petite expérimentation
> en cas réel, pour ceux qui ont l'ACL-Accounting, celle-ci est
> édifiante.
> Le but est pas de lancer le troll du siècle, mais plutôt de 
> sensibiliser le filtrage des annonces: c'est censé être trivial,
> mais en fait pas du tout !
>
> [EMAIL PROTECTED] access-list accounting ethernet 1/3 in
> Collecting ACL accounting for 1/3  ...  Completed successfully. 
> ACL Accounting Information:
> Inbound: ACL ACL_IN_TRANSIT-PROVIDER-1
>   5: deny ip 192.168.0.0 0.0.255.255 any log
>  Hit count: (1 sec)1   (1 
> min)   48
> (5 min)  110   (accum)
> 2132627
>   1: deny ip 10.0.0.0 0.255.255.255 any log
>  Hit count: (1 sec)1   (1
> min)   22
> (5 min)   75   (accum)
> 290302
>   3: deny ip 172.16.0.0 0.15.255.255 any log
>  Hit count: (1 sec)0   (1
> min)4
> (5 min)   33   (accum) 
> 148613
>
> [EMAIL PROTECTED] access-list accounting ethernet 1/3 in
> Collecting ACL accounting for 1/3  ...  Completed successfully.
> ACL Accounting Information:
> Inbound: ACL ACL_IN_TRANSIT-PROVIDER-2 
>   5: deny ip 192.168.0.0 0.0.255.255 any log
>  Hit count: (1 sec)0   (1
> min)4
> (5 min)   57   (accum) 
> 1598758
>   1: deny ip 10.0.0.0 0.255.255.255 any log
>  Hit count: (1 sec)1   (1
> min)0 
> (5 min)   27   (accum)
> 312758
>   3: deny ip 172.16.0.0 0.15.255.255 any log
>  Hit count: (1 sec)0   (1 
> min)0
> (5 min)   22   (accum)
> 167969
>
> [EMAIL PROTECTED] access-list accounting ethernet 2/3 in
> Collecting ACL accounting for 2/3  ...  Completed successfully. 
> ACL Accounting Information:
> Inbound: ACL ACL_IN_TRANSIT-PROVIDER-3
>   5: deny ip 192.168.0.0 0.0.255.255 any log
>  Hit count: (1 sec)0   (1 
> min)0
> (5 min)0
> (accum) 4575
>   3: deny ip 172.16.0.0 0.15.255.255   any log
>  Hit count: (1 sec)0   (1
> min)0
> (5 min)0
> (accum)  291
>   1: deny ip 10.0.0.0 0.255.255.255 any log
>  Hit count: (1 sec)0   (1
> min)0
> (5 min)0
> (accum)   75 
>
> Greg VILLAIN

Correction: s/announces/traffic/g dans le sujet et dans le corps du
mail.
Toutes mes confuses pour cette coquille.

Greg VILLAIN

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






-- 
David Ramahefason - [EMAIL PROTECTED] 

Re: [FRnOG] BGP announces & RFC1918

[David Ramahefason]

http://www.netfacile.net/cgi-bin/bgp.cgi

Le 13/11/07, David CHANIAL <[EMAIL PROTECTED]> a écrit :
>
> Le Tuesday 13 November 2007 19:39:07 David Ramahefason, vous avez écrit:
> > J'ai une moulinette sous la main pour ceux qui veulent pour la
> construction
> > de filter list.
>
> Bonjour,
>
> Je serait intéréssais par ta moulinette :)
> Merci d'avance.
>
> Cordialement,
> --
> David CHANIAL
>



-- 
David Ramahefason - [EMAIL PROTECTED]

Re: [FRnOG] BGP announces & RFC1918

[David Ramahefason]

Oui aussi :)


Le 13/11/07, Ronnie Garcia <[EMAIL PROTECTED]> a écrit :
>
> Romain Tournier a écrit :
> > On Tue, Nov 13, 2007 at 07:39:07PM +0100, David Ramahefason wrote:
> >> Ben tu as donné la réponse :)
> >> C'est non ce n'est pas normal, mais comme tout le monde ne fait pas
> >> forcement attention ben faut filtrer ce que tu reçois, pour cela que je
> >> n'aime pas trop les "max-prefix" comme "securité" en peering.
> >> Je suis/étais assez partisan des filter-list basées sur les objet RIPE
> mais
> >> par chez nous ça ne fonctionne pas très bien (fonctionne trop bien
> plutôt
> >> :)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects,
> le
> >> truc est peut être de filtrer et forcer les personnes à mettre à jour
> leur
> >> records RIPE, ce que j'ai fais un temps.
> >> J'ai une moulinette sous la main pour ceux qui veulent pour la
> construction
> >> de filter list.
> >
> > pourquoi ne pas utiliser les bogon-filter, par exemple ?
>
> Avec comme base, la liste "officielle" du CYMRU :
> http://www.cymru.com/Documents/bogon-list.html
>
> --
> Ronnie Garcia 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>


-- 
David Ramahefason - [EMAIL PROTECTED]

Re: [FRnOG] BGP announces & RFC1918

[Ronnie Garcia]

Romain Tournier a écrit :

On Tue, Nov 13, 2007 at 07:39:07PM +0100, David Ramahefason wrote:

Ben tu as donné la réponse :)
C'est non ce n'est pas normal, mais comme tout le monde ne fait pas
forcement attention ben faut filtrer ce que tu reçois, pour cela que je
n'aime pas trop les "max-prefix" comme "securité" en peering.
Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais
par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt
:)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le
truc est peut être de filtrer et forcer les personnes à mettre à jour leur
records RIPE, ce que j'ai fais un temps.
J'ai une moulinette sous la main pour ceux qui veulent pour la construction
de filter list.


pourquoi ne pas utiliser les bogon-filter, par exemple ?


Avec comme base, la liste "officielle" du CYMRU :
http://www.cymru.com/Documents/bogon-list.html

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

Re: [FRnOG] BGP announces & RFC1918

[David CHANIAL]

Le Tuesday 13 November 2007 19:39:07 David Ramahefason, vous avez écrit :
> J'ai une moulinette sous la main pour ceux qui veulent pour la construction
> de filter list.

Bonjour,

Je serait intéréssais par ta moulinette :)
Merci d'avance.

Cordialement,
-- 
David CHANIAL
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] BGP announces & RFC1918

[Romain Tournier]

On Tue, Nov 13, 2007 at 07:39:07PM +0100, David Ramahefason wrote:
> Ben tu as donné la réponse :)
> C'est non ce n'est pas normal, mais comme tout le monde ne fait pas
> forcement attention ben faut filtrer ce que tu reçois, pour cela que je
> n'aime pas trop les "max-prefix" comme "securité" en peering.
> Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais
> par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt
> :)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le
> truc est peut être de filtrer et forcer les personnes à mettre à jour leur
> records RIPE, ce que j'ai fais un temps.
> J'ai une moulinette sous la main pour ceux qui veulent pour la construction
> de filter list.

pourquoi ne pas utiliser les bogon-filter, par exemple ?

> Le 13/11/07, Greg VILLAIN <[EMAIL PROTECTED]> a écrit :
> >
> > On Nov 13, 2007, at 6:56 PM, Greg VILLAIN wrote:
> >
> > > Hello, j'en profite que la liste soit bien en éveil en ce moment.
> > >
> > > C'est probablement off-topic, mais y'a une discussion NANOG en cours
> > > sur le theme de "est-ce normal que je reçoive des annonces de type
> > > RFC1918" sur nos upstreams.
> > > La réponse bien évidemment est NON, mais une petite expérimentation
> > > en cas réel, pour ceux qui ont l'ACL-Accounting, celle-ci est
> > > édifiante.
> > > Le but est pas de lancer le troll du siècle, mais plutôt de
> > > sensibiliser le filtrage des annonces: c'est censé être trivial,
> > > mais en fait pas du tout !
> > >
> > > [EMAIL PROTECTED] access-list accounting ethernet 1/3 in
> > > Collecting ACL accounting for 1/3  ...  Completed successfully.
> > > ACL Accounting Information:
> > > Inbound: ACL ACL_IN_TRANSIT-PROVIDER-1
> > >   5: deny ip 192.168.0.0 0.0.255.255 any log
> > >  Hit count: (1 sec)1   (1
> > > min)   48
> > > (5 min)  110   (accum)
> > > 2132627
> > >   1: deny ip 10.0.0.0 0.255.255.255 any log
> > >  Hit count: (1 sec)1   (1
> > > min)   22
> > > (5 min)   75   (accum)
> > > 290302
> > >   3: deny ip 172.16.0.0 0.15.255.255 any log
> > >  Hit count: (1 sec)0   (1
> > > min)4
> > > (5 min)   33   (accum)
> > > 148613
> > >
> > > [EMAIL PROTECTED] access-list accounting ethernet 1/3 in
> > > Collecting ACL accounting for 1/3  ...  Completed successfully.
> > > ACL Accounting Information:
> > > Inbound: ACL ACL_IN_TRANSIT-PROVIDER-2
> > >   5: deny ip 192.168.0.0 0.0.255.255 any log
> > >  Hit count: (1 sec)0   (1
> > > min)4
> > > (5 min)   57   (accum)
> > > 1598758
> > >   1: deny ip 10.0.0.0 0.255.255.255 any log
> > >  Hit count: (1 sec)1   (1
> > > min)0
> > > (5 min)   27   (accum)
> > > 312758
> > >   3: deny ip 172.16.0.0 0.15.255.255 any log
> > >  Hit count: (1 sec)0   (1
> > > min)0
> > > (5 min)   22   (accum)
> > > 167969
> > >
> > > [EMAIL PROTECTED] access-list accounting ethernet 2/3 in
> > > Collecting ACL accounting for 2/3  ...  Completed successfully.
> > > ACL Accounting Information:
> > > Inbound: ACL ACL_IN_TRANSIT-PROVIDER-3
> > >   5: deny ip 192.168.0.0 0.0.255.255 any log
> > >  Hit count: (1 sec)0   (1
> > > min)0
> > > (5 min)0
> > > (accum) 4575
> > >   3: deny ip 172.16.0.0 0.15.255.255 any log
> > >  Hit count: (1 sec)0   (1
> > > min)0
> > > (5 min)0
> > > (accum)  291
> > >   1: deny ip 10.0.0.0 0.255.255.255 any log
> > >  Hit count: (1 sec)0   (1
> > > min)0
> > > (5 min)0
> > > (accum)   75
> > >
> > > Greg VILLAIN
> >
> > Correction: s/announces/traffic/g dans le sujet et dans le corps du
> > mail.
> > Toutes mes confuses pour cette coquille.
> >
> > Greg VILLAIN
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
> >
> 
> 
> -- 
> David Ramahefason - [EMAIL PROTECTED]

-- 
Romain

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

Re: [FRnOG] BGP announces & RFC1918

[David Ramahefason]

Ben tu as donné la réponse :)
C'est non ce n'est pas normal, mais comme tout le monde ne fait pas
forcement attention ben faut filtrer ce que tu reçois, pour cela que je
n'aime pas trop les "max-prefix" comme "securité" en peering.
Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais
par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt
:)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le
truc est peut être de filtrer et forcer les personnes à mettre à jour leur
records RIPE, ce que j'ai fais un temps.
J'ai une moulinette sous la main pour ceux qui veulent pour la construction
de filter list.

Le 13/11/07, Greg VILLAIN <[EMAIL PROTECTED]> a écrit :
>
> On Nov 13, 2007, at 6:56 PM, Greg VILLAIN wrote:
>
> > Hello, j'en profite que la liste soit bien en éveil en ce moment.
> >
> > C'est probablement off-topic, mais y'a une discussion NANOG en cours
> > sur le theme de "est-ce normal que je reçoive des annonces de type
> > RFC1918" sur nos upstreams.
> > La réponse bien évidemment est NON, mais une petite expérimentation
> > en cas réel, pour ceux qui ont l'ACL-Accounting, celle-ci est
> > édifiante.
> > Le but est pas de lancer le troll du siècle, mais plutôt de
> > sensibiliser le filtrage des annonces: c'est censé être trivial,
> > mais en fait pas du tout !
> >
> > [EMAIL PROTECTED] access-list accounting ethernet 1/3 in
> > Collecting ACL accounting for 1/3  ...  Completed successfully.
> > ACL Accounting Information:
> > Inbound: ACL ACL_IN_TRANSIT-PROVIDER-1
> >   5: deny ip 192.168.0.0 0.0.255.255 any log
> >  Hit count: (1 sec)1   (1
> > min)   48
> > (5 min)  110   (accum)
> > 2132627
> >   1: deny ip 10.0.0.0 0.255.255.255 any log
> >  Hit count: (1 sec)1   (1
> > min)   22
> > (5 min)   75   (accum)
> > 290302
> >   3: deny ip 172.16.0.0 0.15.255.255 any log
> >  Hit count: (1 sec)0   (1
> > min)4
> > (5 min)   33   (accum)
> > 148613
> >
> > [EMAIL PROTECTED] access-list accounting ethernet 1/3 in
> > Collecting ACL accounting for 1/3  ...  Completed successfully.
> > ACL Accounting Information:
> > Inbound: ACL ACL_IN_TRANSIT-PROVIDER-2
> >   5: deny ip 192.168.0.0 0.0.255.255 any log
> >  Hit count: (1 sec)0   (1
> > min)4
> > (5 min)   57   (accum)
> > 1598758
> >   1: deny ip 10.0.0.0 0.255.255.255 any log
> >  Hit count: (1 sec)1   (1
> > min)0
> > (5 min)   27   (accum)
> > 312758
> >   3: deny ip 172.16.0.0 0.15.255.255 any log
> >  Hit count: (1 sec)0   (1
> > min)0
> > (5 min)   22   (accum)
> > 167969
> >
> > [EMAIL PROTECTED] access-list accounting ethernet 2/3 in
> > Collecting ACL accounting for 2/3  ...  Completed successfully.
> > ACL Accounting Information:
> > Inbound: ACL ACL_IN_TRANSIT-PROVIDER-3
> >   5: deny ip 192.168.0.0 0.0.255.255 any log
> >  Hit count: (1 sec)0   (1
> > min)0
> > (5 min)0
> > (accum) 4575
> >   3: deny ip 172.16.0.0 0.15.255.255 any log
> >  Hit count: (1 sec)0   (1
> > min)0
> > (5 min)0
> > (accum)  291
> >   1: deny ip 10.0.0.0 0.255.255.255 any log
> >  Hit count: (1 sec)0   (1
> > min)0
> > (5 min)0
> > (accum)   75
> >
> > Greg VILLAIN
>
> Correction: s/announces/traffic/g dans le sujet et dans le corps du
> mail.
> Toutes mes confuses pour cette coquille.
>
> Greg VILLAIN
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>


-- 
David Ramahefason - [EMAIL PROTECTED]

Re: [FRnOG] BGP announces & RFC1918

[Greg VILLAIN]

On Nov 13, 2007, at 6:56 PM, Greg VILLAIN wrote:


Hello, j'en profite que la liste soit bien en éveil en ce moment.

C'est probablement off-topic, mais y'a une discussion NANOG en cours  
sur le theme de "est-ce normal que je reçoive des annonces de type  
RFC1918" sur nos upstreams.
La réponse bien évidemment est NON, mais une petite expérimentation  
en cas réel, pour ceux qui ont l'ACL-Accounting, celle-ci est  
édifiante.
Le but est pas de lancer le troll du siècle, mais plutôt de  
sensibiliser le filtrage des annonces: c'est censé être trivial,  
mais en fait pas du tout !


[EMAIL PROTECTED] access-list accounting ethernet 1/3 in
Collecting ACL accounting for 1/3  ...  Completed successfully.
ACL Accounting Information:
Inbound: ACL ACL_IN_TRANSIT-PROVIDER-1
  5: deny ip 192.168.0.0 0.0.255.255 any log
 Hit count: (1 sec)1   (1  
min)   48
(5 min)  110   (accum)   
2132627

  1: deny ip 10.0.0.0 0.255.255.255 any log
 Hit count: (1 sec)1   (1  
min)   22
(5 min)   75   (accum)
290302

  3: deny ip 172.16.0.0 0.15.255.255 any log
 Hit count: (1 sec)0   (1  
min)4
(5 min)   33   (accum)
148613


[EMAIL PROTECTED] access-list accounting ethernet 1/3 in
Collecting ACL accounting for 1/3  ...  Completed successfully.
ACL Accounting Information:
Inbound: ACL ACL_IN_TRANSIT-PROVIDER-2
  5: deny ip 192.168.0.0 0.0.255.255 any log
 Hit count: (1 sec)0   (1  
min)4
(5 min)   57   (accum)   
1598758

  1: deny ip 10.0.0.0 0.255.255.255 any log
 Hit count: (1 sec)1   (1  
min)0
(5 min)   27   (accum)
312758

  3: deny ip 172.16.0.0 0.15.255.255 any log
 Hit count: (1 sec)0   (1  
min)0
(5 min)   22   (accum)
167969


[EMAIL PROTECTED] access-list accounting ethernet 2/3 in
Collecting ACL accounting for 2/3  ...  Completed successfully.
ACL Accounting Information:
Inbound: ACL ACL_IN_TRANSIT-PROVIDER-3
  5: deny ip 192.168.0.0 0.0.255.255 any log
 Hit count: (1 sec)0   (1  
min)0
(5 min)0
(accum) 4575

  3: deny ip 172.16.0.0 0.15.255.255 any log
 Hit count: (1 sec)0   (1  
min)0
(5 min)0
(accum)  291

  1: deny ip 10.0.0.0 0.255.255.255 any log
 Hit count: (1 sec)0   (1  
min)0
(5 min)0
(accum)   75


Greg VILLAIN


Correction: s/announces/traffic/g dans le sujet et dans le corps du  
mail.

Toutes mes confuses pour cette coquille.

Greg VILLAIN

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

[FRnOG] BGP announces & RFC1918

[Greg VILLAIN]

Hello, j'en profite que la liste soit bien en éveil en ce moment.

C'est probablement off-topic, mais y'a une discussion NANOG en cours  
sur le theme de "est-ce normal que je reçoive des annonces de type  
RFC1918" sur nos upstreams.
La réponse bien évidemment est NON, mais une petite expérimentation en  
cas réel, pour ceux qui ont l'ACL-Accounting, celle-ci est édifiante.
Le but est pas de lancer le troll du siècle, mais plutôt de  
sensibiliser le filtrage des annonces: c'est censé être trivial, mais  
en fait pas du tout !


[EMAIL PROTECTED] access-list accounting ethernet 1/3 in
Collecting ACL accounting for 1/3  ...  Completed successfully.
ACL Accounting Information:
Inbound: ACL ACL_IN_TRANSIT-PROVIDER-1
   5: deny ip 192.168.0.0 0.0.255.255 any log
  Hit count: (1 sec)1   (1  
min)   48
 (5 min)  110   (accum)   
2132627

   1: deny ip 10.0.0.0 0.255.255.255 any log
  Hit count: (1 sec)1   (1  
min)   22
 (5 min)   75   (accum)
290302

   3: deny ip 172.16.0.0 0.15.255.255 any log
  Hit count: (1 sec)0   (1  
min)4
 (5 min)   33   (accum)
148613


[EMAIL PROTECTED] access-list accounting ethernet 1/3 in
Collecting ACL accounting for 1/3  ...  Completed successfully.
ACL Accounting Information:
Inbound: ACL ACL_IN_TRANSIT-PROVIDER-2
   5: deny ip 192.168.0.0 0.0.255.255 any log
  Hit count: (1 sec)0   (1  
min)4
 (5 min)   57   (accum)   
1598758

   1: deny ip 10.0.0.0 0.255.255.255 any log
  Hit count: (1 sec)1   (1  
min)0
 (5 min)   27   (accum)
312758

   3: deny ip 172.16.0.0 0.15.255.255 any log
  Hit count: (1 sec)0   (1  
min)0
 (5 min)   22   (accum)
167969


[EMAIL PROTECTED] access-list accounting ethernet 2/3 in
Collecting ACL accounting for 2/3  ...  Completed successfully.
ACL Accounting Information:
Inbound: ACL ACL_IN_TRANSIT-PROVIDER-3
   5: deny ip 192.168.0.0 0.0.255.255 any log
  Hit count: (1 sec)0   (1  
min)0
 (5 min)0
(accum) 4575

   3: deny ip 172.16.0.0 0.15.255.255 any log
  Hit count: (1 sec)0   (1  
min)0
 (5 min)0
(accum)  291

   1: deny ip 10.0.0.0 0.255.255.255 any log
  Hit count: (1 sec)0   (1  
min)0
 (5 min)0
(accum)   75


Greg VILLAIN

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

[FRnOG] RE: [FRnOG] redondance réseau sur plusieurs sites

[Wlodek Stankiewicz]

Bonjour,

Je te conseille vivement d'établir une cahier de charge pour la résilience
de ton réseau et même pour ta liaison BGP.
Il y a beaucoup de solutions possible et vérification contre ledit cahier
peut t'aider dans tous ces choix.

On peut aussi formalise la CA en créant un 'failure matrix'. 
Dans la première colonne on liste tous le panne (simple pour commencer) et
dans la second, on spécifie le comportement souhaitable de ton réseau.
N'oubli pas possible impact sur des équipements en aval, firewall, load
balancers, ISP/IDS etc.
Est-ce que tu as besoin de traite les double pannes (normalement c'est n'est
pas nécessaire mais c'est bien de définir un plan d'action en cas ou)? 
Pour BGP, 
- Quelle est utilité de BGP pour ton réseaux ? 
- Est-ce que tu a besoin de tout les routes ?
- Si oui (je ne te crois pas .-) quelle est ta stratégie en cas de surcharge
(ca vas arrive) ?
- Si non - quelle visibilité du monde extérieur est raisonnable pour toi (en
AS ou profondeur de path AS)?

Les solutions standard on été déjà mentionné. 
De toute manier, il faut aussi crée et exécute une cahier de test pour tous
le cas pris en charge dans ta matrice.

Solution de redondance d'un Interlan via WAN sont toujours très délicates et
nécessite beaucoup de test. 
Est-ce que c'est vraiment nécessaire dans ton cas ? Est-ce que les sites
sont indépendantes ? (..CA !!).

Cordialement

Wlodek
[excuse mon français, je traduit du Cro-Magnon]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Raymond Caracatamatere
Sent: Tuesday, November 13, 2007 12:01 AM
To: frnog@frnog.org
Subject: [FRnOG] redondance réseau sur plusieurs sites

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

Re: [FRnOG] redondance réseau sur plusieurs sit es

[Greg VILLAIN]

... nan mais t'as raison, je schématise un peu.
Me souviens de certains mecs prévoyants qui avaient un double anneau  
européen, un coté chez EBone, l'autre chez KPN. Z'étaient contents  
quand le conglomérat des deux a fait faillite après de le rachat de  
l'un par l'autre.


Greg
PS: David: "de ma petite expérience[...]", qui tu crois duper ? ;)

On Nov 13, 2007, at 6:13 PM, David Ramahefason wrote:


Certes Greg,

Mais murphy veille toujours et dans le cas particulier où l'interco  
flanche, si tu n'as pas pris de précaution/pensé à ce qu'il pourrait  
se passer,
le fait d'avoir 2 salles ne te servira a rien sauf a foutre tes  
services en l'air.
La solution de Jerôme est "tricky" mais intéressante, la mienne  
coûte plus cher en matériel, les deux doivent fonctionner et répondre

au problème de perte d'une qui flanche interco entre les 2 sites.
Et de ma petite expérience réseau, le "c'est super redondant, ça ne  
plantera jamais" ben je n'y souscris pas a 100% bien que les technos
s'ameliorent, murphy veille toujours. Mon expérience actuelle ne  
fait que confirmer ce que j'avance, bug multiple sur du matériel  
redondant en anneau et tout et tout de la "mort qui tue".


David

Le 13/11/07, Greg VILLAIN <[EMAIL PROTECTED]> a  
écrit : Rh la solution à haute teneur en classe :) - je trouve  
la solution

particulièrement interessante d'un point de vue esthétique (merci
Jerome & David), mais bon, se payer deux salles si c'est pour bricoler
derrière, j'ai des doutes.

En général, tu prends jamais un point à point pour relier 2 salles si
c'est critique: tu constitue un anneau à partir de deux points à
points achetés chez deux fournisseurs différents, ton IGP annoncera
tes loopbacks BGP pour que quand une patte de l'anneau claque, le
voisin iBGP soit encore intègre.

Dis toi bien que si tu prends deux salles, l'idéal est de prendre un
anneau fibre noire et de l'éclairer toi même, ce qui est simple si
c'est du métro - le passif ne coute plus rien.
Si tout ce que tu gagnes en ayant deux sales, tu le perds en prenant
des liens pourris inter-salles, tu perds tout le bénéfice de ta
redondance de site.

Greg

On Nov 13, 2007, at 3:25 PM, David Ramahefason wrote:

> Si le lien GRE fait partie de l'IGP ca doit pourvoir marcher.
>
>
> Le 13/11/07, Cédric BODIGUEL < [EMAIL PROTECTED] > a
> écrit :En cas de perte de l'interlan, le site1 ne recevra pas les
> prefixes du site2 par le eBGP (et vice versa).
> Il faudrait donc utiliser des routes statiques pour faire
> communiquer les 2 sites ou au moins pour établir le tunnel GRE.
>
> Cedric
>
> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part
> de Jerome Fleury
> Envoyé : mardi 13 novembre 2007 14:55
> À : David Ramahefason
> Cc : Raymond Caracatamatere; frnog@frnog.org
> Objet : Re: [FRnOG] redondance réseau sur plusieurs sites
>
> Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu
> ne fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi
> monter une interco IGP entre tes routeurs via un tunnel GRE en
> forcant l'établissement du tunnel par tes transits (annonce d'un
> plus spécifique sur chaque transit par exemple).
> Tu mets une bonne grosse métrique sur l'interface Tunnel pour
> t'assurer qu'elle sert de backup et le tour est joué.
>
> Pas très propre mais ca devrait fonctionner.
>
> David Ramahefason wrote:
> > Comme dit avant la perte du lien d'interco est la partie la moins
> > triviale à gérer sur ton archi.
> > Pour ce qui est d'annonces des morceaux de classes de part et
> d'autre,
> > ca n'est pas trop l'usage sur les IXs.
> > A la rigueur tu peux jouer sur les communautés de tes Upstream  
comme
> > le disait quelqu'un dans les échanges précédents pour prépender  
vers

> > certains/es IX's/destinations.
> > Une solution à base de SLB (Server Iron / F5 ou autre) pourrait  
peut

> > être fonctionner, vue qu'en cas de coupure de ton intersite tes 2
> > équipements passerait en master, jamais testé, mais je pense que  
ca

> > devrait fonctionner.
> > Par contre cela te fait un autre point de coupure dans le  
réseau, et

> > la gestion de l'adressage s'en voit un peu modifiée.
> >
> >
> >
> > Le 13/11/07, * Raymond Caracatamatere*
> > <[EMAIL PROTECTED]
> > > a écrit :
> >
> > Merci à tous pour toutes ces réponses, la lumière commence à
> se faire.
> > C'est vrai que cette problématique de redondance sur plusieurs
> > sites est très interessante.
> >
> > Vous l'avez compris l'important pour moi est la continuité de
> > service que je dois offrir.
> > Donc avec un seul AS 2 routeurs sur chaques sites avec  
disons 1
> > opérateur sur chaques routeurs et 2 interlan pour y faire  
passer

> > de l'ibgp, cela vous semble la meilleure solution ?
> > Simplement on le sait tous, le réseau n'est jamais 100%  
fiable,
> > que se passera t-il si jamais je perd l'interlan (même  
redondé)

> > mon AS et l'ensemble de mes IP seront annoncés via les deux

Re: [FRnOG] redondance réseau sur plusieurs sites

[David Ramahefason]

Certes Greg,

Mais murphy veille toujours et dans le cas particulier où l'interco flanche,
si tu n'as pas pris de précaution/pensé à ce qu'il pourrait se passer,
le fait d'avoir 2 salles ne te servira a rien sauf a foutre tes services en
l'air.
La solution de Jerôme est "tricky" mais intéressante, la mienne coûte plus
cher en matériel, les deux doivent fonctionner et répondre
au problème de perte d'une qui flanche interco entre les 2 sites.
Et de ma petite expérience réseau, le "c'est super redondant, ça ne plantera
jamais" ben je n'y souscris pas a 100% bien que les technos
s'ameliorent, murphy veille toujours. Mon expérience actuelle ne fait que
confirmer ce que j'avance, bug multiple sur du matériel redondant en anneau
et tout et tout de la "mort qui tue".

David

Le 13/11/07, Greg VILLAIN <[EMAIL PROTECTED]> a écrit :
>
> Rh la solution à haute teneur en classe :) - je trouve la solution
> particulièrement interessante d'un point de vue esthétique (merci
> Jerome & David), mais bon, se payer deux salles si c'est pour bricoler
> derrière, j'ai des doutes.
>
> En général, tu prends jamais un point à point pour relier 2 salles si
> c'est critique: tu constitue un anneau à partir de deux points à
> points achetés chez deux fournisseurs différents, ton IGP annoncera
> tes loopbacks BGP pour que quand une patte de l'anneau claque, le
> voisin iBGP soit encore intègre.
>
> Dis toi bien que si tu prends deux salles, l'idéal est de prendre un
> anneau fibre noire et de l'éclairer toi même, ce qui est simple si
> c'est du métro - le passif ne coute plus rien.
> Si tout ce que tu gagnes en ayant deux sales, tu le perds en prenant
> des liens pourris inter-salles, tu perds tout le bénéfice de ta
> redondance de site.
>
> Greg
>
> On Nov 13, 2007, at 3:25 PM, David Ramahefason wrote:
>
> > Si le lien GRE fait partie de l'IGP ca doit pourvoir marcher.
> >
> >
> > Le 13/11/07, Cédric BODIGUEL <[EMAIL PROTECTED] > a
> > écrit :En cas de perte de l'interlan, le site1 ne recevra pas les
> > prefixes du site2 par le eBGP (et vice versa).
> > Il faudrait donc utiliser des routes statiques pour faire
> > communiquer les 2 sites ou au moins pour établir le tunnel GRE.
> >
> > Cedric
> >
> > -Message d'origine-
> > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part
> > de Jerome Fleury
> > Envoyé : mardi 13 novembre 2007 14:55
> > À : David Ramahefason
> > Cc : Raymond Caracatamatere; frnog@frnog.org
> > Objet : Re: [FRnOG] redondance réseau sur plusieurs sites
> >
> > Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu
> > ne fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi
> > monter une interco IGP entre tes routeurs via un tunnel GRE en
> > forcant l'établissement du tunnel par tes transits (annonce d'un
> > plus spécifique sur chaque transit par exemple).
> > Tu mets une bonne grosse métrique sur l'interface Tunnel pour
> > t'assurer qu'elle sert de backup et le tour est joué.
> >
> > Pas très propre mais ca devrait fonctionner.
> >
> > David Ramahefason wrote:
> > > Comme dit avant la perte du lien d'interco est la partie la moins
> > > triviale à gérer sur ton archi.
> > > Pour ce qui est d'annonces des morceaux de classes de part et
> > d'autre,
> > > ca n'est pas trop l'usage sur les IXs.
> > > A la rigueur tu peux jouer sur les communautés de tes Upstream comme
> > > le disait quelqu'un dans les échanges précédents pour prépender vers
> > > certains/es IX's/destinations.
> > > Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut
> > > être fonctionner, vue qu'en cas de coupure de ton intersite tes 2
> > > équipements passerait en master, jamais testé, mais je pense que ca
> > > devrait fonctionner.
> > > Par contre cela te fait un autre point de coupure dans le réseau, et
> > > la gestion de l'adressage s'en voit un peu modifiée.
> > >
> > >
> > >
> > > Le 13/11/07, * Raymond Caracatamatere*
> > > <[EMAIL PROTECTED]
> > > > a écrit :
> > >
> > > Merci à tous pour toutes ces réponses, la lumière commence à
> > se faire.
> > > C'est vrai que cette problématique de redondance sur plusieurs
> > > sites est très interessante.
> > >
> > > Vous l'avez compris l'important pour moi est la continuité de
> > > service que je dois offrir.
> > > Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1
> > > opérateur sur chaques routeurs et 2 interlan pour y faire passer
> > > de l'ibgp, cela vous semble la meilleure solution ?
> > > Simplement on le sait tous, le réseau n'est jamais 100% fiable,
> > > que se passera t-il si jamais je perd l'interlan (même redondé)
> > > mon AS et l'ensemble de mes IP seront annoncés via les deux
> > sites
> > > mais sans IBGP entre les deux sites quelles seront les
> > conséquences ?
> > >
> > > Aussi vous semblez dire que l'on puisse annoncer des prefixes
> > > différents sur les deux sites (chose que je ne pensais pas
> > > possible) avec le même AS ? n'est 

Re: [FRnOG] redondance réseau sur plusieurs sit es

[Greg VILLAIN]

Rh la solution à haute teneur en classe :) - je trouve la solution  
particulièrement interessante d'un point de vue esthétique (merci  
Jerome & David), mais bon, se payer deux salles si c'est pour bricoler  
derrière, j'ai des doutes.


En général, tu prends jamais un point à point pour relier 2 salles si  
c'est critique: tu constitue un anneau à partir de deux points à  
points achetés chez deux fournisseurs différents, ton IGP annoncera  
tes loopbacks BGP pour que quand une patte de l'anneau claque, le  
voisin iBGP soit encore intègre.


Dis toi bien que si tu prends deux salles, l'idéal est de prendre un  
anneau fibre noire et de l'éclairer toi même, ce qui est simple si  
c'est du métro - le passif ne coute plus rien.
Si tout ce que tu gagnes en ayant deux sales, tu le perds en prenant  
des liens pourris inter-salles, tu perds tout le bénéfice de ta  
redondance de site.


Greg

On Nov 13, 2007, at 3:25 PM, David Ramahefason wrote:


Si le lien GRE fait partie de l'IGP ca doit pourvoir marcher.


Le 13/11/07, Cédric BODIGUEL <[EMAIL PROTECTED] > a  
écrit :En cas de perte de l'interlan, le site1 ne recevra pas les  
prefixes du site2 par le eBGP (et vice versa).
Il faudrait donc utiliser des routes statiques pour faire  
communiquer les 2 sites ou au moins pour établir le tunnel GRE.


Cedric

-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part  
de Jerome Fleury

Envoyé : mardi 13 novembre 2007 14:55
À : David Ramahefason
Cc : Raymond Caracatamatere; frnog@frnog.org
Objet : Re: [FRnOG] redondance réseau sur plusieurs sites

Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu  
ne fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi  
monter une interco IGP entre tes routeurs via un tunnel GRE en  
forcant l'établissement du tunnel par tes transits (annonce d'un  
plus spécifique sur chaque transit par exemple).
Tu mets une bonne grosse métrique sur l'interface Tunnel pour  
t'assurer qu'elle sert de backup et le tour est joué.


Pas très propre mais ca devrait fonctionner.

David Ramahefason wrote:
> Comme dit avant la perte du lien d'interco est la partie la moins
> triviale à gérer sur ton archi.
> Pour ce qui est d'annonces des morceaux de classes de part et  
d'autre,

> ca n'est pas trop l'usage sur les IXs.
> A la rigueur tu peux jouer sur les communautés de tes Upstream comme
> le disait quelqu'un dans les échanges précédents pour prépender vers
> certains/es IX's/destinations.
> Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut
> être fonctionner, vue qu'en cas de coupure de ton intersite tes 2
> équipements passerait en master, jamais testé, mais je pense que ca
> devrait fonctionner.
> Par contre cela te fait un autre point de coupure dans le réseau, et
> la gestion de l'adressage s'en voit un peu modifiée.
>
>
>
> Le 13/11/07, * Raymond Caracatamatere*
> <[EMAIL PROTECTED]
> > a écrit :
>
> Merci à tous pour toutes ces réponses, la lumière commence à  
se faire.

> C'est vrai que cette problématique de redondance sur plusieurs
> sites est très interessante.
>
> Vous l'avez compris l'important pour moi est la continuité de
> service que je dois offrir.
> Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1
> opérateur sur chaques routeurs et 2 interlan pour y faire passer
> de l'ibgp, cela vous semble la meilleure solution ?
> Simplement on le sait tous, le réseau n'est jamais 100% fiable,
> que se passera t-il si jamais je perd l'interlan (même redondé)
> mon AS et l'ensemble de mes IP seront annoncés via les deux  
sites
> mais sans IBGP entre les deux sites quelles seront les  
conséquences ?

>
> Aussi vous semblez dire que l'on puisse annoncer des prefixes
> différents sur les deux sites (chose que je ne pensais pas
> possible) avec le même AS ? n'est ce pas "mal" ? certain d'entre
> vous le font ? l'ont fait ?
> Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2
> annonce mon dernier /24  c'est possible? donc si je perds 1  
salle
> l'autre continu de fonctionner et il me suffirai d'annoncer  
sur la

> salle restante les préfixes de la salle1 pour que le transit se
> fasse via l'interlan ?
>
> Merci encore de vos idées,et de votre forte expérience, cette
> échange est très enrichissant pour moi
>
>
> Le 13/11/07, *Radu-Adrian Feurdean* < [EMAIL PROTECTED]
> > a écrit :
>
>
> On Tue, 13 Nov 2007 08:17:03 +0100, "Geoffroy RIVAT"
> <[EMAIL PROTECTED] > said:
>
> > intersite :
> > bgp routeur 1 =   bgp routeur 3
> > bgp routeur 2 =   bgp routeur 4
>
> Ou plutot que d'avoir deux interco separes (1-3 , 2-4), tu
> peux mettre
> les 4 routeurs sur un /29 sur l'interlan.
> Si en plus tu veux imperativement avoir deux liens pour  
raison de
> r

[FRnOG] RE: [FRnOG] redondance réseau sur plusieurs sites

[Cédric BODIGUEL]

Jérôme,

Je suis d'accord avec toi sur la solution. Je ne parlais pas de mettre du eBGP 
dans le tunnel GRE.

Je voulais juste souligner qu'on ne pouvait pas utiliser le eBGP natif entre 
les sites et qu'établir un tunnel GRE pouvait être un bit plus complexe si on 
le base sur ses propres adresses IP. Je n'ai pas été clair : mea culpa.

FYI, il y a 3 ans, j'avais le même problème : 2 sites, 1 ASN.
J'avais aussi utilisé cette solution GRE avec de l'IGP puis rencontrer des bugs 
CEF+GRE sur C6k et accessoirement des problèmes logiques de MTU ;-)
 
C.

-Message d'origine-
De : Jerome Fleury [mailto:[EMAIL PROTECTED] 
Envoyé : mardi 13 novembre 2007 15:25
À : Cédric BODIGUEL
Cc : Raymond Caracatamatere; David Ramahefason; frnog@frnog.org
Objet : Re: [FRnOG] redondance réseau sur plusieurs sites

Cédric BODIGUEL wrote:
> En cas de perte de l'interlan, le site1 ne recevra pas les prefixes du site2 
> par le eBGP (et vice versa).
> Il faudrait donc utiliser des routes statiques pour faire communiquer les 2 
> sites ou au moins pour établir le tunnel GRE.
>   

Je n'ai pas pas parlé d'eBGP, j'ai parlé de monter une adjacence IGP via une 
interface tunnel.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] RE: [FRnOG] redondance réseau sur plusieurs sites

[Cédric BODIGUEL]

En cas de perte de l'interlan, le site1 ne recevra pas les prefixes du site2 
par le eBGP (et vice versa).
Il faudrait donc utiliser des routes statiques pour faire communiquer les 2 
sites ou au moins pour établir le tunnel GRE.

Cedric

-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Jerome Fleury
Envoyé : mardi 13 novembre 2007 14:55
À : David Ramahefason
Cc : Raymond Caracatamatere; frnog@frnog.org
Objet : Re: [FRnOG] redondance réseau sur plusieurs sites

Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu ne fais 
pas confiance à tes fournisseurs d'Interlan, tu peux aussi monter une interco 
IGP entre tes routeurs via un tunnel GRE en forcant l'établissement du tunnel 
par tes transits (annonce d'un plus spécifique sur chaque transit par exemple).
Tu mets une bonne grosse métrique sur l'interface Tunnel pour t'assurer qu'elle 
sert de backup et le tour est joué.

Pas très propre mais ca devrait fonctionner.

David Ramahefason wrote:
> Comme dit avant la perte du lien d'interco est la partie la moins 
> triviale à gérer sur ton archi.
> Pour ce qui est d'annonces des morceaux de classes de part et d'autre, 
> ca n'est pas trop l'usage sur les IXs.
> A la rigueur tu peux jouer sur les communautés de tes Upstream comme 
> le disait quelqu'un dans les échanges précédents pour prépender vers 
> certains/es IX's/destinations.
> Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut 
> être fonctionner, vue qu'en cas de coupure de ton intersite tes 2 
> équipements passerait en master, jamais testé, mais je pense que ca 
> devrait fonctionner.
> Par contre cela te fait un autre point de coupure dans le réseau, et 
> la gestion de l'adressage s'en voit un peu modifiée.
>
>
>
> Le 13/11/07, * Raymond Caracatamatere* 
> <[EMAIL PROTECTED] 
> > a écrit :
>
> Merci à tous pour toutes ces réponses, la lumière commence à se faire.
> C'est vrai que cette problématique de redondance sur plusieurs
> sites est très interessante.
>
> Vous l'avez compris l'important pour moi est la continuité de
> service que je dois offrir.
> Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1
> opérateur sur chaques routeurs et 2 interlan pour y faire passer
> de l'ibgp, cela vous semble la meilleure solution ?
> Simplement on le sait tous, le réseau n'est jamais 100% fiable,
> que se passera t-il si jamais je perd l'interlan (même redondé)
> mon AS et l'ensemble de mes IP seront annoncés via les deux sites
> mais sans IBGP entre les deux sites quelles seront les conséquences ?
>
> Aussi vous semblez dire que l'on puisse annoncer des prefixes
> différents sur les deux sites (chose que je ne pensais pas
> possible) avec le même AS ? n'est ce pas "mal" ? certain d'entre
> vous le font ? l'ont fait ?
> Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2
> annonce mon dernier /24  c'est possible? donc si je perds 1 salle
> l'autre continu de fonctionner et il me suffirai d'annoncer sur la
> salle restante les préfixes de la salle1 pour que le transit se
> fasse via l'interlan ?
>
> Merci encore de vos idées,et de votre forte expérience, cette
> échange est très enrichissant pour moi
>
>
> Le 13/11/07, *Radu-Adrian Feurdean* < [EMAIL PROTECTED]
> > a écrit :
>
>
> On Tue, 13 Nov 2007 08:17:03 +0100, "Geoffroy RIVAT"
> <[EMAIL PROTECTED] > said:
>
> > intersite :
> > bgp routeur 1 =   bgp routeur 3
> > bgp routeur 2 =   bgp routeur 4
>
> Ou plutot que d'avoir deux interco separes (1-3 , 2-4), tu
> peux mettre
> les 4 routeurs sur un /29 sur l'interlan.
> Si en plus tu veux imperativement avoir deux liens pour raison de
> redondance/securite, tu fais de l'aggregation sur les 2 liens,
> comme ca
> ta bande passante inter-site double.
>
> Apres, c'est a toi de choisir si tu veux faire du full-BGP (tu
> partage
> la bande passante entre tes 2 sites) ou du default-route
> (chaque site
> avec sa route par default en local, l'interlan seulement pour
> rapatrier
> le trafic qui arrive sur le "mauvais" site ou pour le cas ou
> un des
> operateurs sont down).
>
> Pour ce qui est le fait d'annoncer des prefixes separes sur
> chaque site,
> l'idee n'est pas geniale. Au mieux tu annonces les prefixes de
> l'autre
> site avec as-path prepend (ou community pour que ton uplink le
> fait a ta
> place). Ca juste parce-que tu as des /24, probablement pas
> contigues.
> S'il s'agit des bloc qui peuvent etre aggreges, beaucoup de
> gens ici
> vont te detester jusqu'a la fin de tes jours si tu annonces
> chaque bloc
> 

Re: [FRnOG] redondance réseau sur plusieurs sites

[Jerome Fleury]

Cédric BODIGUEL wrote:

En cas de perte de l'interlan, le site1 ne recevra pas les prefixes du site2 
par le eBGP (et vice versa).
Il faudrait donc utiliser des routes statiques pour faire communiquer les 2 
sites ou au moins pour établir le tunnel GRE.
  


Je n'ai pas pas parlé d'eBGP, j'ai parlé de monter une adjacence IGP via 
une interface tunnel.

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

Re: [FRnOG] redondance réseau sur plusieurs sites

[David Ramahefason]

Si le lien GRE fait partie de l'IGP ca doit pourvoir marcher.


Le 13/11/07, Cédric BODIGUEL <[EMAIL PROTECTED]> a écrit :
>
> En cas de perte de l'interlan, le site1 ne recevra pas les prefixes du
> site2 par le eBGP (et vice versa).
> Il faudrait donc utiliser des routes statiques pour faire communiquer les
> 2 sites ou au moins pour établir le tunnel GRE.
>
> Cedric
>
> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de
> Jerome Fleury
> Envoyé : mardi 13 novembre 2007 14:55
> À : David Ramahefason
> Cc : Raymond Caracatamatere; frnog@frnog.org
> Objet : Re: [FRnOG] redondance réseau sur plusieurs sites
>
> Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu ne
> fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi monter une
> interco IGP entre tes routeurs via un tunnel GRE en forcant l'établissement
> du tunnel par tes transits (annonce d'un plus spécifique sur chaque transit
> par exemple).
> Tu mets une bonne grosse métrique sur l'interface Tunnel pour t'assurer
> qu'elle sert de backup et le tour est joué.
>
> Pas très propre mais ca devrait fonctionner.
>
> David Ramahefason wrote:
> > Comme dit avant la perte du lien d'interco est la partie la moins
> > triviale à gérer sur ton archi.
> > Pour ce qui est d'annonces des morceaux de classes de part et d'autre,
> > ca n'est pas trop l'usage sur les IXs.
> > A la rigueur tu peux jouer sur les communautés de tes Upstream comme
> > le disait quelqu'un dans les échanges précédents pour prépender vers
> > certains/es IX's/destinations.
> > Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut
> > être fonctionner, vue qu'en cas de coupure de ton intersite tes 2
> > équipements passerait en master, jamais testé, mais je pense que ca
> > devrait fonctionner.
> > Par contre cela te fait un autre point de coupure dans le réseau, et
> > la gestion de l'adressage s'en voit un peu modifiée.
> >
> >
> >
> > Le 13/11/07, * Raymond Caracatamatere*
> > <[EMAIL PROTECTED]
> > > a écrit :
> >
> > Merci à tous pour toutes ces réponses, la lumière commence à se
> faire.
> > C'est vrai que cette problématique de redondance sur plusieurs
> > sites est très interessante.
> >
> > Vous l'avez compris l'important pour moi est la continuité de
> > service que je dois offrir.
> > Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1
> > opérateur sur chaques routeurs et 2 interlan pour y faire passer
> > de l'ibgp, cela vous semble la meilleure solution ?
> > Simplement on le sait tous, le réseau n'est jamais 100% fiable,
> > que se passera t-il si jamais je perd l'interlan (même redondé)
> > mon AS et l'ensemble de mes IP seront annoncés via les deux sites
> > mais sans IBGP entre les deux sites quelles seront les conséquences
> ?
> >
> > Aussi vous semblez dire que l'on puisse annoncer des prefixes
> > différents sur les deux sites (chose que je ne pensais pas
> > possible) avec le même AS ? n'est ce pas "mal" ? certain d'entre
> > vous le font ? l'ont fait ?
> > Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2
> > annonce mon dernier /24  c'est possible? donc si je perds 1 salle
> > l'autre continu de fonctionner et il me suffirai d'annoncer sur la
> > salle restante les préfixes de la salle1 pour que le transit se
> > fasse via l'interlan ?
> >
> > Merci encore de vos idées,et de votre forte expérience, cette
> > échange est très enrichissant pour moi
> >
> >
> > Le 13/11/07, *Radu-Adrian Feurdean* < [EMAIL PROTECTED]
> > > a écrit :
> >
> >
> > On Tue, 13 Nov 2007 08:17:03 +0100, "Geoffroy RIVAT"
> > <[EMAIL PROTECTED] > said:
> >
> > > intersite :
> > > bgp routeur 1 =   bgp routeur 3
> > > bgp routeur 2 =   bgp routeur 4
> >
> > Ou plutot que d'avoir deux interco separes (1-3 , 2-4), tu
> > peux mettre
> > les 4 routeurs sur un /29 sur l'interlan.
> > Si en plus tu veux imperativement avoir deux liens pour raison
> de
> > redondance/securite, tu fais de l'aggregation sur les 2 liens,
> > comme ca
> > ta bande passante inter-site double.
> >
> > Apres, c'est a toi de choisir si tu veux faire du full-BGP (tu
> > partage
> > la bande passante entre tes 2 sites) ou du default-route
> > (chaque site
> > avec sa route par default en local, l'interlan seulement pour
> > rapatrier
> > le trafic qui arrive sur le "mauvais" site ou pour le cas ou
> > un des
> > operateurs sont down).
> >
> > Pour ce qui est le fait d'annoncer des prefixes separes sur
> > chaque site,
> > l'idee n'est pas geniale. Au mieux tu annonces les prefixes de
> > l'autre
> > site avec as-path prepend (ou communit

Re: [FRnOG] redondance réseau sur plusieurs sites

[Jerome Fleury]

Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu ne 
fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi monter 
une interco IGP entre tes routeurs via un tunnel GRE en forcant 
l'établissement du tunnel par tes transits (annonce d'un plus spécifique 
sur chaque transit par exemple).
Tu mets une bonne grosse métrique sur l'interface Tunnel pour t'assurer 
qu'elle sert de backup et le tour est joué.


Pas très propre mais ca devrait fonctionner.

David Ramahefason wrote:
Comme dit avant la perte du lien d'interco est la partie la moins 
triviale à gérer sur ton archi.
Pour ce qui est d'annonces des morceaux de classes de part et d'autre, 
ca n'est pas trop l'usage sur les IXs.
A la rigueur tu peux jouer sur les communautés de tes Upstream comme 
le disait quelqu'un dans les échanges précédents pour prépender vers 
certains/es IX's/destinations.
Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut 
être fonctionner, vue qu'en cas de coupure de ton intersite tes 2 
équipements passerait en master, jamais testé, mais je pense que ca 
devrait fonctionner.
Par contre cela te fait un autre point de coupure dans le réseau, et 
la gestion de l'adressage s'en voit un peu modifiée.




Le 13/11/07, * Raymond Caracatamatere* 
<[EMAIL PROTECTED] 
> a écrit :


Merci à tous pour toutes ces réponses, la lumière commence à se faire.
C'est vrai que cette problématique de redondance sur plusieurs
sites est très interessante.

Vous l'avez compris l'important pour moi est la continuité de
service que je dois offrir.
Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1
opérateur sur chaques routeurs et 2 interlan pour y faire passer
de l'ibgp, cela vous semble la meilleure solution ?
Simplement on le sait tous, le réseau n'est jamais 100% fiable,
que se passera t-il si jamais je perd l'interlan (même redondé)
mon AS et l'ensemble de mes IP seront annoncés via les deux sites
mais sans IBGP entre les deux sites quelles seront les conséquences ?

Aussi vous semblez dire que l'on puisse annoncer des prefixes
différents sur les deux sites (chose que je ne pensais pas
possible) avec le même AS ? n'est ce pas "mal" ? certain d'entre
vous le font ? l'ont fait ?
Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2
annonce mon dernier /24  c'est possible? donc si je perds 1 salle
l'autre continu de fonctionner et il me suffirai d'annoncer sur la
salle restante les préfixes de la salle1 pour que le transit se
fasse via l'interlan ?

Merci encore de vos idées,et de votre forte expérience, cette
échange est très enrichissant pour moi


Le 13/11/07, *Radu-Adrian Feurdean* < [EMAIL PROTECTED]
> a écrit :


On Tue, 13 Nov 2007 08:17:03 +0100, "Geoffroy RIVAT"
<[EMAIL PROTECTED] > said:

> intersite :
> bgp routeur 1 =   bgp routeur 3
> bgp routeur 2 =   bgp routeur 4

Ou plutot que d'avoir deux interco separes (1-3 , 2-4), tu
peux mettre
les 4 routeurs sur un /29 sur l'interlan.
Si en plus tu veux imperativement avoir deux liens pour raison de
redondance/securite, tu fais de l'aggregation sur les 2 liens,
comme ca
ta bande passante inter-site double.

Apres, c'est a toi de choisir si tu veux faire du full-BGP (tu
partage
la bande passante entre tes 2 sites) ou du default-route
(chaque site
avec sa route par default en local, l'interlan seulement pour
rapatrier
le trafic qui arrive sur le "mauvais" site ou pour le cas ou
un des
operateurs sont down).

Pour ce qui est le fait d'annoncer des prefixes separes sur
chaque site,
l'idee n'est pas geniale. Au mieux tu annonces les prefixes de
l'autre
site avec as-path prepend (ou community pour que ton uplink le
fait a ta
place). Ca juste parce-que tu as des /24, probablement pas
contigues.
S'il s'agit des bloc qui peuvent etre aggreges, beaucoup de
gens ici
vont te detester jusqu'a la fin de tes jours si tu annonces
chaque bloc
separement.

--
Radu-Adrian Feurdean
raf (a) ftml ! net

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





--
David Ramahefason - [EMAIL PROTECTED]  


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

Re: Re: [FRnOG] redondance réseau sur plusieurs sites

[Radu-Adrian Feurdean]

On Tue, 13 Nov 2007 13:58:50 +0100, "Raymond Caracatamatere"
<[EMAIL PROTECTED]> said:

> Aussi vous semblez dire que l'on puisse annoncer des prefixes différents
> sur
> les deux sites (chose que je ne pensais pas possible) avec le même AS ?
> n'est ce pas "mal" ? certain d'entre vous le font ? l'ont fait ?

Si les prefixes peuvent etre agreges, c'est "mal". Si ce n'est pas le
cas (ca semble etre ton cas) ca n'a aucune importance.

> Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2 annonce mon
> dernier /24  c'est possible? donc si je perds 1 salle l'autre continu de
> fonctionner et il me suffirai d'annoncer sur la salle restante les
> préfixes
> de la salle1 pour que le transit se fasse via l'interlan ?

Ce que j'ai fait:
Les salles declarent uniquement leurs prefix avec "network x.y.z.t". Au
niveau de l'annonce vers l'upstream je mets en sortie une route-map qui
laisse passer que des prefix a moi. Quand l'interlan marche, les deux
salles annoncent tous les prefix (le prefix de l'autre salle etant recu
via IBGP). Quand l'interlan tombe, la connexion IBGP tombe et les
routeurs sur chaque site annoncent que leurs propres prefixes. 

Maintenant, vu que la redondance des liens est en train d'etre mise en
place, je pense annoncer juste le super-net partout, les chances qu'un
site soit totalement isole etant extremement faibles (quasi-nulles). Ca
va aussi m'epargner les foudres des gens par ici.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

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

Re: [FRnOG] redondance réseau sur plusieurs sites

[David Ramahefason]

Comme dit avant la perte du lien d'interco est la partie la moins triviale à
gérer sur ton archi.
Pour ce qui est d'annonces des morceaux de classes de part et d'autre, ca
n'est pas trop l'usage sur les IXs.
A la rigueur tu peux jouer sur les communautés de tes Upstream comme le
disait quelqu'un dans les échanges précédents pour prépender vers
certains/es IX's/destinations.
Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut être
fonctionner, vue qu'en cas de coupure de ton intersite tes 2 équipements
passerait en master, jamais testé, mais je pense que ca devrait fonctionner.
Par contre cela te fait un autre point de coupure dans le réseau, et la
gestion de l'adressage s'en voit un peu modifiée.



Le 13/11/07, Raymond Caracatamatere <[EMAIL PROTECTED]> a
écrit :
>
> Merci à tous pour toutes ces réponses, la lumière commence à se faire.
> C'est vrai que cette problématique de redondance sur plusieurs sites est
> très interessante.
>
> Vous l'avez compris l'important pour moi est la continuité de service que
> je dois offrir.
> Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1 opérateur
> sur chaques routeurs et 2 interlan pour y faire passer de l'ibgp, cela vous
> semble la meilleure solution ?
> Simplement on le sait tous, le réseau n'est jamais 100% fiable, que se
> passera t-il si jamais je perd l'interlan (même redondé) mon AS et
> l'ensemble de mes IP seront annoncés via les deux sites mais sans IBGP entre
> les deux sites quelles seront les conséquences ?
>
> Aussi vous semblez dire que l'on puisse annoncer des prefixes différents
> sur les deux sites (chose que je ne pensais pas possible) avec le même AS ?
> n'est ce pas "mal" ? certain d'entre vous le font ? l'ont fait ?
> Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2 annonce mon
> dernier /24  c'est possible? donc si je perds 1 salle l'autre continu de
> fonctionner et il me suffirai d'annoncer sur la salle restante les préfixes
> de la salle1 pour que le transit se fasse via l'interlan ?
>
> Merci encore de vos idées,et de votre forte expérience, cette échange est
> très enrichissant pour moi
>
>
> Le 13/11/07, Radu-Adrian Feurdean < [EMAIL PROTECTED]> a écrit :
> >
> >
> > On Tue, 13 Nov 2007 08:17:03 +0100, "Geoffroy RIVAT"
> > <[EMAIL PROTECTED]> said:
> >
> > > intersite :
> > > bgp routeur 1 =   bgp routeur 3
> > > bgp routeur 2 =   bgp routeur 4
> >
> > Ou plutot que d'avoir deux interco separes (1-3 , 2-4), tu peux mettre
> > les 4 routeurs sur un /29 sur l'interlan.
> > Si en plus tu veux imperativement avoir deux liens pour raison de
> > redondance/securite, tu fais de l'aggregation sur les 2 liens, comme ca
> > ta bande passante inter-site double.
> >
> > Apres, c'est a toi de choisir si tu veux faire du full-BGP (tu partage
> > la bande passante entre tes 2 sites) ou du default-route (chaque site
> > avec sa route par default en local, l'interlan seulement pour rapatrier
> > le trafic qui arrive sur le "mauvais" site ou pour le cas ou un des
> > operateurs sont down).
> >
> > Pour ce qui est le fait d'annoncer des prefixes separes sur chaque site,
> > l'idee n'est pas geniale. Au mieux tu annonces les prefixes de l'autre
> > site avec as-path prepend (ou community pour que ton uplink le fait a ta
> > place). Ca juste parce-que tu as des /24, probablement pas contigues.
> > S'il s'agit des bloc qui peuvent etre aggreges, beaucoup de gens ici
> > vont te detester jusqu'a la fin de tes jours si tu annonces chaque bloc
> > separement.
> >
> > --
> > Radu-Adrian Feurdean
> > raf (a) ftml ! net
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
> >
>


-- 
David Ramahefason - [EMAIL PROTECTED]

Re: [FRnOG] redondance réseau sur plusieurs sites

[Radu-Adrian Feurdean]

On Tue, 13 Nov 2007 08:17:03 +0100, "Geoffroy RIVAT"
<[EMAIL PROTECTED]> said:

> intersite :
> bgp routeur 1 =   bgp routeur 3
> bgp routeur 2 =   bgp routeur 4

Ou plutot que d'avoir deux interco separes (1-3 , 2-4), tu peux mettre
les 4 routeurs sur un /29 sur l'interlan.
Si en plus tu veux imperativement avoir deux liens pour raison de
redondance/securite, tu fais de l'aggregation sur les 2 liens, comme ca
ta bande passante inter-site double.

Apres, c'est a toi de choisir si tu veux faire du full-BGP (tu partage
la bande passante entre tes 2 sites) ou du default-route (chaque site
avec sa route par default en local, l'interlan seulement pour rapatrier
le trafic qui arrive sur le "mauvais" site ou pour le cas ou un des
operateurs sont down).

Pour ce qui est le fait d'annoncer des prefixes separes sur chaque site,
l'idee n'est pas geniale. Au mieux tu annonces les prefixes de l'autre
site avec as-path prepend (ou community pour que ton uplink le fait a ta
place). Ca juste parce-que tu as des /24, probablement pas contigues.
S'il s'agit des bloc qui peuvent etre aggreges, beaucoup de gens ici
vont te detester jusqu'a la fin de tes jours si tu annonces chaque bloc
separement.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

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

Re: [FRnOG] Re: [FRnOG] redondance réseau sur plusieurs sites

[David Ramahefason]

Perso avoir 2 sites avec des machines qui répondent aux mêmes adresses ça me
pose problème.

Mais on sort du sujet initial.


Le 13/11/07, Spyou <[EMAIL PROTECTED]> a écrit :
>
> At 11:13 13/11/2007, you wrote:
> >mmmouip mais dans ce cas quand l'interco  est
> >active ça risque de poser des problèmes non ?
>
> Ben .. non .. quand elle est active, l'IBGP
> réparti le trafic entre les deux pop en fonction
> des besoin et des envies. Si elle est down, tout
> ce qui rentre par un pop sors par ce meme pop et basta.
>
> Le seul soucis, c'est si les deux transitaires
> sont tres déséquilibré en entrant, ca risque de
> faire un pop qui crache beaucoup et l'autre qui se la coule douce.
> 
> 'Spyou' - www.spyou.org - [EMAIL PROTECTED]
>  ircnet.nerim.net - UIN : 6871374
>
> Don't dream it,
> Be it.
> (RHPS)
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>


-- 
David Ramahefason - [EMAIL PROTECTED]

Re: [FRnOG] Re: [FRnOG] redondance réseau sur plusieurs sites

[Spyou]

At 11:13 13/11/2007, you wrote:
mmmouip mais dans ce cas quand l'interco  est 
active ça risque de poser des problèmes non ?


Ben .. non .. quand elle est active, l'IBGP 
réparti le trafic entre les deux pop en fonction 
des besoin et des envies. Si elle est down, tout 
ce qui rentre par un pop sors par ce meme pop et basta.


Le seul soucis, c'est si les deux transitaires 
sont tres déséquilibré en entrant, ca risque de 
faire un pop qui crache beaucoup et l'autre qui se la coule douce.


'Spyou' - www.spyou.org - [EMAIL PROTECTED]
ircnet.nerim.net - UIN : 6871374

Don't dream it,
Be it.
(RHPS)

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

Re: [FRnOG] Re: [FRnOG] redondance réseau sur plusieurs sites

[David Ramahefason]

mmmouip mais dans ce cas quand l'interco  est active ça risque de poser des
problèmes non ?

Le 13/11/07, Spyou <[EMAIL PROTECTED]> a écrit :
>
>
>
> S'il y'a les memes blocs annoncés des deux cotés
> avec des machines qui répondent pour toutes les
> IP (redondance complete de ce coté, donc), la
> perte de l'interco n'est qu'un moindre mal qui
> risque juste de degrader les perfs.
> 
> 'Spyou' - www.spyou.org - [EMAIL PROTECTED]
>  ircnet.nerim.net - UIN : 6871374
>
> Don't dream it,
> Be it.
> (RHPS)
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>


-- 
David Ramahefason - [EMAIL PROTECTED]

Re: [FRnOG] Moderation de la liste

[Charles]

Spyou a écrit :
> C'est de ce monde que sont originaire pas mal de vieux dinosaures du
> milieu (a coté de ceux qui ont d'abord trainé dans le milieu BBS :))

Je n'ai que 35 ans et j'ai déjà l'impression de faire parti de ces 
dinosaures... Le minitel planqué sous un meuble du salon qui faisait 
modem (modem retourné), et le PC branché dessus pour faire le serveur 
monovoie avec MultiM... Mes parents crisaient ! J'étais souvent connecté 
sur un rtc "SDE, serveur des étudiants"... ça doit bientôt faire 20 ans 
tout ça

(mais non je ne pense pas à ça à cause de mon anniversaire dans 5 jours :-)
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] redondance réseau sur plusieurs sites

[Spyou]

At 10:40 13/11/2007, David Ramahefason wrote:


Le 13/11/07, RIGARD Lilian - SARL Devclic 
<[EMAIL PROTECTED]> a écrit :


Ma fois, le BGP est trop utilisé dans un cadre de redondance, et il ne
faut pas oublier, qu'il est la aussi pour des questions de performances
! Election du best path ... et j'en passe.



La performance en BGP vient surtout de la 
manière dont sont gérer les routes par l'admin/ingé réseau.
Sinon dans le cas d'un architecture sur 2 sites 
(avec annonce des mêmes super blocs de part et 
d'autre), il faut bien faire attention à la 
gestion du routage entrant en cas de perte du 
lien d'interco entre les 2 sites, donc comme dit 
précédemment bien sécuriser/redonder cette interco.


S'il y'a les memes blocs annoncés des deux cotés 
avec des machines qui répondent pour toutes les 
IP (redondance complete de ce coté, donc), la 
perte de l'interco n'est qu'un moindre mal qui 
risque juste de degrader les perfs.


'Spyou' - www.spyou.org - [EMAIL PROTECTED]
ircnet.nerim.net - UIN : 6871374

Don't dream it,
Be it.
(RHPS)

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

Re: [FRnOG] redondance réseau sur plusieurs sites

[David Ramahefason]

Le 13/11/07, RIGARD Lilian - SARL Devclic <[EMAIL PROTECTED]> a écrit :
>
>
> Ma fois, le BGP est trop utilisé dans un cadre de redondance, et il ne
> faut pas oublier, qu'il est la aussi pour des questions de performances
> ! Election du best path ... et j'en passe.



La performance en BGP vient surtout de la manière dont sont gérer les routes
par l'admin/ingé réseau.
Sinon dans le cas d'un architecture sur 2 sites (avec annonce des mêmes
super blocs de part et d'autre), il faut bien faire attention à la gestion
du routage entrant en cas de perte du lien d'interco entre les 2 sites, donc
comme dit précédemment bien sécuriser/redonder cette interco.

-- 
David Ramahefason - [EMAIL PROTECTED]

Re: [FRnOG] Moderation de la liste

[Spyou]

At 09:59 13/11/2007, Antoine Musso wrote:

phx a écrit :

Bonjour,
desole mais c'est quoi BBS et RTC ?
Desole on doit aussi etre pas mal de jeunes :D


Salut,

   Le BBS : bulletin board system. En gros 
c'est un panel de services comme l'était le 
minitel mais plus souvent géré par des 
particuliers (et oui pas besoin de payer de 
folles redevances à France Telecom). Pour se 
connecter au BBS il suffisait de composer le 
numéro de téléphone et l'on avait accès à un 
espace de téléchargement, un forum de 
discussion et éventuellement une boite de messagerie.
   Donc un espèce de minitel (l'utilisateur 
appel un service) mais avec l'esprit ouvert 
d'internet (le service n'était généralement pas 
facturé) ou des radio-amateurs (beaucoup de 
geek et d'amateurs de nouvelles technologies).


   Pour le RTC : Réseau Téléphonique Commuté. 
C'est l'acronyme courrament utilisé pour 
désigner le réseau de téléphone. Les abonnés 
sont liés via une paire de cuivre à central, et 
les centrals connectés entre eux.
   Il y a quelque temps, la commutation était 
réalisée par des opérateurs humains, on 
demandait par exemple "le 22 à Asnière". Bien 
sur avec le temps, tout çà est devenu numérique 
et on entre en relation en quelques centaines de milisecondes.


RTC également utilisé comme acronyme a une race 
particuliere de BBS accessibles par minitel (et 
autre), basé sur du videotex (minitel oblige), 
censé etre plus convival et ouvert que le monde austere des BBS.


Sans (ou avec peu de) surtaxe a la connexion, biensur.

C'est de ce monde que sont originaire pas mal de 
vieux dinosaures du milieu (a coté de ceux qui 
ont d'abord trainé dans le milieu BBS :))


'Spyou' - www.spyou.org - [EMAIL PROTECTED]
ircnet.nerim.net - UIN : 6871374

Don't dream it,
Be it.
(RHPS)

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

Re: [FRnOG] Moderation de la liste

[Antoine Musso]

phx a écrit :

Bonjour,

desole mais c'est quoi BBS et RTC ?

Desole on doit aussi etre pas mal de jeunes :D


Salut,

   Le BBS : bulletin board system. En gros c'est un panel de services 
comme l'était le minitel mais plus souvent géré par des particuliers (et 
oui pas besoin de payer de folles redevances à France Telecom). Pour se 
connecter au BBS il suffisait de composer le numéro de téléphone et l'on 
avait accès à un espace de téléchargement, un forum de discussion et 
éventuellement une boite de messagerie.
   Donc un espèce de minitel (l'utilisateur appel un service) mais avec 
l'esprit ouvert d'internet (le service n'était généralement pas facturé) 
ou des radio-amateurs (beaucoup de geek et d'amateurs de nouvelles 
technologies).


   Pour le RTC : Réseau Téléphonique Commuté. C'est l'acronyme 
courrament utilisé pour désigner le réseau de téléphone. Les abonnés 
sont liés via une paire de cuivre à central, et les centrals connectés 
entre eux.
   Il y a quelque temps, la commutation était réalisée par des 
opérateurs humains, on demandait par exemple "le 22 à Asnière". Bien sur 
avec le temps, tout çà est devenu numérique et on entre en relation en 
quelques centaines de milisecondes.


cheers,

--
Antoine MUSSO
DISIT/PROD/QFO/OUT
mailto:[EMAIL PROTECTED]
tél. 02 40 12 73 62
Post-scriptum La Poste

Ce message est confidentiel. Sous réserve de tout accord conclu par
écrit entre vous et La Poste, son contenu ne représente en aucun cas un
engagement de la part de La Poste. Toute publication, utilisation ou
diffusion, même partielle, doit être autorisée préalablement. Si vous
n'êtes pas destinataire de ce message, merci d'en avertir immédiatement
l'expéditeur.