
<html><head></head><body>Salut ! <br>

<br>

super cette petite présentation !!! <br>

<br>

+1 pour le VPLS (c'est VxLAN chez cisco non ?) <br>

<br>

+100 pour le SRX100 virtuel. même si c'est un firewall, ça tourne sous Jun OS et c'est pas mal comme truc. <br>

<br>

+1000 pour des ateliers !!! <br>

<br>

au passage, proposition : pourquoi ne pas se monter un GNS3, un dynamips ou un vyatta pour ce genre de choses ? <br>

<br>

+++<br><br><div class="gmail_quote"><br>

"Jérôme Nicolle" <jerome@ceriz.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">Plop,<br /><br />On a eu une petite discussion hier soir sur le design d'un réseau<br />métropolitain, et sur les approches L2 contre L3.<br /><br />Par L2, on entend un réseau ethernet natif, n'utilisant pas<br />d'encapsulation spécifique.<br /><br />Par L3, on parle d'un réseau IP / IPv6, utilisant du routage.<br /><br />Une troisième approche existe, celle du L2 encapsulé sur du L3,<br />typiquement en utilisant la technologie VPLS (Virtual Private LAN Service).<br /><br />* Le problème<br /><br />En niveau 2, ethernet n'est pas prévu pour être routé, c'est à dire pour<br />pouvoir utiliser une topologie complexe, potentiellement maillée, afin<br />d'obtenir de meilleures performances et une meilleure résilience.<br /><br />La prévention des boucles dans le réseau, qui sont la cause des<br />broadcast-storm pouvant faire s'écrouler n'importe quel réseau de niveau<br />2, se fait historiquement en Spanning Tree (802.1D). De nombreuses<br

/>variantes existent (spanning tree rapide, par vlan, à topologie d'arbres<br />multiples...) et ont permi au fil des années d'améliorer les délais de<br />convergence et le taux d'utilisation des liens.<br /><br />D'autres approches, spécifiques à chaque constructeur, ont émergé, pour<br />répondre à des cas d'utilisation spécifiques. Le Metro Ring Protocol,<br />développé par Foundry, permet par exemple une convergence très rapide en<br />cas de perte d'un lien d'une boucle.<br /><br />Plus récement, le concept de "Fabric Ethernet" est apparu, et avec lui<br />le protocole TRILL et ses dérivés. L'idée est de pouvoir mailler le<br />réseau sans limite et utiliser tous les liens disponibles. C'est surtout<br />utile en datacenter, sur des réseaux de stockage ou de calcul par<br />exemple, qui se satisfont mal de la latence et de la complexité induite<br />par le routage.<br /><br />TRILL, en gros, c'est la version auto-magique améliorée de la somme des<br

/>protocoles proprio développés ces 15 dernières années. Mais en réseau,<br />si c'est auto-magique, il faut auto-pas_faire_ça.<br /><br />Le problème de fond avec le niveau 2 c'est qu'il est difficile à<br />débuguer. Les implémentations des différents protocoles sont plus ou<br />moins intéropérables, et on peut facilement avoir des surprises. Plus on<br />complique la couche 2, plus on risque d'avoir des surprises.<br /><br />Enfin, ces protocoles modernes sont assez sensible à l’homogénéité de<br />l'infrastructure. Outre le fait qu'ils imposent tous un montage<br />mono-constructeur, des réseaux étendus (plus de 50km / 3ms) sont<br />difficile à stabiliser.<br /><br />Du coup, les topologies les plus complexes des infras les plus critiques<br />ne reposent que marginalement sur du niveau 2.<br /><br />* L'approche L3<br /><br />En fait, le L2 a la préférence de la plupart des sysadmins et petits<br />réseaux car il permet très facilement de propager

des services sous<br />forme de VLANs, là ou le routage apparait comme étant une solution plus<br />complexe au premier abord.<br /><br />C'est sans compter sur l'exploitation, l'évolution et la maintenance du<br />réseau, pour lesquels les constructeurs vantent les mérites de<br />l'auto-magie en taisant bien volontiers les bugs qu'elle apporte.<br /><br />Sur une topologie routée, on va donc s'en tenir à des interconnexions<br />entre les routeurs, qui sont finalement de l'ethernet en point à point,<br />et à différentes couches de switching sur chaque site couvert par le réseau.<br /><br />Dans le cas du réseau sans-fil de <a href="http://tetaneutral.net">tetaneutral.net</a>, ça reviendrait à ce<br />que chaque antenne soit un routeur, ce qui pose d'autre soucis<br />(performance, complexité ajoutée), ou a rajouter des routeurs entre<br />chaque paire d'antennes.<br /><br />Ca modifie aussi les habitudes puisque des services reposant sur le<br />broadcast ne

peuvent être routés, et ceux nécessitant multicast doivent<br />l'être différemment. Le multicast c'est un peu la plaie de tout ingé<br />réseau, mais je n peux pas en parler en détail, j'ai toujours refusé<br />d'en faire ;)<br /><br />* Approche hybride<br /><br />Au prix d'une certaine lourdeur protocolaire, il est possible de<br />transporté des réseaux switchés sur un réseau routé.<br /><br />par lourdeur protocolaire, je veux d'ire qu'il faut à peu près tout ça<br />pour que ça tombe en marche :<br />- IPv4 et un IGP (OSPF ou IS-IS) pour l'adressage backbone<br />- MPLS, LDP et RSVP pour l'encapsulation et le traffic-engineering<br />- MP-BGP / iBGP pour la signalisation des services L2VPN et L3VPN<br />(certains le font en LDP, c'est moins flexible)<br /><br />Avec ça, on peut établir des pseudo-wires ou switchs virtuels regroupant<br />des ports ou "services" (sous-interface d'un port, généralement par<br />tagging 802.1Q) des différents routeurs.<br

/><br />Les avantages de cette approche sont nombreux :<br />- On peut instancier autant de services L2 et L3 que l'on souhaite<br />(fonction de la limite de mémoire et de licence des équipements)<br />- Le backbone converge aussi vite que son IGP le permet en OSPF et IS-IS<br />sur un réseau métropolitain on parle de délais inférieurs à la seconde<br />- MPLS-TE (avec RSVP) permet de gérer de la QoS de bout en bout et<br />d'utiliser le plus de potentiel sur le maillage des liens.<br />- Le debug se fait avec des protocoles avancés et relativement verbeux,<br />il est globalement plus facile que sur des protocoles jeunes comme TRILL<br />ou archaïques comme STP.<br /><br />Du coup, les cas d'utilisation de cette approche sont nombreux : réseaux<br />privés nationaux et régionaux, réseaux métropolitains, réseaux de<br />collecte des opérateurs, points d'échanges (tous les gros IX utilisent<br />ça)...<br /><br />En fait, une analogie simple est faisable, les

services MPLS comme L2VPN<br />et L3VPN sont finalement de la virtualisation de réseau, avec presque<br />toute la souplesse que permet la virtualisation de serveurs.<br /><br />* Par contre...<br /><br />Il n'existe pas d'implémentation libre et utilisable de MPLS. Il ya<br />bien une implémentation abordable sur les mikrotik, mais les cas<br />d'utilisation de ces technos concernent avant tout des équipements<br />proprio chers.<br /><br />Chez les constructeurs majeurs, le moins cher pour commencer à jouer<br />avec MPLS est le Juniper SRX100, qui se trouve dans les 350€ H.T. (8<br />ports fast, 200Mbps de capa de routage). Il est aussi utilisable en<br />machine virtuelle (sous VMWare uniquement), gratuitement pour évaluation<br />et usage pédagogique..<br /><br />Chez Cisco, le minimum pour jouer avec ça va être un 7301 ou 7204-NPEG1<br />qui vaut environ 1100€ d'occasion. On peut faire quelques tests avec des<br />ISR-G1 un peu moins chers mais ils sont beaucoup

moins performants (et<br />pas de L2VPN). Il y a plus gros et moins cher mais vraiment obsolète. En<br />neuf, il faut partir sur des ISR-G2 (à partir de 2k€) ou des ASR1001 (à<br />partir de 6k€).<br /><br />On a quelque équipements mobilisables pour tenter des ateliers sur le<br />sujet, mais l'idéal est encore de virtualiser et émuler ce qui peut l'être.<br /><br />Je peux tenter de faire un brief un peu plus technique sur ces<br />différentes approches, qui serait intéressé ? Qui est volontaire pour y<br />bosser un peu ?<br /><br />@+</pre></blockquote></div><br>

-- <br>

Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.</body></html>