[FRnOG] RFC 6382: Unique Per-Node Origin ASNs for Globally Anycasted Services
Amusant : les différents serveurs DNS n'ont pas la même politique BGP pour de l'anycast. Ce RFC recommande un numéro d'AS différent par site. Que devrait faire l'AFNIC (qui n'a pas cette politique) ? http://www.bortzmeyer.org/6382.html Auteur(s) du RFC: Danny McPherson, Ryan Donnelly, Frank Scalzo (Verisign) Ce court RFC propose un changement radical dans la gestion des annonces BGP par les services anycastés. Actuellement, ils utilisent presque tous un seul numéro d'AS pour tous les n#339;uds d'un nuage anycast. Notre RFC 6382, au contraire, suggère d'utiliser un numéro d'AS par n#339;ud. Comme l'explique la section 2 de notre RFC, l'anycast (RFC 4786) est désormais une technique banale. Elle permet notamment d'augmenter sérieusement la résistance aux dDoS. Dans le monde du DNS, l'anycast est particulièrement répandu (par exemple, .fr n'a plus que deux serveurs unicasts, tous les autres sont anycastés). L'anycast fonctionnant en injectant la même route, via BGP, depuis des points différents du réseau, on peut se demander s'il faut que tous ces points annonçent le préfixe depuis le même AS, ou bien si chacun doit utiliser un AS différent ? Aujourd'hui, la quasi-totalité des services anycastés utilisent un seul numéro d'AS pour tous leurs points de présence (POP). VeriSign (la boîte des auteurs du RFC) est un des rares acteurs à le faire, pour certains de leurs serveurs. Cela a notamment l'avantage de préserver une ressource rare : les numéros d'AS n'étaient codés que sur seize bits. Cela facilite également la configuraion des routeurs. Et, aujourd'hui, cela évite des ennuis avec les systèmes d'alarme BGP http://www.bortzmeyer.org/alarmes-as.html, qui pourraient couiner en voyant le même préfixe avoir plusieurs AS d'origine. Hurricane Electric fournit ainsi une liste des préfixes annoncés par plusieurs AS http://bgp.he.net/report/multi-origin-routes. Même chose chez Cymru http://www.cymru.com/BGP/incon_asn_list.html. Comme illustré par un exposé à NANOG en 2001 http://www.nanog.org/meetings/nanog23/abstracts.php?nm=nanog23pt=OTc3J m5hbm9nMjM=, c'était plutôt considéré comme une erreur. Mais cette politique a aussi des défauts : lorsqu'un routeur BGP voit arriver une annonce pour un préfixe anycasté, il ne sait pas exactement de quel n#339;ud elle vient. Cela peut compliquer le déboguage des problèmes. Certains services ont un mécanisme pour identifier le serveur (RFC 5001 pour le DNS, ou bien le traditionnel quoique non normalisé hostname.bind dans la classe CH). Et, évidemment, on peut toujours utiliser traceroute pour trouver où se trouve telle instance anycast. Essayons avec un serveur DNS anycasté, d.nic.fr, depuis une machine située dans le Missouri : % dig +nsid @d.nic.fr SOA fr. ... ; NSID: 64 6e 73 2e 6c 79 6e 32 2e 6e 69 63 2e 66 72 (d) (n) (s) (.) (l) (y) (n) (2) (.) (n) (i) (c) (.) (f) (r) ... C'est donc dns.lyn2.nic.fr qui a répondu. Et on confirme qu'on touche l'instance de Lyon (cette machine a surtout des instances en métropole et dans les DOM-TOM et aucune aux États-Unis) : # tcptraceroute d.nic.fr 53 Selected device eth0, address 208.75.84.80, port 43778 for outgoing packets Tracing the path to d.nic.fr (194.0.9.1) on TCP port 53 (domain), 30 hops max 1 208.75.84.1 0.000 ms 0.000 ms 0.000 ms 2 host123.datotel.com (208.75.82.123) 0.000 ms 0.000 ms 0.000 ms 3 stl-c1-g1-15.datotel.com (208.82.151.29) 10.000 ms 0.000 ms 0.000 ms 4 stl-e2-g0-2.datotel.com (208.82.151.13) 0.000 ms 0.000 ms 0.000 ms 5 vlan100.car2.StLouis1.Level3.net (4.53.162.121) 0.000 ms 0.000 ms 0.000 ms 6 ae-4-4.ebr2.Chicago1.Level3.net (4.69.132.190) 10.000 ms 9.999 ms 10.000 ms 7 ae-5-5.ebr2.Chicago2.Level3.net (4.69.140.194) 0.000 ms 9.999 ms 9.999 ms 8 ae-6-6.ebr2.Washington12.Level3.net (4.69.148.145) 10.000 ms 19.999 ms 19.999 ms 9 ae-5-5.ebr2.Washington1.Level3.net (4.69.143.221) 19.999 ms 19.999 ms 29.998 ms 10 ae-44-44.ebr2.Paris1.Level3.net (4.69.137.61) 89.994 ms 99.994 ms 109.994 ms 11 ae-22-52.car2.Paris1.Level3.net (4.69.139.227) 109.994 ms 99.994 ms 99.994 ms 12 JAGUAR-NETW.car2.Paris1.Level3.net (212.73.207.162) 109.993 ms 99.995 ms 99.994 ms 13 dns.lyn2.afnic.cust.jaguar-network.net (78.153.224.126) 119.993 ms 119.993 ms 139.992 ms 14 d.nic.fr (194.0.9.1) [open] 109.994 ms 119.993 ms 109.993 ms Autre essai, avec un serveur de la racine du DNS, L.root-servers.net, largement anycasté. Depuis un fournisseur en France : % dig +nsid @l.root-servers.net SOA . ... ; NSID: 6c 79 73 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 2e 6f 72 67 (l) (y) (s) (0) (1) (.) (l) (.) (r) (o) (o) (t) ( -) (s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g) On touche lys01.l.root-servers.org. Comme son opérateur, l'ICANN, utilise (comme beaucoup), les codes aéroport pour nommer les machines, on voit qu'elle est également à Lyon (LYS est l'aéroport de
[FRnOG] Livebox Pro Fibre, Echolife hg810a et mode pont
Salut la liste, Je reviens avec mes problèmes d’administrateur système. Je suis chez un client qui se fait poser une offre fibre Orange sur LiveBox. Le commercial nous vendit un mode pont que le technicien ne connait absolument pas… Est-ce que quelqu’un ici aurait des infos sur comment me sortir de cette panade ? L’objectif étant de récupérer l’adresse IP publique de la ligne sur mon propre routeur Cisco. Actuellement je le fais avec la ligne ADSL via un modem PPPoE. La fibre Orange passe par un echolife hg810a pour ressortir en Ethernet et venir se brancher sur la LiveBox. Est-ce que quelqu’un connait se produit ? Est-il possible de connecter un routeur perso dessus ? Cordialement Yoann Gini smime.p7s Description: S/MIME cryptographic signature
Re: [FRnOG] Livebox Pro Fibre, Echolife hg810a et mode pont
Le 25 oct. 2011 à 10:43, Benjamin Sonntag a écrit : livebox orange fibre dans google ;) http://benjamin.sonntag.fr/a59-Se_debarasser_de_la_livebox_fibre_orange_pppoe_mode_d_emploi_.html C’est ce que j’ai vu oui. Sauf que le Cisco SA520 que j’ai en place ne me permet pas de gérer les VLan sur les interfaces WAN… Je suis dans la panade \o/ Merci pour vos réponses en tout cas ! smime.p7s Description: S/MIME cryptographic signature
[FRnOG] Re: RFC 6382: Unique Per-Node Origin ASNs for Globally Anycasted Services
Mais cette politique a aussi des défauts : lorsqu'un routeur BGP voit arriver une annonce pour un préfixe anycasté, il ne sait pas exactement de quel noeud elle vient. Cela peut compliquer le déboguage des problèmes. Une question pour les experts BGP. Pour identifier l'origine d'une annonce d'un service anycasté, plutôt que d'avoir un numéro d'AS par site, comme le propose le RFC, pourquoi ne pas ajouter une communauté identifiant ladite origine ? Je ne vois qu'un seul inconvénient, le risque que certaines « looking glasses » (par exemple la passerelle DNS de routeviews.org) affichent l'AS path mais pas les communautés. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Le troll du vendredi par Michel
Ouh ! Un troll dans le troll ! Un troll v4 dans un troll v6, y a une RFC de Troll over DS-Lite ou GRE de Troll à creuser là ! Voilà ça c'etait pour la partie comme l'info m'arrange pas j'en démolis le vecteur. Principe de base du troll, non ? Il est certain qu'une suite d'assertions péremptoires balancées sur un ton parternaliste sur la liste FRnoG par Michel Py from California a une crédibilité supérieure à ce que dit le chef IPv6 de FT sur v6ops@ietf. En même temps, le chef IPv6 de FT, il a qu'à poster sur FRNoG aussi, au lieu de poster sur l'IETF. Moi je dis, il cherche les coups. Entre un californien qui poste en France et un français qui poste aux US, franchement, c'est bonnet blanc et blanc bonnet. :D Après j'ai toujours plus confiance dans celui qui accepte de parler aux graisseux d'en bas, mais c'est personnel comme vision, j'ai jamais aimé les tours d'ivoire non plus ! Dans le style, y a Alain Durand, ex-Comcast, qui a écrit le rfc sur DS-Lite qui a eu la gentillesse de venir nous présenter son boulot, et ça pour moi, c'est crédible. Le reste, c'est beau, mais à chacun de se faire son avis. FT c'est FT, avec ses contraintes internes, ses problématiques, et sa stratégie. C'est pas une référence ou un exemple...
Re: [FRnOG] Re: Le troll du vendredi par Michel
Le 25 octobre 2011 12:01, Guillaume Barrot guillaume.bar...@gmail.com a écrit : Le reste, c'est beau, mais à chacun de se faire son avis. FT c'est FT, avec ses contraintes internes, ses problématiques, et sa stratégie. C'est pas une référence ou un exemple... Nous sommes entièrement d'accord. Pour recadrer le propos, j'illustrais à l'origine avec cette citation la phrase suivante : le déploiement d'IPv6 arrive dans ce cas en même temps que celui du CGN (et non leur calendrier de déploiement). Guillaume
Re: [FRnOG] RFC 6382: Unique Per-Node Origin ASNs for Globally Anycasted Services
Les communautés BGP, c'est vrai que c'est transitif optionnel, mais c'est très fréquemment écrasé en entrée ou en sortie d'un AS, voire tout simplement pas transmis par défaut (IOS par exemple). Du coup, pas trop utilisable pour cet usage. Une autre possibilité serait d'avoir un AS unique prépendé un certain nombre de fois sur chaque site d'annonce, ce nombre identifiant le site d'origine. Mais ça serait crade, illisible, et rapidement limité/foireux vu que l'AS path, au delà de 255, ça se passe mal dans une bonne partie d'Internet. Donc non en fait :) Le 25 oct. 2011 à 11:48, Stephane Bortzmeyer a écrit : Mais cette politique a aussi des défauts : lorsqu'un routeur BGP voit arriver une annonce pour un préfixe anycasté, il ne sait pas exactement de quel noeud elle vient. Cela peut compliquer le déboguage des problèmes. Une question pour les experts BGP. Pour identifier l'origine d'une annonce d'un service anycasté, plutôt que d'avoir un numéro d'AS par site, comme le propose le RFC, pourquoi ne pas ajouter une communauté identifiant ladite origine ? Je ne vois qu'un seul inconvénient, le risque que certaines « looking glasses » (par exemple la passerelle DNS de routeviews.org) affichent l'AS path mais pas les communautés. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Opérateur Celeste 1GBPS
Bonjour Avez-vous des retours concernant l'offre Céleste 1GBPS. Est-ce sérieux ? http://www.celeste.fr/fibre-optique-1g Et une idée des tarifs ?, j'attends le retour d'une réponse de leur part. Cordialement
Re: [FRnOG] Opérateur Celeste 1GBPS
Chez moi (ile d'Oléron, 17480), pour du 1GBps, c'était 4K€HT d'install puis 3K€HT/mois. Après c'est assez bizarre ce qu'ils vendent derrière, les tarifs des IPs et pleins d'options minitel. Bref, en attente de concurrence, rien trouvé de moins cher. Le 25/10/2011 14:16, SDL a écrit : Bonjour Avez-vous des retours concernant l'offre Céleste 1GBPS. Est-ce sérieux ? http://www.celeste.fr/fibre-optique-1g Et une idée des tarifs ?, j'attends le retour d'une réponse de leur part. Cordialement --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] RFC 6382: Unique Per-Node Origin ASNs for Globally Anycasted Services
Si on compare avec un anycast interne à un FAI (ex : les DNS récursifs d'un FAI), on ne va pas annoncer les routes en BGP au sein de son propre AS, autant utiliser l'IGP pour ça. Donc, on va avoir la /32 portant le service DNS qui va être annoncé plusieurs fois dans OSPF/ISIS. Sur quoi on peut jouer pour connaitre le site qui a originé la route en IGP, ou pour modifier la façon dont sera vu cette route sur certain PE ? A priori, juste sur la métrique de cet IGP, et éventuellement les tags pour l'origine. Pour du globaly anycast, vu qu'on parle maintenant d'annonce de route en BGP, effectivement l'idée la plus rapide serait d'adapter cette vision avec AS PATH et des communautés. Utiliser un ASPATH pour chaque site d'origine, c'est bien, surtout maintenant que les AS sur 32bits sont supportés sur les plateformes récentes, mais c'est pas super logique avec la notion d'AS déjà, et on connait les limitations d'un champ sur 32bit... Les communautés, comme le souligne Olivier, ont tendance à être toujours écrasées en entrée car, voyons les choses en face, c'est généralement de la tambouille interne à l'AS : est-ce que c'est bien ou pas de le faire, c'est une excellente question, mais le fait est que c'est comme ça, donc il faut faire avec. En clair, il faudrait une communauté, type SOO (site of origin), mappée sur un paramètre physique *normé* afin que tout le monde utilise la même chose (code aéroport du site, coordonnées GPS, age du capitaine), et avec un transit mandatory (MUST), ie non écrasable sur une annonce BGP. J'aime bien les coordonnées GPS, ça ferait des beaux plugins googlemap dans les outils de traceroute :D En attendant une éventuelle RFC normalisant ça, le n° d'AS différent par site semble le seul truc déployable rapidement. Sinon, pour troller dès le lundi : http://www.ietf.org/mail-archive/web/lisp/current/msg00398.html http://www.ietf.org/mail-archive/web/lisp/current/msg00420.html Effectivement, on pourrait alors mapper par exemple une communauté SOO sur le RLOC de l'ITR sur lequel est présent l'EID anycasté (désolé pour les acronymes pour ceux qui n'ont pas lu la doc sur LISP...) De cette manière, les couples EID/RLOC étant eux bien définis sur le réseaux (un EID pouvant être présent sur plusieurs RLOC), on a résolu le problème. Je crois même avoir lu quelque part que le RLOC peut être une @IP, une @MAC, et même des coordonnées GPS ... Mais bon là c'est bel et bien de la science-fiction :D Le 25 octobre 2011 12:41, Olivier Benghozi olivier.bengh...@wifirst.fr a écrit : Les communautés BGP, c'est vrai que c'est transitif optionnel, mais c'est très fréquemment écrasé en entrée ou en sortie d'un AS, voire tout simplement pas transmis par défaut (IOS par exemple). Du coup, pas trop utilisable pour cet usage. Une autre possibilité serait d'avoir un AS unique prépendé un certain nombre de fois sur chaque site d'annonce, ce nombre identifiant le site d'origine. Mais ça serait crade, illisible, et rapidement limité/foireux vu que l'AS path, au delà de 255, ça se passe mal dans une bonne partie d'Internet. Donc non en fait :) Le 25 oct. 2011 à 11:48, Stephane Bortzmeyer a écrit : Mais cette politique a aussi des défauts : lorsqu'un routeur BGP voit arriver une annonce pour un préfixe anycasté, il ne sait pas exactement de quel noeud elle vient. Cela peut compliquer le déboguage des problèmes. Une question pour les experts BGP. Pour identifier l'origine d'une annonce d'un service anycasté, plutôt que d'avoir un numéro d'AS par site, comme le propose le RFC, pourquoi ne pas ajouter une communauté identifiant ladite origine ? Je ne vois qu'un seul inconvénient, le risque que certaines « looking glasses » (par exemple la passerelle DNS de routeviews.org) affichent l'AS path mais pas les communautés. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Cordialement, Guillaume BARROT
Re: [FRnOG] Opérateur Celeste 1GBPS
Tu en as besoin où ? Ici en IDF on est contents de la prestation de Neo Telecoms, néanmoins je ne connais pas le tarif de tête. On 25 Oct 2011, at 14:16, SDL siteduli...@gmail.com wrote: Bonjour Avez-vous des retours concernant l'offre Céleste 1GBPS. Est-ce sérieux ? http://www.celeste.fr/fibre-optique-1g Et une idée des tarifs ?, j'attends le retour d'une réponse de leur part. Cordialement
Re: [FRnOG] Opérateur Celeste 1GBPS
Bonjour, SDL wrote: Avez-vous des retours concernant l'offre Céleste 1GBPS. Est-ce sérieux ? http://www.celeste.fr/fibre-optique-1g Et une idée des tarifs ?, j'attends le retour d'une réponse de leur part. J'ai vu l'un de leurs commerciaux la semaine dernière, ils faisaient une réunion locale dans ma banlieue. Le discours c'était Vous ne pouvez avoir que de l'ADSL 512K. Bougez pas, on arrive, on vient sauver les PME. et on fait la fibre pas cher, le Giga est au prix du 50 Mega. Bon, le Gb/s était quand-même dans les 4 Keurs ou plus par mois. J'ai fait remarquer que ça faisait quand-même un peu élevé pour des PME, et qu'on pouvait se payer plein de SDSLs et des machines en datacenter pour moins cher. Le gars a fini par m'avouer qu'ils ne voulaient pas vendre d'abonnement en dessous de 1000 € HT / mois ... -- Francois Tigeot --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Opérateur Celeste 1GBPS
Bonjour, Je ne vous ferai pas un discours commercial car je suis dans la partie technique. Pour les tarifs de l'offre 1Giga, il faut tabler sur à peu près 2000 € par mois sur toute la France. Le prix est évalué au cas par cas. En effet, cela dépend de la proximité de nos pop dans la région et donc par conséquent du génie civil à réaliser. Le prix par mois peut varier dans d'importantes mesures car les commerciaux font en sorte de lisser les FAS sur la période d'engagement. Pourquoi proposer un abonnement à 2000€ si c'est pour vous assommer avec 100 000 € de mise en service ? Après il faut comparer avec les offres des autres. Beaucoup de clients ne trouvent pas crédible une offre 1Gb/s à 2000€ quand FT leur fait la 10Mb/s à 1500... Vincent Mialon Ingénieur Réseaux CELESTE Email: vincent.mia...@celeste.fr Tel: 01 70 17 60 20 Testez votre éligibilité à la fibre optique 1 GIGA Visitez le datacenter haute densité Marilyn - Mail Original - De: François Tigeot ftig...@zefyris.com À: frnog@frnog.org Envoyé: Mardi 25 Octobre 2011 15h14:12 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [FRnOG] Opérateur Celeste 1GBPS Bonjour, SDL wrote: Avez-vous des retours concernant l'offre Céleste 1GBPS. Est-ce sérieux ? http://www.celeste.fr/fibre-optique-1g Et une idée des tarifs ?, j'attends le retour d'une réponse de leur part. J'ai vu l'un de leurs commerciaux la semaine dernière, ils faisaient une réunion locale dans ma banlieue. Le discours c'était Vous ne pouvez avoir que de l'ADSL 512K. Bougez pas, on arrive, on vient sauver les PME. et on fait la fibre pas cher, le Giga est au prix du 50 Mega. Bon, le Gb/s était quand-même dans les 4 Keurs ou plus par mois. J'ai fait remarquer que ça faisait quand-même un peu élevé pour des PME, et qu'on pouvait se payer plein de SDSLs et des machines en datacenter pour moins cher. Le gars a fini par m'avouer qu'ils ne voulaient pas vendre d'abonnement en dessous de 1000 € HT / mois ... -- Francois Tigeot --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Re: Le troll du vendredi par Michel
Guillaume Barrot a écrit: Après j'ai toujours plus confiance dans celui qui accepte de parler aux graisseux d'en bas, mais c'est personnel comme vision, j'ai jamais aimé les tours d'ivoire non plus ! Dans le style, y a Alain Durand, ex-Comcast, qui a écrit le rfc sur DS-Lite qui a eu la gentillesse de venir nous présenter son boulot, et ça pour moi, c'est crédible. Alain est un réaliste et quelqu'un que j'admire énormément; il est tombé dans IPv6 quand il était petit. C'est le parfait mauvais exemple de ce que l'IETF est: si tout le monde était comme lui, peut être qu'IPv6 serait quelque part ailleurs de ce que c'est aujourd'hui. Ceci dit, je ne suis pas convaincu même par DS-Lite; ça a les mêmes ennuis si ce n'est pire qu'un CGN v4, surtout en matière de logs. Bonjour l'usine à gaz pour loguer quelle adresse v4 tu donnes à un client à travers IPv6 et retransformes en IPv4 public quelque part ailleurs. Ca n'a plus rien à voir avec l'IPv6 d'origine; on en a fait une usine à gaz avec des tunnels dans tous les sens et des NAT à chaque bout des tunnels. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Le troll du vendredi par Michel
Ceci dit, je ne suis pas convaincu même par DS-Lite; ça a les mêmes ennuis si ce n'est pire qu'un CGN v4, surtout en matière de logs. Bonjour l'usine à gaz pour loguer quelle adresse v4 tu donnes à un client à travers IPv6 et retransformes en IPv4 public quelque part ailleurs. +1 Cout de la mise en place d'IPv6 sur le réseau : 10 Cout du log du CGN : 10E(beaucoup) Tu donnes de la connectivité en v6, tu conserves la connectivité en v4 ... mais a quel prix ? (les opérateurs mobiles le savent bien, puisque peu d'APN sont en v4 publique, en général c'est du prive + CGN) Attention a un truc tout de meme : le CGN qu'on peut faire dans le cas de DSLite n'est pas du vrai CGN, il est un peu plus intelligent que ça. L'AFTR (truc qui finit le tunnel DSLite) gère un NAT enrichi par un champ : l'IPv6 sur laquelle a été initiée le tunnel. Ce qui fait qu'on peut logguer un truc du style hh:mm:ss ipv4 privee + ipv6 du tunnel == ipv4 publique. Cela etant dit dans le cas d'une requisition judiciaire, tu as toujours 1 IPv4 publique = N clients, donc après il faut s'en sortir avec de l'inspection de service, et la on tombe dans des solutions de DPI etc. A noter aussi que le NAT dans le cas du DSLite est optionnel, et qu'on peut bien mapper directement du trafic en v4 public. Interet ? Sur un reseau FAI, offrir de la connectivite v4+v6, et pour les 10% de clients geek offrir un service d'IPv4 publique dédiée. Ok c'est quand même une régression, mais bon, on se console comme on peut ... Apres, on ne parle plus de mécanisme de transition pour DSLite mais bien d'un mécanisme de gestion du manque de v4 publique... On est loin du dual-stack ! Et pour les gens qui codent dans le kernel, le truc marrant avec DSLite, c'est que la stabilite de la pile v4 depend directement de la stabilite de la pile v6. Autrement dit, a chaque développement, tu touches a la pile v6 = tu dois re-valider tout le fonctionnement de la pile v4 = joie !
Re: [FRnOG] RFC 6382: Unique Per-Node Origin ASNs for Globally Anycasted Services
Bonjour la liste FRnOG, Juste une question sur la RFC 6382: Pourquoi ne pas avoir utilisé l'attribut transitif optionnel AGGREGATOR ? Même s'il n'est pas exactement fait pour cela, il intègre une adresse IPv4 en plus d'un numéro d'AS, qui identifie le routeur aillant généré l'annonce et n'a à ma connaissance pas d'autre objectif que le troubleshooting. Cet attribut n'est pas modifié lors de la propagation de l'update BGP dans Internet. A défaut d'intégrer précisément le Node (ce qui nécessiterait de modifier les implémentations), il permettrait de savoir le premier routeur BGP situé face au sous-réseau anycast. Chaque instance anycast aurait donc pu utiliser un identifiant différent. Avantage, il est lisible en CLI sur la plupart des implémentations et ne nécessite pas de modifications de celles-ci pour le diagnostic, contrairement à un nouvel attribut. Il n'est pas supprimé ou modifié contrairement à l'attribut de communautés. Il ne devrait pas causer d'alarmes étant donné qu'il est normal d'avoir de routes agrégées par différents routeurs, contrairement au premier numéro d'AS de l'attribut AS_PATH. Et ne requerrait pas l'assignation de numéros d'AS supplémentaires. Cordialement, -- Jean Rebiffé --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Re: Le troll du vendredi par Michel
Guillaume Barrot a écrit: Note: je suis d'accord avec le reste de ta contrib, donc vu qu'on n'est pas vendredi je ne vais pas remuer le couteau dans la plaie. Ceci dit: A noter aussi que le NAT dans le cas du DSLite est optionnel, et qu'on peut bien mapper directement du trafic en v4 public. En tant que geek, je n'achète pas. Une IPv4 publique tunnellée à travers v6? Non merci. Même si je vois bien ou tu veux en venir, et même si tu peux convaincre Michu Junior que c'est une IPv4 publique avec tous les ports etc etc, je ne prends pas pour des raisons qui devraient être évidentes à la majorité des lecteurs et que tu as mentionnées toi-même. Bon et pour être intellectuellement honnête, mis à part que j'adore Alain, DS-Lite c'est un super bon raisonnement: à tant que s'enquiquiner avec une solution de CGN, autant en prendre une qui, en même temps, a le mérite de déployer IPv6 dans le backbone des FAI. Faut pas être hypocrite: DS-Lite c'est le radeau de sauvetage d'IPv6: finalement le monde a compris que de donner IPv6 à Mme Michu, ça ne sert à rien donc on invente encore une autre solution qui embedde (inclus?) v6 donc dans 50 ans quand on se serra finalement débarrassé de v4 on aura le backbone natif. Et, je ne critique pas, chacun prêche pour sa paroisse et j'ai prêché pour celle-là, moi aussi. C'est un peu la même chose que ce Microsoft avait dans le temps essayé avec three degrees: on se sert d'IPv6 pour traverser NAT, ou l'inverse. Mais encore une fois, too little to late. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Switch 12 ports SFP ?
Bonjour, Besoin de conseil ;=) j'ai sur un site un cisco 3750 12 ports SFP, probleme, il me faut plus de ports (24 a 48) sans depasser les 1U .. J'ai cherché dans la gamme cisco, rien trouvé alors je me tourne vers d'autres constructeurs mais dur dur quand on est que cisco. Alors si vous pouvez m'orienter, cela serait sympa ;=) Seul petite contrainte: - Support du jumbo frame - Support du QinQ - Bon dialogue avec les switchs cisco Cordialement Olivier
Re : [FRnOG] Switch 12 ports SFP ?
Hello chez cisco ce sont les 3750-X avec 24 ports SFP WS-C3750X-24S-E http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6406/data_sheet_c78-584733.html Pas sûr que ça fasse du Q-in-Q par contre... faudrait vérifier dans la doc de config. Sinon faut aller regarder les switchs Metro Ethernet. http://www.cisco.com/en/US/prod/collateral/switches/ps6568/ps9637/data_sheet_c78-495220.html http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps5532/product_data_sheet0900aecd806e27b9.html http://www.cisco.com/en/US/prod/collateral/switches/ps6568/ps10956/data_sheet_c78-601946.html Surya De : Olivier CALVANO o.calv...@gmail.com À : frnog@frnog.org Envoyé le : Mercredi 26 Octobre 2011 7h30 Objet : [FRnOG] Switch 12 ports SFP ? Bonjour, Besoin de conseil ;=) j'ai sur un site un cisco 3750 12 ports SFP, probleme, il me faut plus de ports (24 a 48) sans depasser les 1U .. J'ai cherché dans la gamme cisco, rien trouvé alors je me tourne vers d'autres constructeurs mais dur dur quand on est que cisco. Alors si vous pouvez m'orienter, cela serait sympa ;=) Seul petite contrainte: - Support du jumbo frame - Support du QinQ - Bon dialogue avec les switchs cisco Cordialement Olivier
