Re: [FRnOG] [TECH] SDN chez Google
Bonjour, Celui de commander le réseau opérateur pour programmer une bande passante sur une période donnée. Nous sommes à l'ère du VPN agile, à la demande. Cordialement, Michel - Mail original - De: Julien Schafer j.scha...@actilogie.com À: frnog-tech frnog-t...@frnog.org Envoyé: Mercredi 24 Juin 2015 15:34:24 Objet: RE: [FRnOG] [TECH] SDN chez Google Mis à part pour les très gros et les hébergeurs, SDN ça peut avoir un quelconque intérêt pour un client final classique...? -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Louis Envoyé : mercredi 24 juin 2015 15:24 À : frnog-tech Objet : [FRnOG] [TECH] SDN chez Google un article plutôt intéressant http://www.reseaux-telecoms.net/actualites/lire-google-explique-pourquoi-il-a-ete-oblige-de-construire-ses-propres-reseaux-27365.html?utm_source=mailutm_medium=emailutm_campaign=Newsletter Il y a aussi une keynote que je regarderai quand j'aurai un peu de temps https://www.youtube.com/watch?v=n4gOZrUwWmc Louis --- Liste de diffusion du FRnOG http://www.frnog.org/ __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 11836 (20150624) __ Le message a t v rifi par ESET NOD32 Antivirus. http://www.eset.com --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] SDN chez Google
Mis à part pour les très gros et les hébergeurs, SDN ça peut avoir un quelconque intérêt pour un client final classique...? -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Louis Envoyé : mercredi 24 juin 2015 15:24 À : frnog-tech Objet : [FRnOG] [TECH] SDN chez Google un article plutôt intéressant http://www.reseaux-telecoms.net/actualites/lire-google-explique-pourquoi-il-a-ete-oblige-de-construire-ses-propres-reseaux-27365.html?utm_source=mailutm_medium=emailutm_campaign=Newsletter Il y a aussi une keynote que je regarderai quand j'aurai un peu de temps https://www.youtube.com/watch?v=n4gOZrUwWmc Louis --- Liste de diffusion du FRnOG http://www.frnog.org/ __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 11836 (20150624) __ Le message a t v rifi par ESET NOD32 Antivirus. http://www.eset.com --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] SDN chez Google
Euh oui. Enfin tu supposes déjà que tu es fibré sinon avec du cuivre je vois pas bien ce que tu feras, c'est pas SDN qui va te passer en quadripaire si besoin ;) Déjà si tous les opérateurs pouvaient construire des VPN non agiles, pas à la demande mais qui marchent comme ils le devraient ce serait déjà beau. Je garde en tête cette possibilité, mais j'attends d'en voir la couleur dans les catalogues et surtout que ca marche... Déjà que pouvoir faire un show conf expurgé sur un CPE c'est compliqué/impossible avec certains, j'imagine meme pas si on leur dit que le client aura une interface permettant d'avoir des possibilités de modifications sur le réseau opérateur. Pour tout te dire j'y crois pas bcp... -Message d'origine- De : Michel Hostettler [mailto:michel.hostett...@telecom-paristech.fr] Envoyé : mercredi 24 juin 2015 15:58 À : Julien Schafer Cc : frnog-tech Objet : Re: [FRnOG] [TECH] SDN chez Google Bonjour, Celui de commander le réseau opérateur pour programmer une bande passante sur une période donnée. Nous sommes à l'ère du VPN agile, à la demande. Cordialement, Michel - Mail original - De: Julien Schafer j.scha...@actilogie.com À: frnog-tech frnog-t...@frnog.org Envoyé: Mercredi 24 Juin 2015 15:34:24 Objet: RE: [FRnOG] [TECH] SDN chez Google Mis à part pour les très gros et les hébergeurs, SDN ça peut avoir un quelconque intérêt pour un client final classique...? -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Louis Envoyé : mercredi 24 juin 2015 15:24 À : frnog-tech Objet : [FRnOG] [TECH] SDN chez Google un article plutôt intéressant http://www.reseaux-telecoms.net/actualites/lire-google-explique-pourquoi-il-a-ete-oblige-de-construire-ses-propres-reseaux-27365.html?utm_source=mailutm_medium=emailutm_campaign=Newsletter Il y a aussi une keynote que je regarderai quand j'aurai un peu de temps https://www.youtube.com/watch?v=n4gOZrUwWmc Louis --- Liste de diffusion du FRnOG http://www.frnog.org/ __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 11836 (20150624) __ Le message a t v rifi par ESET NOD32 Antivirus. http://www.eset.com --- Liste de diffusion du FRnOG http://www.frnog.org/ __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 11836 (20150624) __ Le message a t v rifi par ESET NOD32 Antivirus. http://www.eset.com --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] SDN chez Google
Le 24/06/2015 15:57, Michel Hostettler a écrit : Celui de commander le réseau opérateur pour programmer une bande passante sur une période donnée. À quoi bon brider à la base ? Si on veux simplifier l'opérationnel commençons donc par simplifier l'offre… Nous sommes à l'ère du VPN agile, à la demande. Instancier une VM de terminaison de VPN avec une patte dans une VRF, ça requiert du SDN ? @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] SDN chez Google
un article plutôt intéressant http://www.reseaux-telecoms.net/actualites/lire-google-explique-pourquoi-il-a-ete-oblige-de-construire-ses-propres-reseaux-27365.html?utm_source=mailutm_medium=emailutm_campaign=Newsletter Il y a aussi une keynote que je regarderai quand j'aurai un peu de temps https://www.youtube.com/watch?v=n4gOZrUwWmc Louis --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Term Serv 16 ports
Bonsoir tous; Il y a quelques temps, quelqu’un sur la liste avait recommandé les serveurs de terminaux Opengear. C’est en effet (sur le papier) super, mais un peu overkill pour un usage de pur prise de contrôle de console à distance (environ 1100€ le modèle 16 ports). Quelqu’un a eu l’occasion d’essayer autre chose de moins onéreux ? Moxa par exemple ? Merci --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Term Serv 16 ports
Hello, Il y a quelques temps, quelqu’un sur la liste avait recommandé les serveurs de terminaux Opengear. C’est en effet (sur le papier) super, mais un peu overkill pour un usage de pur prise de contrôle de console à distance (environ 1100€ le modèle 16 ports). Quelqu’un a eu l’occasion d’essayer autre chose de moins onéreux ? Moxa par exemple ? Avant d'utiliser un opengear j'avais mis des cartes 4xserial - pci dans un pc. C'est plein de cables avec les pieuvres, ça consomme plus et ça prends plus de place, mais au final si tu as un serveur sous la main, ça coute 1/10e du prix de l'opengear. Note : la plupart des distribs Linux compilent le noyau avec 4 ttyS, s'attendre à recompiler. -- petrus --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] SDN chez Google
Bonjour, Je n'ai pas testé mais il y a l'air d'y avoir des pistes niveau devops réseau par exemple : https://github.com/spotify/napalm/blob/master/README.md qui vient avec un plugin ansible. RDR Le 25 juin 2015 06:33:31 GMT+10:00, Olivier Cochard-Labbé oliv...@cochard.me a écrit : 2015-06-24 21:01 GMT+02:00 Thomas Barandon t.baran...@gmail.com: Hi, Bref, le SDN c'est bon. Mangez en. De toute façon il faudra composer avec. Juste un «détail» qui me chiffonne avec les solutions SDN du moment: Ou est passé le principe KISS ? Prenons l'exemple de Juniper Contrail (je prends cet exemple uniquement car la solution fonctionne pas mal et la doc bien foutue): cf le white paper CONTRAIL ARCHITECTURE, Figure 1 Contrail system overview: http://www.juniper.net/us/en/local/pdf/whitepapers/2000535-en.pdf Donc sur ce schéma d'introduction simplifié (car réduire OpenStack à un seul bloc, j'appelle cela de la simplification) je découvre un joli mélange de: - XMPP, pour que routeur fasse des échanges multimédias ou du chat entre eux et le contrôleur ? :-) - BGP, normal c'est du réseau - Netconf, tiens… enfin! - API Rest, car c'est la mode de tout encapsuler dans HTTP… quelle connerie d'avoir prévus 65535 ports pour TCP, alors qu'il en suffisait de trois: 53, 80 et 443. - Une couche d'overlay MPLS over GRE/UDP ou d'overlay VXLAN… - Pourquoi absolument du MPLS over quelques chose et pas le faire nativement ? - VXLAN: quel intérêt en 2015, dans un monde IP, d'ajouter une couche supplémentaire pour maintenir l'existence de domaines de broadcast Ethernet entre serveurs ? - hyperviseur - Comment garantir le jitter minimum lorsque l'on doit traverser plusieurs hyperviseurs ? (chainage de VMs) Et le pire: C'est que ça fonctionne. Par contre le jour il y aura un problème: Qui est capable de maitriser et comprendre l'ensemble des technos mis en œuvre dans une telle solution ? Cela me donne l'impression que la révolution SDN va vraiment trop vite. J'aurai aimé une étape intermédiaire plus simple avant, comme par exemple juste trouver une solution de déploiement automatisée de configuration d'un réseau hétérogène. Netconf, après des années de réflexions et je ne sais plus combien de RFC n'est toujours pas utilisable à grande échelle dans un environnement vraiment multi-constructeurs. Le monde de l'IT n'ont pas perdus leur temps en discussion: Ils disposent désormais de plusieurs solutions éprouvées qui leur permet de gérer leur énormes parc de serveurs (ansible, puppet, chef, salt, etc...). Et pendant ce temps là, nous au réseau: Que dalle! Pourtant un serveur est autrement plus complexe à gérer qu'un simple switch/routeur. Cela nous aurai permis de commencer tranquillement notre migration en mode devops au lieu de nous prendre la grosse claque SDN d'un coup. My two cents, Olivier --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] problème de route pour un ping !
Ah ok, je comprends mieux. Donc c’est bien un ip nat inside qu’il faut mais tu veux pas NATer vers 192.168.1.0/24 pour que la réponse au ping fonctionne: ip nat inside source list 100 interface Loopback0 overload access-list 100 deny ip 10.0.1.0 0.0.0.3 192.168.1.0 0.0.0.255 access-list 100 permit ip 10.0.1.0 0.0.0.3 any Allez, dis-moi que ça marche, que je passe une bonne soirée, et qu’on passe à autre chose :) Le 24 juin 2015 à 19:54, Antoine Durant antoine.duran...@yahoo.fr a écrit : Salut David ! ip nat inside source list 100 interface Loopback0 overload access-list 100 permit ip 10.0.1.0 0.0.0.3 any Là, par contre, j’ai un problème. Si tu veux NATer les paquets qui rentrent par l’interface « ip nat outside » FE4 et qui vont vers « ip nat inside » VLAN1, l’inverse donc, la règle doit être: ip nat outside source list 100 interface Loopback0 overload et avec ton ACL 100, tu le ferais que pour les paquets qui viennent de l’IP de FE4, ou l’interface de RTR_A qui porte 10.0.1.2. J’ai du mal à voir l’intérêt, et je me demande si cette règle en inside mal placée ne serait pas la cause de ton problème. Oui comme tu le précise mon problème est sur l'ACL n°100 (je n'ai pas de problème avec la 101) J'ai placé volontairement cette ACL pour pouvoir depuis le RTR pinguer des adresses extérieures en sortant avec l'IP de la loopback0 Celle ci me pose problème car le ping sur les intercos ne fonctionne pas. Si j'enlève l'ACL 100 je peux pinguer mes IPs d'interco mais pas une IP dans le WAN De : David Ponzone david.ponz...@gmail.com À : Antoine Durant antoine.duran...@yahoo.fr Cc : Frnog-tech frnog-t...@frnog.org Envoyé le : Mercredi 24 juin 2015 1h06 Objet : Re: [FRnOG] [TECH] problème de route pour un ping ! Voilà déjà un truc qui me plait pas: interface FastEthernet4 ip address 10.0.1.1 255.255.255.252 no ip redirects no ip unreachables no ip proxy-arp ip nat outside ip virtual-reassembly in ip verify unicast reverse-path duplex full speed 100 ! interface Vlan1 ip address 172.16.1.254 255.255.255.0 no ip redirects no ip unreachables no ip proxy-arp ip nat inside ip virtual-reassembly in ip verify unicast reverse-path ip nat inside source list 101 interface Loopback0 overload access-list 101 permit ip 172.16.1.0 0.0.0.255 any ! Ca, c’est ok. Les paquets arrivant par VLAN1 avec 172.16.1.0/24 comme IP source et qui ressortent par FE4 (la default) vont être NATés en 192.168.1.100. ip nat inside source list 100 interface Loopback0 overload access-list 100 permit ip 10.0.1.0 0.0.0.3 any Là, par contre, j’ai un problème. Si tu veux NATer les paquets qui rentrent par l’interface « ip nat outside » FE4 et qui vont vers « ip nat inside » VLAN1, l’inverse donc, la règle doit être: ip nat outside source list 100 interface Loopback0 overload et avec ton ACL 100, tu le ferais que pour les paquets qui viennent de l’IP de FE4, ou l’interface de RTR_A qui porte 10.0.1.2. J’ai du mal à voir l’intérêt, et je me demande si cette règle en inside mal placée ne serait pas la cause de ton problème. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] problème de route pour un ping !
Salut David ! ip nat inside source list 100 interface Loopback0 overload access-list 100 permit ip 10.0.1.0 0.0.0.3 any Là, par contre, j’ai un problème. Si tu veux NATer les paquets qui rentrent par l’interface « ip nat outside » FE4 et qui vont vers « ip nat inside » VLAN1, l’inverse donc, la règle doit être: ip nat outside source list 100 interface Loopback0 overload et avec ton ACL 100, tu le ferais que pour les paquets qui viennent de l’IP de FE4, ou l’interface de RTR_A qui porte 10.0.1.2. J’ai du mal à voir l’intérêt, et je me demande si cette règle en inside mal placée ne serait pas la cause de ton problème. Oui comme tu le précise mon problème est sur l'ACL n°100 (je n'ai pas de problème avec la 101) J'ai placé volontairement cette ACL pour pouvoir depuis le RTR pinguer des adresses extérieures en sortant avec l'IP de la loopback0 Celle ci me pose problème car le ping sur les intercos ne fonctionne pas.Si j'enlève l'ACL 100 je peux pinguer mes IPs d'interco mais pas une IP dans le WAN De : David Ponzone david.ponz...@gmail.com À : Antoine Durant antoine.duran...@yahoo.fr Cc : Frnog-tech frnog-t...@frnog.org Envoyé le : Mercredi 24 juin 2015 1h06 Objet : Re: [FRnOG] [TECH] problème de route pour un ping ! Voilà déjà un truc qui me plait pas: interface FastEthernet4 ip address 10.0.1.1 255.255.255.252 no ip redirects no ip unreachables no ip proxy-arp ip nat outside ip virtual-reassembly in ip verify unicast reverse-path duplex full speed 100 ! interface Vlan1 ip address 172.16.1.254 255.255.255.0 no ip redirects no ip unreachables no ip proxy-arp ip nat inside ip virtual-reassembly in ip verify unicast reverse-path ip nat inside source list 101 interface Loopback0 overload access-list 101 permit ip 172.16.1.0 0.0.0.255 any ! Ca, c’est ok. Les paquets arrivant par VLAN1 avec 172.16.1.0/24 comme IP source et qui ressortent par FE4 (la default) vont être NATés en 192.168.1.100. ip nat inside source list 100 interface Loopback0 overload access-list 100 permit ip 10.0.1.0 0.0.0.3 any Là, par contre, j’ai un problème. Si tu veux NATer les paquets qui rentrent par l’interface « ip nat outside » FE4 et qui vont vers « ip nat inside » VLAN1, l’inverse donc, la règle doit être: ip nat outside source list 100 interface Loopback0 overload et avec ton ACL 100, tu le ferais que pour les paquets qui viennent de l’IP de FE4, ou l’interface de RTR_A qui porte 10.0.1.2. J’ai du mal à voir l’intérêt, et je me demande si cette règle en inside mal placée ne serait pas la cause de ton problème. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] problème de route pour un ping !
Merci David !! Tu vas pouvoir passer une bonne soirée ta solution fonctionne :) Bravo et encore merci ! De : David Ponzone david.ponz...@gmail.com À : Antoine Durant antoine.duran...@yahoo.fr Cc : Frnog-tech frnog-t...@frnog.org Envoyé le : Mercredi 24 juin 2015 20h23 Objet : Re: [FRnOG] [TECH] problème de route pour un ping ! Ah ok, je comprends mieux. Donc c’est bien un ip nat inside qu’il faut mais tu veux pas NATer vers 192.168.1.0/24 pour que la réponse au ping fonctionne: ip nat inside source list 100 interface Loopback0 overload access-list 100 deny ip 10.0.1.0 0.0.0.3 192.168.1.0 0.0.0.255 access-list 100 permit ip 10.0.1.0 0.0.0.3 any Allez, dis-moi que ça marche, que je passe une bonne soirée, et qu’on passe à autre chose :) Le 24 juin 2015 à 19:54, Antoine Durant antoine.duran...@yahoo.fr a écrit : Salut David ! ip nat inside source list 100 interface Loopback0 overload access-list 100 permit ip 10.0.1.0 0.0.0.3 any Là, par contre, j’ai un problème. Si tu veux NATer les paquets qui rentrent par l’interface « ip nat outside » FE4 et qui vont vers « ip nat inside » VLAN1, l’inverse donc, la règle doit être: ip nat outside source list 100 interface Loopback0 overload et avec ton ACL 100, tu le ferais que pour les paquets qui viennent de l’IP de FE4, ou l’interface de RTR_A qui porte 10.0.1.2. J’ai du mal à voir l’intérêt, et je me demande si cette règle en inside mal placée ne serait pas la cause de ton problème. Oui comme tu le précise mon problème est sur l'ACL n°100 (je n'ai pas de problème avec la 101) J'ai placé volontairement cette ACL pour pouvoir depuis le RTR pinguer des adresses extérieures en sortant avec l'IP de la loopback0 Celle ci me pose problème car le ping sur les intercos ne fonctionne pas.Si j'enlève l'ACL 100 je peux pinguer mes IPs d'interco mais pas une IP dans le WAN De : David Ponzone david.ponz...@gmail.com À : Antoine Durant antoine.duran...@yahoo.fr Cc : Frnog-tech frnog-t...@frnog.org Envoyé le : Mercredi 24 juin 2015 1h06 Objet : Re: [FRnOG] [TECH] problème de route pour un ping ! Voilà déjà un truc qui me plait pas: interface FastEthernet4 ip address 10.0.1.1 255.255.255.252 no ip redirects no ip unreachables no ip proxy-arp ip nat outside ip virtual-reassembly in ip verify unicast reverse-path duplex full speed 100 ! interface Vlan1 ip address 172.16.1.254 255.255.255.0 no ip redirects no ip unreachables no ip proxy-arp ip nat inside ip virtual-reassembly in ip verify unicast reverse-path ip nat inside source list 101 interface Loopback0 overload access-list 101 permit ip 172.16.1.0 0.0.0.255 any ! Ca, c’est ok. Les paquets arrivant par VLAN1 avec 172.16.1.0/24 comme IP source et qui ressortent par FE4 (la default) vont être NATés en 192.168.1.100. ip nat inside source list 100 interface Loopback0 overload access-list 100 permit ip 10.0.1.0 0.0.0.3 any Là, par contre, j’ai un problème. Si tu veux NATer les paquets qui rentrent par l’interface « ip nat outside » FE4 et qui vont vers « ip nat inside » VLAN1, l’inverse donc, la règle doit être: ip nat outside source list 100 interface Loopback0 overload et avec ton ACL 100, tu le ferais que pour les paquets qui viennent de l’IP de FE4, ou l’interface de RTR_A qui porte 10.0.1.2. J’ai du mal à voir l’intérêt, et je me demande si cette règle en inside mal placée ne serait pas la cause de ton problème. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
