[FRnOG] [MISC] Mail to SMS Service from USA to France
Bonjour la liste, Sauriez-vous, comment faire pour recevoir des SMS sur un téléphone mobile en France avec la particularité que ces SMS sont envoyés depuis la source aux US sous forme d'emails. Par, exemple en US, avec le service Wireless Verizon , des message SMS peuvent être envoyés vers un téléphone mobile via email en utilisant (par exemple) l'email: 4252751...@vtext.com. avec 4252751XYZ correspondant à un numéro de téléphone portable d'un abonné Verizon aux US. Existe-il une sorte d'@ mail composée de la même façon, chez les opérateurs français, exemple, quelque chose comme (01133)610164XYZ@opérateur.frqui sera utilisé comme point de sortie des emails aux US et qui me permettra de recevoir des SMS en France. What my colleague need is the method to send me SMS messages by email from US. For instance, in the US, with Verizon Wireless SMS messages can be sent to a cell phone by email using 4252751...@vtext.com. Le service existe-il en France ou pas? Chez quel opérateur? le service client SFR vient de me dire qu'ils n'ont pas ce service? Que pourriez vous me conseiller, svp? Bien cordialement, Fethi --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Mail to SMS Service from USA to France
Merci pour vos éclaircissements. Pour répondre à certains points: * La source de SMS via email: sera des scripts de monitoring qui génèrent des alertes en cas d'atteinte de certains seuils aux DCs en US. Certains alertes critiques seront envoyées automatiquement par ce mode. le nombre de SMS via email dépends des alertes critiques dépendant de l'état de l'infrastructure. théoriquement, ça pourra aller de 0 à des dizaines par jour (centaines peut-être en cas de grosses pannes étendues?) * @ Pat M.: la solution avec Orange pourrait m’intéresser. Aurait-tu plus d'info? Est elle applicable en cas d'envoie d'email par scripts? *@ Guillaume B. Je ne suis pas sûr que la liste sur Wikipédia est à jour vue la réponse du contacte SFR, mais on va tenter cette piste. Après, la questions qui se pose (par curiosité) est ce que ce service est juste en locale ou pas. Éventuellement, modification de la tarification pour un exit vers l'internationale. Une transformation des emails en SMS tardive chez l'opérateur dest finale ou intermédiaire est faisable ou pas, selon accord ? * Transformer les emails en SMS en destination (mon portable) est une solution possible mais je préfère que ça soit l'option de dernier recours. De : Sidney Boumendil sidney.boumen...@gmail.com À : Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net Cc : frnog@frnog.org Envoyé le : Lundi 15 juillet 2013 22h19 Objet : Re: [FRnOG] [MISC] Mail to SMS Service from USA to France 2013/7/15 Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net Pas de facon traditionelle, mais il peut l'etre. Non, je t'assure pas plus en wholesale qu'en retail :) Ou alors chez les fraudeurs patentés comme il en existe tant dans ce milieu. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] contact postmaster OVH
Sur wikipedia c'est féminin apparemment mais ça n'engage personne à mon avis,
vue que ce n'est pas dans le dictionnaire.
http://fr.wikipedia.org/wiki/Request_for_comments
dans comment ça marche aussi c'est féminin.
Cdt,
Fethi
De : Ludovic LACOSTE ludoviclaco...@hotmail.com
À : 'Jordan VIARD' jordan.vi...@gmail.com
Cc : 'Salim Gasmi' sa...@sdv.fr; 'Sebastien PLOT' sp...@afone.com;
frnog@frnog.org
Envoyé le : Jeudi 4 avril 2013 22h08
Objet : RE: [FRnOG] [TECH] contact postmaster OVH
Exact Jordan, Request for comments, ce qui ne change rien au genre puisque
C'est comme pour les anges, y'en a pas :-)
-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
Jordan VIARD
Envoyé : jeudi 4 avril 2013 21:59
À : Ludovic LACOSTE
Cc : Salim Gasmi; Sebastien PLOT; frnog@frnog.org
Objet : Re: [FRnOG] [TECH] contact postmaster OVH
Le 4 avril 2013 21:42, Ludovic LACOSTE ludoviclaco...@hotmail.com a écrit
:
-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la
part de Salim Gasmi Envoyé : jeudi 4 avril 2013 21:02 À : Sebastien
PLOT Cc : frnog@frnog.org Objet : Re: [FRnOG] [TECH] contact
postmaster OVH
Puisque la mode du jour est de citer des RFC
Le RFC 1912 section 2.1 dit:
[...]
Make sure your PTR and A records match. For every IP address, there
should be a matching PTR record in the in-addr.arpa domain.
{...]
Question subsidiaire, RFC c'est masculin ou feminin ?
Rule For Comment, donc en Anglais, ni l'un ni l'autre, ni HE, ni
SHE
juste IT
Request For Comments, si je ne m'abuse !
Salim
Le 04/04/2013 19:48, Sebastien PLOT a écrit :
Merci aux membres de la liste qui ont répondu.
La piste de radu et de benjamin était la bonne.
aaa IN A a.b.c.d != a.b.c.d IN PTR aaa
Le 04/04/2013 19:00, Radu-Adrian Feurdean a écrit :
On Thu, Apr 4, 2013, at 11:57, Sylvain Rochet wrote:
Ce qui est tout aussi faux, il n'y a aucune restriction sur la
chaîne suivant le HELO/EHLO.
Une fois sorti du monde des bisounours qui respectent les RFC a la
regle et de la facon la plus relaxe possible, une fois revenu dans
le monde reel, pas mal d'hebergeurs de mailbox imposent des
restrictions sur la partie HELO/EHLO, le plus souvent argument =
reverse of connecting IP, qui lui resoud sur ce meme IP:
une connexion venant de X.Y.Z.T doit fournir un HELO/EHLO
toto.example.com, ou toto.example.com IN PTR X.Y.Z.T et Z.Y.X.T IN
A toto.example.com. Si ce n'est pas le cas, tu est libre de ne pas
envoyer des mails aux hebergeurs en question.
Regards,
---
Liste de diffusion du FRnOG
http://www.frnog.org/
--
Salim Gasmi -- Directeur Technique -- SdV Plurimedia
---
Liste de diffusion du FRnOG
http://www.frnog.org/
-
Aucun virus trouvé dans ce message.
Analyse effectuée par AVG - www.avg.fr
Version: 2013.0.3267 / Base de données virale: 3162/6224 - Date:
04/04/2013
---
Liste de diffusion du FRnOG
http://www.frnog.org/
--
Jordan VIARD
---
Liste de diffusion du FRnOG
http://www.frnog.org/
-
Aucun virus trouvé dans ce message.
Analyse effectuée par AVG - www.avg.fr
Version: 2013.0.3267 / Base de données virale: 3162/6224 - Date: 04/04/2013
---
Liste de diffusion du FRnOG
http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] contact postmaster OVH
Le mot chose n'est pas définie de la même façon en Français et en Anglais. Ou
plus précisément ça n'a pas tout à fait la même sémantique que Thing. C'est
quelque chose qui est inné dans chaque langue car chaque langue a ses origines
de niveau plus haut avec possibilité d' intersections au niveau des origines
communes. Après, il y a aussi les facteurs sociaux-culturelles qui influencent
la perception/définition des choses dans chaque langue.
Mais, cela relève du domaine du linguistique.
Bref, en français (c'est binaire) on va utiliser le (genre) masculin ou le
(genre) féminin car on n' a pas le choix mais en anglais on peut utiliser le/se
référer au genre thing si j'ose dire (avec It).
Cdt,
De : Ludovic LACOSTE ludoviclaco...@hotmail.com
À : 'Ccde Cissp' ccdeci...@yahoo.fr; 'Jordan VIARD' jordan.vi...@gmail.com
Cc : 'Salim Gasmi' sa...@sdv.fr; 'Sebastien PLOT' sp...@afone.com;
frnog@frnog.org
Envoyé le : Jeudi 4 avril 2013 23h01
Objet : RE: [FRnOG] [TECH] contact postmaster OVH
Bah, la prochaine fois que tu parleras à un anglophone, tu diras The RFC,
specifies ..., For the purposes of HER, ... et tu verras bien sa réaction
quand tu diras HER :-)
De :Ccde Cissp [mailto:ccdeci...@yahoo.fr]
Envoyé : jeudi 4 avril 2013 22:52
À : Ludovic LACOSTE; 'Jordan VIARD'
Cc : 'Salim Gasmi'; 'Sebastien PLOT'; frnog@frnog.org
Objet : Re: [FRnOG] [TECH] contact postmaster OVH
Sur wikipedia c'est féminin apparemment mais ça n'engage personne à mon avis,
vue que ce n'est pas dans le dictionnaire.
http://fr.wikipedia.org/wiki/Request_for_comments
dans comment ça marche aussi c'est féminin.
Cdt,
Fethi
De :Ludovic LACOSTE ludoviclaco...@hotmail.com
À : 'Jordan VIARD' jordan.vi...@gmail.com
Cc : 'Salim Gasmi' sa...@sdv.fr; 'Sebastien PLOT' sp...@afone.com;
frnog@frnog.org
Envoyé le : Jeudi 4 avril 2013 22h08
Objet : RE: [FRnOG] [TECH] contact postmaster OVH
Exact Jordan, Request for comments, ce qui ne change rien au genre puisque
C'est comme pour les anges, y'en a pas :-)
-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
Jordan VIARD
Envoyé : jeudi 4 avril 2013 21:59
À : Ludovic LACOSTE
Cc : Salim Gasmi; Sebastien PLOT; frnog@frnog.org
Objet : Re: [FRnOG] [TECH] contact postmaster OVH
Le 4 avril 2013 21:42, Ludovic LACOSTE ludoviclaco...@hotmail.com a écrit
:
-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la
part de Salim Gasmi Envoyé : jeudi 4 avril 2013 21:02 À : Sebastien
PLOT Cc : frnog@frnog.org Objet : Re: [FRnOG] [TECH] contact
postmaster OVH
Puisque la mode du jour est de citer des RFC
Le RFC 1912 section 2.1 dit:
[...]
Make sure your PTR and A records match. For every IP address, there
should be a matching PTR record in the in-addr.arpa domain.
{...]
Question subsidiaire, RFC c'est masculin ou feminin ?
Rule For Comment, donc en Anglais, ni l'un ni l'autre, ni HE, ni
SHE
juste IT
Request For Comments, si je ne m'abuse !
Salim
Le 04/04/2013 19:48, Sebastien PLOT a écrit :
Merci aux membres de la liste qui ont répondu.
La piste de radu et de benjamin était la bonne.
aaa IN A a.b.c.d != a.b.c.d IN PTR aaa
Le 04/04/2013 19:00, Radu-Adrian Feurdean a écrit :
On Thu, Apr 4, 2013, at 11:57, Sylvain Rochet wrote:
Ce qui est tout aussi faux, il n'y a aucune restriction sur la
chaîne suivant le HELO/EHLO.
Une fois sorti du monde des bisounours qui respectent les RFC a la
regle et de la facon la plus relaxe possible, une fois revenu dans
le monde reel, pas mal d'hebergeurs de mailbox imposent des
restrictions sur la partie HELO/EHLO, le plus souvent argument =
reverse of connecting IP, qui lui resoud sur ce meme IP:
une connexion venant de X.Y.Z.T doit fournir un HELO/EHLO
toto.example.com, ou toto.example.com IN PTR X.Y.Z.T et Z.Y.X.T IN
A toto.example.com. Si ce n'est pas le cas, tu est libre de ne pas
envoyer des mails aux hebergeurs en question.
Regards,
---
Liste de diffusion du FRnOG
http://www.frnog.org/
--
Salim Gasmi -- Directeur Technique -- SdV Plurimedia
---
Liste de diffusion du FRnOG
http://www.frnog.org/
-
Aucun virus trouvé dans ce message.
Analyse effectuée par AVG - www.avg.fr
Version: 2013.0.3267 / Base de données virale: 3162/6224 - Date:
04/04/2013
---
Liste de diffusion du FRnOG
http://www.frnog.org/
--
Jordan VIARD
---
Liste de diffusion du FRnOG
http://www.frnog.org/
-
Aucun virus trouvé dans ce message.
Analyse effectuée par AVG - www.avg.fr
Version: 2013.0.3267 / Base de données virale: 3162/6224 - Date: 04/04/2013
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Aucun virus trouvé
Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
Bonsoir, Piste intéressante que je qualifie aussi out of the box. En effet, j'avais pensé à ça aussi. Par contre, il faudrait s'assurer que l'EEM est supportée par la version d'IOS et que le script est bien customisé pour traduire l’ingénierie cible et se méfier de CPU surtout en cas de Flapping. J'ai proposé aussi une solution qui semble, à priori, répondre au besoin indiqué. Je vais la transmettre. Bien cordialement, Fethi De : Mohamed Touré mohamed.to...@secresys.com À : jehan procaccia INT jehan.procac...@int-evry.fr Cc : Ccde Cissp ccdeci...@yahoo.fr; frnog-t...@frnog.org frnog-t...@frnog.org Envoyé le : Mardi 5 mars 2013 14h49 Objet : Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques Bonjour, Je peux vous proposer une solution qui consiste à mettre à jour les prefix-list via cisco EEM. (je suppose que vous utilisez du cisco) La solution est spécifique certes, mais c'est pour répondre à un besoin non standard. Topogie : CPE : R1 f0/0 : 192.168.12.1 - To ISP1 f0/1 : 192.168.13.1 - To ISP2 PE1: R2 f0/0 : 192.168.12.2 - To R1 PE2: R3 f0/0 : 192.168.13.3 - To R1 Config BGP : ! router bgp 1 neighbor 192.168.12.2 remote-as 2 neighbor 192.168.12.2 route-map TO-ISP1 out neighbor 192.168.12.2 soft-reconfiguration inbound neighbor 192.168.13.3 remote-as 3 neighbor 192.168.13.3 route-map TO-ISP2 out neighbor 192.168.13.3 soft-reconfiguration inbound exit ! ip prefix-list ISP1 permit 10.10.10.0/24 ip prefix-list ISP2 permit 11.11.11.0/24 ! ! route-map TO-ISP1 permit 10 match ip address prefix-list ISP1 ! route-map TO-ISP2 permit 10 match ip address prefix-list ISP2 ! Mise en situation : A ce stade, supposons que CPE1 ait dans sa table BGP les prefix : 10.10.10.0/24 et 11.11.11.0/24. Avec la config ci-dessus, ISP1 recevra le prefix 10 et ISP2 le prefix 11 : on est en situation nominale. Maintenant supposons qu'on perde le lien vers ISP1. Ce que vous souhaitez c'est d'annoncer 10 et 11 à l'ISP2. Code EEM : event manager applet DOWN event syslog pattern %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Down Interface flap action 1.0 syslog msg Interface Down : Modifying Prefix-list = message qui va apparaitre dans les logs action 1.1 cli command enable action 1.2 cli command configure terminal action 2.0 cli command ip prefix-list ISP2 permit 10.10.10.0/24 action 3.0 cli command end action 4.0 cli command write action 5.0 clear ip bgp 192.168.13.3 soft ! event manager applet UP event syslog pattern %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up action 1.0 syslog msg BGP Session UP : Modifying Prefix-list = message qui va apparaitre dans les logs action 1.1 cli command enable action 1.2 cli command configure terminal action 2.0 cli command no ip prefix-list ISP2 permit 10.10.10.0/24 action 3.0 cli command end action 4.0 cli command write action 5.0 clear ip bgp 192.168.13.3 soft ! Explications : Principe : Siévenement alors action. L'événement peut-être choisi parmi une liste définie par le constructeur (présence d'un préfixe dans la table de routage, interface down, ipsla ...). Ici je traque le message %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Down Interface flap dans syslog. Un autre peut-être choisi bien entendu. Lorsque cette condition est satisfaite, je modifie à la volée ma prefix-list vers ISP2. ! enable configure terminal ip prefix-list ISP2 permit 10.10.10.0/24 end ! Dans le meme principe, si la session devient UP à nouveau, je retire le prefix. A chaque fois un clear soft sera necessaire pour prendre en compte la route-map au niveau du process BGP. NB : A toute fin utile, il faudrait surveiller la charge CPU avant de mettre en production. Cordialement Mohamed Touré 2013/3/4 jehan procaccia INT jehan.procac...@int-evry.fr bonjour, la methode suivante fonctionne partiellement mieux: router bgp ASNUM neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP neighbor x.x.x.x route-map MY-PREFIXES out en mode nominal (ISP primaire UP) j'annonce bien mes QQ-PREFIX à l'ISP secondaire en cas de perte de l'ISP primaire j'annonce bien dynamiquement tous mes prefixes MY-PREFIXES à l'ISP secondaire mais malheureusement je n'annonce plus les prefix QQ-PREFIX dans cette situation, en effet exist-map 1ST-ISP-UP n'est plus vrai, donc je suppose qu'il élimine les prefix QQ-PREFIX qui sont inclus dans MY-PREFIXES et n’annonce que le reste des MY-PREFIXES . Bref c'est mieux, mais ce n'est pas encore satisfaisant pour assurer le trafic engineering attendu , en effet quand l'ISP primaire est tombé, les QQ-PREFIX qui profitaient d'un trafic engineering via les 2eme ISP se retrouvent coupé du monde car ils ne sont plus annoncés au secondaire, alors même que ce dernier (ISP 2) n'a subit aucune perte ! J'ai bien entendu
Re: RE : Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
Bonjour, Effectivement, vue cette histoire de AND Logique entre les différentes maps définies. Vous pouvez par exemple tester: 1. Et là (je pense que) ce notre dernier espoir avec les annonces conditionnelles :-) router bgp ASNUM neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP neighbor x.x.x.x route-map MY-PREFIXES out 2. Sinon, il faut jouer avec l'AS PATH PREPENDING ou toute autre chose influençant le trafic INBOUND autre que les annonces conditionnelles via des advertise map... Bien cordialement, Fethi De : touremoha...@gmail.com touremoha...@gmail.com À : jehan.procac...@int-evry.fr; frnog-t...@frnog.org Cc : ccdeci...@yahoo.fr Envoyé le : Vendredi 1 mars 2013 15h38 Objet : RE : Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques Bonjour, Une piste peut eventuellement etre testee. Il s'agit de voir si on peut cumuler une exist-map et une non-exist-map pour le meme peer bgp. Si on note A la liste des 55 prefixes annonces a l'ISP1 et B la liste des 5 prefixes annonces a l'ISP2. On annonce inconditionnellement A a l'ISP1. On annonce B a l'ISP2 si exist-map XXX (a definir). On annonce A et B si non-exist-map YYY (a definir). De sorte que si ISP1 down les 60 prefixes sont annonces a l'ISP2. Une autre piste : utiliser as-path prepend. On annonce A vers ISP1 sans modification. On annonce B vers ISP2 sans modification. On annonce A vers ISP2 avec un as-path prepend. Internet recevra les prefixes (s'il nya pas d'alteration des ISP : summarization, modif ...) et l'ISP1 sera prefere pour la liste A et ISP2 pour la liste B. Si la session vers ISP1 est down alors l'ISP2 sera prefere. Bien sur, il ya d'autres pistes :). Cordialement Mohamed Toure -- Envoyé de mon téléphone Nokia --Message original-- De : jehan procaccia INT jehan.procac...@int-evry.fr To: frnog-t...@frnog.org frnog-t...@frnog.org Cc: Ccde Cissp ccdeci...@yahoo.fr Date: vendredi 1 mars 2013 12:25:54 GMT+0100 Subject: Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques Le 28/02/2013 22:45, Ccde Cissp a écrit : Hello, Je n'ai pas très bien compris votre question et je souhaite vous demander quelques informations: 1. Concernant votre conf: Pourquoi vous annoncer la même chose (MY-PREFIXES) au même neighbor (x.x.x.x) avec deux façon différentes alors que votre but ultime c'est d'annoncer MY-PREFIXES si et seulement si la condition non-exist-map est vérifiée et donc la ligne : neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP suffira pour satisfaire votre 1ère condition. ! La ligne de conf: neighbor x.x.x.x route-map MY-PREFIXES out: je ne vois pas son intérêt ici elle n'apporte rien vis à vis de vos 2 conditions que vous souhaitez mettre en oeuvre. cette deuxième ligne est nécessaire, car sans elle je n'annonce pas MY-PREFIXES quand la condition est vraie (1st ISP is down) c'est du vecu , certes empirique car je trouve ça aussi apparemment redondant, mais je constate que je n'annonce tj rien sans cette ligne meme si l'ISP primaire est down :-( . 2. Je vous conseille de faire un test/LAB avec seulement: neighbor x.x.x.x route-map QQ-PREFIX out et voir si l'interaction avec neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP est un AND LOGIC ou pas càd si le résultat de deux types d'annonce utilisés simultanément est l'annonce de l'intersection entre les deux ensemble QQ-PREFIX et MY-PREFIXES qui sera dans ce cas l'ensemble QQ-PREFIX. apparement c'est plutot un AND j'ai mis en 2eme ligne neighbor x.x.x.x route-map QQ-PREFIX out, tout en gardant en 1er ligne neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP quand l'ISP primaire est UP, rien n'est annoncée (j'aurai esperé voir QQ-PREFIX) et quand l'ISP primaire est Down alors seulement QQ-PREFIX est annoncé: Edge2#show ip bgp neighbors x.x.x.x advertised-routes Network Next Hop Metric LocPrf Weight Path * X.X.21.0/24 p.p.p.p 2 32768 i Edge2#show ip route X.X.21.0 Routing entry for X.X.21.0/24 Known via ospf 1, distance 110, metric 2, type extern 1 Redistributing via bgp Advertised by bgp match internal external 1 2 ce n'est pas le resultat attendu, je voulais voir MY-PREFIXES annoncés au minimum et au mieux MY-PREFIXES + QQ-PREFIX (ps: l'unique /24 QQ-PREFIX actuellement dans mon test/lab est contenu dans MY-PREFIXES, cela a peut-etre une incidence ?). 3. Remarque: Le résultat que vous avez pu voir et que vous avez décrit dans: neighbor x.x.x.x route-map QQ-PREFIX out cette ligne écrase alors neighbor x.x.x.x route-map MY-PREFIXES out serait du à un AND LOGIC entre les deux lignes de conf qui sont ici équivalentes de point de vue syntaxe. A vérifier, donc, que cet AND LOGIC n'existe pas entre
Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
Hello, Je n'ai pas très bien compris votre question et je souhaite vous demander quelques informations: 1. Concernant votre conf: Pourquoi vous annoncer la même chose (MY-PREFIXES) au même neighbor (x.x.x.x) avec deux façon différentes alors que votre but ultime c'est d'annoncer MY-PREFIXES si et seulement si la condition non-exist-map est vérifiée et donc la ligne : neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP suffira pour satisfaire votre 1ère condition. ! La ligne de conf: neighbor x.x.x.x route-map MY-PREFIXES out: je ne vois pas son intérêt ici elle n'apporte rien vis à vis de vos 2 conditions que vous souhaitez mettre en oeuvre. 2. Je vous conseille de faire un test/LAB avec seulement: neighbor x.x.x.x route-map QQ-PREFIX out et voir si l'interaction avec neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP est un AND LOGIC ou pas càd si le résultat de deux types d'annonce utilisés simultanément est l'annonce de l'intersection entre les deux ensemble QQ-PREFIX et MY-PREFIXES qui sera dans ce cas l'ensemble QQ-PREFIX. 3. Remarque: Le résultat que vous avez pu voir et que vous avez décrit dans: neighbor x.x.x.x route-map QQ-PREFIX outcette ligne écrase alors neighbor x.x.x.x route-map MY-PREFIXES out serait du à un AND LOGIC entre les deux lignes de conf qui sont ici équivalentes de point de vue syntaxe. A vérifier, donc, que cet AND LOGIC n'existe pas entre deux syntaxes d'annonces différentes: neighbor x.x.x.x route-map QQ-PREFIX out et neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP a mon avis le AND logic persistera, à confirmer car cela dépend du code constructeur. Please ;) dites nous les résultats de vos tests. Si vos deux conditions ne seront pas vérifiées (fort probable), il faut intervenir des nouveaux ingrédients :) Cordialement, Fethi De : jehan PRocaccia jehan.procac...@int-evry.fr À : frnog-t...@frnog.org Envoyé le : Jeudi 28 février 2013 13h09 Objet : [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques Bonjour, je suis end user avec 2 FAI, je souhaite annoncer quelques prefixes (5) au second FAI afin de favoriser le trafic entrant pour ces qq prefixes via le 2nd FAI (plutot que le FAI primaire) , tout en bénéficiant d'un mécanisme automatique d'annonce de tous mes prefixes (60) au secondaire en cas de défaillance totale du FAI primaire . Je n'annonce pas tous mes préfixes aux 2 FAI en parallèle car je ne me sert du 2em FAI qu'en cas de backup et/ou de trafic engineering sur certains prefixes sélectionnés suivant les besoins du moment. j'ai bien réussi dans le cadre de ce dual homing BGP a annoncer de manière conditionnelle tous mes prefixes au second FAI seulement quand le primaire est défaillant = annonce bgp au 2eme FAI conditionnée sur la présence ou non d'une route venant du FAI primaire. En termes technique: router bgp ASNUM neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP neighbor x.x.x.x route-map MY-PREFIXES out show route-map 1ST-ISP-UP Match clauses: ip address (access-lists): 3 Standard IP access list 3 10 permit Y.Y.Y.Y, wildcard bits 0.0.0.7 log (4604 matches) Y.Y.Y.Y = reseau interco avec FAI primaire et route-map MY-PREFIXES contiens tous mes prefix Cette solution est satisfaisante, sauf que dans cette configuration, je n'arrive pas a annoncer au 2em FAI en complément mes qq prefixes que je juge non conditionnés par la présence du FAI primaire, bref que je souhaite annoncer à ma convenance, sans attendre que le primaire tombe j'ai bien peur de rentrer à tous les coups dans la condition advertise-map if non-exist-map, et comme la route du FAI primaire est présente la condition est fausse et ainsi je n'annonce rien au 2em FAI . En résumer, comment cumuler les 2 ? = 1) annoncer automatiquement et de manière conditionnelle (perte du 1er FAI) tous mes prefix, 2) tout en annonçant à ma convenance (non dependante de l'etat du 1er FAI) qq prefixes que j'aurai selectionné manuellement . j'ai beau ajouter aux lignes router BGP ASNUM ci-dessus pour ce peer neighbor x.x.x.x route-map QQ-PREFIX out cette ligne écrase alors neighbor x.x.x.x route-map MY-PREFIXES out, comment les cumuler ? Merci pour vos conseils . --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
1000% d'accord. Plein de respect aux chercheurs qui ont ouverts la voie au monde pro/industriel et qui ne sont pas (je trouve) assez récompensé de point de vue salaire. Sinon, je propose aux sponsors de distribuer des porte-clés GBIC lors du meeting : D . Cordialement, De : Salim Gasmi sa...@sdv.fr À : Kavé Salamatian kave.salamat...@univ-savoie.fr Cc : s.lesim...@b-and-c.net; frnog@frnog.org frnog@frnog.org Envoyé le : Jeudi 10 janvier 2013 12h30 Objet : Re: [FRnOG] Re: [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie] Bonjour à tous, je vais ajouter ma part de bruit dans ce brouhaha. Je ne comprends pas du tout le sens de ce débat. Deux choses sont surprenantes (en tous cas me surprennent): 1: Le GBICGate est assez surréaliste, c’était un simple filtre anti bot et n'importe qui (chercheur ou pas) pouvait trouver la réponse et il est délirant d'y voir une forme de filtrage autre que de s'assurer que l'interface chaise clavier est dotée d'un cœur (et d'un cerveau). J'ai fait le test avec mon fils de 10 ans qui n'est ni chercheur, ni informaticien, il a tappé tout seul GBIC image et SFP image dans google et a trouvé la bonne réponse en moins d'une minute. Venir ici se plaindre de la pratique relève de la mauvaise foi. 2: Le discours de certains ici sur la méconnaissance supposée du monde réseau concret et du monde de l'entreprise des universitaires. Oui, c'est vrai, un chercheur ne reconnait pas naturellement un GBIC d'un SFP, par ce que ce n'est pas son metier. Son métier c'est de chercher (et éventuellement trouver) des choses qui seront ensuite implémentés dans le monde réel. Grace a Bresenhem nos ordis savent tracer des lignes. Grace a Dijkstra ont fait du routage Grace aux theories des graphes ont fait de l'optimisation de routes Grace aux matheux cryptographes on sécurise nos données. La liste est très longue. Tout ce qu'on fait en opérationnel a d'abord été pensé par un chercheur dans son lab, et je suis content qu'il ne connaisse pas un GBIC d'un SFP ca c'est pour les graisseux comme moi qui se bornent a le brancher dans le trou sans comprendre exactement comment il marche. Alors oui, un peu de respect pour les chercheurs et universitaires n'est pas de refus, la recherche fondamentale est la base de notre métier. Salim --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
Hello, 1.Pour moi un enseignant, enseigne une logique plutôt qu'un contenu. Un bon enseignant apprends à ces étudiants comment apprendre. Surtout dans un domaine en perpétuelle évolution qui est le notre. C'est l'histoire ne me donne pas un poisson mais apprends moi comment pêcher. Combien des bons enseignants chercheurs dans un domaine précis mais qui sont capable d'enseigner plus large... Ce n'est pas un inconvénient. 2.Pour l'histoire du connecteur, il y a google image pour ça. J'en connais des architecte de très haut niveau qui n'ont jamais toucher un routeur ou un câble ... Par contre, si vous êtes technicien de câblage vous avez intérêt à le connaître. Mais bon le but bien sûr sur le formulaire d'inscription c'est d'éviter le SPAMM. ;) Fethi De : Arnaud Launay a...@launay.org À : frnog@frnog.org Envoyé le : Mercredi 9 janvier 2013 22h01 Objet : Re: [FRnOG] Re: [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie] Le Wed, Jan 09, 2013 at 03:21:19PM +0100, Samuel Thibault a écrit: Mais par exemple pour un enseignant dont le domaine de recherche n'est pas du tout le réseau (c'est mon cas, d'ailleurs), mais qui se trouve à enseigner le réseau parce qu'il en faut bien dans n'importe quel cursus d'info Merci de confirmer que les enseignants enseignent n'importe quoi sur des sujets sur lesquels ils ne sont pas compétents. Maintenant, on comprend mieux pourquoi les pseudo-diplômés doivent être reformés lorsqu'ils arrivent en entreprise. Arnaud. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG] [TECH] Solution Wifi moyenne échelle
Bonjour, Il y a des gens qui aiment bien partager/aider/discuter/s'exprimer sur un sujet ou un autre peu importe le contexte. Et d'autres qui n'aiment pas. Cela dépends juste de la mentalité et de l'état d'esprit de chacun. Vous pouvez répondre. Vous pouvez ne pas répondre. Vous êtes libre bien sûr. C'est sûr qu'on s'adressant à la liste, on s'attend pas à une consultation formelle, mais plutôt à un avis ou des fois c'est juste pour évoquer un sujet qui pourrait faire couler les plumes des passionnés ou attiré l'attention des curieux. Ce n'est pas beau de faire de la censure. Soyons positifs ;-). De : David Ramahefason r...@netfacile.net À : frnog@frnog.org Envoyé le : Mercredi 26 décembre 2012 11h31 Objet : Re: [FRnOG] [FRNOG] [TECH] Solution Wifi moyenne échelle Marrant c'est exactement le sentiment que j'ai depuis un certain temps sur les post tech FrNOG. Bon Noël à tous/toutes David R. Le 17 décembre 2012 11:58, Sylvain Vallerot sylv...@gixe.net a écrit : On 17/12/2012 10:20, Frédéric wrote: Le 2012-12-17 10:16, Bruno CAVROS / SKIWEBCENTER a écrit : Il suffit de réfléchir un peu... le Campus de triffouilli les oies avec 2 salles ou campus de cambridge n'ont je pense pas la même superficie ni le même nombre d'utilisateurs.. Dans le doute.. laissez faire des pros du réseau.. Vachement constructif ta remarque... Ben si c'est constructif. Et vu les questions étranges qui sont soumises ici depuis quelques semaines (répondre à l'étude de l'un, chiffrer le datacenter de l'autre, quantifier l'infra wifi du 3è) je comprends bien la réaction de Bruno. Non pas que ces questions n'aient pas d'intérêt; mais ce sont des dossiers qui se constituent au moyen de longues recherches, études, démarches auprès des fournisseurs, prestataires, de négociations, business plan, étude de marché, et réactualisations incessantes, en fonction du lieu, du besoin, du ciblage, de l'implantation, des moyens de financement, de la stratégie. Ce sont des dossiers complexes, qui prennent du temps et coûtent de l'argent à monter, il y a de quoi écrire un bouquin à chaque fois. Alors quelle espèce de recette miracle peut-on fournir qui soit plus pertinente que le dernier perdre votre ventre en 2 semaines ou devenir riche sans sortir de chez soi ? Bonjour, je voudrais monter un FAI, pouvez-vous me proposer un business plan et m'apprendre le métier ? Je ne suis pas loin de penser (comme Bruno ?) que quand on a besoin de monter un réseau sur un campus de la taille d'une petite ville et qu'on pose des question comme celle-là sur FRnog, il y a un décalage manifeste et la véritable question qu'il faut se poser est peut-être «ai-je la capacité de gérer un tel projet» ? Et ça n'est pas une insulte : ce genre de questions il faut mieux se les poser avant que de se lancer dans un chantier au milieu duquel si on n'a pas les connaissances techniques et de gestion nécessaires, on on se retrouvera submergé par les imprévus, rattrapé par les deadlines et à court de cash forcé de déposer le bilan. Il vaut mieux prévenir que guérir, et prévenir c'est souvent perçu comme négatif, mais en réalité c'est s'assurer que les bases sont saines pour pouvoir correctement construire. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason r...@netfacile.net --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Disaster Recovery IP Addressing
Hello, Quelqu'un aurait-il confronté le même problème, s'il vous plaît ? Auriez-vous des conseils, des suggestions, des idées ou des points de vue personnel? Cordialement, De : Ccde Cissp ccdeci...@yahoo.fr À : frnog-t...@frnog.org frnog-t...@frnog.org Envoyé le : Vendredi 7 décembre 2012 16h20 Objet : [FRnOG] [TECH] [Urgent] Disaster Recovery IP Addressing Bonjour la liste, Dans le cadre d'un projet de PCI, un nouveau DataCenter de Backup est à concevoir. Le premier point à voir: est-il préférable ou pas de garder le même plan d'adressage que le site primaire et utiliser des VIP sachant que sur beaucoup d'applications l'adressage est codé en dur ? Le but est de faire en prémier lieu de l'Actif/Backup manuel pour évoluer vers de l'actif/Actif sans nécessairement faire de la réplication synchrone(ce n'est pas une exigence). De point de vue système, une solution SRM Vmware sera utilisée. VMotion à voir aussi si la distance et le lien physique le permettra mais ce n'est pas vraiment le but? La distance entre les deux sites est de 240 Km et la liaison n'est pas de la fibre optique. Théoriquement, 3 grands Scénarios se posent: 1. faire l'image identique du 1er site tout en interdisant tout contact direct entre les deux sites en utilsant du Source NAT par exemple pour la réplication des donnés ou autres flux inter sites? Pour l'adressage public on jouera sur les poids des routes annoncés à l'identique de deux côté. 2. Garder le même plan d'adressage et utiliser des VIP, et propager les VLANs entre les deux sites pour faire des extensions de niveau 2 permettant ainsi de faire des probes sur les serveurs réparties sur les deux sites et détecter rapidement les pannes. Par contre, un problème de routage optimum se pose si on veut faire un failover à l'échelle d'une seule appli car on ne peut pas annoncer son /32 du côté du site secondaire sachant que cela sera filtré par l'operateur donc le flux INCOMING passera toujours par le site primaire et traversera le lien inter sites pour attaquer l'appli et le flux OUTCOMING sortira par la GW local du site secondaire (=routage asymétrique). 3. Utiliser un plan d'adressage complètement différent entre les deux sites et jouer sur le DNS public pour faire du failover ou du Load Balancing entre les deux sites. Sachant que le DNS public est géré par l'opérateur et que sur beaucoup des appli les adresseS IP sont codées en dur. Je ne sais pas si LISP est mis en oeuvre actuellement chez les opérateurs ou pas ou peut-être il n'y aurai pas besoin ? Je ne sais pas si des solutions Cisco GSS (Global Site Selector) avec ACE existent chez les opérateurs ou pas? Bien cordialement, Merci d'avance de votre aide. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [Urgent] Disaster Recovery IP Addressing
Bonjour la liste, Dans le cadre d'un projet de PCI, un nouveau DataCenter de Backup est à concevoir. Le premier point à voir: est-il préférable ou pas de garder le même plan d'adressage que le site primaire et utiliser des VIP sachant que sur beaucoup d'applications l'adressage est codé en dur ? Le but est de faire en prémier lieu de l'Actif/Backup manuel pour évoluer vers de l'actif/Actif sans nécessairement faire de la réplication synchrone(ce n'est pas une exigence). De point de vue système, une solution SRM Vmware sera utilisée. VMotion à voir aussi si la distance et le lien physique le permettra mais ce n'est pas vraiment le but? La distance entre les deux sites est de 240 Km et la liaison n'est pas de la fibre optique. Théoriquement, 3 grands Scénarios se posent: 1. faire l'image identique du 1er site tout en interdisant tout contact direct entre les deux sites en utilsant du Source NAT par exemple pour la réplication des donnés ou autres flux inter sites? Pour l'adressage public on jouera sur les poids des routes annoncés à l'identique de deux côté. 2. Garder le même plan d'adressage et utiliser des VIP, et propager les VLANs entre les deux sites pour faire des extensions de niveau 2 permettant ainsi de faire des probes sur les serveurs réparties sur les deux sites et détecter rapidement les pannes. Par contre, un problème de routage optimum se pose si on veut faire un failover à l'échelle d'une seule appli car on ne peut pas annoncer son /32 du côté du site secondaire sachant que cela sera filtré par l'operateur donc le flux INCOMING passera toujours par le site primaire et traversera le lien inter sites pour attaquer l'appli et le flux OUTCOMING sortira par la GW local du site secondaire (=routage asymétrique). 3. Utiliser un plan d'adressage complètement différent entre les deux sites et jouer sur le DNS public pour faire du failover ou du Load Balancing entre les deux sites. Sachant que le DNS public est géré par l'opérateur et que sur beaucoup des appli les adresseS IP sont codées en dur. Je ne sais pas si LISP est mis en oeuvre actuellement chez les opérateurs ou pas ou peut-être il n'y aurai pas besoin ? Je ne sais pas si des solutions Cisco GSS (Global Site Selector) avec ACE existent chez les opérateurs ou pas? Bien cordialement, Merci d'avance de votre aide. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Candidature: Ingénieur d’étude Réseaux/Ingénieur Avant-vente Réseaux/ Architecte Réseaux
Bonjour, Je suis actuellement en poste d’Ingénieur Réseaux et sécurité chez un Opérateur (/Intégrateur) Télécom International à la Défense. J’ai un Bac plus 5 spécialisé en Réseaux d’entreprise (Conservatoire National des Arts et Métiers CNAM Paris) et deux ans d’expériences (hors divers projets). Je suis à la recherche d’une nouvelle expérience en tant qu’Ingénieur d’étude Réseaux/Ingénieur Avant-vente Réseaux/ Architecte Réseaux en Île-de-France. J’ai l’esprit d’équipe et de communication, je m’adapte facilement et je sais prendre des initiatives. Je suis proactif, passionné et très motivé. Spécialités : Ø Ingénierie Réseaux LAN/MAN/WAN ; Ø Opération d’infrastructure Réseaux et sécurité ; Ø Planification, Dimensionnement et Modélisation réseaux sous OPNET ; Ø Analyse et évaluation des risques en sécurité des systèmes d’information. Si mon profile vous intéresse, n’hésitez pas à m’envoyer un courriel en privé pour que je puisse vous envoyer mon CV détaillé. Hello, I am currently working as a Network and security Engineer at an International telecom Operator in Paris La Défense. I earned a master’s degree from Conservatoire National des Arts et Métiers: CNAM Paris, with specialization in Network engineering, Security and LAN/WAN Management. I have the team spirit and good communication skills. I adapt easily and I am initiative. I am proactive, passionate and highly motivated. I’ m seeking for a new job opportunity in Île-de-France region as a Network Engineer/Pre-sales Engineer/TDA. Specialties: Ø LAN/MAN/WAN engineering; Ø Network and security operations; Ø Network planning, sizing and modeling under OPNET; Ø Information Systems Security Risk assessment and analysis. Please let me know if you are interested. I’ll send you my detailed CV. An English version is already available. Best regards, Cordialement, Fethi ORF --- Liste de diffusion du FRnOG http://www.frnog.org/
