Re: [FRnOG] [TECH] BGP software
En filtrant juste jusqu'à /22 on est en dessous des 200k préfixes :) J'ai eu le coup sur un routeur cisco ou le fournisseur a envoyé des cartes 8ports 10G pour 7609 en 3C au lieu de 3cxl, du coup filtrage obligatoire sur la full view. Donc 2 default en bgp et même du peering on est bien en dessous des 239k routes limitées par la carte 3C sur cisco. Donc le MLX avec les 512k, ça devrait largement le faire et ça coûte une route-Map et une prefix-list :) Raphaël Envoyé de canapé Le 2 sept. 2013 à 18:49, William Gacquer a écrit : > Salut Jérome, > > il est vrai que je suis gourmand et habitué à manger des full view depuis 11 > ans au service de la matrice. > La default en dessous de /21, c'est peut être bien une bonne idée pour > attendre un peu. > > William > > Le 2 sept. 2013 à 18:15, Jérôme Nicolle > a écrit : > >> Salut William, >> >> Le 02/09/2013 17:42, William Gacquer a écrit : >>> mes cartes 10GbE sur MLX sont limitées à 500k routes. Bien >>> évidemment, nous y sommes déjà, ou presque. Tous ces investissements >>> à répétition pour du BGP, ça me fatigue et ça troue le porte monnaie >>> de mes patrons. >> >> Comme nous tous... >> >>> Brocade investissant dans Vyatta, je me demande si un bon X86-64 muni >>> de deux ports 10GbE tiendrait 3Gbps et surtout si le service rendu >>> serait carrier class, en faisant abstraction bien entendu de >>> l'architecture bancale du PC. >>> >>> Quel est votre retour la dessus? >> >> Sur une architecture de PC ce n'est pas tant le débit que le nombre de >> paquets par seconde qui compte. >> >> Sur une architecture classique, l'interface lève une interruption par >> paquet reçu. Sur les chips plus modernes, le driver informe le chip >> qu'il peut bufferiser, s'il en est capable, pendant une certaine période >> avant de lever l'interruption pour que le CPU le décharge. >> >> Le gros problème du routage soft est donc ce qu'il se passe en cas de >> DDoS : beaucoup de petits paquets vont lever beaucoup plus >> d'interruptions et saturer la capacité de forwarding du routeur, parfois >> au oint d'en perdre le control-plane. Les utilisateurs de C7200 et >> autres routeurs softs t'en parleront bien. >> >> Une fois les paquets en RAM, ce n'est qu'une question de lookup, et un >> linux récent a une table relativement efficace (à base de trie, pas de >> hashtable). Gaffe par contre à la validation des routes IPv6, un bug >> existe sur certaines release 3.9 et 3.10. >> >> L'implémentation de BGP en elle même n'est alors plus le problème, ça ne >> coute pas grand chose à faire tourner. Celle de Vyatta est Quagga, avec >> les quelques travers qu'on lui connait mais qui restent gérables dans un >> scenario siimple (pas de MP-BGP au delà des afi inet et inet6, pas de >> topologie trop complexe, pas de MPLS). >> >>> J'avoue que ça me fait mal d'écrire cela mais je suis un peu dos au >>> mur. >> >> En même temps, un MX80 doté de 4 ports 10G se trouve à moins de 20k€ >> (tendance 10-12k€ d'occaz). Un CER2024F-4X-RT (1.5M routes) devrait >> tourner au même ordre de grandeur de prix (mais neuf). Est ce que ça >> vaut le coup de prendre des risques pour ce tarif là ? >> >> Enfin, as-tu vraiment besoin d'une full-view sur l'ensemble de ton >> réseau ? Est ce qu'une default + filtrage à /21 (sauf sur les IX) ne te >> suffirait pas ? >> >> Une autre approche serait d'utiliser certains concepts intéressants du >> SDN avec les équipements dont tu disposes, en factorisant les routes au >> niveau d'un route-reflector, qui recevrait les full-view de tes transits >> mais n’enverrait à tes routeurs que des agrégats. >> >> Ce soft auto-magique n'existe pas encore, ça fait quelques temps qu'il >> me trotte dans la tête mais sans le temps ni toutes les compétences pour >> l'implémenter. On pourra toujours en parler au FRnOG si tu viens ;) >> >> @+ >> >> -- >> Jérôme Nicolle >> 06 19 31 27 14 >> >> >> --- >> 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] BGP software
Je vais essayer de venir mais ce n est pas gagne car je suis déjà a l EPF ce week-end. sinon Skype/FaceTime ? Thomas Sent from my iPad On 2 Sep 2013, at 22:11, Jérôme Nicolle wrote: >> Si quelqu'un veut écrire qque chose de ce type, je suis prêt a' aider >> l'intégration. >> https://github.com/Thomas-Mangin/exabgp > > On en cause dans 2 semaines, de vive voix avec quelques binches en main ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP software
Salut Thomas, Le 02/09/2013 19:16, Thomas Mangin a écrit : > Ces logiciels magiques existent mais sont toujours propriétaires. Oui, et vu la criticité de la manip je ne peux pas leur faire confiance... > Certains utilisent même ExaBGP comme backend BGP pour ce travail, avec des > manipulations parfois très complexes : d'ailleurs certaines de ces solutions > me font un peu très peur - mais ce n'est pas grave : pas mon réseau. > Il y a des gens qui me font trop confiance - et non ce n'est pas ma femme :-D C'est bien pour ça que je me sers d'ExaBGP pour mes tests :p Ton ilem est bonne pour ça, quoique j'ai pas encore eu (pris?) e temps de te faire un feedback su mes dernières trouvailles. Mais promis, je ferais ça d'ici la fin de l'année. Une fois l'automate implémenté, i ne reste que le séquençage des agrégation et la structure de données permettant de modéliser les extrémités de ton réseau (ASBR). Avec ça en tête, c'est pas trop complexe à implémenter, mais pour l'instant je suis resté en pur python, donc c'est pas réactif du tout. > Si quelqu'un veut écrire qque chose de ce type, je suis prêt a' aider > l'intégration. > https://github.com/Thomas-Mangin/exabgp On en cause dans 2 semaines, de vive voix avec quelques binches en main ? @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP software
On Mon, Sep 2, 2013, at 17:42, William Gacquer wrote: > Tous ces investissements à répétition pour du BGP, ça me fatigue et ça > troue le porte monnaie de mes patrons. > > Brocade investissant dans Vyatta, je me demande si un bon X86-64 muni de > deux ports 10GbE tiendrait 3Gbps et surtout si le service rendu serait > carrier class, en faisant abstraction bien entendu de l'architecture > bancale du PC. > > Quel est votre retour la dessus? De ce que j'ai pu comprendre, c'est un investissement plutot oriente "datacenter", et non pas "BGP en DFZ". Dans le passe, mon approche etait de filtrer plus agressivement les prefixes "lointains" (APNIC/LACNIC) et utiliser la route par default. A present (pas la meme boite, pas le meme matos, surtout pas les memes exigences et pas les memes moyens), je pense carrement laisser tomber la full-table et passer en 0.0.0.0/0 + ::/0 Par contre, dans les deux cas fournir du transit "full-table" a des clients ne faisait pas partie du program. Si tu est dans ce cas-la, il me *semble* que chez Brocoundry il y avait des fonctionalites pour filter les routes qui descendent en FIB, sans les enlever du RIB. PC+"carrier-class", pour moi c'est "non". Par contre, en mode plus "freestyle", il y a moyen de faire pousser 3Gbps avec un x86(_64). Ca depend du gout du risque de tes patrons :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP software
On 2 Sep 2013, at 17:15, Jérôme Nicolle wrote: > Une autre approche serait d'utiliser certains concepts intéressants du > SDN avec les équipements dont tu disposes, en factorisant les routes au > niveau d'un route-reflector, qui recevrait les full-view de tes transits > mais n’enverrait à tes routeurs que des agrégats. > > Ce soft auto-magique n'existe pas encore, ça fait quelques temps qu'il > me trotte dans la tête mais sans le temps ni toutes les compétences pour > l'implémenter. On pourra toujours en parler au FRnOG si tu viens ;) Ces logiciels magiques existent mais sont toujours propriétaires. Certains utilisent même ExaBGP comme backend BGP pour ce travail, avec des manipulations parfois très complexes : d'ailleurs certaines de ces solutions me font un peu très peur - mais ce n'est pas grave : pas mon réseau. Il y a des gens qui me font trop confiance - et non ce n'est pas ma femme :-D Si quelqu'un veut écrire qque chose de ce type, je suis prêt a' aider l'intégration. https://github.com/Thomas-Mangin/exabgp A+ Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP software
Le 9/2/13 6:49 PM, William Gacquer a écrit : > Salut Jérome, > > il est vrai que je suis gourmand et habitué à manger des full view depuis 11 > ans au service de la matrice. > La default en dessous de /21, c'est peut être bien une bonne idée pour > attendre un peu. > > William Hello, Surtout sur des /8 assignées à de continents pas forcément très habitués à fréquenter ton réseau en temps normal :) Tant que tu ne fournis pas de full view à des clients toi même, ça n'est pas très pénalisant de les filtrer (enfin pour la mémoire, pas pour le CPU). Cordialement, Frédéric > Le 2 sept. 2013 à 18:15, Jérôme Nicolle > a écrit : > >> Salut William, >> >> Le 02/09/2013 17:42, William Gacquer a écrit : >>> mes cartes 10GbE sur MLX sont limitées à 500k routes. Bien >>> évidemment, nous y sommes déjà, ou presque. Tous ces investissements >>> à répétition pour du BGP, ça me fatigue et ça troue le porte monnaie >>> de mes patrons. >> Comme nous tous... >> >>> Brocade investissant dans Vyatta, je me demande si un bon X86-64 muni >>> de deux ports 10GbE tiendrait 3Gbps et surtout si le service rendu >>> serait carrier class, en faisant abstraction bien entendu de >>> l'architecture bancale du PC. >>> >>> Quel est votre retour la dessus? >> Sur une architecture de PC ce n'est pas tant le débit que le nombre de >> paquets par seconde qui compte. >> >> Sur une architecture classique, l'interface lève une interruption par >> paquet reçu. Sur les chips plus modernes, le driver informe le chip >> qu'il peut bufferiser, s'il en est capable, pendant une certaine période >> avant de lever l'interruption pour que le CPU le décharge. >> >> Le gros problème du routage soft est donc ce qu'il se passe en cas de >> DDoS : beaucoup de petits paquets vont lever beaucoup plus >> d'interruptions et saturer la capacité de forwarding du routeur, parfois >> au oint d'en perdre le control-plane. Les utilisateurs de C7200 et >> autres routeurs softs t'en parleront bien. >> >> Une fois les paquets en RAM, ce n'est qu'une question de lookup, et un >> linux récent a une table relativement efficace (à base de trie, pas de >> hashtable). Gaffe par contre à la validation des routes IPv6, un bug >> existe sur certaines release 3.9 et 3.10. >> >> L'implémentation de BGP en elle même n'est alors plus le problème, ça ne >> coute pas grand chose à faire tourner. Celle de Vyatta est Quagga, avec >> les quelques travers qu'on lui connait mais qui restent gérables dans un >> scenario siimple (pas de MP-BGP au delà des afi inet et inet6, pas de >> topologie trop complexe, pas de MPLS). >> >>> J'avoue que ça me fait mal d'écrire cela mais je suis un peu dos au >>> mur. >> En même temps, un MX80 doté de 4 ports 10G se trouve à moins de 20k€ >> (tendance 10-12k€ d'occaz). Un CER2024F-4X-RT (1.5M routes) devrait >> tourner au même ordre de grandeur de prix (mais neuf). Est ce que ça >> vaut le coup de prendre des risques pour ce tarif là ? >> >> Enfin, as-tu vraiment besoin d'une full-view sur l'ensemble de ton >> réseau ? Est ce qu'une default + filtrage à /21 (sauf sur les IX) ne te >> suffirait pas ? >> >> Une autre approche serait d'utiliser certains concepts intéressants du >> SDN avec les équipements dont tu disposes, en factorisant les routes au >> niveau d'un route-reflector, qui recevrait les full-view de tes transits >> mais n’enverrait à tes routeurs que des agrégats. >> >> Ce soft auto-magique n'existe pas encore, ça fait quelques temps qu'il >> me trotte dans la tête mais sans le temps ni toutes les compétences pour >> l'implémenter. On pourra toujours en parler au FRnOG si tu viens ;) >> >> @+ >> >> -- >> Jérôme Nicolle >> 06 19 31 27 14 >> >> >> --- >> 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] BGP software
Salut Jérome, il est vrai que je suis gourmand et habitué à manger des full view depuis 11 ans au service de la matrice. La default en dessous de /21, c'est peut être bien une bonne idée pour attendre un peu. William Le 2 sept. 2013 à 18:15, Jérôme Nicolle a écrit : > Salut William, > > Le 02/09/2013 17:42, William Gacquer a écrit : >> mes cartes 10GbE sur MLX sont limitées à 500k routes. Bien >> évidemment, nous y sommes déjà, ou presque. Tous ces investissements >> à répétition pour du BGP, ça me fatigue et ça troue le porte monnaie >> de mes patrons. > > Comme nous tous... > >> Brocade investissant dans Vyatta, je me demande si un bon X86-64 muni >> de deux ports 10GbE tiendrait 3Gbps et surtout si le service rendu >> serait carrier class, en faisant abstraction bien entendu de >> l'architecture bancale du PC. >> >> Quel est votre retour la dessus? > > Sur une architecture de PC ce n'est pas tant le débit que le nombre de > paquets par seconde qui compte. > > Sur une architecture classique, l'interface lève une interruption par > paquet reçu. Sur les chips plus modernes, le driver informe le chip > qu'il peut bufferiser, s'il en est capable, pendant une certaine période > avant de lever l'interruption pour que le CPU le décharge. > > Le gros problème du routage soft est donc ce qu'il se passe en cas de > DDoS : beaucoup de petits paquets vont lever beaucoup plus > d'interruptions et saturer la capacité de forwarding du routeur, parfois > au oint d'en perdre le control-plane. Les utilisateurs de C7200 et > autres routeurs softs t'en parleront bien. > > Une fois les paquets en RAM, ce n'est qu'une question de lookup, et un > linux récent a une table relativement efficace (à base de trie, pas de > hashtable). Gaffe par contre à la validation des routes IPv6, un bug > existe sur certaines release 3.9 et 3.10. > > L'implémentation de BGP en elle même n'est alors plus le problème, ça ne > coute pas grand chose à faire tourner. Celle de Vyatta est Quagga, avec > les quelques travers qu'on lui connait mais qui restent gérables dans un > scenario siimple (pas de MP-BGP au delà des afi inet et inet6, pas de > topologie trop complexe, pas de MPLS). > >> J'avoue que ça me fait mal d'écrire cela mais je suis un peu dos au >> mur. > > En même temps, un MX80 doté de 4 ports 10G se trouve à moins de 20k€ > (tendance 10-12k€ d'occaz). Un CER2024F-4X-RT (1.5M routes) devrait > tourner au même ordre de grandeur de prix (mais neuf). Est ce que ça > vaut le coup de prendre des risques pour ce tarif là ? > > Enfin, as-tu vraiment besoin d'une full-view sur l'ensemble de ton > réseau ? Est ce qu'une default + filtrage à /21 (sauf sur les IX) ne te > suffirait pas ? > > Une autre approche serait d'utiliser certains concepts intéressants du > SDN avec les équipements dont tu disposes, en factorisant les routes au > niveau d'un route-reflector, qui recevrait les full-view de tes transits > mais n’enverrait à tes routeurs que des agrégats. > > Ce soft auto-magique n'existe pas encore, ça fait quelques temps qu'il > me trotte dans la tête mais sans le temps ni toutes les compétences pour > l'implémenter. On pourra toujours en parler au FRnOG si tu viens ;) > > @+ > > -- > Jérôme Nicolle > 06 19 31 27 14 > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP software
Bonjour, William Gacquer wrote: Brocade investissant dans Vyatta, je me demande si un bon X86-64 muni de deux ports 10GbE tiendrait 3Gbps et surtout si le service rendu serait carrier class, en faisant abstraction bien entendu de l'architecture bancale du PC. Quel est votre retour la dessus? Ca va dépendre de l'usage des cartes en question; avec des Intel X520 et un Xeon X56xx (ancienne génération de 2010), on peut facilement tenir 10 ou 20 Gbps dans certaines limites de tailles de paquets et/ou paquets par seconde. J'ai mesuré en pratique du 9.82 Gbps/tcp par port avec la mtu maximale possible (presque 16KB sur ces cartes). C'était pour du stockage, je n'ai pas d'expérience directe de routage avec ces cartes. Le PC n'a pas d'architecture bancale en soit; les routeurs classiques sont parfois (souvent ?) des PCs avec des composants additionnels et du logiciel non vendus en supermarché. Dans tous les cas, tu veux utiliser au minimum une machine à base de Xeon Sandy-Bridge: sur cette génération, les cartes ethernet peuvent directement écrire dans la mémoire cache L3 des processeurs sans passer par la mémoire classique. Le nom marketing de cette techno chez Intel est Direct I/O (DDIO) -- Francois Tigeot --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP software
Salut William, Le 02/09/2013 17:42, William Gacquer a écrit : > mes cartes 10GbE sur MLX sont limitées à 500k routes. Bien > évidemment, nous y sommes déjà, ou presque. Tous ces investissements > à répétition pour du BGP, ça me fatigue et ça troue le porte monnaie > de mes patrons. Comme nous tous... > Brocade investissant dans Vyatta, je me demande si un bon X86-64 muni > de deux ports 10GbE tiendrait 3Gbps et surtout si le service rendu > serait carrier class, en faisant abstraction bien entendu de > l'architecture bancale du PC. > > Quel est votre retour la dessus? Sur une architecture de PC ce n'est pas tant le débit que le nombre de paquets par seconde qui compte. Sur une architecture classique, l'interface lève une interruption par paquet reçu. Sur les chips plus modernes, le driver informe le chip qu'il peut bufferiser, s'il en est capable, pendant une certaine période avant de lever l'interruption pour que le CPU le décharge. Le gros problème du routage soft est donc ce qu'il se passe en cas de DDoS : beaucoup de petits paquets vont lever beaucoup plus d'interruptions et saturer la capacité de forwarding du routeur, parfois au oint d'en perdre le control-plane. Les utilisateurs de C7200 et autres routeurs softs t'en parleront bien. Une fois les paquets en RAM, ce n'est qu'une question de lookup, et un linux récent a une table relativement efficace (à base de trie, pas de hashtable). Gaffe par contre à la validation des routes IPv6, un bug existe sur certaines release 3.9 et 3.10. L'implémentation de BGP en elle même n'est alors plus le problème, ça ne coute pas grand chose à faire tourner. Celle de Vyatta est Quagga, avec les quelques travers qu'on lui connait mais qui restent gérables dans un scenario siimple (pas de MP-BGP au delà des afi inet et inet6, pas de topologie trop complexe, pas de MPLS). > J'avoue que ça me fait mal d'écrire cela mais je suis un peu dos au > mur. En même temps, un MX80 doté de 4 ports 10G se trouve à moins de 20k€ (tendance 10-12k€ d'occaz). Un CER2024F-4X-RT (1.5M routes) devrait tourner au même ordre de grandeur de prix (mais neuf). Est ce que ça vaut le coup de prendre des risques pour ce tarif là ? Enfin, as-tu vraiment besoin d'une full-view sur l'ensemble de ton réseau ? Est ce qu'une default + filtrage à /21 (sauf sur les IX) ne te suffirait pas ? Une autre approche serait d'utiliser certains concepts intéressants du SDN avec les équipements dont tu disposes, en factorisant les routes au niveau d'un route-reflector, qui recevrait les full-view de tes transits mais n’enverrait à tes routeurs que des agrégats. Ce soft auto-magique n'existe pas encore, ça fait quelques temps qu'il me trotte dans la tête mais sans le temps ni toutes les compétences pour l'implémenter. On pourra toujours en parler au FRnOG si tu viens ;) @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] BGP software
Bonjour mes cartes 10GbE sur MLX sont limitées à 500k routes. Bien évidemment, nous y sommes déjà, ou presque. Tous ces investissements à répétition pour du BGP, ça me fatigue et ça troue le porte monnaie de mes patrons. Brocade investissant dans Vyatta, je me demande si un bon X86-64 muni de deux ports 10GbE tiendrait 3Gbps et surtout si le service rendu serait carrier class, en faisant abstraction bien entendu de l'architecture bancale du PC. Quel est votre retour la dessus? J'avoue que ça me fait mal d'écrire cela mais je suis un peu dos au mur. William Gacquer --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Retour d'expériences CGN 444 / NAT64
Le 2013-09-02 16:42, Raphael Mazelier a écrit : > Le problème c'est qu'avec du CGN/LSN même en 444 tu as quand même besoin > de plus de fonctionnalités : > - batch logging (ou autre) > - des fonctionnalités qui rendent le truc le plus transparent possible à > tes clients, genre hair-pinning et l'EIP/EIM > > Hors ça j'ai pas vraiment trouvé d'equivalent en opensource. Même expérience ici. Mais bon, le logging et le "NAT gentil", ça n'a pas la même importance pour tout le monde. Simon --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Retour d'expériences CGN 444 / NAT64
Le 02/09/2013 15:53, Grégoire Leroy a écrit : Bonjour à tous, Nous sommes en train de tester plusieurs solutions de CGN444 et du NAT64 à états. Pour l'instant, on a mis en place une solution en lab avec un ASR1001 qui fonctionne plutôt bien. Dans la mesure où est plus proche de quelques milliers de clients que du million, on se demande si une solution libre Linux/iptables, FreeBSD/IPFW ou OpenBSD/Packet Filter ne serait pas aussi efficace pour le CGN 444 (pour le NAT 64, les tests avec viagenie/iptables ne se sont pas révélés concluants). Sauf que bon, par expérience, dans le libre, on trouve du stable, du pas stable. Du coup, on serait preneur si vous avez le moindre retour d'expérience en production avec les solutions suscitées. J'ai regardé du côté de Juniper, mais il semblerait que le CGN 444 + NAT64 soit supporté par les MX 240 et 480, soit une gamme visiblement largement au-dessus de l'ASR 1001. Au fond, puisque le CGN 444 c'est "juste" du NAT classique qu'on sait faire depuis 10 ans, avec juste des problématiques de logs et d'échelle en plus, je me demande si ça n'est pas possible de s'en sortir avec quelque chose de moins spécialisé. Avez vous des retours d'expérience à ce sujet, y compris avec des solutions/constructeurs/modèles non cités ? Nous sommes nous aussi en phase de test d'une solution CGN, a priori du NAT444 car nous ne voulons pas (encore) déployer de v6 sur nos CPEs. Pour le moment les tests que nous avons réaliser avec du matériel A10network sont très concluants. C'est pas super donné mais c'est simple à configurer et ça fait le job. Ceci dit je me posais les mêmes questions que toi au départ, à savoir est que les outils open sources ne peuvent pas gérer ça ? Le problème c'est qu'avec du CGN/LSN même en 444 tu as quand même besoin de plus de fonctionnalités : - batch logging (ou autre) - des fonctionnalités qui rendent le truc le plus transparent possible à tes clients, genre hair-pinning et l'EIP/EIM Hors ça j'ai pas vraiment trouvé d'equivalent en opensource. L'OS qui semble le plus évolué sur la gestion des pools en nat semble OpenBSD avec pf, mais cela ne me semble pas encore assez finement paramétrable. Note : coté Juniper oublie, c'est en pre-test, et comme toutes technos chez Juniper en test, ça va être long à faire déboguer par les clients :/ -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Retour d'expériences CGN 444 / NAT64
Le 2013-09-02 15:53, Grégoire Leroy a écrit : > Nous sommes en train de tester plusieurs solutions de CGN444 et du NAT64 > à états. Pour l'instant, on a mis en place une solution en lab avec un > ASR1001 qui fonctionne plutôt bien. Dans la mesure où est plus proche de > quelques milliers de clients que du million, on se demande si une > solution libre Linux/iptables, FreeBSD/IPFW ou OpenBSD/Packet Filter ne > serait pas aussi efficace pour le CGN 444 (pour le NAT 64, les tests > avec viagenie/iptables ne se sont pas révélés concluants). À noter que notre implémentation NAT64 OpenBSD, qui fait maintenant partie de la distro officielle, est *beaucoup* plus efficace que notre implémentation Linux. Les deux implémentations ne partagent aucune ligne de code. À tester indépendamment, donc. Que ce soit en NAT44 ou en NAT64, OpenBSD devrait facilement supporter "quelques milliers de clients" sur une bonne machine, tout dépendant du trafic généré (en paquets par seconde). On peut aussi configurer une paire en actif/passif avec partage d'état de NAT et VRRP, ou même de la répartition de charge actif/actif. OpenBSD fait ça "out of the box", sans avoir à ajouter quoi que ce soit à la distro de base. Et ce, avec une config simple et lisible, et la réputation d'être l'OS le plus sécuritaire au monde. Simon --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Retour d'expériences CGN 444 / NAT64
Le 2013-09-02 15:53, Grégoire Leroy a écrit : Bonjour à tous, Nous sommes en train de tester plusieurs solutions de CGN444 et du NAT64 à états. Pour l'instant, on a mis en place une solution en lab avec un ASR1001 qui fonctionne plutôt bien. Dans la mesure où est plus proche de quelques milliers de clients que du million, on se demande si une solution libre Linux/iptables, FreeBSD/IPFW ou OpenBSD/Packet Filter ne serait pas aussi efficace pour le CGN 444 (pour le NAT 64, les tests avec viagenie/iptables ne se sont pas révélés concluants). Sauf que bon, par expérience, dans le libre, on trouve du stable, du pas stable. Du coup, on serait preneur si vous avez le moindre retour d'expérience en production avec les solutions suscitées. J'ai regardé du côté de Juniper, mais il semblerait que le CGN 444 + NAT64 soit supporté par les MX 240 et 480, soit une gamme visiblement largement au-dessus de l'ASR 1001. Au fond, puisque le CGN 444 c'est "juste" du NAT classique qu'on sait faire depuis 10 ans, avec juste des problématiques de logs et d'échelle en plus, je me demande si ça n'est pas possible de s'en sortir avec quelque chose de moins spécialisé. Avez vous des retours d'expérience à ce sujet, y compris avec des solutions/constructeurs/modèles non cités ? Bonjour, Tu peux regarder de ce coté : http://schedule2012.rmll.info/IPv6-only-in-a-dual-stack-environnment-using-Free-Software?lang=fr Cdlt, -- Pascal Rullier --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH]Retour d'expériences CGN 444 / NAT64
Bonjour à tous, Nous sommes en train de tester plusieurs solutions de CGN444 et du NAT64 à états. Pour l'instant, on a mis en place une solution en lab avec un ASR1001 qui fonctionne plutôt bien. Dans la mesure où est plus proche de quelques milliers de clients que du million, on se demande si une solution libre Linux/iptables, FreeBSD/IPFW ou OpenBSD/Packet Filter ne serait pas aussi efficace pour le CGN 444 (pour le NAT 64, les tests avec viagenie/iptables ne se sont pas révélés concluants). Sauf que bon, par expérience, dans le libre, on trouve du stable, du pas stable. Du coup, on serait preneur si vous avez le moindre retour d'expérience en production avec les solutions suscitées. J'ai regardé du côté de Juniper, mais il semblerait que le CGN 444 + NAT64 soit supporté par les MX 240 et 480, soit une gamme visiblement largement au-dessus de l'ASR 1001. Au fond, puisque le CGN 444 c'est "juste" du NAT classique qu'on sait faire depuis 10 ans, avec juste des problématiques de logs et d'échelle en plus, je me demande si ça n'est pas possible de s'en sortir avec quelque chose de moins spécialisé. Avez vous des retours d'expérience à ce sujet, y compris avec des solutions/constructeurs/modèles non cités ? Merci d'avance, Bonne journée, Grégoire Leroy --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Datacenters : fibres optiques brutes ou pas ?
Quelques précisions : - En Rhône-Alpes, le GIX est un NAP. Avoir un lien vers Lyonix, c'est pouvoir y collecter les services fournis (transits, peering, voix...) de plus de 50 opérateurs sans surcoût majeur. C'est équivalent pour un parigot nombriliste à avoir un lien et 1U à TH2. - Une fibre en domaine public ne peut être possedée que par un opérateur déclaré s'aquittant de redevances. Elle peut être louée par un non-opérateur sous forme de bail classique ou d'IRU. mais on ne peut pas _vendre_ au sens strict une fibre à une entité qui n'est pas opérateur. Du coup, pour un ensemble de salles proches, le point critique est de se raccorder au NAP du coin, avec une forte capacité de fibres pour les mettre à disposition dans le cadre d'un contrat multi-service (maintenance, remote-hands, gardiennage, énergie, etc...), si possible avec des itinéraires redondants. Il ne s'agit bien que de mise à disposition, et pour permettre le plus grand nombre d'usages possibles, il faut envisager de préférence des fibres noires avec en option les équipements pour multiplexer en passif ou actif dessus (et la maintenance qui va avec). Pour un acheteur corporate, il peut être préférable est d'associer à la présentation de l'offre commerciale l'ensemble des offres des opérateurs capables de livrer à moindre frais sur le site. Enfin, assurer un déport du NAP peut aussi être intéressant, mais dans le cas de Rezopole ou TOUIX ça pose un problème : on s'interdit d'assurer le transport inter-sites pour ne pas concurrencer l'activité des membres. Ca pourrait créer un précédent fâcheux. @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
