<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Commentaires sur : Routing réseau : Intel écrase les prix du 10 Gbe</title>
	<atom:link href="http://www.virtua-network-services.com/deen/blogonews/news-network/routing-reseau-%c2%a0intel-ecrase-les-prix-du-10-gbe/feed" rel="self" type="application/rss+xml" />
	<link>http://www.virtua-network-services.com/blogonews/news-network/routing-reseau-%c2%a0intel-ecrase-les-prix-du-10-gbe</link>
	<description>Virtua Network</description>
	<lastBuildDate>Fri, 10 Dec 2010 06:04:19 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.5</generator>
	<item>
		<title>Par : marcel</title>
		<link>http://www.virtua-network-services.com/blogonews/news-network/routing-reseau-%c2%a0intel-ecrase-les-prix-du-10-gbe/comment-page-1#comment-389</link>
		<dc:creator>marcel</dc:creator>
		<pubDate>Fri, 03 Sep 2010 09:10:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.virtua-network.com/blogonews/news-network/routing-reseau-%c2%a0intel-ecrase-les-prix-du-10-gbe#comment-389</guid>
		<description>Bonjour,

Notre historique est assez original : en 2004, notre premier AS tournait sous FreeBSD+Zebra ... bonne expérience même si un memory leak de net-snmpd nous a fait perdre quelques cheveux.

Nous avons ensuite migré sous un setup OpenBSD/OpenBGPd. Meilleure expérience, mais OpenBGPd est vraiment pauvre en &quot;traffic engineering&quot; ... nous avions besoin de filtrage suivant la longueur de l&#039;AS-path, impossible avec OpenBGPd. De plus, OpenBSD commence à accuser un sérieux retard au niveau du support hardware (SMP), et gère mal la charge (gestion des interruption vraiment limite). Matthieu de notre équipe a participé au &lt;a href=&quot;http://www.freshports.org/net/openbgpd/&quot; rel=&quot;nofollow&quot;&gt;portage&lt;/a&gt; de OpenBGPd sous FreeBSD qui semblait un combo plus prometteur mais OpenBGPd est trop ancré dans OpenBSD pour offrir une alternative utilisable à long terme.

Nous avons finalement migré sous Vyatta, et il faut reconnaitre que c&#039;est la meilleure solution dans notre expérience. Parfaitement stable, très souple, moins &quot;rapide&quot; et léger qu&#039;OpenBGPd mais pour nous, passer de ~3-4s à 7-8s pour intégrer 100000 prefixes n&#039;est pas franchement un problème, et utiliser ~200Mb de RAM pour tout notre setup au lieu de 50Mb n&#039;est pas plus génant au prix de la RAM &quot;serveur&quot; actuel, sachant que Quagga offre tous les outils nécessaires pour nos spécialités et que Vyatta simplifie grandement la gestion en général.

Quagga s&#039;est largement amélioré ces dernières années (merci ex-Sun qui a pas mal investit de temps dedans) et a réussi à vraiment corriger ses principaux défauts (loop bloquante par exemple), les critiques que l&#039;on entendait ne sont plus vraiment fondées, encore moins avec les performances actuelles du hardware.

Si votre but est de faire un softrouter embarqué dans du hardware très léger, passez votre chemin, mais si vous avez 1Gb de RAM, un CPU moderne et des interfaces gbit correctes (Intel ou Broadcom), y&#039;a pas vraiment de limite.

Quagga a utilisé au début un autre softrouter, &lt;a href=&quot;http://www.xorp.org/&quot; rel=&quot;nofollow&quot;&gt;XORP&lt;/a&gt; mais on était largement en dessous de Quagga au niveau stabilité et performance (les daemons discutent en XML ...). La migration vers Quagga a été très appréciée.

Vyatta supporte les sessions MD5, avec quelques limitations sauf erreur. De toute façon l&#039;utilité de cette feature reste à prouver à notre avis (autre débat ...).

Pas de soucis pour les communities, ni pour le route reflector, même si pour ce dernier d&#039;autres solutions software spécialisées existent. Différents liens intéressants sont disponibles à cette &lt;a href=&quot;http://www.bgp4.as/tools&quot; rel=&quot;nofollow&quot;&gt;adresse&lt;/a&gt;.

Le temps de boot est plus que raisonnable, nous utilisons exclusivement des SSD sata, donc pas de scan scsi au boot, et vyatta n&#039;a pas 1000 daemons à starter, donc c&#039;est vraiment pas un soucis.

Le point faible est probablement les performances dans des cas extrêmes de multi-10Gbe je suppose. Dans nos cas (gbit), nous n&#039;avons honnêtement rien à reprocher, ça roule comme sur des roulettes comme on dit par ici :-)

Au niveau de l&#039;uptime, on a vraiment une solution imbattable : non seulement Vyatta est très stable, mais en plus, vu les budgets ultra-légers par routeur, on ne monte QUE des setups 100% redondants, pour 10%-15% du prix d&#039;un setup non-redondant chez Cisco ou autre ! ...  y&#039;a pas photo, si vous êtes à l&#039;aise avec CARP et ibgp, ce sera increvable, même supérieur à du Cisco de base rien que pour les updates ios (Incredibly Overpriced Software) qui nécessitent des reboot ...

On n&#039;a pas eu de flap, pas de perte de paquet, pas de problème de charge ni se soucis quelconque sur les bientôt 24 mois d&#039;utilisation ... je crois que ça résume la situation :-)</description>
		<content:encoded><![CDATA[<p>Bonjour,</p>
<p>Notre historique est assez original : en 2004, notre premier AS tournait sous FreeBSD+Zebra &#8230; bonne expérience même si un memory leak de net-snmpd nous a fait perdre quelques cheveux.</p>
<p>Nous avons ensuite migré sous un setup OpenBSD/OpenBGPd. Meilleure expérience, mais OpenBGPd est vraiment pauvre en &laquo;&nbsp;traffic engineering&nbsp;&raquo; &#8230; nous avions besoin de filtrage suivant la longueur de l&#8217;AS-path, impossible avec OpenBGPd. De plus, OpenBSD commence à accuser un sérieux retard au niveau du support hardware (SMP), et gère mal la charge (gestion des interruption vraiment limite). Matthieu de notre équipe a participé au <a href="http://www.freshports.org/net/openbgpd/" rel="nofollow">portage</a> de OpenBGPd sous FreeBSD qui semblait un combo plus prometteur mais OpenBGPd est trop ancré dans OpenBSD pour offrir une alternative utilisable à long terme.</p>
<p>Nous avons finalement migré sous Vyatta, et il faut reconnaitre que c&#8217;est la meilleure solution dans notre expérience. Parfaitement stable, très souple, moins &laquo;&nbsp;rapide&nbsp;&raquo; et léger qu&#8217;OpenBGPd mais pour nous, passer de ~3-4s à 7-8s pour intégrer 100000 prefixes n&#8217;est pas franchement un problème, et utiliser ~200Mb de RAM pour tout notre setup au lieu de 50Mb n&#8217;est pas plus génant au prix de la RAM &laquo;&nbsp;serveur&nbsp;&raquo; actuel, sachant que Quagga offre tous les outils nécessaires pour nos spécialités et que Vyatta simplifie grandement la gestion en général.</p>
<p>Quagga s&#8217;est largement amélioré ces dernières années (merci ex-Sun qui a pas mal investit de temps dedans) et a réussi à vraiment corriger ses principaux défauts (loop bloquante par exemple), les critiques que l&#8217;on entendait ne sont plus vraiment fondées, encore moins avec les performances actuelles du hardware.</p>
<p>Si votre but est de faire un softrouter embarqué dans du hardware très léger, passez votre chemin, mais si vous avez 1Gb de RAM, un CPU moderne et des interfaces gbit correctes (Intel ou Broadcom), y&#8217;a pas vraiment de limite.</p>
<p>Quagga a utilisé au début un autre softrouter, <a href="http://www.xorp.org/" rel="nofollow">XORP</a> mais on était largement en dessous de Quagga au niveau stabilité et performance (les daemons discutent en XML &#8230;). La migration vers Quagga a été très appréciée.</p>
<p>Vyatta supporte les sessions MD5, avec quelques limitations sauf erreur. De toute façon l&#8217;utilité de cette feature reste à prouver à notre avis (autre débat &#8230;).</p>
<p>Pas de soucis pour les communities, ni pour le route reflector, même si pour ce dernier d&#8217;autres solutions software spécialisées existent. Différents liens intéressants sont disponibles à cette <a href="http://www.bgp4.as/tools" rel="nofollow">adresse</a>.</p>
<p>Le temps de boot est plus que raisonnable, nous utilisons exclusivement des SSD sata, donc pas de scan scsi au boot, et vyatta n&#8217;a pas 1000 daemons à starter, donc c&#8217;est vraiment pas un soucis.</p>
<p>Le point faible est probablement les performances dans des cas extrêmes de multi-10Gbe je suppose. Dans nos cas (gbit), nous n&#8217;avons honnêtement rien à reprocher, ça roule comme sur des roulettes comme on dit par ici :-)</p>
<p>Au niveau de l&#8217;uptime, on a vraiment une solution imbattable : non seulement Vyatta est très stable, mais en plus, vu les budgets ultra-légers par routeur, on ne monte QUE des setups 100% redondants, pour 10%-15% du prix d&#8217;un setup non-redondant chez Cisco ou autre ! &#8230;  y&#8217;a pas photo, si vous êtes à l&#8217;aise avec CARP et ibgp, ce sera increvable, même supérieur à du Cisco de base rien que pour les updates ios (Incredibly Overpriced Software) qui nécessitent des reboot &#8230;</p>
<p>On n&#8217;a pas eu de flap, pas de perte de paquet, pas de problème de charge ni se soucis quelconque sur les bientôt 24 mois d&#8217;utilisation &#8230; je crois que ça résume la situation :-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Gregory Agerba</title>
		<link>http://www.virtua-network-services.com/blogonews/news-network/routing-reseau-%c2%a0intel-ecrase-les-prix-du-10-gbe/comment-page-1#comment-281</link>
		<dc:creator>Gregory Agerba</dc:creator>
		<pubDate>Fri, 30 Apr 2010 12:31:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.virtua-network.com/blogonews/news-network/routing-reseau-%c2%a0intel-ecrase-les-prix-du-10-gbe#comment-281</guid>
		<description>Bonjour,

Je ne suis absolument pas contre Vyatta ou un autre produit open source éprouvé qui puisse faire du routage et maintenir des sessions BGP. D’ailleurs il est étonnant de remarquer qu’il n’existe en fait que très peu de châssis (tout constructeur confondu) réellement capable de gérer beaucoup de peers faute de mémoire adjacente.

De plus, certains constructeurs, dont par exemple la référence en terme de BGP/MPLS Juniper tendent à essayer de consolider JunOS (pour en faire un mono-os) et ont changé la manière dont la mémoire adresse la mise en mémoire des routes. Autant de raisons d’avoir peur d’une solution black-box (même si elles sont stables), des mises à jour et de préférer une solution open-source ou il est possible de fouiller le code-source et connaitre son châssis, sans payer la RAM 3x son prix.

Je note que le papier de Tolly donnait un meilleur temps de convergence pour une machine IBM avec Vyatta qu’un châssis 7204VXR, mais il faut l’admettre le VXR n’est de loin pas le meilleur châssis pour faire du routage BGP et de plus il est EOL. Mauvaise approche que de vouloir comparer deux produits qui ne sont pas comparables à mon avis.

En l’occurrence, ce qui m’intéresse puisque vous avez fait des implémentations de Vyatta dans le monde réel, c’était d’avoir un retour sur les capacités BGP de Vyatta. Sauf erreur, Vyatta se base sur Zebra, mais Zebra était tout sauf parfait, d’ailleurs OpenBGPd était basé sur l’idée que Zebra/Quagga étaient incomplets et comportait des problèmes connus. Qu’en est-il de Vyatta ? Est-ce que ça supporte les sessions avec Md5 ? Est-ce que ça supporte les communautés BGP ?  Est-ce que c’est capable de faire office de réflecteur de routes pour un IX, par exemple ?

Quels sont, objectivement les réels contres de Vyatta ? Sachant que j’étudie ce produit pour un projet, je pense notamment au temps de boot qui doit être assez élevé (encore qu’un Procurve L2/3 ca peut mettre 3 minutes à booter… Est-ce qu’il y a des contre-effets après quelques mois d’utilisation ? Uptime ? Flap de sessions ? Pertes de paquets ? Montée en charge ?

Désolé de transformer votre blog en forum et merci pour votre retour ;-)

Gregory</description>
		<content:encoded><![CDATA[<p>Bonjour,</p>
<p>Je ne suis absolument pas contre Vyatta ou un autre produit open source éprouvé qui puisse faire du routage et maintenir des sessions BGP. D’ailleurs il est étonnant de remarquer qu’il n’existe en fait que très peu de châssis (tout constructeur confondu) réellement capable de gérer beaucoup de peers faute de mémoire adjacente.</p>
<p>De plus, certains constructeurs, dont par exemple la référence en terme de BGP/MPLS Juniper tendent à essayer de consolider JunOS (pour en faire un mono-os) et ont changé la manière dont la mémoire adresse la mise en mémoire des routes. Autant de raisons d’avoir peur d’une solution black-box (même si elles sont stables), des mises à jour et de préférer une solution open-source ou il est possible de fouiller le code-source et connaitre son châssis, sans payer la RAM 3x son prix.</p>
<p>Je note que le papier de Tolly donnait un meilleur temps de convergence pour une machine IBM avec Vyatta qu’un châssis 7204VXR, mais il faut l’admettre le VXR n’est de loin pas le meilleur châssis pour faire du routage BGP et de plus il est EOL. Mauvaise approche que de vouloir comparer deux produits qui ne sont pas comparables à mon avis.</p>
<p>En l’occurrence, ce qui m’intéresse puisque vous avez fait des implémentations de Vyatta dans le monde réel, c’était d’avoir un retour sur les capacités BGP de Vyatta. Sauf erreur, Vyatta se base sur Zebra, mais Zebra était tout sauf parfait, d’ailleurs OpenBGPd était basé sur l’idée que Zebra/Quagga étaient incomplets et comportait des problèmes connus. Qu’en est-il de Vyatta ? Est-ce que ça supporte les sessions avec Md5 ? Est-ce que ça supporte les communautés BGP ?  Est-ce que c’est capable de faire office de réflecteur de routes pour un IX, par exemple ?</p>
<p>Quels sont, objectivement les réels contres de Vyatta ? Sachant que j’étudie ce produit pour un projet, je pense notamment au temps de boot qui doit être assez élevé (encore qu’un Procurve L2/3 ca peut mettre 3 minutes à booter… Est-ce qu’il y a des contre-effets après quelques mois d’utilisation ? Uptime ? Flap de sessions ? Pertes de paquets ? Montée en charge ?</p>
<p>Désolé de transformer votre blog en forum et merci pour votre retour ;-)</p>
<p>Gregory</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- WP Super Cache is installed but broken. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! -->
