Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Une question qui reste en suspend :

Nous avons donc 2 routeurs BGP avec un prefixe "localisé" sur chaque
routeur + session iBGP entre les 2 : sur chaque routeur, pas mal de routes
en /32 vers nos différents équipements.

Je voudrais que toutes les routes en /32 du routeur 1 soient annoncées en
iBGP sur le routeur 2, et inversement.

Actuellement cela ne se fait pas. Les routes-map in et out sont OK.  J'ai
des directives network pour mes prefixes mais pas pour mes routes en /32.
Je suppose qu'il faut une directive network pour chaque route en /32 ?

router bgp 1234
 address-family ipv4
  network 1.2.3.4 mask 255.255.255.255
  network 3.4.5.6 mask 255.255.255.255
  

Ca me parait lourd à gérer et pas très clean. Comment faire les choses dans
les règles de l'art ?

Merci pour vos lumières !



Le 2 novembre 2015 11:11, Fabien H <frnog.fab...@gmail.com> a écrit :

> Bonjour Raphael,
>
> Tout à fait, ça parait logique ! D'ailleurs pour les basiques et la mise
> en place y'a pas mal de ressources bien faites sur le net notamment les
> présentations Workshop d'Arnaud Fernioux. Ca permet de voir si globalement
> on est dans les clous ou pas !
>
> Bonne journée !
>
> Le 2 novembre 2015 10:36, Raphael Mazelier <r...@futomaki.net> a écrit :
>
>> Back to basic.
>>
>> Ton AS ne devrait jamais être disjoint.
>> Dépendant de ta localisation de tes deux datacenters, le mieux c'est
>> quand même de prendre une dark. Si tu ne peux pas tu utilise deux l2l, voir
>> un l2l avec backup sur Gre.
>>
>> 2eme point : on redit, tu fait tourner un IGP entre des deux routeurs
>> (Ospf, Isis) juste pour les loopbacks de tes routeurs (et les intercos si
>> tu veux). Et tu montes tes sessions Ibgp entre ces loopbacks de sortes que
>> te sessions IBGP ne doivent jamais tombés (sauf si faillure du routeur,
>> mais faillure de path). Et dans ton IBGP tu mets ce que tu veux, tes mores
>> specifics (dans ton cas tes /32).
>>
>>
>>
>> Le 02/11/15 10:23, Fabien H a écrit :
>>
>>> Mais d'ailleurs, 2 lan2lan de 2 fournisseurs différents en place sur le
>>> même SW de part et d'autre ne risquent pas de mal fonctionner ? C'est
>>> transparent ?
>>>
>>> Le 2 novembre 2015 09:50, Clement Cavadore <clem...@cavadore.net> a
>>> écrit :
>>>
>>> On Mon, 2015-11-02 at 09:41 +0100, Oceanet - Cédric BASSAGET wrote:
>>>>
>>>>> Ça c'est la solution quand y'a des sous ;)
>>>>>
>>>>
>>>> Faut se donner les moyens de ses ambitions...  Surtout vu les prix
>>>> moyens des lan2lan datacenter-datacenter, de nos jours :-)
>>>>
>>>> --
>>>> Clément Cavadore
>>>>
>>>>
>>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

OK, je vais étudier tout ça en reprenant tous les points dans l'ordre.

Ce qui est assez étonnant, c'est que c'est déjà arrivé que le L2L tombe en
journée, et donc la session iBGP tombe rapidement (j'ai mis un SLA icmp qui
ping le loopback d'en face),

Le BGP a bien joué son rôle et chaque routeur fonctionnait de manière
autonome avec son transitaire : Impact minime. C'est pour ça que je
sous-estimait le risque d'un split-brain : pour moi, c'était 40 secondes à
2 minutes de coupure uniquement.

Et là les routes statiques dans ce cas ont bien joué leur rôle (elles ne
disparaissent pas lors de la perte de l'iBGP).

Mais je comprend maintenant que la logique est mauvaise..







Le 2 novembre 2015 20:43, Jérôme Nicolle  a écrit :

> Plop,
>
> Le 02/11/2015 10:46, Christophe Lucas a écrit :
> > Tu peux pas jouer avec du conditional advertisement en désagrégeant le
> cas échéant en fonctions des
> > subnets locaux ?
>
> Alors, c'est pas parce que la plupart des implémentations de BGP sont
> Turing-Complete (http://vanbever.eu/pdfs/vanbever_turing_icnp_2013.pdf)
> qu'en explorer les aspects programmatiques aboutira à un bon design.
>
> Clairement dans ce cas précis, le tuneling GRE via les transits, avec un
> métrique faible sur l'IGP sans toucher à l'iBGP, devrait suffire à
> résoudre la plupart des problématiques opérationnelles, faite de
> redondance sur le L2L.
>
> Après si on veut enculer des mouches, la redistributions conditionnelle
> peut aider à optimiser certains flux, mais c'est à mon avis marginal
> dans la très grande majorité des cas.
>
> Donc option 1 : redonder le L2L pour éviter le split-brain, option 2
> tunneling GRE (ou autre) signalisé par l'IGP. Les deux ne sont pas
> mutuellement exclusifs.
>
> @+
>
> --
> Jérôme Nicolle
> 06 19 31 27 14
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Bonjour,

merci, si j'ai bien compris, cette solution s'approche un peu du
redistribute en EIGRP mais en BGP. C'est effectivement à tester.

Mais je bloque toujours sur le besoin de failover Routeur BGP.

Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2 ne
pourra pas assurer le failover de R1 pour les routes en /32...

Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI <montgom...@simonpietri.net
> a écrit :

> Bonjour,
>
> Est-ce que vous avez pensé à mettre une solution avec du "redistribute
> static route-map" pour éviter d'annoncer les /32 et du prepend sur les
> prefix a backuper ?
>
>
>
> Du style :
>
> ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
> ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999
>
> access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1
>
> access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2
>
> route-map BACKUP-PREPEND permit 10
>  match ip address 70
>  set as-path prepend 1234
>
> route-map BACKUP-PREPEND permit 20
>
> route-map TAGGED-STATIC permit 10
>  match tag 999
>
> router bgp 1234
>  redistribute static route-map TAGGED-STATIC
>  neighbor PEER_ADDRESS route-map BACKUP-PREPEND out
>
>
>
>
>
> 2015-11-02 9:16 GMT+01:00 Fabien H <frnog.fab...@gmail.com>:
>
>> Bonjour la liste,
>>
>> J'ai une question BGP à vous soumettre :
>>
>> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
>> avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
>> Sur chaque routeur BGP, nous avons au moins un transitaire.
>>
>> Tout fonctionne parfaitement !
>>
>> Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
>> utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
>> route Null0).
>> Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
>> sur le routeur BGP concerné.
>>
>> - Ma question : Nous aimerions mettre en place un failover BGP automatique
>> en cas de défaillance matérielle totale d'un des routeurs BGP.
>>
>> La solution que j'imaginais est de mettre en place, pour un même prefixe,
>> une route Null0 sur les 2 routeurs en même temps.
>>
>> Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
>> les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
>> => Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
>> problème.
>>
>> Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
>> mais que le L2L tombe.
>>
>> Dans ce cas, un paquet va continuer à arriver par le transit sur le
>> routeur
>> BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
>> mais l'IP de GW étant normalement accessible via le L2L sur un VLAN donné,
>> le routage ne fonctionnera pas car le L2L est tombé.
>>
>> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une solution
>> à
>> ce problème ?
>>
>> Merci,
>> Bonne journée,
>> Fabien
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Bonjour la liste,

J'ai une question BGP à vous soumettre :

En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
Sur chaque routeur BGP, nous avons au moins un transitaire.

Tout fonctionne parfaitement !

Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
route Null0).
Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
sur le routeur BGP concerné.

- Ma question : Nous aimerions mettre en place un failover BGP automatique
en cas de défaillance matérielle totale d'un des routeurs BGP.

La solution que j'imaginais est de mettre en place, pour un même prefixe,
une route Null0 sur les 2 routeurs en même temps.

Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
=> Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
problème.

Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
mais que le L2L tombe.

Dans ce cas, un paquet va continuer à arriver par le transit sur le routeur
BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
mais l'IP de GW étant normalement accessible via le L2L sur un VLAN donné,
le routage ne fonctionnera pas car le L2L est tombé.

Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une solution à
ce problème ?

Merci,
Bonne journée,
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Bonjour Cedric,
merci pour la réponse, intéressant !

Malgré tout, comme j'ai des routes statiques et spécifiques vers des IP en
/32 dupliquées sur chaque routeur BGP, elles seront toujours prioritaires
sur les routes apprises en iBGP .. Ca doit être le fond du problème je
pense ..

Le 2 novembre 2015 09:28, Oceanet - Cédric BASSAGET <ced...@oceanet.com> a
écrit :

> Bonjour Fabien,
>
> Un tunnel GRE entre tes deux routeurs via du transit, et une session iBGP
> sur ce GRE ?
> Cédric
>
> OCEANET
> ---
> [AGENCE DU MANS]
> 7, rue des Frênes
> ZAC de la Pointe
> 72190 SARGE LES LE MANS
> [t] +33 (0)2.43.50.26.50
> [f] +33 (0)2.43.72.21.14
>
> [AGENCE D'ANGERS]
> 5, rue Fleming
> Angers Technopole
> 49066 ANGERS
> [t] +33 (0)2.41.19.28.65
> [f] +33 (0)2.52.19.22.00
>
>
> On 02/11/2015 09:16, Fabien H wrote:
>
>> Bonjour la liste,
>>
>> J'ai une question BGP à vous soumettre :
>>
>> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
>> avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
>> Sur chaque routeur BGP, nous avons au moins un transitaire.
>>
>> Tout fonctionne parfaitement !
>>
>> Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
>> utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
>> route Null0).
>> Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
>> sur le routeur BGP concerné.
>>
>> - Ma question : Nous aimerions mettre en place un failover BGP automatique
>> en cas de défaillance matérielle totale d'un des routeurs BGP.
>>
>> La solution que j'imaginais est de mettre en place, pour un même prefixe,
>> une route Null0 sur les 2 routeurs en même temps.
>>
>> Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
>> les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
>> => Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
>> problème.
>>
>> Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
>> mais que le L2L tombe.
>>
>> Dans ce cas, un paquet va continuer à arriver par le transit sur le
>> routeur
>> BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
>> mais l'IP de GW étant normalement accessible via le L2L sur un VLAN donné,
>> le routage ne fonctionnera pas car le L2L est tombé.
>>
>> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une solution
>> à
>> ce problème ?
>>
>> Merci,
>> Bonne journée,
>> Fabien
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Bonjour Clement,

effectivement ... J'avais l'impression pourtant que je n'étais pas loin du
but. Il y'a juste ce problème de L2L. BGP est très flexible, je pensais
qu'il y'avait une solution pour chaque défaillance ..

Le 2 novembre 2015 09:29, Clement Cavadore <clem...@cavadore.net> a écrit :

> On Mon, 2015-11-02 at 09:16 +0100, Fabien H wrote:
> > Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
> > solution à ce problème ?
>
> La bonne démarche, c'est de sécuriser le L2L avec un autre, afin de ne
> jamais te retrouver en split brain sur ton ASN :-)
>
> --
> Clément Cavadore
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] E1 ISDN et fournisseurs Tier1

[Fabien H]

Bonjour,
oui nous avons eu aussi une offre Verizon pour plusieurs E1 il y'a 2-3 ans,
un peu cher par rapport au SIP mais en fait pas tant que ça si derrière la
qualité est au rendez-vous.

Sinon, hors sujet mais Completel nous a demandé en interco SIP au moins X K
de CA pour pouvoir souscrire (je peux pas donner le chiffre je pense !:-) )
Sauf que dans les faits, tu vas pas planter ton fournisseur habituel du
jour au lendemain pour tout passer là dessus, surtout s'il continue à te
faire la collecte le temps des portabilités sortantes !


Le 7 novembre 2015 12:04, nikolaii  a écrit :

> On 11/07/2015 11:30 AM, Sebastien Lesimple wrote:
> > Bonjour chers tous!
> >
> > Je m'interrogeais sur les Tiers1 restants encore actifs sur la Voix dans
> > l'hexagone...
>
> Hello, je en sais pas s'ils sont Tiers1, mais à une époque pas si
> lointaine (2013) j'avais travaillé avec Verizon qui nous fournissait des
> accès E1 pour des accès modems de TPE, cela fonctionnait bien.
>
> --
> Nicolas
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] E1 ISDN et fournisseurs Tier1

[Fabien H]

C'est pas encore Noel, mais de l'E1 redondé sur 2 sites, c'est une offre
qui existe ?

Le 7 novembre 2015 14:35, David Ponzone  a écrit :

> De l'E1, pas un problème chez Colt je pense. Verizon je parierais pas, ils
> se désengagent de la voix au maximum.
> Par contre,gérer ton préfixe de porta et te donner accès à leur abo
> APNF
> Si tu trouves, dis-moi ;)
>
> David Ponzone
>
>
>
> > Le 7 nov. 2015 à 11:30, Sebastien Lesimple  a
> écrit :
> >
> > Bonjour chers tous!
> >
> > Je m'interrogeais sur les Tiers1 restants encore actifs sur la Voix dans
> > l'hexagone...
> >
> > Existe-t-il encore un Tier1 capable de fournir de bons vieux E1 ISDN de
> > dans le temps d'avant?
> > (Sans se planter dans le cablage TE/ Vous vous souvenez? Les trucs sur
> cuivre avec 30B+D sur 2048kb/s, même
> > pas compressés et qui fonctionnaient parfaitement bien?
> > (Pas les machins SIP bricolés sur un coin de table avec un Asterisk et
> > livrés sur une Patton ou un OneAccess hein, du vrais de vrais!)
> >
> > Mieux, un qui sache livrer 2 ou 4 E1 sans exiger de les commander par
> > paquets 32 ou de leurs fournir 100k€ de business a J+1 de la signature
> > du contrat??
> >
> > Encore plus mieux, un qui en plus, soit capable de prendre ton prefix de
> > portabilité et te laisser jouer directement avec l'APNF sans
> t'emmerder
> >
> > Et soyons fous, avec de tarifs intelligents?
> >
> > J’arrête de rêver mais si quelqu'un a un "polaroid" (tant qu'a causer
> > Vintage...) du marché Français, cela m’intéresse.
> >
> > Seb.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Oui c'est relativement clair :-)
Je vais étudier ça merci

Le 2 novembre 2015 10:17, David Ponzone <david.ponz...@gmail.com> a écrit :

> Oui effectivement, il faut forcer le routage de l’autre extrémité du
> tunnel GRE par le transit, alors que le routeur doit recevoir une route
> connected redistribuée par iBGP.
> C’est un peu sioux, mais une route statique en /32 vers le transit doit
> suffire, sans effets de bord à priori.
> Attention, route pas le /30 entier car tu dois recevoir des annonces iBGP
> qui viennent du transitaire de l’autre site qui ont l’autre IP dans ce /30
> comme next-hop.
> Ou alors tu fais du next-hop-self sur les sessions iBGP pour ne plus avoir
> de trace du next-hop du transitaire quand tu arrives sur l’autre routeur.
>
> Désolé si c’est pas très clair :)
>
> Le 2 nov. 2015 à 10:11, Fabien H <frnog.fab...@gmail.com> a écrit :
>
> Bonjour David,
>
> sur chaque site, des SW niveau 2, LNS et serveurs. Donc effectivement un
> LAN en /24 est dédié pour le routage entre le BGP et les LNS ou Firewalls
> ou autre. Par contre ce LAN est le même sur les 2 sites (même VLAN, même
> /24)
>
> Je suis donc dans le cas 2 : OK même solution que Cédric :
>
> Je crois que j'ai compris ce qui ne va pas dans notre archi : Nous
> filtrons les préfixes plus restreints que /24 en iBGP.
> Dans le cas 2, vous sous-entendez que même les routes /32 sont échangées
> en iBGP ? Et donc logiquement pas besoin de  dupliquer les routes /32 sur
> chaque routeur... Tant qu'une des sessions iBGP est UP, ça fonctionne !
>
>
> Y'a juste une chose qui me chiffonne un peu , c'est quelles IP publiques
> utiliser pour le tunnel GRE car il faut que ces IP ne soient pas routées
> par l'iBGP (actuellement on annonce tous les préfixes des 2 côtés) mais ça
> je vais étudier..
>
> Merci beaucoup pour vous retours !
>
>
> Le 2 novembre 2015 09:34, David Ponzone <david.ponz...@gmail.com> a écrit
> :
>
>> Il manque quelques infos je pense.
>> Sur chaque site, il y a quoi à part les routeurs BGP ?
>> Un LAN avec du hosting ou autre ? J’imagine que oui.
>> Le L2L, il relie pas les routeurs directement, mais des switch L2 qui
>> sont derrière les routeurs, je suppose ?
>> Autre point qui n’est pas clair: tu as bien un /24 minimum dédié au LAN
>> de chaque site ?
>>
>> Ta problématique est donc simple, si je résume:
>> Le L2L tombe, mais les 2 routeurs sont OK.
>> Chacun annonce les 2 préfixes et donc si le site A reçoit un paquet pour
>> B, c’est mort.
>>
>> Cas 1: tu as bien des subnets séparés pour le LAN de chaque site.
>> Il faut juste utiliser IP SLA (chez Cisco) sur chaque routeur pour
>> détecter que le L2L est mort, et faire tomber l’annonce du BGP du préfixe
>> de l’autre site.
>>
>> Cas 2: les 2 sites partagent le même subnet pour le LAN
>> Tunnel GRE entre les 2 routeurs qui passent par leur transit respectif et
>> iBGP dessus, avec un localpref défavorable par rapport à la session iBGP du
>> L2L.
>>
>>
>> > Le 2 nov. 2015 à 09:16, Fabien H <frnog.fab...@gmail.com> a écrit :
>> >
>> > Bonjour la liste,
>> >
>> > J'ai une question BGP à vous soumettre :
>> >
>> > En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
>> > avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
>> > Sur chaque routeur BGP, nous avons au moins un transitaire.
>> >
>> > Tout fonctionne parfaitement !
>> >
>> > Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
>> > utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
>> > route Null0).
>> > Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
>> > sur le routeur BGP concerné.
>> >
>> > - Ma question : Nous aimerions mettre en place un failover BGP
>> automatique
>> > en cas de défaillance matérielle totale d'un des routeurs BGP.
>> >
>> > La solution que j'imaginais est de mettre en place, pour un même
>> prefixe,
>> > une route Null0 sur les 2 routeurs en même temps.
>> >
>> > Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
>> > les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
>> > => Si un routeur BGP tombe, l'autre va normalement prendre le relais
>> sans
>> > problème.
>> >
>> > Le seul cas qui pose problème, c'est si les 2 routeurs BGP
>> fonctionnement
>> > mais que le L2L tombe.
>> >
>> > Dans ce cas, un paquet va continuer à arriver par le transit sur le
>> routeur
>> > BGP concerné, puis la route statique correspondant à l'IP sera
>> appliquée,
>> > mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
>> donné,
>> > le routage ne fonctionnera pas car le L2L est tombé.
>> >
>> > Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
>> solution à
>> > ce problème ?
>> >
>> > Merci,
>> > Bonne journée,
>> > Fabien
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Bonjour Christophe,
oui intéressant aussi, à creuser. Merci !

Le 2 novembre 2015 10:46, Christophe Lucas <christo...@clucas.fr> a écrit :

> Bonjour,
>
> Tu peux pas jouer avec du conditional advertisement en désagrégeant le cas
> échéant en fonctions des
> subnets locaux ?
> Genre : ton /23, tu l'annonces en temps normal et en cas de coupure tu
> annonces uniquement le /24
> local au PE1 et l'autre /24 local au PE2 et ceci si tu reçois en iBGP des
> subnet particulier.
>
>
> http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/16137-cond-adv.html
>
> Cdt
> Christophe
>
> 2 novembre 2015 10:31 "Fabien H" <frnog.fab...@gmail.com> a écrit:
>
> > Oui c'est relativement clair :-)
> > Je vais étudier ça merci
> >
> > Le 2 novembre 2015 10:17, David Ponzone <david.ponz...@gmail.com> a
> écrit :
> >
> >> Oui effectivement, il faut forcer le routage de l’autre extrémité du
> >> tunnel GRE par le transit, alors que le routeur doit recevoir une route
> >> connected redistribuée par iBGP.
> >> C’est un peu sioux, mais une route statique en /32 vers le transit doit
> >> suffire, sans effets de bord à priori.
> >> Attention, route pas le /30 entier car tu dois recevoir des annonces
> iBGP
> >> qui viennent du transitaire de l’autre site qui ont l’autre IP dans ce
> /30
> >> comme next-hop.
> >> Ou alors tu fais du next-hop-self sur les sessions iBGP pour ne plus
> avoir
> >> de trace du next-hop du transitaire quand tu arrives sur l’autre
> routeur.
> >>
> >> Désolé si c’est pas très clair :)
> >>
> >> Le 2 nov. 2015 à 10:11, Fabien H <frnog.fab...@gmail.com> a écrit :
> >>
> >> Bonjour David,
> >>
> >> sur chaque site, des SW niveau 2, LNS et serveurs. Donc effectivement un
> >> LAN en /24 est dédié pour le routage entre le BGP et les LNS ou
> Firewalls
> >> ou autre. Par contre ce LAN est le même sur les 2 sites (même VLAN, même
> >> /24)
> >>
> >> Je suis donc dans le cas 2 : OK même solution que Cédric :
> >>
> >> Je crois que j'ai compris ce qui ne va pas dans notre archi : Nous
> >> filtrons les préfixes plus restreints que /24 en iBGP.
> >> Dans le cas 2, vous sous-entendez que même les routes /32 sont échangées
> >> en iBGP ? Et donc logiquement pas besoin de dupliquer les routes /32 sur
> >> chaque routeur... Tant qu'une des sessions iBGP est UP, ça fonctionne !
> >>
> >> Y'a juste une chose qui me chiffonne un peu , c'est quelles IP publiques
> >> utiliser pour le tunnel GRE car il faut que ces IP ne soient pas routées
> >> par l'iBGP (actuellement on annonce tous les préfixes des 2 côtés) mais
> ça
> >> je vais étudier..
> >>
> >> Merci beaucoup pour vous retours !
> >>
> >> Le 2 novembre 2015 09:34, David Ponzone <david.ponz...@gmail.com> a
> écrit
> >> :
> >>
> >>> Il manque quelques infos je pense.
> >>> Sur chaque site, il y a quoi à part les routeurs BGP ?
> >>> Un LAN avec du hosting ou autre ? J’imagine que oui.
> >>> Le L2L, il relie pas les routeurs directement, mais des switch L2 qui
> >>> sont derrière les routeurs, je suppose ?
> >>> Autre point qui n’est pas clair: tu as bien un /24 minimum dédié au LAN
> >>> de chaque site ?
> >>>
> >>> Ta problématique est donc simple, si je résume:
> >>> Le L2L tombe, mais les 2 routeurs sont OK.
> >>> Chacun annonce les 2 préfixes et donc si le site A reçoit un paquet
> pour
> >>> B, c’est mort.
> >>>
> >>> Cas 1: tu as bien des subnets séparés pour le LAN de chaque site.
> >>> Il faut juste utiliser IP SLA (chez Cisco) sur chaque routeur pour
> >>> détecter que le L2L est mort, et faire tomber l’annonce du BGP du
> préfixe
> >>> de l’autre site.
> >>>
> >>> Cas 2: les 2 sites partagent le même subnet pour le LAN
> >>> Tunnel GRE entre les 2 routeurs qui passent par leur transit respectif
> et
> >>> iBGP dessus, avec un localpref défavorable par rapport à la session
> iBGP du
> >>> L2L.
> >>>
> >>>> Le 2 nov. 2015 à 09:16, Fabien H <frnog.fab...@gmail.com> a écrit :
> >>>>
> >>>> Bonjour la liste,
> >>>>
> >>>> J'ai une question BGP à vous soumettre :
> >>>>
> >>>> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
> >>

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Bonjour David,

sur chaque site, des SW niveau 2, LNS et serveurs. Donc effectivement un
LAN en /24 est dédié pour le routage entre le BGP et les LNS ou Firewalls
ou autre. Par contre ce LAN est le même sur les 2 sites (même VLAN, même
/24)

Je suis donc dans le cas 2 : OK même solution que Cédric :

Je crois que j'ai compris ce qui ne va pas dans notre archi : Nous filtrons
les préfixes plus restreints que /24 en iBGP.
Dans le cas 2, vous sous-entendez que même les routes /32 sont échangées en
iBGP ? Et donc logiquement pas besoin de  dupliquer les routes /32 sur
chaque routeur... Tant qu'une des sessions iBGP est UP, ça fonctionne !


Y'a juste une chose qui me chiffonne un peu , c'est quelles IP publiques
utiliser pour le tunnel GRE car il faut que ces IP ne soient pas routées
par l'iBGP (actuellement on annonce tous les préfixes des 2 côtés) mais ça
je vais étudier..

Merci beaucoup pour vous retours !


Le 2 novembre 2015 09:34, David Ponzone <david.ponz...@gmail.com> a écrit :

> Il manque quelques infos je pense.
> Sur chaque site, il y a quoi à part les routeurs BGP ?
> Un LAN avec du hosting ou autre ? J’imagine que oui.
> Le L2L, il relie pas les routeurs directement, mais des switch L2 qui sont
> derrière les routeurs, je suppose ?
> Autre point qui n’est pas clair: tu as bien un /24 minimum dédié au LAN de
> chaque site ?
>
> Ta problématique est donc simple, si je résume:
> Le L2L tombe, mais les 2 routeurs sont OK.
> Chacun annonce les 2 préfixes et donc si le site A reçoit un paquet pour
> B, c’est mort.
>
> Cas 1: tu as bien des subnets séparés pour le LAN de chaque site.
> Il faut juste utiliser IP SLA (chez Cisco) sur chaque routeur pour
> détecter que le L2L est mort, et faire tomber l’annonce du BGP du préfixe
> de l’autre site.
>
> Cas 2: les 2 sites partagent le même subnet pour le LAN
> Tunnel GRE entre les 2 routeurs qui passent par leur transit respectif et
> iBGP dessus, avec un localpref défavorable par rapport à la session iBGP du
> L2L.
>
>
> > Le 2 nov. 2015 à 09:16, Fabien H <frnog.fab...@gmail.com> a écrit :
> >
> > Bonjour la liste,
> >
> > J'ai une question BGP à vous soumettre :
> >
> > En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
> > avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
> > Sur chaque routeur BGP, nous avons au moins un transitaire.
> >
> > Tout fonctionne parfaitement !
> >
> > Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
> > utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
> > route Null0).
> > Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
> > sur le routeur BGP concerné.
> >
> > - Ma question : Nous aimerions mettre en place un failover BGP
> automatique
> > en cas de défaillance matérielle totale d'un des routeurs BGP.
> >
> > La solution que j'imaginais est de mettre en place, pour un même prefixe,
> > une route Null0 sur les 2 routeurs en même temps.
> >
> > Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
> > les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
> > => Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
> > problème.
> >
> > Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
> > mais que le L2L tombe.
> >
> > Dans ce cas, un paquet va continuer à arriver par le transit sur le
> routeur
> > BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
> > mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
> donné,
> > le routage ne fonctionnera pas car le L2L est tombé.
> >
> > Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
> solution à
> > ce problème ?
> >
> > Merci,
> > Bonne journée,
> > Fabien
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Mais d'ailleurs, 2 lan2lan de 2 fournisseurs différents en place sur le
même SW de part et d'autre ne risquent pas de mal fonctionner ? C'est
transparent ?

Le 2 novembre 2015 09:50, Clement Cavadore  a écrit :

> On Mon, 2015-11-02 at 09:41 +0100, Oceanet - Cédric BASSAGET wrote:
> > Ça c'est la solution quand y'a des sous ;)
>
> Faut se donner les moyens de ses ambitions...  Surtout vu les prix
> moyens des lan2lan datacenter-datacenter, de nos jours :-)
>
> --
> Clément Cavadore
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Bonjour Raphael,

Tout à fait, ça parait logique ! D'ailleurs pour les basiques et la mise en
place y'a pas mal de ressources bien faites sur le net notamment les
présentations Workshop d'Arnaud Fernioux. Ca permet de voir si globalement
on est dans les clous ou pas !

Bonne journée !

Le 2 novembre 2015 10:36, Raphael Mazelier <r...@futomaki.net> a écrit :

> Back to basic.
>
> Ton AS ne devrait jamais être disjoint.
> Dépendant de ta localisation de tes deux datacenters, le mieux c'est quand
> même de prendre une dark. Si tu ne peux pas tu utilise deux l2l, voir un
> l2l avec backup sur Gre.
>
> 2eme point : on redit, tu fait tourner un IGP entre des deux routeurs
> (Ospf, Isis) juste pour les loopbacks de tes routeurs (et les intercos si
> tu veux). Et tu montes tes sessions Ibgp entre ces loopbacks de sortes que
> te sessions IBGP ne doivent jamais tombés (sauf si faillure du routeur,
> mais faillure de path). Et dans ton IBGP tu mets ce que tu veux, tes mores
> specifics (dans ton cas tes /32).
>
>
>
> Le 02/11/15 10:23, Fabien H a écrit :
>
>> Mais d'ailleurs, 2 lan2lan de 2 fournisseurs différents en place sur le
>> même SW de part et d'autre ne risquent pas de mal fonctionner ? C'est
>> transparent ?
>>
>> Le 2 novembre 2015 09:50, Clement Cavadore <clem...@cavadore.net> a
>> écrit :
>>
>> On Mon, 2015-11-02 at 09:41 +0100, Oceanet - Cédric BASSAGET wrote:
>>>
>>>> Ça c'est la solution quand y'a des sous ;)
>>>>
>>>
>>> Faut se donner les moyens de ses ambitions...  Surtout vu les prix
>>> moyens des lan2lan datacenter-datacenter, de nos jours :-)
>>>
>>> --
>>> Clément Cavadore
>>>
>>>
>>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Oui, c'est tout à fait ça !

Peut-être juste inverser la condition c'est à dire installer la route quand
R2 n'est pas reachable plutot que quand il est reachable mais apparemment
c'est faisable :

track 456 list boolean and
 object 123 not

Ca commence à être tiré par les cheveux .. ! A voir


Le 3 novembre 2015 14:47, Montgomery SIMONPIETRI <montgom...@simonpietri.net
> a écrit :

> Il faudra sans doute dupliquer les routes sur les deux routeurs, mais en
> ajoutant du tracking ip sla pour etre sur de les mettre dans la table
> uniquement en cas de failover.
>
> Sur R1 :
>
> ip sla 123
>  icmp-echo IP_LAN_R2 source-ip IP_LAN_R1
>  frequency 5
> ip sla schedule 123 life forever start-time now
>
> track 123 ip sla 123 reachability
>  delay down 25
>
> ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 track 123
>
>
> Et vice-versa sur R2.
> Est-ce que je suis à côté ?
>
> Montgomery
>
>
>
> 2015-11-03 14:28 GMT+01:00 Fabien H <frnog.fab...@gmail.com>:
>
>> Bonjour,
>>
>> merci, si j'ai bien compris, cette solution s'approche un peu du
>> redistribute en EIGRP mais en BGP. C'est effectivement à tester.
>>
>> Mais je bloque toujours sur le besoin de failover Routeur BGP.
>>
>> Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2 ne
>> pourra pas assurer le failover de R1 pour les routes en /32...
>>
>> Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI <
>> montgom...@simonpietri.net> a écrit :
>>
>>> Bonjour,
>>>
>>> Est-ce que vous avez pensé à mettre une solution avec du "redistribute
>>> static route-map" pour éviter d'annoncer les /32 et du prepend sur les
>>> prefix a backuper ?
>>>
>>>
>>>
>>> Du style :
>>>
>>> ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
>>> ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999
>>>
>>> access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1
>>>
>>> access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2
>>>
>>> route-map BACKUP-PREPEND permit 10
>>>  match ip address 70
>>>  set as-path prepend 1234
>>>
>>> route-map BACKUP-PREPEND permit 20
>>>
>>> route-map TAGGED-STATIC permit 10
>>>  match tag 999
>>>
>>> router bgp 1234
>>>  redistribute static route-map TAGGED-STATIC
>>>  neighbor PEER_ADDRESS route-map BACKUP-PREPEND out
>>>
>>>
>>>
>>>
>>>
>>> 2015-11-02 9:16 GMT+01:00 Fabien H <frnog.fab...@gmail.com>:
>>>
>>>> Bonjour la liste,
>>>>
>>>> J'ai une question BGP à vous soumettre :
>>>>
>>>> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
>>>> avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
>>>> Sur chaque routeur BGP, nous avons au moins un transitaire.
>>>>
>>>> Tout fonctionne parfaitement !
>>>>
>>>> Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
>>>> utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
>>>> route Null0).
>>>> Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
>>>> sur le routeur BGP concerné.
>>>>
>>>> - Ma question : Nous aimerions mettre en place un failover BGP
>>>> automatique
>>>> en cas de défaillance matérielle totale d'un des routeurs BGP.
>>>>
>>>> La solution que j'imaginais est de mettre en place, pour un même
>>>> prefixe,
>>>> une route Null0 sur les 2 routeurs en même temps.
>>>>
>>>> Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
>>>> les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
>>>> => Si un routeur BGP tombe, l'autre va normalement prendre le relais
>>>> sans
>>>> problème.
>>>>
>>>> Le seul cas qui pose problème, c'est si les 2 routeurs BGP
>>>> fonctionnement
>>>> mais que le L2L tombe.
>>>>
>>>> Dans ce cas, un paquet va continuer à arriver par le transit sur le
>>>> routeur
>>>> BGP concerné, puis la route statique correspondant à l'IP sera
>>>> appliquée,
>>>> mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
>>>> donné,
>>>> le routage ne fonctionnera pas car le L2L est tombé.
>>>>
>>>> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
>>>> solution à
>>>> ce problème ?
>>>>
>>>> Merci,
>>>> Bonne journée,
>>>> Fabien
>>>>
>>>> ---
>>>> Liste de diffusion du FRnOG
>>>> http://www.frnog.org/
>>>>
>>>
>>>
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

OK d'où les redistribute des routes connected vs routes statiques etc etc
.. C'est très clair maintenant merci !

Le 3 novembre 2015 17:26, Montgomery SIMONPIETRI <montgom...@simonpietri.net
> a écrit :

> Tout a fait d'accord avec Raphael !
> BGP / OSPF  ... c'est pas les proto qui manquent ;)
>
> 2015-11-03 16:30 GMT+01:00 Raphael Mazelier <r...@futomaki.net>:
>
>>
>>
>> Le 03/11/15 15:18, Fabien H a écrit :
>>
>>>
>>> @Raphael
>>>
>>> Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
>>> puis par exemple sur le LNS, il y'a une interface avec un masque en /31
>>>
>>>
>>>
>>
>> Dans ce cas le mieux c'est que tes équipements FW/LNS annoncent leurs
>> préfixes aux deux routeurs via le protocole de ton choix (BGP est souvent
>> un bon choix).
>>
>>
>> --
>> Raphael Mazelier
>>
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

@Montgomery

Oui, c'est beaucoup plus propre et c'est compatible avec le redistribute,
merci !

@Raphael

Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
puis par exemple sur le LNS, il y'a une interface avec un masque en /31



Le 3 novembre 2015 15:09, Raphael Mazelier <r...@futomaki.net> a écrit :

> Question : tes /32 correspondent a quoi ? des IPs de services sur des
> serveurs ?
>
> Et sinon oui tu mes les /32 sur tes deux routeurs avec des poids
> différents.
>
>
>
> Le 03/11/15 15:06, Montgomery SIMONPIETRI a écrit :
>
> Hmmm l'autre option peut être encore plus simple serait simplement de
>> mettre un poids supérieur à BGP dans la route.
>>
>>
>> Sur R1 :
>>
>> ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 250
>>
>>
>> Si la route BGP disparait (poids de 20 par défaut je crois) alors cest la
>> statique qui prendrait le relais...
>>
>> 2015-11-03 15:03 GMT+01:00 Montgomery SIMONPIETRI <
>> montgom...@simonpietri.net>:
>>
>> Exact ! Il faut inverser la condition ;)
>>>
>>> 2015-11-03 15:01 GMT+01:00 Fabien H <frnog.fab...@gmail.com>:
>>>
>>> Oui, c'est tout à fait ça !
>>>>
>>>> Peut-être juste inverser la condition c'est à dire installer la route
>>>> quand R2 n'est pas reachable plutot que quand il est reachable mais
>>>> apparemment c'est faisable :
>>>>
>>>> track 456 list boolean and
>>>>   object 123 not
>>>>
>>>> Ca commence à être tiré par les cheveux .. ! A voir
>>>>
>>>>
>>>> Le 3 novembre 2015 14:47, Montgomery SIMONPIETRI <
>>>> montgom...@simonpietri.net> a écrit :
>>>>
>>>> Il faudra sans doute dupliquer les routes sur les deux routeurs, mais en
>>>>> ajoutant du tracking ip sla pour etre sur de les mettre dans la table
>>>>> uniquement en cas de failover.
>>>>>
>>>>> Sur R1 :
>>>>>
>>>>> ip sla 123
>>>>>   icmp-echo IP_LAN_R2 source-ip IP_LAN_R1
>>>>>   frequency 5
>>>>> ip sla schedule 123 life forever start-time now
>>>>>
>>>>> track 123 ip sla 123 reachability
>>>>>   delay down 25
>>>>>
>>>>> ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 track 123
>>>>>
>>>>>
>>>>> Et vice-versa sur R2.
>>>>> Est-ce que je suis à côté ?
>>>>>
>>>>> Montgomery
>>>>>
>>>>>
>>>>>
>>>>> 2015-11-03 14:28 GMT+01:00 Fabien H <frnog.fab...@gmail.com>:
>>>>>
>>>>> Bonjour,
>>>>>>
>>>>>> merci, si j'ai bien compris, cette solution s'approche un peu du
>>>>>> redistribute en EIGRP mais en BGP. C'est effectivement à tester.
>>>>>>
>>>>>> Mais je bloque toujours sur le besoin de failover Routeur BGP.
>>>>>>
>>>>>> Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2
>>>>>> ne pourra pas assurer le failover de R1 pour les routes en /32...
>>>>>>
>>>>>> Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI <
>>>>>> montgom...@simonpietri.net> a écrit :
>>>>>>
>>>>>> Bonjour,
>>>>>>>
>>>>>>> Est-ce que vous avez pensé à mettre une solution avec du
>>>>>>> "redistribute
>>>>>>> static route-map" pour éviter d'annoncer les /32 et du prepend sur
>>>>>>> les
>>>>>>> prefix a backuper ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Du style :
>>>>>>>
>>>>>>> ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
>>>>>>> ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999
>>>>>>>
>>>>>>> access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1
>>>>>>>
>>>>>>> access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2
>>>>>>>
>>>>>>> route-map BACKUP-PREPEND permit 10
>>>>>>>   match ip address 70
>>>>>>>   set as-path prepend 1234
>>>>>>>
>>>>>>> route-map BACKUP-PREPEND permit 20
>>>>>

[FRnOG] [TECH] Re: Trames BOOTP ne traversent pas un Cisco 3750 ?

[Fabien H]

Bonsoir, Merci pour le retour rapide !

@Pierre

Ok pour le port fast je vais essayer. L'histoire de la mac source je crois
que c'est justement la commande ip dhcp relay information trust-all ou
approchant..

@David

La commande ne retourne rien. Que du niveau 2 sir le SW.



Le mercredi 6 janvier 2016, David Ponzone <david.ponz...@gmail.com> a
écrit :
> Le Cat3750 ne joue aucune rôle L3 ?
>
> Un petit:
> show running | inc bootp
> donne quoi ?
>
>
>> Le 6 janv. 2016 à 23:07, Fabien H <frnog.fab...@gmail.com> a écrit :
>>
>> Bonsoir la liste,
>>
>>
>> Nous nous arrachons les cheveux depuis plusieurs heures sur un truc tout
>> con :
>>
>> Nous avons une carte CPU d'un autocom qui utilise le protocole BOOTP pour
>> démarrer (ne démarre pas si pas de serveur BOOTP)
>>
>> Lors du maquettage sur un switch DELL, aucun souci.
>>
>> En production sur un SW Cisco  WS-C3750G-24T IOS Version 12.2, nous avons
>> branché la carte CPU sur un port et le serveur BOOTP sur un autre port du
>> SW.
>>
>> => les requetes BOOTP semblent arriver sur le port (les paquets
>> s'incrementent sur le port), mais sur le serveur, un wireshark ne voit
>> aucun paquet arriver !!
>>
>> Comme si les paquets entraient dans le switch mais qu'ensuite il droppait
>> les paquets BOOTP !! Par contre les paquets DHCP passent eux sur ce meme
>> switch !!
>>
>> Nous avons essayé quelques commandes :
>>
>> sh log (mais quel debug activer ..?!)
>>
>> ip dhcp relay information trust-all
>>
>> Ou sur chaque port :
>>
>> no switchport port-security
>>
>> mais rien n'y fait !
>> Est-ce que quelqu'un aurait déjà vu ça et aurait la solution ?
>>
>> Merci !
>> Fabien
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Trames BOOTP ne traversent pas un Cisco 3750 ?

[Fabien H]

Bonsoir la liste,


Nous nous arrachons les cheveux depuis plusieurs heures sur un truc tout
con :

Nous avons une carte CPU d'un autocom qui utilise le protocole BOOTP pour
démarrer (ne démarre pas si pas de serveur BOOTP)

Lors du maquettage sur un switch DELL, aucun souci.

En production sur un SW Cisco  WS-C3750G-24T IOS Version 12.2, nous avons
branché la carte CPU sur un port et le serveur BOOTP sur un autre port du
SW.

=> les requetes BOOTP semblent arriver sur le port (les paquets
s'incrementent sur le port), mais sur le serveur, un wireshark ne voit
aucun paquet arriver !!

Comme si les paquets entraient dans le switch mais qu'ensuite il droppait
les paquets BOOTP !! Par contre les paquets DHCP passent eux sur ce meme
switch !!

Nous avons essayé quelques commandes :

sh log (mais quel debug activer ..?!)

ip dhcp relay information trust-all

Ou sur chaque port :

no switchport port-security

mais rien n'y fait !
Est-ce que quelqu'un aurait déjà vu ça et aurait la solution ?

Merci !
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Trames BOOTP ne traversent pas un Cisco 3750 ?

[Fabien H]

Pour information,

voici la configuration quasi complète :

version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
no aaa new-model
system mtu routing 1500
vtp mode transparent
!
!
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
!
vlan 4094
 name BOOTP
!
!
interface GigabitEthernet1/0/2
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 4094
 switchport mode trunk
!
interface GigabitEthernet1/0/3
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 4094
 switchport mode trunk
!
ip classless
no ip http server
no ip http secure-server
!
line con 0
line vty 0 4
 login local
 transport input telnet ssh
line vty 5 15
 login local
 transport input telnet ssh
!

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Trames BOOTP ne traversent pas un Cisco 3750 ?

[Fabien H]

Non, je note tout ça pour la prochaine tentative.. merci

2016-01-07 14:06 GMT+01:00 David Ponzone <david.ponz...@gmail.com>:

> Tu as essayé d’ajouter un petit:
> « no service dhcp »
> ?
>
>
> > Le 7 janv. 2016 à 13:20, Fabien H <frnog.fab...@gmail.com> a écrit :
> >
> > Pour information,
> >
> > voici la configuration quasi complète :
> >
> > version 12.2
> > no service pad
> > service timestamps debug datetime msec
> > service timestamps log datetime msec
> > no service password-encryption
> > !
> > no aaa new-model
> > system mtu routing 1500
> > vtp mode transparent
> > !
> > !
> > spanning-tree mode pvst
> > spanning-tree extend system-id
> > !
> > vlan internal allocation policy ascending
> > !
> > !
> > vlan 4094
> > name BOOTP
> > !
> > !
> > interface GigabitEthernet1/0/2
> > switchport trunk encapsulation dot1q
> > switchport trunk native vlan 4094
> > switchport mode trunk
> > !
> > interface GigabitEthernet1/0/3
> > switchport trunk encapsulation dot1q
> > switchport trunk native vlan 4094
> > switchport mode trunk
> > !
> > ip classless
> > no ip http server
> > no ip http secure-server
> > !
> > line con 0
> > line vty 0 4
> > login local
> > transport input telnet ssh
> > line vty 5 15
> > login local
> > transport input telnet ssh
> > !
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Numero urgence et reconnaissance adresse physique de l'appelant

[Fabien H]

Il y'a bien un service de l'état proche des préfectures capable de faire ça
et d'en assumer la responsabilité non ?

C'est pas une base de 36 000 communes avec une interface web contenant 1
liste et 1 formulaire de saisie qui vont faire peur à l'état ? (+ 1 login
par prefecture)

Après un accès sécurisé en lecture seule (CSV journalier sur SFTP) par
opérateur déclaré ARCEP et c'est reglé ?

C'est assez incroyable d'entendre ça sachant qu'au final, le but est
effectivement de sauver des vies.


Le 25 novembre 2015 13:07, alexandre Moutot  a écrit
:

> Concernant la base centralisée de PDAAU, pour en avoir un peu discuté, ce
> que j'ai compris :
> - c'est une excellente idée
> - personne ne veut prendre la responsabilité d'une telle base :
> hébergement, maintenance, disponibilité
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Numero urgence et reconnaissance adresse physique de l'appelant

[Fabien H]

Bonjour,
Nous recevons pas mal de MAJ via la plateforme Envol(2) ce que l'on peut
considérer comme étant une bonne chose !

juste une question : J'ai cherché partout dans notre BAL de contact PDAAU
mais je ne trouve pas la procédure pour télécharger les fichiers, et
notamment, une fois que l'on a cliqué sur l'URL complexe, un mot de passe
est demandé..

J'ignore où le trouver, j'ai chercher sur les sites en gouv.fr + pdaau mais
pas d'info. J'ai redemandé le mot de passe en cliquant sur "mot de passe
oublié" sur Envol2, mais notre mail n'est pas connu sur la plateforme..

Est-ce que quelqu'un peut m'envoyer un lien vers un document public ou une
adresse mail à qui s'adresser pour récupérer ce mot de passe ?

Merci !


Le 27 novembre 2015 à 20:39, Michel Py 
a écrit :

> > Sylvain Charron a écrit :
> > Je faisais juste référence au pb initiale de Philippe BARRANCO
> > Completel fait bien pour son client le routage ZNE vers le bon service
> (PDAAU).
> > Cependant le service d'urgence a une base annuaire interne qui ne
> contient pas
> > la nouvelle adresse postale du client suite a son déménagement.
> > Et là 2 possibilités:
> >  - soit Completel n'a pas publier dans les annuaires universelles les
> nouvelles
> >coordonnées (et dans ce cas c'est pas bien Completel)
> >  - soit c'est le service d'urgence qui a une méthode non pertinente de
> gestion des fichiers annuaires et qui n'est
> >pas a jour (et dans ce cas c'est le service d'urgence qui est en tord
> et Completel a bien fait son boulot).
>
> Je suis d'accord, sauf que tu oublies une troisième possibilité, tout
> aussi pertinente :
>
> - Completel a fait son boulot.
> - Le service d'urgence met à jour sa base de données par une méthode
> pertinente, mais avec un autre fournisseur que Completel.
> - Il n'y a aucun protocole défini entre Completel et le fournisseur
> d'annuaire inverse que le service d'urgence utilise, leurs bases de données
> ne sont pas synchronisées, et ce n'est ni la faute de Completel ni celle du
> service d'urgence.
> En anglais, on a un acronyme pour çà : C.Y.A. Cover Your Ass.
>
> A qui la faute ? Hmmm réfléchissons un peu, à qui on pourrait faire une
> vacherie ? :-D
>
>
> > David Ponzone a écrit :
> > Mais t’as pas vraiment répondu, non ? :)
>
> Ben quoi, c'est trolldi sur MISC, je peux plus m'entrainer à la langue de
> bois maintenant ?
> Sérieusement, je ne sais pas, parce que çà dépend de plein de variables.
>
> > Ok, le 911 est un dispatch manuel qui pourrait être remplacé par un IVR.
> > On pourrait d’ailleurs faire pareil en France, on se demande pourquoi ça
> n’est pas le cas.
>
> A part que je suis l'avocat du diable, je préfère quand même un opérateur
> humain centralisé. Même si c'est vrai que c'est cher pour souvent ne pas
> faire plus qu'un IVR.
>
> > Avec reportage de l’appel, dans quelle base les pompiers de Baton Rouge
> vont taper pour avoir l’adresse de l’appelant ?
> > Qui met à jour la base, sachant que cela implique (particulièrement aux
> USA) des opérateurs locaux et nationaux ?
> > C’est une base locale (fédérale ?) ou nationale ?
>
> Sylvain a très bien répondu à cette question plus tot :
>
> > Sylvain Charron a écrit :
> > - Exemple de Philippe et de son soucis Jusqu'à la mise en place de la
> PFLAU (enfin, pour quand cela sera en
> > production), chaque service d'urgence traient ce sujet de manière
> totalement hétérogène, et là on a vu de tout:
>
> C'est le même joyeux bordel désorganisé chez nous que chez vous.
>
>
> > Qui est « accountable »  ?
>
> Pas moi, car j'ai fait la partie que je devais faire :-D : CYA.
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Numero urgence et reconnaissance adresse physique de l'appelant

[Fabien H]

Oups  désolé pour le bruit, effectivement, un coup de scroll et c'est bon !
Quel boulet..
merci


Le 25 février 2016 à 11:33, David Ponzone <david.ponz...@gmail.com> a écrit
:

> Le mot de passe est à chaque fois dans le mail :)
> C’est de la Sécurité avec un grand S :)
>
>
> > Le 25 févr. 2016 à 11:15, Fabien H <frnog.fab...@gmail.com> a écrit :
> >
> > Bonjour,
> > Nous recevons pas mal de MAJ via la plateforme Envol(2) ce que l'on peut
> > considérer comme étant une bonne chose !
> >
> > juste une question : J'ai cherché partout dans notre BAL de contact PDAAU
> > mais je ne trouve pas la procédure pour télécharger les fichiers, et
> > notamment, une fois que l'on a cliqué sur l'URL complexe, un mot de passe
> > est demandé..
> >
> > J'ignore où le trouver, j'ai chercher sur les sites en gouv.fr + pdaau
> mais
> > pas d'info. J'ai redemandé le mot de passe en cliquant sur "mot de passe
> > oublié" sur Envol2, mais notre mail n'est pas connu sur la plateforme..
> >
> > Est-ce que quelqu'un peut m'envoyer un lien vers un document public ou
> une
> > adresse mail à qui s'adresser pour récupérer ce mot de passe ?
> >
> > Merci !
> >
> >
> > Le 27 novembre 2015 à 20:39, Michel Py <
> mic...@arneill-py.sacramento.ca.us>
> > a écrit :
> >
> >>> Sylvain Charron a écrit :
> >>> Je faisais juste référence au pb initiale de Philippe BARRANCO
> >>> Completel fait bien pour son client le routage ZNE vers le bon service
> >> (PDAAU).
> >>> Cependant le service d'urgence a une base annuaire interne qui ne
> >> contient pas
> >>> la nouvelle adresse postale du client suite a son déménagement.
> >>> Et là 2 possibilités:
> >>> - soit Completel n'a pas publier dans les annuaires universelles les
> >> nouvelles
> >>>   coordonnées (et dans ce cas c'est pas bien Completel)
> >>> - soit c'est le service d'urgence qui a une méthode non pertinente de
> >> gestion des fichiers annuaires et qui n'est
> >>>   pas a jour (et dans ce cas c'est le service d'urgence qui est en tord
> >> et Completel a bien fait son boulot).
> >>
> >> Je suis d'accord, sauf que tu oublies une troisième possibilité, tout
> >> aussi pertinente :
> >>
> >> - Completel a fait son boulot.
> >> - Le service d'urgence met à jour sa base de données par une méthode
> >> pertinente, mais avec un autre fournisseur que Completel.
> >> - Il n'y a aucun protocole défini entre Completel et le fournisseur
> >> d'annuaire inverse que le service d'urgence utilise, leurs bases de
> données
> >> ne sont pas synchronisées, et ce n'est ni la faute de Completel ni
> celle du
> >> service d'urgence.
> >> En anglais, on a un acronyme pour çà : C.Y.A. Cover Your Ass.
> >>
> >> A qui la faute ? Hmmm réfléchissons un peu, à qui on pourrait faire une
> >> vacherie ? :-D
> >>
> >>
> >>> David Ponzone a écrit :
> >>> Mais t’as pas vraiment répondu, non ? :)
> >>
> >> Ben quoi, c'est trolldi sur MISC, je peux plus m'entrainer à la langue
> de
> >> bois maintenant ?
> >> Sérieusement, je ne sais pas, parce que çà dépend de plein de variables.
> >>
> >>> Ok, le 911 est un dispatch manuel qui pourrait être remplacé par un
> IVR.
> >>> On pourrait d’ailleurs faire pareil en France, on se demande pourquoi
> ça
> >> n’est pas le cas.
> >>
> >> A part que je suis l'avocat du diable, je préfère quand même un
> opérateur
> >> humain centralisé. Même si c'est vrai que c'est cher pour souvent ne pas
> >> faire plus qu'un IVR.
> >>
> >>> Avec reportage de l’appel, dans quelle base les pompiers de Baton Rouge
> >> vont taper pour avoir l’adresse de l’appelant ?
> >>> Qui met à jour la base, sachant que cela implique (particulièrement aux
> >> USA) des opérateurs locaux et nationaux ?
> >>> C’est une base locale (fédérale ?) ou nationale ?
> >>
> >> Sylvain a très bien répondu à cette question plus tot :
> >>
> >>> Sylvain Charron a écrit :
> >>> - Exemple de Philippe et de son soucis Jusqu'à la mise en place de la
> >> PFLAU (enfin, pour quand cela sera en
> >>> production), chaque service d'urgence traient ce sujet de manière
> >> totalement hétérogène, et là on a vu de tout:
> >>
> >> C'est le même joyeux bordel désorganisé chez nous que chez vous.
> >>
> >>
> >>> Qui est « accountable »  ?
> >>
> >> Pas moi, car j'ai fait la partie que je devais faire :-D : CYA.
> >>
> >> Michel.
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Relais SMTP

[Fabien H]

Désolé, je suis légèrement HS, mais en parlant de mauvaises habitudes
données au client : sur le "in", comment vous faites pour expliquer au
client que son client/fournisseur utilise un SMTP blacklisté (dans les RBL)
et que le problème ne vient pas de notre coté mais de celui du
client/fournisseur ?  Quand le fournisseur dit que ça marche partout
ailleurs..

Surtout quand en face c'est un SMTP 1and1 voire même orange.

Vous restez ferme vis à vis de votre client ?

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Relais SMTP

[Fabien H]

De manière générale, quels RBL utilisez vous ?

Chez nous : Baraccuda et Spamhaus

On a eu pas mal de problèmes avec sorbs et spamcop..

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Telehouse & les cross-connects

[Fabien H]

Oui et délai d'install ! Quand tu attend 2 mois la livraison d'un x-connect
dans un DC autre que TH2, ton biz en prend un coup. Alors OK, ça s'anticipe
mais y'a des limites ! Et le pire c'est que tu paies pour ça !


Le 31 mars 2016 à 14:27, David Ponzone  a écrit :

> C’est pas faux.
> La vraie question est: pour X00 € de setup et 50€/mois, c’est quoi le SLA
> que TH2 donne en cas de panne sur un X-connect ?
>
>
> > Le 31 mars 2016 à 14:19, Kevin Polizzi [Jaguar Network] <
> kevin.poli...@jaguar-network.com> a écrit :
> >
> > Vous avez pas bientôt fini d'enfiler des perles ?
> >
> > Je préfère payer et que ce soit plus la jungle dans les faux planchers
> ... Si t'a pas les moyens de payer un x-connect c'est que le biz model est
> à updater.
> >
> > Kevin Polizzi
> > Jaguar Network
> >
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [BIZ] Re: Zonage offre CELAN Orange

[Fabien H]

Merci David & Jérôme pour vos reponses précises,
J'etudie tout ça..

Fabien


Le vendredi 22 juillet 2016, David Ponzone <david.ponz...@gmail.com> a
écrit :
> Le 22 juil. 2016 à 12:50, Fabien H <frnog.fab...@gmail.com> a écrit :
>
> la zone de couverture de cette porte sur la région (en cuivre ou fibre)
> correspond bien à ce que Orange appelle la "Région administrative" dans
son
> fichier Excel "Couverture géographique des offres CE2O ou CELAN ou C2E
pour
> les accès sur fibre" ? :
>
>
http://www.orange.com/fr/content/download/13289/268065/version/5/file/Couverture%20g%C3%A9ographique%20et%20zonage%20tarifaire%20des%20offres%20CE2O-C2E-CELAN%20au%201%20septembre%202013.xls
>
> Oui, voilà, il faut regarder les colonnes région ATM et région Ethernet.
> T’es content quand t’es pas dans le Var (la plaque ne comporte qu’un
département) :)
> Mais ils ont le soleil et les cigales.
>
> En dehors de cette région administrative, Orange peut surement fournir du
> lien CELAN "en extension" sur la France entière ? Je ne trouve pas, dans
> l'annexe tarifaire,  le surcout FAS & ABO lorsqu'un lien est commandé en
> extension ?
>
>
http://www.orange.com/fr/content/download/29259/823020/version/2/file/annexe%206%203%209%20a%20-%20prix%20CE%20LAN%20applicable%20au%2015%20avril%202015.pdf
>
> Oui mais ce n’est pas un tarif régulé donc pas public.
> Pas de surcoût FAS. Surcoût abo environ 10-12€/Mbps (dégressif bien sûr
mais surtout au dessus de 20Mbps).
> Ton commercial va se faire une joie de te la communiquer, et tu vas
pleurer :)
>
> Les régions ATM et Ethernet Optique, c'est important aussi vis à vis de
> l'extension ?
>
> Ils sont en train de tuer progressivement le réseau ATM, donc ça
m’étonnerait qu’ils t’en parlent :)
> Je ne sais même pas si on peut encore prendre une porte ATM.
> Détail important: envisage une porte C2E plutôt que CELAN
> Pourquoi ? Parce que tu peux commander une liaison CELAN sur une porte
C2E, pas l’inverse.
> Donc avec une porte C2E, tu peux tout faire, et le C2E est plus
intéressant financièrement en national car la partie extension nationale
est mutualisée.
> Et quand tu as besoin de qualité :) (c’est vendredi, je pars en vacances
ce soir, j’ai droit à un petit troll), tu peux toujours commander une CELAN.
> Il n’y a pas si longtemps, les commerciaux Orange oubliaient de signaler
ce petit point technique :)
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [BIZ] Zonage offre CELAN Orange

[Fabien H]

Bonjour,
nous sommes en train d'étudier la possibilité d'ouvrir une porte CELAN dans
un DC ou Orange est présent.

Juste pour être sur et pour pas passer pour un bleu auprès des commerciaux
Orange :

la zone de couverture de cette porte sur la région (en cuivre ou fibre)
correspond bien à ce que Orange appelle la "Région administrative" dans son
fichier Excel "Couverture géographique des offres CE2O ou CELAN ou C2E pour
les accès sur fibre" ? :

http://www.orange.com/fr/content/download/13289/268065/version/5/file/Couverture%20g%C3%A9ographique%20et%20zonage%20tarifaire%20des%20offres%20CE2O-C2E-CELAN%20au%201%20septembre%202013.xls


En dehors de cette région administrative, Orange peut surement fournir du
lien CELAN "en extension" sur la France entière ? Je ne trouve pas, dans
l'annexe tarifaire,  le surcout FAS & ABO lorsqu'un lien est commandé en
extension ?

http://www.orange.com/fr/content/download/29259/823020/version/2/file/annexe%206%203%209%20a%20-%20prix%20CE%20LAN%20applicable%20au%2015%20avril%202015.pdf

Les régions ATM et Ethernet Optique, c'est important aussi vis à vis de
l'extension ?

Merci pour vos lumières,
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Accès au RSVA par webservice

[Fabien H]

Bonjour,

Le site http://www.infosva.org/ est relativement bien fait pour le
particulier pour avoir les informations sur un numéro spécial à une date
donnée.

Par contre, comme on pouvait s'y attendre, si on l'attaque de manière trop
virulente via un script, il n'apprécie pas et affiche un captcha.

Est-ce que quelqu'un aurait une méthode "universelle" pour obtenir tous les
mois la liste des tarifs de tous les numéros SVA ? Et cela sans avoir à
payer X milliers d'euro / mois chez une SSII d'envergure ?

Merci,
Bon WE,
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Accès au RSVA par webservice

[Fabien H]

Ah oui effectivement, c'est bien ça : RSVA

Donc d'après la doc suivante :
http://www.fftelecoms.org/sites/fftelecoms.org/files/contenus_lies/apnf_rsva_guide_du_futur_utilisateur_20140505.pdf

Prenons un opérateur qui adhère à l'APNF, il a accès en consultation par
internet sans coût supplémentaire si je lis bien le tableau page 25.

Donc il suffit de s'adresser à un opérateur adhérent APNF et voir en terme
de tarif .. Donc CQFD, ça ne sera pas gratuit mais c'est possible.

Merci pour l'info,
Fabien


Le 10 septembre 2016 à 11:45, Francois Demeyer  a
écrit :

> > Bonjour,
>
> Beuah aussi !
>
> > Le site http://www.infosva.org/ est relativement bien fait pour le
> > particulier pour avoir les informations sur un numéro spécial à une date
> > donnée.
>
> et c'est sa raison même d'exister, comme définie par décret :-)
>
> > Par contre, comme on pouvait s'y attendre, si on l'attaque de manière
> trop
> > virulente via un script, il n'apprécie pas et affiche un captcha.
>
> Il n'est pas prévu d'être diumpé pour des usages plus ou moins exotiques…
> pas demandé dans le décret…
>
> > Est-ce que quelqu'un aurait une méthode "universelle" pour obtenir tous
> les
> > mois la liste des tarifs de tous les numéros SVA ? Et cela sans avoir à
> > payer X milliers d'euro / mois chez une SSII d'envergure ?
>
> infosva est l'annaire inversé des numéros SVA  et non pas le RSVA, dont il
> n'est qu'une copie journal!ère partielle. Pas de webservice, pas de VPN
> (contrairement au RSVA)…
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH]

[Fabien H]

Pas de T38 ? étant un ignorant en la manière, je m'étais laissé dire que
> T38 c'est ce qu'il fallait faire pour que fax sur SIP fonctionne.
> Tu pourrais donner des détails ?
>

Le recul que nous avons ici sur le T38 ici après plusieurs années de prod,
c'est que certains fax distants ou locaux (très peu) échouent
systématiquement lors de l'envoi/réception quand le T38 est activé. C'est
donc à priori un problème d'implémentation au niveau de la GW T38/T30, ou
le fax en question qui n'apprécie la manière dont la GW gère le T30 à
certains moments, mais c'est indébuggable.

Alors qu'un bon G711 sans jigue et avec peu de latence obtiendra de très
bons résultats, et si l'envoi du fax échoue au premier essai, souvent il
passera au deuxième.

Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH]

[Fabien H]

> Le t38 n'amene pas d'incoherence c'est l' interfonctionnement IP/ TDM qui
> en amene.
> De toute facon personne ne maitrise le cheminement des appels sur le PSTN
> parfois Tdm parfois IP. Donc prenez de bon constructeur pour garantir au
> moins votre boucle locale.
>

Quand je disais indébuggable avec le T38  : effectivement l'avantage du T38
est qu'il est lisible facilement. Par contre quand cela échouait
systématiquement vers un fax donné, en ayant essayé pas mal de choses
(baisser la vitesse, activer/désactiver le CNG, ..), le T38 ne nous aidait
pas vraiment car on voyait en pleine transmission de données la GW T38
distante nous renvoyer un "fin de transmission". Donc très peu de marge de
manoeuvre ou de solution si la GW ou le fax distant n'apprécie pas une
trame..

A la différence du G711 : quand on joue avec la vitesse ou le CNG en G711,
on arrive la plupart du temps à faire passer le fax.

Problème aussi sur la multitude des GW T38 et de leur implémentation du
T38, soit au niveau opérateur, soit au niveau boucle locale (SPA 2102, sous
marque chinoise, ..). Alors qu'avec les mêmes GW en  G711 passthrough, si
le média est bon (pas de gigue, latence correcte), la communication se fait
directement en T30 de fax à fax, pas de double conversion T38-T30.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH]

[Fabien H]

C'est pas CNG, c'est ECM :-)

Le 24 septembre 2016 à 16:53, Fabien H <frnog.fab...@gmail.com> a écrit :

>
> Le t38 n'amene pas d'incoherence c'est l' interfonctionnement IP/ TDM qui
>> en amene.
>> De toute facon personne ne maitrise le cheminement des appels sur le PSTN
>> parfois Tdm parfois IP. Donc prenez de bon constructeur pour garantir au
>> moins votre boucle locale.
>>
>
> Quand je disais indébuggable avec le T38  : effectivement l'avantage du
> T38 est qu'il est lisible facilement. Par contre quand cela échouait
> systématiquement vers un fax donné, en ayant essayé pas mal de choses
> (baisser la vitesse, activer/désactiver le CNG, ..), le T38 ne nous aidait
> pas vraiment car on voyait en pleine transmission de données la GW T38
> distante nous renvoyer un "fin de transmission". Donc très peu de marge de
> manoeuvre ou de solution si la GW ou le fax distant n'apprécie pas une
> trame..
>
> A la différence du G711 : quand on joue avec la vitesse ou le CNG en G711,
> on arrive la plupart du temps à faire passer le fax.
>
> Problème aussi sur la multitude des GW T38 et de leur implémentation du
> T38, soit au niveau opérateur, soit au niveau boucle locale (SPA 2102, sous
> marque chinoise, ..). Alors qu'avec les mêmes GW en  G711 passthrough, si
> le média est bon (pas de gigue, latence correcte), la communication se fait
> directement en T30 de fax à fax, pas de double conversion T38-T30.
>
>
>
>
>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] SPAM & Score sur SPF

[Fabien H]

Bonjour,
oui c'est pas faux. Reste à voir si c'est simple à faire sur les
Postfix/Zimbra/Exchange.

Merci pour l'info

Fabien


Le 3 octobre 2016 à 23:39, Jean-Yves LENHOF <jean-y...@lenhof.eu.org> a
écrit :

>
>
> Le 03/10/2016 à 18:43, Fabien H a écrit :
> > Bonjour,
> >
> > nous avez constaté ce matin une pluie de spam avec fichier vérolé XLS
> avec
> > comme éxpediteur n'importe quoi @ notredomaine.fr et comme destinataire
> des
> > adresses existantes @ notredomaine.fr .
>
> Hello,
>
> Plutôt que de jouer avec les antispam, déjà j'interdirais ça ;-)
> Pour envoyer depuis ton domaine vers ton domaine, perso j'obligerais à
> faire du SMTP authentifié
>
> 
>
> JYL
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] SPAM & Score sur SPF

[Fabien H]

>
> Si tu n'avais pas encore de record SPF dans ton DNS, je te conseille
> quand même de mettre du dmarc sur ta zone et de regarder un peu ce qu'il
> se passe, histoire d'éviter les mauvaises surprises en ajoutant le SPF.
>
>
Idem, je ne connaissais pas, merci

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] SPAM & Score sur SPF

[Fabien H]

Bonjour,

nous avez constaté ce matin une pluie de spam avec fichier vérolé XLS avec
comme éxpediteur n'importe quoi @ notredomaine.fr et comme destinataire des
adresses existantes @ notredomaine.fr .

Certains mails sont passés car le SMTP qui envoyait était de bonne
réputation au début des envois (pas à la fin !)

Je voudrais renforcer la protection par SPF sur notre passerelle
spamassassin pour éviter ça :

Actuellement, les scores de spamassassin pour le Spam sont :

- Spam : 3.5
- High Spam 5

Par contre bizarrement, les scores sur les SPF FAIL sont faibles dans la
conf par défaut de spamassassin.:

score SPF_FAIL 0 0.919 0 0.001 # n=0 n=2
score SPF_HELO_FAIL 0 0.001 0 0.001 # n=0 n=2
score SPF_HELO_NEUTRAL 0 0.001 0 0.112 # n=0 n=2
score SPF_HELO_SOFTFAIL 0 0.896 0 0.732 # n=0 n=2
score SPF_NEUTRAL 0 0.652 0 0.779 # n=0 n=2
score SPF_SOFTFAIL 0 0.972 0 0.665 # n=0 n=2

Est-ce que vous pensez qu'il y'a une raison ? Manque de fiabilité des SPF
en général ?

Je pensais carrément mettre le SPF_FAIL à 2.9 et le SPF_SOFTFAIL à 1.9, Un
avis ?
Merci pour le retour,

Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Format d'envoi PDAAU Envol

[Fabien H]

Bonjour,

dites, vous savez si les préfectures ont des consignes pour l'envoi des
fichiers PDAAU via envol ?

Je demande ça par rapport à l'envoi d'aujourd'hui pour ceux qui ont reçu le
lien : Le fichier ODS, c'est bien pour un humain, mais les fichiers CSV,
c'est mieux pour une machine .. Sachant que le enregistrer sous > format
CSV ne donne pas directement le format attendu..

Est-ce que les préfectures "doivent" envoyer les 2 fichiers CSV
correspondants en plus de l'ODS, ou c'est au bon vouloir de chaque
préfecture ?

Merci,
Bonne soirée,
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Format d'envoi PDAAU Envol

[Fabien H]

Ok, je vais demander poliment à l'éxpediteur alors ;-)

Bonne soirée,
Fabien

Le 21 novembre 2016 à 20:31, David Ponzone <david.ponz...@gmail.com> a
écrit :

> Oui, normalement ODS et 2 CSV.
> Enfin, "normalement" reste à définir.
> > Le 21 nov. 2016 à 20:24, Fabien H <frnog.fab...@gmail.com> a écrit :
> >
> > Bonjour,
> >
> > dites, vous savez si les préfectures ont des consignes pour l'envoi des
> > fichiers PDAAU via envol ?
> >
> > Je demande ça par rapport à l'envoi d'aujourd'hui pour ceux qui ont reçu
> le
> > lien : Le fichier ODS, c'est bien pour un humain, mais les fichiers CSV,
> > c'est mieux pour une machine .. Sachant que le enregistrer sous > format
> > CSV ne donne pas directement le format attendu..
> >
> > Est-ce que les préfectures "doivent" envoyer les 2 fichiers CSV
> > correspondants en plus de l'ODS, ou c'est au bon vouloir de chaque
> > préfecture ?
> >
> > Merci,
> > Bonne soirée,
> > Fabien
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Secours des appels entrant

[Fabien H]

Et google confirme ensuite assez facilement.

Le 24 novembre 2016 à 20:40, Fabien H <frnog.fab...@gmail.com> a écrit :

> Ah non j'y aurais pas pensé ! Non, c'est juste que Xavier est aussi abonné
> à la ML OVH.
>
> Le 24 novembre 2016 à 20:35, David Ponzone <david.ponz...@gmail.com> a
> écrit :
>
>> Tu dis ça parce que son 0805 est un bloc attributaire OVH ?
>> Sérieux ?
>>
>> Le 24 nov. 2016 à 20:23, Fabien H <frnog.fab...@gmail.com> a écrit :
>>
>> Faut taper les bons mots clés ;-)
>>
>>
>> Le 24 novembre 2016 à 20:18, David Ponzone <david.ponz...@gmail.com> a
>> écrit :
>>
>> Tu peux m'expliquer comment tu trouves son transitaire voix sur Google ?
>> :)
>>
>> David Ponzone
>>
>>
>>
>> Le 24 nov. 2016 à 19:11, Fabien H <frnog.fab...@gmail.com> a écrit :
>>
>> Je confirme ce que dit David, Orange en SIP permet d'avoir 2 intercos
>>
>> sur 2
>>
>> lieux géographiques différents.
>>
>> D'après ce que je lis sur Google, ton transitaire voix serait lillois..
>>
>> Ce
>>
>> qui m'étonne, c'est qu'ils parlaient de doubler leur interco de collecte
>> orange il y'a quelques mois/années, je pensais que c'était en place
>> actuellement.
>>
>>
>>
>> Le 24 novembre 2016 à 11:38, Xavier ROCA <x.r...@sipleo.com> a écrit :
>>
>> Bonjour,
>>
>>
>>
>> En ce jour, ou nous subissons de nouveau des problèmes de qualité de
>>
>> voix
>>
>> avec notre transitaire voix.
>>
>> Cela me fait à nouveau pester !
>>
>> Oui sur lui mais bon cela n’arrange pas nos affaires et l’aidera pas non
>> plus donc pas la peine d’y perdre du temps.
>>
>>
>>
>> Par contre a quand la possibilité d’avoir un secours sur les appels
>> entrants.
>>
>> Car personne n’est parfait 100% du temps.
>>
>> A ce jour a moins que je sois passé a vraiment a côté ce n’est pas
>> possible.
>>
>>
>>
>> J’ai vraiment l’impression que l’on est toujours à l’âge de pierre pour
>> cela
>> !
>>
>>
>>
>> Messieurs les compétents et maître des télécom faudrait-il pas y venir ?
>>
>> Nous, ne devrions nous pas monter aux créneaux ?
>>
>>
>>
>> Quel est votre avis à ce sujet ?
>>
>> Qui doit y travailler ? L’ARCEP
>>
>> Qui peut y faire du lobbying ?
>>
>>
>>
>> Xavier
>>
>>
>>
>>
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Secours des appels entrant

[Fabien H]

D'après les messages sur la ML OVH, en date du 11/10/2015 (méga panne vol
cuivre)  : ils étaient au niveau France  terminaison Orange, Sfr, Completel
et collecte Orange.

Ils étaient déjà en redondance Orange à cette date mais dans le même DC
(no comment..)


Le 24 novembre 2016 à 19:52, Sébastien Lesimple <
sebastien.lesim...@iguanetel.fr> a écrit :

> On 24/11/2016 19:11, Fabien H wrote:
> > Je confirme ce que dit David, Orange en SIP permet d'avoir 2 intercos
> sur 2
> > lieux géographiques différents.
> Toutes les interco voix permettent cela, en SIP mais aussi la bonne
> vielle Interco SS7.
> En in-Span ou Quasi Associée, c'est tout l’intérêt des "vraies intercos"
> construites dans les regles de l'art.
> > D'après ce que je lis sur Google, ton transitaire voix serait lillois..
> Ce
> > qui m'étonne, c'est qu'ils parlaient de doubler leur interco de collecte
> > orange il y'a quelques mois/années, je pensais que c'était en place
> > actuellement.
> Si tu parles d'une boite en 3 lettres qui commence par O et fini par H,
> il me semblait qu'ils étaient 100% LaiSserFaiRe...
> A moins qu'ils n'aient changés de politique en matière de Voix?
> >
> >
> >
> > Le 24 novembre 2016 à 11:38, Xavier ROCA <x.r...@sipleo.com> a écrit :
> >
> >> Bonjour,
> >>
> >>
> >>
> >> En ce jour, ou nous subissons de nouveau des problèmes de qualité de
> voix
> >> avec notre transitaire voix.
> >>
> >> Cela me fait à nouveau pester !
> >>
> >> Oui sur lui mais bon cela n’arrange pas nos affaires et l’aidera pas non
> >> plus donc pas la peine d’y perdre du temps.
> >>
> >>
> >>
> >> Par contre a quand la possibilité d’avoir un secours sur les appels
> >> entrants.
> >>
> >> Car personne n’est parfait 100% du temps.
> >>
> >> A ce jour a moins que je sois passé a vraiment a côté ce n’est pas
> >> possible.
> >>
> >>
> >>
> >> J’ai vraiment l’impression que l’on est toujours à l’âge de pierre pour
> >> cela
> >> !
> >>
> >>
> >>
> >> Messieurs les compétents et maître des télécom faudrait-il pas y venir ?
> >>
> >> Nous, ne devrions nous pas monter aux créneaux ?
> >>
> >>
> >>
> >> Quel est votre avis à ce sujet ?
> >>
> >> Qui doit y travailler ? L’ARCEP
> >>
> >> Qui peut y faire du lobbying ?
> >>
> >>
> >>
> >> Xavier
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Secours des appels entrant

[Fabien H]

Ah non j'y aurais pas pensé ! Non, c'est juste que Xavier est aussi abonné
à la ML OVH.

Le 24 novembre 2016 à 20:35, David Ponzone <david.ponz...@gmail.com> a
écrit :

> Tu dis ça parce que son 0805 est un bloc attributaire OVH ?
> Sérieux ?
>
> Le 24 nov. 2016 à 20:23, Fabien H <frnog.fab...@gmail.com> a écrit :
>
> Faut taper les bons mots clés ;-)
>
>
> Le 24 novembre 2016 à 20:18, David Ponzone <david.ponz...@gmail.com> a
> écrit :
>
> Tu peux m'expliquer comment tu trouves son transitaire voix sur Google ?
> :)
>
> David Ponzone
>
>
>
> Le 24 nov. 2016 à 19:11, Fabien H <frnog.fab...@gmail.com> a écrit :
>
> Je confirme ce que dit David, Orange en SIP permet d'avoir 2 intercos
>
> sur 2
>
> lieux géographiques différents.
>
> D'après ce que je lis sur Google, ton transitaire voix serait lillois..
>
> Ce
>
> qui m'étonne, c'est qu'ils parlaient de doubler leur interco de collecte
> orange il y'a quelques mois/années, je pensais que c'était en place
> actuellement.
>
>
>
> Le 24 novembre 2016 à 11:38, Xavier ROCA <x.r...@sipleo.com> a écrit :
>
> Bonjour,
>
>
>
> En ce jour, ou nous subissons de nouveau des problèmes de qualité de
>
> voix
>
> avec notre transitaire voix.
>
> Cela me fait à nouveau pester !
>
> Oui sur lui mais bon cela n’arrange pas nos affaires et l’aidera pas non
> plus donc pas la peine d’y perdre du temps.
>
>
>
> Par contre a quand la possibilité d’avoir un secours sur les appels
> entrants.
>
> Car personne n’est parfait 100% du temps.
>
> A ce jour a moins que je sois passé a vraiment a côté ce n’est pas
> possible.
>
>
>
> J’ai vraiment l’impression que l’on est toujours à l’âge de pierre pour
> cela
> !
>
>
>
> Messieurs les compétents et maître des télécom faudrait-il pas y venir ?
>
> Nous, ne devrions nous pas monter aux créneaux ?
>
>
>
> Quel est votre avis à ce sujet ?
>
> Qui doit y travailler ? L’ARCEP
>
> Qui peut y faire du lobbying ?
>
>
>
> Xavier
>
>
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Secours des appels entrant

[Fabien H]

Faut taper les bons mots clés ;-)


Le 24 novembre 2016 à 20:18, David Ponzone <david.ponz...@gmail.com> a
écrit :

> Tu peux m'expliquer comment tu trouves son transitaire voix sur Google ?
> :)
>
> David Ponzone
>
>
>
> > Le 24 nov. 2016 à 19:11, Fabien H <frnog.fab...@gmail.com> a écrit :
> >
> > Je confirme ce que dit David, Orange en SIP permet d'avoir 2 intercos
> sur 2
> > lieux géographiques différents.
> >
> > D'après ce que je lis sur Google, ton transitaire voix serait lillois..
> Ce
> > qui m'étonne, c'est qu'ils parlaient de doubler leur interco de collecte
> > orange il y'a quelques mois/années, je pensais que c'était en place
> > actuellement.
> >
> >
> >
> >> Le 24 novembre 2016 à 11:38, Xavier ROCA <x.r...@sipleo.com> a écrit :
> >>
> >> Bonjour,
> >>
> >>
> >>
> >> En ce jour, ou nous subissons de nouveau des problèmes de qualité de
> voix
> >> avec notre transitaire voix.
> >>
> >> Cela me fait à nouveau pester !
> >>
> >> Oui sur lui mais bon cela n’arrange pas nos affaires et l’aidera pas non
> >> plus donc pas la peine d’y perdre du temps.
> >>
> >>
> >>
> >> Par contre a quand la possibilité d’avoir un secours sur les appels
> >> entrants.
> >>
> >> Car personne n’est parfait 100% du temps.
> >>
> >> A ce jour a moins que je sois passé a vraiment a côté ce n’est pas
> >> possible.
> >>
> >>
> >>
> >> J’ai vraiment l’impression que l’on est toujours à l’âge de pierre pour
> >> cela
> >> !
> >>
> >>
> >>
> >> Messieurs les compétents et maître des télécom faudrait-il pas y venir ?
> >>
> >> Nous, ne devrions nous pas monter aux créneaux ?
> >>
> >>
> >>
> >> Quel est votre avis à ce sujet ?
> >>
> >> Qui doit y travailler ? L’ARCEP
> >>
> >> Qui peut y faire du lobbying ?
> >>
> >>
> >>
> >> Xavier
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Secours des appels entrant

[Fabien H]

Pour le transfert,O.H aurait très bien la possibilité d'autoriser le
transfert si l'autocom relié au trunk SIP indique explicitement dans les
entêtes SIP que le sortant du PABX est un transfert, et beaucoup de PABX le
font. C'est propre et pas "trop" dangeureux.

Après, effectivement, c'est une volonté de leur part de ne pas le faire,
tant pis pour eux



Le 25 novembre 2016 à 08:59, Fabien H <frnog.fab...@gmail.com> a écrit :

> Dans mon premier mail sur eux, j'ai parlé au conditionnel. Après le sujet
> a derivé..Désolé pour les conclusions hatives et la dérive du sujet
>
> Donc pour revenir sur le sujet, cherche un un opérateur qui collecte avec
> Orange et sur 2 DC.
>
>
>
>
>
> Le 25 novembre 2016 à 08:51, Xavier ROCA <x.r...@sipleo.com> a écrit :
>
>> Fabien, comment fais-tu pour que Google de donne mon transitaire ?
>> C'est quoi ta requête miracle ?
>> Pour une futur recherche, tu prends la même requête mais juste en
>> excluant les critères utilisées :)
>>
>> Car tu te vois faires faire du transit pro avec un opérateur qui te dit
>> t'interdire d'afficher librement un numéro car c'est soit disant la
>> réglementation qui l'interdit...
>> Si un gus accepte cette réponse c'est qui ne connait même pas un T0. Et
>> la, je reste courtois
>> Du coup, le suivi de numéro lors d'un transfert pas possible ... alors
>> qu'on fait ca depuis des lustres.
>> Sans parler du transcodage qui n'est pas fait quand on accepte N codec
>> mais que ton transit avec l'opérateur F n'est possible que sur un codec
>> bien précis.
>>
>> Oui je suis sur leur ML,
>> Oui j'ai deux 0805 chez eux comme des noms de domaine, (fut un temps ou
>> on était en directe avec l'AFNIC, mais économiquement ce n'est pas
>> intéressant et ils fon cela très bien)
>> Oui on a était le premier iPBX à valider leur offre Trunk SIP.
>> Oui on a fait des interviews croisées et on a même eu un emplacement sur
>> leur Stand à l'IT PARTNER
>>
>> Et de la tu penses que c'est eux notre transitaire voix ... Ouah quel
>> conclusion scientifique.
>> Eux ils se positionnent sur prix très bas c'est un choix affiché, et ils
>> le font je pense mieux que beaucoup.
>> Mais de la a prendre des minutes chez eux faut pas abuser.
>>
>>
>> Voila pour le démenti, d'autres présent dans cette ML pourront te
>> confirmer que ce n'est pas eux car ils ont eu les mêmes soucis et savent
>> par conséquence de qui il y s'agit.
>> David connait assez bien les candidats potentiel pour avoir été assez
>> surpris par ton raisonnement et savoir qu'ils ne sont pas dans la liste
>> potentiel des concernés.
>>
>>
>>
>> J'ai volontairement pas donné le nom car tout le monde peut être
>> défaillant et je ne voulais pas axer la discussion sur ce point la.
>> Bon après il y a les BlackYear pour certain.
>>
>> Ce qui me chagrine, c'est cet immobilisme et acceptation de fait du mode
>> actuel de ne pas avoir un routage dynamique des appels.
>> Oui, au niveau international ce ne serait pas conforme.
>> Oui, cela remet en cause bien des choses au niveau facturation.
>>
>> Mais mince, ne peut-on pas être force de proposition et d'évolution.
>> A ce jour, j'ai deux connexions différentes vers mon transitaire mais si
>> ce dernier a un pb en amont ou en cœur de réseau la double adduction ne me
>> change rien.
>> Et Orange aussi sérieux qu'ils soient, on un problème oui oui ca arrive,
>> aussi faible la cadence soit-elle, c'est pareil.
>>
>> Merci a Jérôme pour ce mail instructif (je vais encore relire une ou deux
>> fois pour tout bien retenir).
>>
>> On voit bien un problème de volonté pas un problème qui est insoluble sur
>> le plan technique.
>> C'est ça qui est frustrant !
>> Et que nous opérateurs de PME (c'est comme cela que OWF nous désigne ce
>> qui est assez vrai pour notre part), que l'on ne soit pas capable de
>> s'organiser pour changer les choses car les gros et l'administratif bloque.
>>
>> // Délire
>> Oui je sais je vis dans le monde des bisounours des télécoms mais notre
>> monde évolue change, et nous aussi, donc pourquoi ne pas lever ces blocages
>> qui n'ont pas lieu d'être.
>>
>> Ou alors, youpi, plus que des appels SIP directe via un bon DNS résolve
>> pour dialoguer entre iPBX
>> Et alors la, plus de minutes a facturé, plus de numéro stupide a retenir.
>> Un coup de fil aussi simple qu'un mail.
>> Vivement que cela arrive, il y a des gros (et beaucoup de moins gros) qui
>> vont perdre la vache a lait.
>> On pourra alors se concentrer sur les vraies 

Re: [FRnOG] [MISC] Secours des appels entrant

[Fabien H]

Dans mon premier mail sur eux, j'ai parlé au conditionnel. Après le sujet a
derivé..Désolé pour les conclusions hatives et la dérive du sujet

Donc pour revenir sur le sujet, cherche un un opérateur qui collecte avec
Orange et sur 2 DC.





Le 25 novembre 2016 à 08:51, Xavier ROCA <x.r...@sipleo.com> a écrit :

> Fabien, comment fais-tu pour que Google de donne mon transitaire ?
> C'est quoi ta requête miracle ?
> Pour une futur recherche, tu prends la même requête mais juste en excluant
> les critères utilisées :)
>
> Car tu te vois faires faire du transit pro avec un opérateur qui te dit
> t'interdire d'afficher librement un numéro car c'est soit disant la
> réglementation qui l'interdit...
> Si un gus accepte cette réponse c'est qui ne connait même pas un T0. Et
> la, je reste courtois
> Du coup, le suivi de numéro lors d'un transfert pas possible ... alors
> qu'on fait ca depuis des lustres.
> Sans parler du transcodage qui n'est pas fait quand on accepte N codec
> mais que ton transit avec l'opérateur F n'est possible que sur un codec
> bien précis.
>
> Oui je suis sur leur ML,
> Oui j'ai deux 0805 chez eux comme des noms de domaine, (fut un temps ou on
> était en directe avec l'AFNIC, mais économiquement ce n'est pas intéressant
> et ils fon cela très bien)
> Oui on a était le premier iPBX à valider leur offre Trunk SIP.
> Oui on a fait des interviews croisées et on a même eu un emplacement sur
> leur Stand à l'IT PARTNER
>
> Et de la tu penses que c'est eux notre transitaire voix ... Ouah quel
> conclusion scientifique.
> Eux ils se positionnent sur prix très bas c'est un choix affiché, et ils
> le font je pense mieux que beaucoup.
> Mais de la a prendre des minutes chez eux faut pas abuser.
>
>
> Voila pour le démenti, d'autres présent dans cette ML pourront te
> confirmer que ce n'est pas eux car ils ont eu les mêmes soucis et savent
> par conséquence de qui il y s'agit.
> David connait assez bien les candidats potentiel pour avoir été assez
> surpris par ton raisonnement et savoir qu'ils ne sont pas dans la liste
> potentiel des concernés.
>
>
>
> J'ai volontairement pas donné le nom car tout le monde peut être
> défaillant et je ne voulais pas axer la discussion sur ce point la.
> Bon après il y a les BlackYear pour certain.
>
> Ce qui me chagrine, c'est cet immobilisme et acceptation de fait du mode
> actuel de ne pas avoir un routage dynamique des appels.
> Oui, au niveau international ce ne serait pas conforme.
> Oui, cela remet en cause bien des choses au niveau facturation.
>
> Mais mince, ne peut-on pas être force de proposition et d'évolution.
> A ce jour, j'ai deux connexions différentes vers mon transitaire mais si
> ce dernier a un pb en amont ou en cœur de réseau la double adduction ne me
> change rien.
> Et Orange aussi sérieux qu'ils soient, on un problème oui oui ca arrive,
> aussi faible la cadence soit-elle, c'est pareil.
>
> Merci a Jérôme pour ce mail instructif (je vais encore relire une ou deux
> fois pour tout bien retenir).
>
> On voit bien un problème de volonté pas un problème qui est insoluble sur
> le plan technique.
> C'est ça qui est frustrant !
> Et que nous opérateurs de PME (c'est comme cela que OWF nous désigne ce
> qui est assez vrai pour notre part), que l'on ne soit pas capable de
> s'organiser pour changer les choses car les gros et l'administratif bloque.
>
> // Délire
> Oui je sais je vis dans le monde des bisounours des télécoms mais notre
> monde évolue change, et nous aussi, donc pourquoi ne pas lever ces blocages
> qui n'ont pas lieu d'être.
>
> Ou alors, youpi, plus que des appels SIP directe via un bon DNS résolve
> pour dialoguer entre iPBX
> Et alors la, plus de minutes a facturé, plus de numéro stupide a retenir.
> Un coup de fil aussi simple qu'un mail.
> Vivement que cela arrive, il y a des gros (et beaucoup de moins gros) qui
> vont perdre la vache a lait.
> On pourra alors se concentrer sur les vraies valeurs ajoutées que chacun
> apporte dans ses services.
> Et moi vendre mon soft qui fait papa et maman (mais pas de bébé !)
> // Fin de mon délire
>
> Bon BlackDredi a tous
>
> Xavier
>
>
>
>
> -Message d'origine-
> De : Fabien H [mailto:frnog.fab...@gmail.com]
> Envoyé : jeudi 24 novembre 2016 19:11
> À : frnog-m...@frnog.org
> Objet : Re: [FRnOG] [MISC] Secours des appels entrant
>
> Je confirme ce que dit David, Orange en SIP permet d'avoir 2 intercos sur
> 2 lieux géographiques différents.
>
> D'après ce que je lis sur Google, ton transitaire voix serait lillois.. Ce
> qui m'étonne, c'est qu'ils parlaient de doubler leur interco de collecte
> orange il y'a quelques mois/années, je pensais que c'était en place
> actuelleme

Re: [FRnOG] [MISC] Secours des appels entrant

[Fabien H]

Je confirme ce que dit David, Orange en SIP permet d'avoir 2 intercos sur 2
lieux géographiques différents.

D'après ce que je lis sur Google, ton transitaire voix serait lillois.. Ce
qui m'étonne, c'est qu'ils parlaient de doubler leur interco de collecte
orange il y'a quelques mois/années, je pensais que c'était en place
actuellement.



Le 24 novembre 2016 à 11:38, Xavier ROCA  a écrit :

> Bonjour,
>
>
>
> En ce jour, ou nous subissons de nouveau des problèmes de qualité de voix
> avec notre transitaire voix.
>
> Cela me fait à nouveau pester !
>
> Oui sur lui mais bon cela n’arrange pas nos affaires et l’aidera pas non
> plus donc pas la peine d’y perdre du temps.
>
>
>
> Par contre a quand la possibilité d’avoir un secours sur les appels
> entrants.
>
> Car personne n’est parfait 100% du temps.
>
> A ce jour a moins que je sois passé a vraiment a côté ce n’est pas
> possible.
>
>
>
> J’ai vraiment l’impression que l’on est toujours à l’âge de pierre pour
> cela
> !
>
>
>
> Messieurs les compétents et maître des télécom faudrait-il pas y venir ?
>
> Nous, ne devrions nous pas monter aux créneaux ?
>
>
>
> Quel est votre avis à ce sujet ?
>
> Qui doit y travailler ? L’ARCEP
>
> Qui peut y faire du lobbying ?
>
>
>
> Xavier
>
>
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Numéro en 06 et 07

[Fabien H]

Bonjour,

ça nous intéresse aussi : juste par curiosité, sans donner de nom, tu as eu
des contacts là dessus ?

Cordialement,
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Portabilité partielle

[Fabien H]

Si c'est du RNIS, c'est bien une demande de portabilité partielle qu'il
faut faire il me semble. Tu indiques le SDA que tu souhaites porter et en
commentaire, tu indiques le NDI concerné.

Et s'ils ne veulent pas savoir, il faut leur envoyer un mail sur l'adresse
ad hoc.

Le 15 mars 2017 à 11:38, Sébastien Lesimple  a écrit :

> On 15/03/2017 11:11, David Ponzone wrote:
> > Il peut pas t’aider l’opérateur qui s’occupe de tes portas ?
> > Normalement, tu peux porter un seul SDA. Tu as essayé en porta simple
> (GP) en donnant le RIO du SDA ?
> >
> >
> >> Le 15 mars 2017 à 11:03, Julien Escario  a écrit :
> >>
> >> Bonjour,
> >> Pour le compte d'un client, nous tentons de porter uniquement un numéro
> (celui
> >> du fax, pour faire du fax2mail) qui est actuellement livré par Orange
> sur une
> >> accès RNIS avec un range de numéro (très peu, quatre).
> >>
> >> Le premier essai un gros fail puisque Orange a répondu que ce n'était
> pas la
> >> tête de ligne. Pas faute d'avoir précisé que c'était le cas et que nous
> ne
> >> voulions PAS porter l'ensemble des numéros.
> >>
> >> Donc question simple : c'est mort pour porter uniquement un numéro dans
> un range
> >> ou est-ce qu'il y a une subtilité qui m'échappe ?
> >> Le client est évidemment un pro.
> >>
> >> Merci et bonne journée,
> >> Julien
> >>
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
> Au pire du pire des cas, si tu es totalement bloqué, fais faire une
> transformation du SDA en Ligne Analogique, puis enclenches la portabilité.
>
> Tu vas en avoir pour 100/120 euro a tout casser mais ca isolera ton SDA
> du "service SDA" qui doit être un bloc de 5 (tête comprise).
>
> T'es pas sur une BIV, ou un accès Open, c'est déjà çà!
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Solution IPTV

[Fabien H]

Bonjour,

Molotov TV !

Ok je sors..


Le 9 mars 2017 à 12:00, Pierrick Tassin  a écrit
:

> Bonjour à tous,
>
> Je suis actuellement sur un projet IPTV et je souhaiterai savoir qu'elles
> solutions vous utilisez et quels sont vos retours sur ces différentes
> solutions.
>
> J'ai eu l'occasion de tester le middleware Stalker avec les stb MAG, seul
> bémol le codec audio E-AC3 pour les chaine de la TNT HD n'est pas supporté.
>
> Cordialement,
> Pierrick
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] QOS par défaut sur liens internet

[Fabien H]

Bonjour,

sur les liens internet que vous fournissez, en dehors éventuellement de la
VOIP, est-ce que vous mettez en place une QOS par défaut genre fair-queue
de manière systématique ? Si oui, est-ce vraiment efficace ?

L'idée est d'améliorer le confort du client, en cas de gros téléchargement
HTTP d'un côté, et par exemple session bureau à distance de l'autre..

Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [MISC] Microsoft (ASN 8075) sur AMS-IX

[Fabien H]

Bonjour,

pour les opérateurs présents sur AMS-IX,

est-ce que vous constatez comme nous que depuis le jeudi 29/06 environ, sur
les RS 1 / 2 / 3 / 4, l'AS 8075 de Microsoft n'annonce aucun réseau et ne
semble pas recevoir nos réseaux non plus.

Leur IPv4 AMS-IX 80.249.209.20 est pingable.

Bien entendu, je vais écrire à leur contact peering, mais c'était pour être
sur que le problème ne vient pas de chez nous.

Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Microsoft (ASN 8075) sur AMS-IX

[Fabien H]

OK, merci pour les retours, donc je vais leur écrire mais pour faire du
peering direct.

J'ai pu vérifier sur notre outil As-stat qu'il y'a encore 2 semaines, ça
passait toujours par les RS AMS-IX.. Dommage car les RS simplifient les
choses. J'ai du mal à comprendre pourquoi certains peers n'utilisent pas
les RS alors qu'il acceptent le peering direct ? Pour des questions de
sécurité BGP ?

Fabien


Le 10 juillet 2017 à 12:08, David Ponzone <david.ponz...@gmail.com> a écrit
:

> Juste pour info, c’est comme ça sur EQNX-IX, mais c’est normal: ils n’ont
> jamais annoncé  leurs routes par le MLPE.
>
>
> > Le 10 juil. 2017 à 12:02, Youssef Bengelloun-Zahr <benge...@gmail.com>
> a écrit :
> >
> > Bonjour Fabien,
> >
> > Je confirme, je vois bien leurs préfixes sur l'ensemble des peerings
> qu'on
> > a en direct avec eux (AMS-IX + NL-IX) mais plus rien via les RS des IXPs.
> >
> > My 2 cents.
> >
> > Y.
> >
> >
> >
> > Le 10 juillet 2017 à 11:46, Fabien H <frnog.fab...@gmail.com> a écrit :
> >
> >> Bonjour,
> >>
> >> pour les opérateurs présents sur AMS-IX,
> >>
> >> est-ce que vous constatez comme nous que depuis le jeudi 29/06 environ,
> sur
> >> les RS 1 / 2 / 3 / 4, l'AS 8075 de Microsoft n'annonce aucun réseau et
> ne
> >> semble pas recevoir nos réseaux non plus.
> >>
> >> Leur IPv4 AMS-IX 80.249.209.20 est pingable.
> >>
> >> Bien entendu, je vais écrire à leur contact peering, mais c'était pour
> être
> >> sur que le problème ne vient pas de chez nous.
> >>
> >> Fabien
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Microsoft (ASN 8075) sur AMS-IX

[Fabien H]

Très intéressant tout ça, merci pour les retours


Le 11 juillet 2017 à 10:26, Xavier Beaudouin  a écrit :

> Hello,
>
> > 3 raisons de plus :
> > - permet de gérer son trafic au cas où sont tuyaux sur le IX est plein
> (depeerer
> > peer par peer)
> > - certain demande une sorte de contrat morale peer par peer. (des gros
> > français...) (ils demandent de pas faire transiter du trafic forbiden ou
> > moralement inacceptable...) rejoint un peu le point 5  de Nicolas je
> crois.
> > - backup les routes serveurs pour ne pas dépendre d'eux (certains clients
> > demande la liste des peerings direct) j'en avais parlé sur cette liste
> il y a
> > qque année :-)
> > - et surement d'autre...
>
> Une autre pratique, en cas de DDoS ca permet de limiter les effets de
> bords surtout quand la connection a l'IX est à faible débit...
>
> Xavier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [BIZ] Re: Contact français Akamai Peering

[Fabien H]

Bonjour,
J'ai pu avoir plusieurs contacts en PV et notre problème est résolu.

Merci la liste !
Fabien

Le 29 août 2017 à 17:46, Fabien H <frnog.fab...@gmail.com> a écrit :

> Bonjour,
>
> est-ce que quelqu'un aurait un contact français chez Akamai (NOC/Peering)
> à me communiquer en privé ?
>
> Je n'ai pas de réponse via les adresses email déclarées au RIPE.
>
> Merci,
> Cordialement,
> Fabien
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [BIZ] Contact français Akamai Peering

[Fabien H]

Bonjour,

est-ce que quelqu'un aurait un contact français chez Akamai (NOC/Peering) à
me communiquer en privé ?

Je n'ai pas de réponse via les adresses email déclarées au RIPE.

Merci,
Cordialement,
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tests de débit

[Fabien H]

Non, non, du bon vieux RJ45 en catégorie 5 ou 6 :-)


Le 28 novembre 2017 à 11:15, David Ponzone <david.ponz...@gmail.com> a
écrit :

> Juste au cas où, tu fais pas le test depuis un PC connecté en WIFI hein ?
> :)
> Le 28 nov. 2017 à 11:12, Fabien H a écrit :
>
> > Test fait en installant
> >
> > https://github.com/adolfintel/speedtest
> >
> > sur un serveur web sur le Backbone pour mesurer le débit sur un lien 100M
> > symétrique :
> >
> > Down : 88 M  / 100M
> > Up : 60 M / 100 M
> >
> > Le down est cohérent car le lien est en utilisation.
> >
> > Par contre, le up n'est pas cohérent : l'Upload n'est quasiment pas
> utilisé
> > d'après les graph de débit que nous avons. Constat déjà fait sur d'autres
> > produits Open Source : le Up n'est pas cohérent (ou alors ça vient de la
> > configuration du serveur web ..)
> >
> >
> >
> > <http://speedtest.fdossena.com/>
> >
> >
> > Le 28 novembre 2017 à 08:24, Fabien H <frnog.fab...@gmail.com> a écrit :
> >
> >> Le speedtest qui est derrière http://speedtest.fdossena.com/  semble
> >> simple et fiable effectivement, merci.
> >>
> >> Je vais l'installer sur un serveur sur notre backbone pour voir s'il est
> >> vraiment fiable ou pas..
> >>
> >> Fabien
> >>
> >> Le 28 novembre 2017 à 08:19, David Ponzone <david.ponz...@gmail.com> a
> >> écrit :
> >>
> >>> Google en donne quelques autres:
> >>>
> >>> http://openspeedtest.com
> >>> -> même résultat que http://speedtest.fdossena.com grosso modo
> >>>
> >>> Celui de Comcast: https://github.com/Comcast/Speed-testJS
> >>> -> pas testé, la version de test ne marche pas chez moi, ou elle est
> >>> réservée aux clients Comcast
> >>>
> >>>
> >>> Le 28 nov. 2017 à 01:16, Arnaud Launay a écrit :
> >>>
> >>>> Le Mon, Nov 27, 2017 at 10:28:28PM +, Michel Py a écrit:
> >>>>> J'ai 85 M en descendant (pas mal sur 100 surtout qu'il y a
> >>>>> autre chose qui tourne) mais seulement 30 M en montant. Pas si
> >>>>> pire a 1 kilomètres avec 200 ms de latence et 30 de gigue.
> >>>>
> >>>> Ici c'est plus proche, et un peu mieux, mais c'est pas encore ça,
> >>>> sur un serveur basé à Milan, Italie:
> >>>>
> >>>> 160/300 en DL
> >>>> 100/100 en UL
> >>>> 35ms de ping
> >>>> 3ms de gigue.
> >>>>
> >>>>  Arnaud.
> >>>>
> >>>>
> >>>> ---
> >>>> Liste de diffusion du FRnOG
> >>>> http://www.frnog.org/
> >>>
> >>>
> >>> ---
> >>> Liste de diffusion du FRnOG
> >>> http://www.frnog.org/
> >>>
> >>
> >>
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tests de débit

[Fabien H]

Test fait en installant

https://github.com/adolfintel/speedtest

sur un serveur web sur le Backbone pour mesurer le débit sur un lien 100M
symétrique :

Down : 88 M  / 100M
Up : 60 M / 100 M

Le down est cohérent car le lien est en utilisation.

Par contre, le up n'est pas cohérent : l'Upload n'est quasiment pas utilisé
d'après les graph de débit que nous avons. Constat déjà fait sur d'autres
produits Open Source : le Up n'est pas cohérent (ou alors ça vient de la
configuration du serveur web ..)



<http://speedtest.fdossena.com/>


Le 28 novembre 2017 à 08:24, Fabien H <frnog.fab...@gmail.com> a écrit :

> Le speedtest qui est derrière http://speedtest.fdossena.com/  semble
> simple et fiable effectivement, merci.
>
> Je vais l'installer sur un serveur sur notre backbone pour voir s'il est
> vraiment fiable ou pas..
>
> Fabien
>
> Le 28 novembre 2017 à 08:19, David Ponzone <david.ponz...@gmail.com> a
> écrit :
>
>> Google en donne quelques autres:
>>
>> http://openspeedtest.com
>> -> même résultat que http://speedtest.fdossena.com grosso modo
>>
>> Celui de Comcast: https://github.com/Comcast/Speed-testJS
>> -> pas testé, la version de test ne marche pas chez moi, ou elle est
>> réservée aux clients Comcast
>>
>>
>> Le 28 nov. 2017 à 01:16, Arnaud Launay a écrit :
>>
>> > Le Mon, Nov 27, 2017 at 10:28:28PM +, Michel Py a écrit:
>> >> J'ai 85 M en descendant (pas mal sur 100 surtout qu'il y a
>> >> autre chose qui tourne) mais seulement 30 M en montant. Pas si
>> >> pire a 1 kilomètres avec 200 ms de latence et 30 de gigue.
>> >
>> > Ici c'est plus proche, et un peu mieux, mais c'est pas encore ça,
>> > sur un serveur basé à Milan, Italie:
>> >
>> > 160/300 en DL
>> > 100/100 en UL
>> > 35ms de ping
>> > 3ms de gigue.
>> >
>> >   Arnaud.
>> >
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tests de débit

[Fabien H]

Ixia : https://www.ixiacom.com

?

Ixia a l'air très puissant mais pas open source ..

Pourquoi à tout prix open source : ça permet en cas de bug mineur/majeur
lié à une MAJ de version de navigateur par exemple de soumettre un patch au
développeur ..





Le 27 novembre 2017 à 19:44, Maxime Renusson  a écrit :

> Un interfaçage web d'iperf / ixia ?
> Juste mes $0.02.
>
> Max Renusson
>
>
>  On Mon, 27 Nov 2017 19:34:22 +0100 * frnog.fab...@gmail.com
>  * wrote 
>
>
> Et en parlant de test de débit, le sujet a déjà été abordé je crois :
>
> Est-ce que vous connaissez un testeur de débit :
>
> - open source
> - à lancer depuis un navigateur
> - qui est fiable au niveau des résultats de DOWN et de UP
> - installable sur un serveur du FAI
>
> ce qui permettrait de limiter beaucoup les aléas de transit et qui
> permettrait que le FAI puisse dire au client : je vous garantie que le
> débit mesuré de votre lien entre chez vous et chez nous sera juste en
> utilisant cet outil ..
>
> Le peu d'outils open source que j'ai testé ne sont pas fiables,
> généralement sur le UP ..
>
> Fabien
>
>
>
> Le 27 novembre 2017 à 19:28, Michel Py 
>
> a écrit :
>
> > > Guillaume Barrot a écrit :
> > > Entre quoi et quoi ?
> >
> > +1 et aussi +1 au billet de David. Je dirais que la vitesse promise,
> c'est
> > généralement pas plus loin que le backbone du FAI.
> > Je ferais remarquer que les speed tests (en tout cas celui dont je me
> > sers, www.speedtest.net / ookla) sont adaptifs : ils trouvent le
> serveur
> > le plus proche pour éviter les aléas du transit.
> >
> > Michel.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tests de débit

[Fabien H]

Et en parlant de test de débit,  le sujet a déjà été abordé je crois :

Est-ce que vous connaissez un testeur de débit :

- open source
- à lancer depuis un navigateur
- qui est fiable au niveau des résultats de DOWN et de UP
- installable sur un serveur du FAI

ce qui permettrait de limiter beaucoup les aléas de transit et qui
permettrait que le FAI puisse dire au client : je vous garantie que le
débit mesuré de votre lien entre chez vous et chez nous sera juste en
utilisant cet outil ..

Le peu d'outils open source que j'ai testé ne sont pas fiables,
généralement sur le UP ..

Fabien



Le 27 novembre 2017 à 19:28, Michel Py 
a écrit :

> > Guillaume Barrot a écrit :
> > Entre quoi et quoi ?
>
> +1 et aussi +1 au billet de David. Je dirais que la vitesse promise, c'est
> généralement pas plus loin que le backbone du FAI.
> Je ferais remarquer que les speed tests (en tout cas celui dont je me
> sers, www.speedtest.net / ookla) sont adaptifs : ils trouvent le serveur
> le plus proche pour éviter les aléas du transit.
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tests de débit

[Fabien H]

Le speedtest qui est derrière http://speedtest.fdossena.com/  semble simple
et fiable effectivement, merci.

Je vais l'installer sur un serveur sur notre backbone pour voir s'il est
vraiment fiable ou pas..

Fabien

Le 28 novembre 2017 à 08:19, David Ponzone  a
écrit :

> Google en donne quelques autres:
>
> http://openspeedtest.com
> -> même résultat que http://speedtest.fdossena.com grosso modo
>
> Celui de Comcast: https://github.com/Comcast/Speed-testJS
> -> pas testé, la version de test ne marche pas chez moi, ou elle est
> réservée aux clients Comcast
>
>
> Le 28 nov. 2017 à 01:16, Arnaud Launay a écrit :
>
> > Le Mon, Nov 27, 2017 at 10:28:28PM +, Michel Py a écrit:
> >> J'ai 85 M en descendant (pas mal sur 100 surtout qu'il y a
> >> autre chose qui tourne) mais seulement 30 M en montant. Pas si
> >> pire a 1 kilomètres avec 200 ms de latence et 30 de gigue.
> >
> > Ici c'est plus proche, et un peu mieux, mais c'est pas encore ça,
> > sur un serveur basé à Milan, Italie:
> >
> > 160/300 en DL
> > 100/100 en UL
> > 35ms de ping
> > 3ms de gigue.
> >
> >   Arnaud.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Craquement voix sur lien fibre

[Fabien H]

OK donc ça ne vient pas de l'IPBX.

(J'ai déjà vu sur certains architectures virtualisées des problèmes
d'horloge sur asterisk (res_timing_*))


Le 27 avril 2018 à 10:13, Sébastien 65  a écrit :

> Pas de craquement chez les autres clients, ils sont eux aussi en fibre ou
> sdsl sur le même IPBX.
>
>
> Que veux-tu dire par "problème d'horloge matérielle" (le Xivo IPBX n'est
> pas virtualisé )?
> --
>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Craquement voix sur lien fibre

[Fabien H]

Bonjour,

Comme indiqué par Mathias, même si le lien ne semble pas beaucoup
sollicité, pour de la voip, il faut mettre en place une priorisation des
paquets dans les 2 sens sur le routeur opérateur et sur le routeur client.

Fabien

Le 27 avril 2018 à 09:41, Sébastien 65  a écrit :

> @Mathias
>
> Non aucune classe ou QoS pour le moment d'active sur le routeur.
>
>
> @Dominique
>
> C'est en Centrex, lors d'appels sortant/entrants, à première vue pas de
> soucis sur l'interne...
>
>
> @ Fabien
>
> Bien sûr, j'ai remplacé un sans-fil par un poste fixe, même symptôme !!
> J'ai également changé le RJ45 uplink entre switch tél et routeur...
>
> 
> De : frnog-requ...@frnog.org  de la part de
> Dominique Rousseau 
> Envoyé : vendredi 27 avril 2018 09:32:37
> À : frnog-t...@frnog.org
> Objet : Re: [FRnOG] [TECH] Craquement voix sur lien fibre
>
> Le Fri, Apr 27, 2018 at 07:28:51AM +, Sébastien 65 [
> sebastien...@live.fr] a écrit:
> > Bonjour,
> >
> > J?ai chez un client un problème que je n?arrive pas à comprendre sur
> > la téléphonie IP? Ça me rend fou :p
> >
> > Des craquements ou des hachures sur la voix, ainsi que des coupures !
> > Le lien du client n?est absolument pas monopolisé il tourne à environ
> > 20% de la capacité.
> >
> > Le client dispose d?un lien fibre 100/100 avec une 15 de postes
> > informatique et autant de téléphone sans-fil (gigaset c530IP).
> [...]
> > Je passe à côté de quelque chose mais quoi ?
>
> Centrex ou IPBX ?
> Si IPBX, le probleme se produit aussi sur un appel "interne" ?
>
> --
> Dominique Rousseau
> Neuronnexion, Prestataire Internet & Intranet
> 6 rue des Hautes cornes - 8 Amiens
> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Craquement voix sur lien fibre

[Fabien H]

Pas de craquement chez les autres clients ?

Si pas testé ailleurs, ça peut être un problème d'horloge matérielle sur
l'IPBX (même si c'est du virtuel)

Le 27 avril 2018 à 09:55, Sébastien 65  a écrit :

> >Si je comprends bien, tu as :
> > - un reseau tel sur un switch,
> >- un reseau info sur un switch,
> > - les deux switchs sur le routeur,
> > - le routeur sur la fibre,
>
> Oui c'est bien ça
>
>
>   - l'iPBX qq part au bout de la fibre, mais on ne sait pas a quelle
>"distance" (je doute qu'il soit directement au bout de la fibre).
>
> Si il est bien au "bout de la fibre" environ 1ms... L'IPBX est sur notre
> réseau de collecte Axione
>
> 
> De : frnog-requ...@frnog.org  de la part de Paul
> Rolland (ポール・ロラン) 
> Envoyé : vendredi 27 avril 2018 09:48:08
> À : frnog@frnog.org
> Objet : Re: [FRnOG] [TECH] Craquement voix sur lien fibre
>
> Hello,
>
> On Fri, 27 Apr 2018 07:28:51 +
> Sébastien 65  wrote:
>
> > Des craquements ou des hachures sur la voix, ainsi que des coupures ! Le
> > lien du client n’est absolument pas monopolisé il tourne à environ 20% de
> > la capacité.
> >
> > Le client dispose d’un lien fibre 100/100 avec une 15 de postes
> > informatique et autant de téléphone sans-fil (gigaset c530IP).
> >
> > Le réseau téléphonique est séparé du réseau informatique ; 1 switch info
> > connecté sur le routeur et 1 switch tél connecté sur le routeur.
> >
> > J’ai changé par acquis de conscience le switch des tél (Cisco 2960) ainsi
> > que le routeur (Cisco 881).
>
> Si je comprends bien, tu as :
>  - un reseau tel sur un switch,
>  - un reseau info sur un switch,
>  - les deux switchs sur le routeur,
>  - le routeur sur la fibre,
>  - l'iPBX qq part au bout de la fibre, mais on ne sait pas a quelle
>"distance" (je doute qu'il soit directement au bout de la fibre).
>
> Du coup, je ferai bien differents tests :
>  - en debranchant le reseau info, voire meme de nuit ou de WE, pour etre
>sur que le reseau n'est pas charge,
>  - entre deux postes locaux, mais je suppose que ca va faire un A/R sur la
>fibre, ca permettra neanmoins de savoir si c'est dans le perimetre local
>
> Paul
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

[Fabien H]

L'APNF est une asso aussi :-) Je trouve qu'elle répondrait au besoin sur
l'aspect "traduction de numéro". Il faudrait ensuite trouver un système
simple et sécurisé (filtrage IP, ..) pour que les différents petits/grands
opérateurs s'interconnectent en SIP entre eux (sur le même principe que
peering@operateur pour initier un "peering SIP"). Chacun est libre ensuite
au niveau IP d'ajouter la redondance et le transport L2 qu'il souhaite.

Le prix de l'adhesion APNF de base n'est pas énorme pour un petit
opérateur.

Mais pour avoir accès à la base APNF pour interroger sur un ND donné ou
pour aller faire des annonces (donc en écriture) dans cette base, c'est
beaucoup plus cher. Et là c'est un autre aspect où cela peut coincer.. Mais
à un moment donné, il faut bien financer aussi l'asso qui héberge la base
de données (ou alors il faut décentraliser)



Le 15 mai 2018 à 10:51, boite frnog  a écrit :

> J'entends bien... Mais je pensais à quelque chose de plus simple. Il faut
> bien que tu saches si tu envoies ton appel à ton transitaire, ou si tu
> envoies ton appel à ton SBC de peering SIP depuis ton SBC.
>
> Ce qui implique que finalement (et je vais sans doute en choquer plus d'un
> sur cette liste) tu t'en moques de la base APNF, puisque soit tu check
> d'abord la base de la supposée asso et si ton SDA de destination n'est pas
> dedans, tu envoies à ton transitaire voix.
>
>
> Le 15 mai 2018 à 10:41, Alain Bieuzent  a écrit :
>
> > La base de données existe déjà et elle est gérée par l'APNF. Elle permet
> > de savoir à un instant T vers quel opérateur doit ont routé un SDA.
> >
> > Le 15/05/2018 10:25, « boite frnog »  > mailbox.fr...@gmail.com> a écrit :
> >
> > Bonjour à tous,
> >
> > Je me permets de créer un nouveau sujet. En effet, je pense que
> Xavier
> > a
> > raison, il est temps de faire bouger les choses. La crise d'hier est
> > critique sur plein de plans, combien d'appels d'urgence n'ont pas été
> > routés hier ? Mais sans aller aussi loin, c'est vrai que ça n'a pas
> > évolué
> > depuis un bout de temps...
> >
> > J'ai cependant plusieurs questions à la liste.
> >
> > Pourquoi ne pas faire du peering SIP, suivant le modèle du France XI
> > (un
> > France SIPIX ?) ? Est-ce que cette question a déjà été soulevée et si
> > oui
> > quels ont été les freins ?
> >
> > Par modèle j'entends à la fois technique, mais aussi associatif.
> >
> > C'est à dire un SBC centralisé joignable en interco IP sur TH2
> > permettant
> > le routage entre opérateurs, mais aussi la proxyfication du RTP et
> > pourquoi
> > pas un nouveau modèle de billing.
> >
> > DNS a été soulevé, c'est bien, mais quand bien même il inutile
> > d'imaginer
> > résoudre et faire du P2P entre les SBC des "petits opérateurs" pour
> > pleins
> > de raisons (notamment sécu, qualité de l'interco)...
> >
> > Mais alors, comment échanger (annoncer) ses tranches SDA ? Je ne
> > connais
> > pas SIP-I mais je ne crois pas qu'une notion d'annonce existe...
> >
> > Faudrait-il créer ce protocole (vecteurs) ? Après tout, les solutions
> > opensource sont là.
> >
> > Mais beaucoup plus simplement, est-ce qu’une base de données gérée
> par
> > un
> > tiers de confiance (l'asso) ne suffirait-elle pas à redistribué à ses
> > membres les tranches connues par ce service ?
> >
> > Charge aux opérateurs de monter ce second trunk et d'envoyer son
> trafic
> > selon ses routes mises à jour dynamiquement sur son SBC...
> >
> > Non ?
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
> >
> >
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

[Fabien H]

Effectivement, on va arrêter de polluer la liste mais une dernière chose :

sans vouloir faire le pessimiste, il y'a quand même 2 gros freins pour ce
projet qui ont été évoqués :

- Le fait que s'il n'y a pas de gros dans le projet, le trafic échangé sera
négligeable, donc le gain négligeable
- Le fait qu'il faut des interco de qualité pour la voix avec des liens
d'interco garantis et de qualité (+ QOS, ..) et cela ça a un cout, qui sera
à multiplier par le nombre d'opérateurs dans le projet. Et du coup, la
viabilité purement financière sera surement limite, voire au final cela
coutera cher, par rapport à terminer chez son fournisseur de terminaison
habituel (Orange ou autre), sur lequel on a investit au niveau interco, et
qui lui garantit "normalement" le transport dans des conditions
excellentes.
Sinon solution best effort, on peut toujours passer par le transit "par
défaut", mais sur le long terme, on n'est jamais à l'abri d'un problème de
qualité de voix, et c'est je pense ce que la plupart ici ne veulent pas.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

[Fabien H]

L'histoire du DNS, oui c'est intéressant mais il faut que le DNS soit privé
ou filtré pour éviter de divulger des informations qui pourraient mettre en
péril la "securité nationale".

Oui, comme le FranceIX finalement. Un AS, des équipements à TH2, et tout le
> monde se rejoint à la meetme. Donc finalement au niveau IP avons-nous
> besoin de tout cela, le FranceIX le fait très bien ? Peut-être qu'il soit
> pleinement séparé de la data ? Ce n’est pas idiot non plus...
>
Sur le principe de faire un meetme de type FranceIX oui, par contre faire
passer du SIP ou du flux RTP via un GIX, c'est assez moyen ..



> Pour faire simple (je vulgarise beaucoup), Fabien , Alain, demain on se
> dit on met un serveur SIP (un peu un route-serveur finalement) à TH2, on
> monte chacun nos Trunk vers ce serveur, et comme on se connait bien et
> qu'on a confiance entre nous on s'échange par mail nos SDA, charge à chacun
> de mettre à jour ses routes. Sur le papier rien de compliqué... Faut juste
> un peu automatiser les choses, avoir un garant de confiance, et on n'embête
> personne...
>

A la limite, oui la signalisation pourrait être centralisée et passer par
un ou deux proxy SIP d'une asso, et ensuite la SIG initie/reinvite le RTP
entre l'operateur A et B via leurs IP d'interco sans repasser par le proxy
SIP central .

Mais cela fait malgré tout un SPOF sur la signalisation. Alors que si
chaque opérateur maintient quotidiennement sa base de SDA à jour localement
(via un système de batch) et ses interco réseau+voix avec les autres
opérateurs, il n'y a plus de SPOF, chaque opérateur reste maitre de son
infra. (ça ressemble quand même beaucoup au système APNF actuel .. :-) )

Donc au final, c'est juste une histoire de base de routage de numéro
décentralisée chez chaque opérateur (avec système de MAJ) + interco voix
entre chaque opérateur interessé.

Mais effectivement comme indique "boite frnog", le projet sera/serait
surement tué dans l'oeuf faute de gros souhaitant rentrer et donc peu
d'intérêt pour les petits

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Redondance automatique routeur pour lien opérateur niveau 2

[Fabien H]

Bonjour,

Nous avons de manière classique une porte avec un fournisseur qui nous
fournit un lien niveau 2 par client (1 VLAN).

Nous cherchons un moyen d'assurer une redondance au niveau 3 : routeur.

1) L'idéal sur les liens avec IP publique serait d'avoir 3 IP publiques :

- 1 IP pub sur le routeur client
- 1 IP pub sur le routeur coeur de réseau 1
- 1 IP pub sur le routeur coeur de réseau 2

Mais ça fait un masque en /29 consommé donc 6 IP publiques .. impossible !

Donc on utilise un /31, c'est mieux pour la consommation d'IP !

2) VRRP

Ca me parait mal adapté pour un routeur coeur de réseau ..

3) Déclarer toutes les interfaces Dot1Q en double sur un autre routeur
coeur de réseau sur un port shutdown. En cas de défaillance du routeur
principal, on a juste à faire un no shutdown sur le port et les sub
interfaces passent aussi en no shut ?

Avez-vous d'autres idées, notamment sur l'aspect automatique ?

Merci,
Bonne journée,

Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Redondance automatique routeur pour lien opérateur niveau 2

[Fabien H]

Je voyais plutôt une offre équivalente à CELAN mais je me suis peut-être
mal exprimé ..!

Oui intéressant le PPPoE, mais ça ne rajoute pas de l'encapsulation ?


Le 8 juin 2018 à 09:37, David Ponzone  a écrit :

> Tu parles d’une offre C2E ou équivalent donc.
>
> La solution propre (quoique certains vont dire que non), c’est de monter
> du PPPoE depuis le routeur client.
> Un /32 par PPPoE, y a pas mieux.
> Tu dois monter 2 PPPoE, 1 vers chaque PE, donc il faut les différencier.
> Pour ça je vois 2 moyens:
> -évident: sur ton routeur client, tu montes 2 sous-interfaces QinQ (si tu
> peux) et tu montes un PPPoE par VLAN QinQ, et chaque PE termine chaque QinQ
> -moins évident: tu restes sur ton VLAN unique qui peut atteindre les 2 PE,
> et tu utilises le service-name du PPPoE pour faire en sorte que ton routeur
> client envoie un PADI pour le bon PE. Jamais fait mais en théorie, c’est
> fait pour ça :)
>
> > Le 8 juin 2018 à 09:26, Fabien H  a écrit :
> >
> > Bonjour,
> >
> > Nous avons de manière classique une porte avec un fournisseur qui nous
> > fournit un lien niveau 2 par client (1 VLAN).
> >
> > Nous cherchons un moyen d'assurer une redondance au niveau 3 : routeur.
> >
> > 1) L'idéal sur les liens avec IP publique serait d'avoir 3 IP publiques :
> >
> > - 1 IP pub sur le routeur client
> > - 1 IP pub sur le routeur coeur de réseau 1
> > - 1 IP pub sur le routeur coeur de réseau 2
> >
> > Mais ça fait un masque en /29 consommé donc 6 IP publiques .. impossible
> !
> >
> > Donc on utilise un /31, c'est mieux pour la consommation d'IP !
> >
> > 2) VRRP
> >
> > Ca me parait mal adapté pour un routeur coeur de réseau ..
> >
> > 3) Déclarer toutes les interfaces Dot1Q en double sur un autre routeur
> > coeur de réseau sur un port shutdown. En cas de défaillance du routeur
> > principal, on a juste à faire un no shutdown sur le port et les sub
> > interfaces passent aussi en no shut ?
> >
> > Avez-vous d'autres idées, notamment sur l'aspect automatique ?
> >
> > Merci,
> > Bonne journée,
> >
> > Fabien
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Redondance automatique routeur pour lien opérateur niveau 2

[Fabien H]

Oui c'est quand même séduisant ton truc, je vais me pencher dessus pour
voir .

Merci !



Le 8 juin 2018 à 10:27, David Ponzone  a écrit :

> Oui pardon, c’est ton histoire de 2 PE qui m’a fourvoyé, je pensais que tu
> avais 2 collectes.
>
> Pareil en CELAN.
> Même plus simple car comme c’est pas le CPE qui met le premier tag, tu as
> juste à faire du dot1q sur Eth0  (tous les CPE savent pas faire du QinQ),
> et tu vas te retrouver avec les QinQ côté PE (qui savent le gérer ou alors
> jette les).
>
> Oui encapsulation, mais bon, ça marche, ça bloque rien si tu fais gaffe,
> et l’ensemble du parc ADSL et une grande partie du parc FTTH fonctionne
> comme ça depuis des années.
> Je dis pas que c’est moderne et que c’est ce que je préfère, mais ça
> marche, ça gère le fail-over en évitant BGP/IP SLA/autre saloperie (pas
> taper), ça limite l’utilisation des tes IP à un /32 par connexion.
>
>
>
> Le 8 juin 2018 à 10:18, Fabien H  a écrit :
>
> Je voyais plutôt une offre équivalente à CELAN mais je me suis peut-être
> mal exprimé ..!
>
> Oui intéressant le PPPoE, mais ça ne rajoute pas de l'encapsulation ?
>
>
> Le 8 juin 2018 à 09:37, David Ponzone  a écrit :
>
> Tu parles d’une offre C2E ou équivalent donc.
>
> La solution propre (quoique certains vont dire que non), c’est de monter
> du PPPoE depuis le routeur client.
> Un /32 par PPPoE, y a pas mieux.
> Tu dois monter 2 PPPoE, 1 vers chaque PE, donc il faut les différencier.
> Pour ça je vois 2 moyens:
> -évident: sur ton routeur client, tu montes 2 sous-interfaces QinQ (si tu
> peux) et tu montes un PPPoE par VLAN QinQ, et chaque PE termine chaque QinQ
> -moins évident: tu restes sur ton VLAN unique qui peut atteindre les 2 PE,
> et tu utilises le service-name du PPPoE pour faire en sorte que ton routeur
> client envoie un PADI pour le bon PE. Jamais fait mais en théorie, c’est
> fait pour ça :)
>
> Le 8 juin 2018 à 09:26, Fabien H  a écrit :
>
> Bonjour,
>
> Nous avons de manière classique une porte avec un fournisseur qui nous
> fournit un lien niveau 2 par client (1 VLAN).
>
> Nous cherchons un moyen d'assurer une redondance au niveau 3 : routeur.
>
> 1) L'idéal sur les liens avec IP publique serait d'avoir 3 IP publiques :
>
> - 1 IP pub sur le routeur client
> - 1 IP pub sur le routeur coeur de réseau 1
> - 1 IP pub sur le routeur coeur de réseau 2
>
> Mais ça fait un masque en /29 consommé donc 6 IP publiques .. impossible
>
> !
>
>
> Donc on utilise un /31, c'est mieux pour la consommation d'IP !
>
> 2) VRRP
>
> Ca me parait mal adapté pour un routeur coeur de réseau ..
>
> 3) Déclarer toutes les interfaces Dot1Q en double sur un autre routeur
> coeur de réseau sur un port shutdown. En cas de défaillance du routeur
> principal, on a juste à faire un no shutdown sur le port et les sub
> interfaces passent aussi en no shut ?
>
> Avez-vous d'autres idées, notamment sur l'aspect automatique ?
>
> Merci,
> Bonne journée,
>
> Fabien
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Redondance automatique routeur pour lien opérateur niveau 2

[Fabien H]

Oui, c'est du CISCO 1841 la plupart du temps.


Le 8 juin 2018 à 09:44, Pierre LANCASTRE  a
écrit :

> Bonjour,
>
> Première question : vous fournissez le cpe ? si oui, quel modèle ?
>
> Pierre
>
>
> Le ven. 8 juin 2018 à 09:38, David Ponzone  a
> écrit :
>
>> Tu parles d’une offre C2E ou équivalent donc.
>>
>> La solution propre (quoique certains vont dire que non), c’est de monter
>> du PPPoE depuis le routeur client.
>> Un /32 par PPPoE, y a pas mieux.
>> Tu dois monter 2 PPPoE, 1 vers chaque PE, donc il faut les différencier.
>> Pour ça je vois 2 moyens:
>> -évident: sur ton routeur client, tu montes 2 sous-interfaces QinQ (si tu
>> peux) et tu montes un PPPoE par VLAN QinQ, et chaque PE termine chaque QinQ
>> -moins évident: tu restes sur ton VLAN unique qui peut atteindre les 2
>> PE, et tu utilises le service-name du PPPoE pour faire en sorte que ton
>> routeur client envoie un PADI pour le bon PE. Jamais fait mais en théorie,
>> c’est fait pour ça :)
>>
>> > Le 8 juin 2018 à 09:26, Fabien H  a écrit :
>> >
>> > Bonjour,
>> >
>> > Nous avons de manière classique une porte avec un fournisseur qui nous
>> > fournit un lien niveau 2 par client (1 VLAN).
>> >
>> > Nous cherchons un moyen d'assurer une redondance au niveau 3 : routeur.
>> >
>> > 1) L'idéal sur les liens avec IP publique serait d'avoir 3 IP publiques
>> :
>> >
>> > - 1 IP pub sur le routeur client
>> > - 1 IP pub sur le routeur coeur de réseau 1
>> > - 1 IP pub sur le routeur coeur de réseau 2
>> >
>> > Mais ça fait un masque en /29 consommé donc 6 IP publiques ..
>> impossible !
>> >
>> > Donc on utilise un /31, c'est mieux pour la consommation d'IP !
>> >
>> > 2) VRRP
>> >
>> > Ca me parait mal adapté pour un routeur coeur de réseau ..
>> >
>> > 3) Déclarer toutes les interfaces Dot1Q en double sur un autre routeur
>> > coeur de réseau sur un port shutdown. En cas de défaillance du routeur
>> > principal, on a juste à faire un no shutdown sur le port et les sub
>> > interfaces passent aussi en no shut ?
>> >
>> > Avez-vous d'autres idées, notamment sur l'aspect automatique ?
>> >
>> > Merci,
>> > Bonne journée,
>> >
>> > Fabien
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [ALERT] Fort trafic UDP IN provenant de transit/GIX

[Fabien H]

Bonsoir,

est-ce que vous constatez des pics trafic UDP anormalement elevé cet
après-midi : 2 pics vers 16H30 et 17H30 dans le sens transit vers clients ?

En regardant un peu sur les différentes statistiques sur internet, ça
semble généralisé.

A priori beaucoup de port 53, mais pas que .. Donc surement un Ddos mais
provoqué par quoi ??

Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Fort trafic UDP IN provenant de transit/GIX

[Fabien H]

Ah oui, tout à fait, même chute vers 16h45-17h, ça correspond effectivement
au match, je n'y avais pas pensé !



Le 26 juin 2018 à 21:40, Radu-Adrian Feurdean <
fr...@radu-adrian.feurdean.net> a écrit :

> On Tue, Jun 26, 2018, at 18:17, Fabien H wrote:
> > est-ce que vous constatez des pics trafic UDP anormalement elevé cet
> > après-midi : 2 pics vers 16H30 et 17H30 dans le sens transit vers
> clients ?
>
> Je ne sais pas si c'etait du UDP, mais on a bien eu une bonne montee en
> traffic dans les deux directions en provenance/direction des principaux FAI
> francais entre ~16h00 et ~17h50, avec une petite "chute" vers 16h45-17h00.
>
> Comme le phenomene etait present sur les liens pro/entreprise (beaucoup)
> plus que sur les liens GP, on suspecte un/des player(s) TV type Molotov ou
> MyTF1 qui fonctionneraient (aussi) en mode P2P - des gens qui regardent le
> match au bureau.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RE: Craquement voix sur lien fibre

[Fabien H]

Aucun souci sur de l' ESXI depuis de nombreuses années. Attention malgré
tout aux ressource partagées malgré tout, surtout le stockage.


> Pour ma part j'utilise du Asterisk et du Xivo/Wazo, peut être que demain
> cela sera installé sur un cluster type Proxmox... Dois-je m'attendre à des
> problèmes ?
>
> 
> De : Michel Py 
> Envoyé : dimanche 29 avril 2018 21:52:18
> À : 'Cedric Millet (pro)'; Sébastien 65
> Cc : frnog-t...@frnog.org
> Objet : RE: [FRnOG] [TECH] RE: Craquement voix sur lien fibre
>
> >> Michel Py a écrit :
> >> A propos de ce problème, est-ce que quelqu'un ici a déjà installé ce
> produit ?
> >> http://amfeltec.com/products/x1-pci-express-system-timer-2/
>
> > Cedric Millet a écrit :
> > @ Michel : non je ne connais pas cette carte mais ils ne sont pas très
> loquaces sur les
> > détails des composants  qu'elle embarquent ; ou alors je n'ai pas vu
> dans les docs joints.
>
> Je me demande si çà sert à quelque avec Asterisk dans un environnement
> entièrement IP.
> Sur du PC relativement récent qui a HPET activé dans le BIOS, j'ai jamais
> eu de problème.
>
> Avec une partie TDM (j'ai des Digium TE420) le clocking pour les PRI est
> fourni par la carte.
>
>
> Seb, un truc a essayer mais çà serait chez ton fournisseur de tronc SIP çà
> serait d'avoir une carte T1/E1 dans le serveur et d'avoir DAHDI chargé même
> si le PRI n'est pas utilisé. Avec les versions récentes d'Asterisk sous
> Linux quand DAHDI est chargé je pense qu'il utilise le clocking fourni par
> la carte.
>
> Ceci étant dit, ayant lu le fil, je pense pas que c'est un problème de
> clocking. Tu peux avoir l'utilisation CPU du serveur qui fournit le tronc
> SIP ?
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Modem 4G/LTE multi sim

[Fabien H]

Bonjour,

nous sommes à la recherche d'un modem 3G/4G de type professionnel, avec
port Ethernet, si possible multi-sim. Bien entendu, il faut qu'il soit
stable au niveau connexion 3G/4G.

L'idée est de brancher ce modem à notre routeur client de type CISCO 18XX.

Avez-vous des exemples que vous utilisez et qui donnent satisfaction ?

Merci,
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Modem 4G/LTE multi sim

[Fabien H]

Un grand merci pour toutes vos réponses en moins de 20 minutes ;-)

Pour le C899G-LTE-GA-K9, on avait vu, mais on a un stock de Cisco 18XX en
reconditionné, donc on voulait garder la même base de routeur, et adjoindre
la fonction 4G. Mais pourquoi pas, et comme c'est de l'IOS, on ne sera pas
dépaysé ..

Pour le reste, le RUT950 semble répondre exactement au besoin !

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] FAX dématérialisés

[Fabien H]

Nous proposons le service d'envoi de fax à nos clients. Ca marche
relativement bien sur un système d'envoi à base d'Asterisk avec les
caractéristiques suivantes :

Interco Orange
G711A
9600 Bauds forcés
ECM activé au 1er essai (ça juste marche), désactivé au 2eme essai au cas ou


(pas de T38 : On a essayé dans le passé avec certains opérateurs T38, mais
on a l'impression que le support T38 était buggé soit sur Asterisk, soit
sur la GW de l'opérateur T38 car certains fax vers certains destinataires
précis (avec des fax de 1980) passaient très bien en G711 mais jamais en
T38. Du coup on a arreté)

On n'a pas de plaintes sur les échecs d'envoi (je ne m'en souviens plus
donc c'est bon signe). En cas d'échec au bout de X essais, on indique bien
la cause de l'échec : Ligne occupée, Impossible de joindre le numéro,..




Le mer. 5 sept. 2018 à 14:40, Richard Klein  a
écrit :

> >Pour le 1 : Aucune idée, ça va dépendre des tribunaux (TGI) et autres.
> Tu peux regarder sur le site de l'ARCEP qui te donne un indice sur
> l'operateur :
>  https://www.arcep.fr/index.php?id=interactivenumeros
> et c'est un indice car le client peux avoir effectué une porta vers un
> autre opérateur.
>
> >Le fax, c’est la merde.
> Heu non ... comme expliqué si effectivement les faxs passent par des trunks
> SIP avec de la compression cela ne va pas aider.
> Après lorsque tu connais les fax et que tu as participé au lancement des
> premier modems 56K sur chipset Rockwell et Lucent 1643 je peux affirmer que
> c'est de la merde lorsque l'ICC a mal configuré le modem fax de sa machine
> !
> Dans les années 2000 j'avais conçu une passerelle GSM en 2G avec une
> interface analogique  (FXS) et pour éprouver le produit (pondeuse d'appels)
> j'avais connecté un modem/fax pour tests.
> Et oui en mode par defaut les faxs étaient tous en echec. Par contre les
> modulations et protocoles fax sont suffisamment robuste car il est possible
> de brider la vitesse a 2400Bds et de jouer sur l'ECM
> Et la quasiment plus de problèmes.
>
> et les fax qui sont en occupation a longueur de journée cela existe et
> entre dans les stats d'echec.
>
> Richard
>
>
> Le mer. 5 sept. 2018 à 14:11, babounx baboun  a écrit :
>
> > Hello Richard.
> >
> > Pour le 1 : Aucune idée, ça va dépendre des tribunaux (TGI) et autres.
> > 2 ) La plus part du temps c'est un problème de baud mais pas toujours.
> 'Status
> > : Failure to train at 2400 bps or +FMINSP value ; Giving up after 3
> > attempts to send same page'
> >
> > Le mer. 5 sept. 2018 à 11:51, Richard Klein  a
> > écrit :
> >
> >> Bonjour,
> >>
> >> 1) Il serait intéressant de savoir chez qui sont les destinataires
> >> (opérateurs) ?
> >> 2 ) C'est quoi un problème d'envoi ?
> >>l'appel n'arrive pas au destinataire (aboutissement)
> >>Ou il y a des problème de qualité ? (fax tronqué, lignes noir ...)
> >>
> >> Richard
> >>
> >>
> >> Le mer. 5 sept. 2018 à 11:43, babounx baboun  a
> >> écrit :
> >>
> >>> Bonjour,
> >>>
> >>> Nous utilisons aujourd'hui le service d'OVH concernant les fax
> >>> dématérialisés.
> >>> Nous avons beaucoup de problème d'envoi vers certains TGI ou parquets.
> >>> Retour d'un utilisateur -> "sur l'envoi et de réception de télécopies
> >>> adressées par Ecofax à 24 parquets font ressortir que 14 d'entre elles
> ne
> >>> sont pas reçues."
> >>> Le ticket OVH concernant ces envois à presque 1 ans sans aucun
> avancement
> >>> sur la résolution. Malgré plusieurs relances et tests...
> >>> Le blabla habituel : Information envoyée aux techniciens nous revenons
> >>> vers
> >>> vous etc...
> >>>
> >>> Nous essayons de passer par d'autres moyens mais certaines
> >>> administrations
> >>> restent encore sur le FAX :(
> >>>
> >>> J'aimerais savoir si certains de la liste on le même problème d'envoi
> >>> vers
> >>> les tribunaux ou parquets avec ou sans OVH.
> >>>
> >>> J'aimerais aussi trouver / avoir un retour d'expérience sur d'autres
> >>> fournisseurs de ce service. Car j'imagine qu'il est compliqué de tester
> >>> chez certains ;)
> >>>
> >>>
> >>> Merci pour vos retour.
> >>>
> >>> Bab
> >>>
> >>> ---
> >>> Liste de diffusion du FRnOG
> >>> http://www.frnog.org/
> >>>
> >>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Slack down....

[Fabien H]

Bonjour,

question con : quelle est la valeur ajoutée de slack par rapport un IRC ou
un XMPP ?

J'ai vu qu'il y'avait de la gestion de projet entre membres, donc surement
avec une timeline, et des évenements, ajout de pièce jointe, .. mais j'ai
du mal à décrocher d'une messagerie classique email + serveur de partage de
fichiers ..



Le mar. 11 sept. 2018 à 11:27, Samuel Gaiani-Porquet <
samuel.gaiani-porq...@infiniteconnection.fr> a écrit :

> Bonjour à tous,
>
> Ce que toute cette histoire veut à nouveau dire, vu les crises que je
> vois sur twitter et le nombre de personne qui hurle, c'est qu'un paquet
> de gens ont mis leurs éléments critiques de comm' et collaboration dans
> un unique panier externalisé, sans prévoir de mode dégradé en local, via
> un IRC, un bon vieux serveur XMPP ou autres.
>
> Si quelque chose est ultra critique, il vaut mieux essayer de prévoir le
> mode dégradé/backup, sauf peut être quand des problématiques économiques
> rentrent en jeu, ce que je peux comprendre.
>
> Mattermost, il y a une offre SaaS et une possibilité de faire du high
> availability cluster non? Avec un noeud en local et un noeud à distance?
>
> Rapatrié un peu de technique en interne ne fait jamais de mal, AMHA.
>
>
> Sam
>
> On 11/09/2018 10:47, Bruno Pagani wrote:
>
> > Le 11/09/2018 à 10:24, Wallace a écrit :
> >> Le 11/09/2018 à 10:13, Hugues Voiturier a écrit :
> >>> … ainsi que les trolls qui te disent que IRC c’est franchement mieux :)
> >>>
> >>> Mattermost, j’eu utilisé, ça ne m’a pas convaincu face à Slack. Si
> quelqu’un a des alternatives, idéalement auto-hébergées, je suis preneur :p
> >> Pour avoir eu des stagiaires à fond sur Slack et qui jouent avec les
> >> api, ils découvraient notre Mattermost et ils ont pas vu de différence.
> >> Ils ont même pu importer leur thème de couleurs et avaient donc un Slack
> >> tout pareil sauf le bot slack.
> >>
> >> Niveau autohébergement c'est top, un binaire à déposer, un service à
> >> lancer, la conf sql et roule, mise à jour super facile c'est top.
> >>
> >> Pour nous c'est un bon compromis entre les vieux comme moi qui préfèrent
> >> IRC et les jeunes.
> >
> > On peut d’ailleurs mettre en place des passerelles Mattermost/IRC (ou
> > Slack/IRC) par exemple. Soit plus ou moins directement via Matterbridge,
> > soit en passant par Matrix ou l’intégration est un peu plus propre dans
> > ce cas de figure.
> >
> >
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Question BGP IX

[Fabien H]

Bonjour,

la question est de savoir ce que tu veux y gagner ?

Pouvoir peerer en direct avec certains partenaires ?
Economiser des frais de transit vers/depuis certains peers ? (à calculer)
autres ... ?

Fabien



Le 18 avril 2018 à 15:15, Seb  a écrit :

> Bonjour la liste,
>
> Nous avons, depuis peu, notre propre numéro d'AS (IPv4 /22 + IPv6/48)
> multi-home sur notre site (donc pas dans un Datacenter).
>
> On souhaite augmenter la capacité de notre connexion vers un de
> fournisseurs qui nous donne accès (Colt dans ce cas 300Mbps->1Gbps).
>
> Et du coup je me demandais si il y avait un intérêt (pour un petit client
> comme nous avec un seul AS et dans le future 2x 1Gbps) a se "connecter" à
> un IX genre France-IX ou dans notre cas BNIX ? est-ce que ce genre de chose
> est plutôt réservé a de plus gros profile ? est-ce que c'est simplement
> hyper compliqué et déconseillé ?
>
> Dans ma tête la convergence serait plus rapide vu que connecté directement
> à un IX, mais bon c'est peut être juste une mauvaise idée (pas frapper trop
> vite le noob svp :) )
>
> Merci d'avance pour vos réponses
>
> Sébastien
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] SFP+ Solid Optics vs Sandstone

[Fabien H]

Bonjour Quentin,

merci pour ce retour précis !

Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] SFP+ Solid Optics vs Sandstone

[Fabien H]

Bonjour,

nous souhaitons nous équiper en SFP+ 10G monomode pour du SW Cisco. On a eu
de bons échos sur Solid Optics.

Est-ce que certains d'entre vous utilisent du Sandstone ? Si oui, en êtes
vous contents ?

PS: On cherche aussi du SFP+ 10G Cuivre, et pour l'instant on n'a pas trop
d'idée..

Merci !
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Panne Porte CELAN dans le Var

[Fabien H]

Ah OK, le concept est puissant !

Et le forfait RSC est cher par curiosité ?

Le mar. 16 oct. 2018 à 09:42, Jerome SCHEVINGT 
a écrit :

> Le 16/10/2018 à 09:35, Fabien H a écrit :
> > Forfait RSC et option GTR S1 sur la porte CELAN, c'est la même chose ?
>
>
> Non, ce n'est pas la meme chose. Le RSC va être sur ton compte client
> pas sur un lien précis.
>
> Tu peux avoir une GTR S1 sur la porte CELAN mais devoir passer par une
> boite
> générique pour demander les escalades.
>
>
>
>
>
>
> >
> > Le mar. 16 oct. 2018 à 09:03, Jerome SCHEVINGT <
> jerome...@phibee-telecom.net>
> > a écrit :
> >
> >>
> >> Si tu paye le forfait RSC, tu as les interlocuteur pour escalader.
> >>
> >> jerome
> >>
> >> Le 16/10/2018 à 08:05, Laurent Ducassou a écrit :
> >>> Hey,
> >>>
> >>> Longue = supérieur à 4H après déclenchement ticket Orange? :/
> >>>
> >>> C'est vrai que maintenant on n'a plus personne pour escalader sauf le
> >>> mail générique de wholesale adv (qui regarde les mail parfois...) et le
> >>> CSC qui n'est pas une escalade...
> >>>
> >>> Laurent
> >>>
> >>>
> >>> Le 15/10/2018 à 21:06, Bruno VELUET a écrit :
> >>>> Bonsoir la liste,
> >>>>
> >>>> nous rencontrons une longue panne de porte CELAN sur Toulon (Var)
> >> depuis ce matin,
> >>>> toujours pas de rétablissement sur une porte, et sans communication,
> >> c’est très difficile de dialoguer avec les clients.
> >>>> Quelqu’un d’autre d’impacté sur la liste ?
> >>>>
> >>>>
> >>>> Bruno Veluet - Leonix Telecom - AS50628
> >>>> ---
> >>>> Liste de diffusion du FRnOG
> >>>> http://www.frnog.org/
> >>> ---
> >>> Liste de diffusion du FRnOG
> >>> http://www.frnog.org/
> >>>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Panne Porte CELAN dans le Var

[Fabien H]

Forfait RSC et option GTR S1 sur la porte CELAN, c'est la même chose ?

Le mar. 16 oct. 2018 à 09:03, Jerome SCHEVINGT 
a écrit :

>
>
> Si tu paye le forfait RSC, tu as les interlocuteur pour escalader.
>
> jerome
>
> Le 16/10/2018 à 08:05, Laurent Ducassou a écrit :
> > Hey,
> >
> > Longue = supérieur à 4H après déclenchement ticket Orange? :/
> >
> > C'est vrai que maintenant on n'a plus personne pour escalader sauf le
> > mail générique de wholesale adv (qui regarde les mail parfois...) et le
> > CSC qui n'est pas une escalade...
> >
> > Laurent
> >
> >
> > Le 15/10/2018 à 21:06, Bruno VELUET a écrit :
> >> Bonsoir la liste,
> >>
> >> nous rencontrons une longue panne de porte CELAN sur Toulon (Var)
> depuis ce matin,
> >> toujours pas de rétablissement sur une porte, et sans communication,
> c’est très difficile de dialoguer avec les clients.
> >>
> >> Quelqu’un d’autre d’impacté sur la liste ?
> >>
> >>
> >> Bruno Veluet - Leonix Telecom - AS50628
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Technicolor, enfin la fin ?

[Fabien H]

Bonjour,
nous utilisons du Cisco RV 132W.

C'est très limité car c'est du Cisco Small Business mais ça fonctionne. Le
SNMP existe mais je ne crois pas avoir réussi à le faire fonctionner sur le
WAN. Je n'ai pas creusé..



Le lun. 1 avr. 2019 à 11:23, Olivier Lange  a écrit :

> C'est ce que j'ai pensé aussi... Et la, je pense que je vais tester un
> Netgear DM200, et lui changer son firmware pour passer en OpenWRT:
> https://openwrt.org/toh/netgear/dm200
>
> Je voulais mettre un tp-link, mais j'ai eu une fin de non recevoir
> parce que "ca fait pas pro" ! Mais ca risque de se terminer comme
> ca...
>
> Olivier
>
> Le lun. 1 avr. 2019 à 11:18, David Ponzone  a
> écrit :
> >
> > Rien trouvé d’autre pour le moment.
> > Je voulais tester le tp-link à moins de 30€ parce que tant qu’à mettre
> un truc pourri, autant qu’il coûte moins cher.
> > Ca va clairement devenir compliqué.
> > A mon avis, il va falloir oublier les velléités de
> supervision/monitoring pour commencer.
> > L’avantage avec un Mikrotik derrière, c’est que tu peux éventuellement
> scripter la récupération d’infos sur le modem, ou le reboot automatique
> conditionnel.
> >
> > > Le 1 avr. 2019 à 10:54, Olivier Lange  a écrit :
> > >
> > > Hello,
> > >
> > > Je me permets de remonter le post (désolé si c'était préférable que
> > > j'en crée un autre, pas taper!).
> > >
> > > Je cherche à remplacer mes TG588, vu qu'ils sont en rupture de stock
> > > partout... Vous mettez quoi comme modem a/vDSL basique? Au final, j'ai
> > > besoins d'aucunes fonctions avancée ou autre, on les mets derrière un
> > > Mikrotik, soit en routeur simple (donc juste pour monter un pppoe et
> > > une interco avec le mikrotik), soit en bridge (qui va etre la conf par
> > > défaut).
> > >
> > > J'ai besoin:
> > > - de pouvoir les configurer facilement via une cli (ssh/telnet) voir
> > > un fichier de backup à importer
> > > - de remonter en snmp les informations de synchronisation (idéalement
> > > aussi quand je suis en bridge)
> > > - et... Ben c'est tout en fait!
> > >
> > > Je trouve rien qui me satisfasse... Je test un Zyxel VMG1312-B10 mais
> > > c'est une catastrophe au niveau de la cli, on arrive pas a tout faire,
> > > voir tout n'est peut être pas documenté.
> > >
> > > Y a vraiment rien comme matériel pas cher, basique? Y a le smartMG
> > > SR501 https://www.smartrg.com/sr501 qui me semble pas mal sur le
> > > papier, mais impossible de savoir ou le trouver en France ni à quel
> > > prix... TP-Link, ca fait un peu cheap... Cisco, à 200€ le modem, c'est
> > > compliqué... J'ai vu passé le planet VDR-301N dans le post, mais je
> > > vois pas ou le trouver sur France (un fournisseur) ?
> > >
> > > Bref, certains d'entre vous n'auraient pas des pistes sérieuses à
> > > proposer sur un équipement autour de 50-70€ HT qui fasse l'affaire et
> > > soit provisionnable facilement?
> > >
> > > Merci.
> > > Olivier
> > >
> > > Le lun. 5 nov. 2018 à 15:45, BASSAGET Cédric
> > >  a écrit :
> > >>
> > >> Merci pour l'info, je connaissais pas ce constructeur.
> > >> Cédric
> > >>
> > >> Le ven. 2 nov. 2018 à 14:17, David Ponzone 
> a
> > >> écrit :
> > >>
> > >>> Cédric,
> > >>>
> > >>> y a aussi le Planet VDR-301N qui peut être une option. Un peu plus
> de 30€
> > >>> en plus.
> > >>>
> > >>> Ce qu’il sait faire:
> > >>> -PVC ADSL/VLAN VDSL multiples
> > >>> -activation/désactivation NAT par PVC/VLAN de sortie
> > >>> -seconde IP LAN
> > >>> -exclusions du NAT de certaines IP du LAN
> > >>> -pools DHCP différents en fonction du device name (reste à savoir de
> quel
> > >>> device name il s’agit, la doc ne précise pas: hostname, vendor-class
> ? Il
> > >>> faudrait également que ça accepte les wildcard)
> > >>>
> > >>> Ce qu’il ne sait pas faire à priori:
> > >>> -plusieurs bridge LAN/WAN isolés pour l’utiliser en modem pur
> > >>>
> > >>>
> > >>> Le 31 oct. 2018 à 12:57, BASSAGET Cédric <
> cedric.bassaget...@gmail.com> a
> > >>> écrit :
> > >>>
> > >>> https://www.tp-link.com/fr/products/details/TD-W9977.html quelqu'un
> a
> > >>> testé çà ?
> > >>> J'ai globalement du mal a trouver des infos concernant le support du
> PTM
> > >>> pour les VDSL EFM et le support de tag vlan côté VDSL.
> > >>> Cédric
> > >>>
> > >>> Le mar. 18 sept. 2018 à 17:36, David Ponzone <
> david.ponz...@gmail.com> a
> > >>> écrit :
> > >>>
> >  Ouais.
> > 
> >  Un CPE à 30€ qui est capable d’avoir plusieurs pools DHCP sur la
> même
> >  interface IP en fonction du préfixe de l’adresse MAC source…
> >  Même Cisco sait pas faire ça (en tout cas j’ai jamais réussi).
> >  Mikrotik non plus.
> > 
> >  Le 18 sept. 2018 à 17:26, r...@futomaki.net a écrit :
> > 
> >  La fin d'une époque. Le bon vieux logo speedtouch et la cli
> particulière
> >  nous manquerons. Enfin pas sur pour la cli. N'empêche que pour du
> cpe à 10e
> >  c'était quand même pas mal.
> > 
> >  Sent from Mobile
> > 
> > 
> >   Original Message 
> >  

Re: [FRnOG] [MISC] Conservation log appels opérateurs/presta Voip

[Fabien H]

Bonsoir,
Juste comme ça :

si c'est un IPBX type OXO et que l'opérateur reçoit la signalisation SIP
mais ne reçoit pas le RTP, il faut que le mainteneur de l'IPBX vérifie que
le RTP Direct n'est pas par hasard activé  .. ? Et le désactiver

Fabien

Le dim. 3 mars 2019 à 21:07, admin Obf  a écrit :

> Le one way permanent, ça serait si simple ici … ça ne le fait que sur
> certain appel en tout ou rien ^^'
>
> Là, l'opérateur a pris des traces à son niveau directement sur son sbc et
> ainsi mettre en évidence qu'il ne recevait pas de son en provenance de
> l'équipement client (sdp et cie OK, fait via tcpdump) tandis que le presta
> se contente de dire qu'il envoie bien et que c'est l'opérateur qui reçoit
> pas
> Bref, un bon presta comme on les aime (:
>
> Le plus moche, c'est qu'effectivement le client est pris entre les deux …
> Vu que c'est technique, il se repose sur son presta qui rejette la balle
> sur l'opérateur et inversement …
>
>
> Le 3 mars 2019 20:15:52 GMT+01:00, David Ponzone 
> a écrit :
> >Si c’est une situation de one-way permanente, et que les 2 ne font pas
> >leurs meilleurs efforts pour comprendre, je plains le client.
> >C’est stupide de la part de l’opérateur et du presta, mais pour le
> >vivre fréquemment, y a des prestas qui devraient changer de métier
> >(surtout un qui dit qu’il peut pas prendre de traces….).
> >
> >> Le 3 mars 2019 à 19:35, admin Obf  a écrit :
> >>
> >> Effectivement …
> >> Erreur de ma part dans le précédent message
> >> il fallait lire :
> >>
> >> Je sens que l'opérateur va fermer l'incident et renvoyer son client
> >vers le gestionnaire de l'équipement (le presta), même en cas de
> >nouvelles ouverture pour la même problématique
> >>
> >>
> >>
> >> Le 3 mars 2019 19:25:33 GMT+01:00, David Ponzone
> > a écrit :
> >>> Je comprends plus.
> >>> Il fait quoi le presta s’il n’est pas gestionnaire de l’équipement ?
> >>> Ptet qu’il sert juste à rien, à part bloquer :)
> >>>
>  Le 3 mars 2019 à 17:39, admin Obf  a écrit :
> 
>  Dans le cas en tête, l'opérateur a déjà tenté de prouvé qu'il n'est
> >>> pas en cause avec l'aide de capture de trames (identique dans les
> >deux
> >>> cas, on est sur du one way en provenance presta/client vers
> >opérateur),
> >>> mais le presta refuse de l'entendre et part du principe que vu qu'il
> >>> n'a pas de trace ou de moyen d'en prendre, le défaut ne peut venir
> >que
> >>> du coté opérateur et refuse tout dialogue, se limitant à
> >"passe-plat"
> >>> selon ces propres termes
> 
>  Ce qui provoque un blocage des deux cotés :/
>  Je sens que le presta va fermer l'incident et renvoyer son client
> >>> vers le gestionnaire de l'équipement, même en cas de nouvelles
> >>> ouverture pour la même problématique
> 
>  Le 3 mars 2019 16:55:11 GMT+01:00, David Ponzone
> >>>  a écrit :
>  Le 3 mars 2019 à 13:08, admin Obf  a écrit :
> 
>  Bien le bonjour @toutes et tous,
> 
>  Quelques questionnements me taraudent quant à la conservation des
> >>> logs par les différents acteurs dans le cadre de fourniture de VoIP
> 
>  J'ai vu que l'opérateur se devait de conserver des logs (du moins,
> >en
> >>> France) ne serait-ce que pour des raisons légales (réquisition
> >>> judiciaire, etc.).
> 
>  Qu'en est-il des autres parties ? Le presta notamment sur un trunk
> >>> SIP doit il aussi conserver des logs ?
> 
>  Je vois pas pourquoi le prestataire serait concerné. Il ne fait que
> >>> configurer/maintenir un équipement qui appartient au client.
>  Au pire, il a un devoir de conseil envers le client, qui est
> >>> probablement une "obligation" assez floue dans notre domaine.
> 
>  Pour moi, l’obligation de conserver les logs est sur les
> >opérateurs,
> >>> pour pouvoir répondre à la Police/Justice.
> 
>  Dans le cas de debug entre le presta et l'opérateur, le presta
> >>> (gestionnaire d'un oxo par exemple) peut-il se cacher derrière le
> >fait
> >>> d'avoir un système ne permettant pas de conserver ne serait-ce que
> >des
> >>> journaux d'appels et ainsi mettre la faute sur l'opérateur sans
> >avoir
> >>> de quoi le prouver ? (Cdr)
> 
>  Je cherche dans quelle situation de debug tu voudrais mettre la
> >faute
> >>> sur l’opérateur.
>  Quand tu debug, c’est qu’à priori tu es dans une démarche
> >>> constructive avec l’opérateur pour régler un problème chez le
> >client.
>  Mais ne t’inquiète pas, tout PBX moderne (OXO compris) permet de
> >>> conserver logs et CDR.
>  Tu penses à quoi ?
>  Si ton client a passé des appels pour 20k€ dans le mois, et que tu
> >>> espères pouvoir dire que c’est la faute de l’opérateur parce que tu
> >>> n’as pas les CDR pour prouver le contraire sur le PBX, j’ai peur que
> >tu
> >>> lances ton client dans une procédure difficile et perdue d’avance :)
>  Liste de diffusion du FRnOG
>  http://www.frnog.org/ 
> 
>  --
> >>
> >> --
> >> Librement,
> >> 

Re: [FRnOG] [TECH] SD-WAN encore !

[Fabien H]

Troll inside ..

Le mar. 5 févr. 2019 à 15:35, Michel Hostettler <
michel.hostett...@telecom-paristech.fr> a écrit :

> Bonjour,
>
> Le SD-WAN peut être traité avec mépris, et même être ignoré... Le seul
> ennui, il nous rattrapera un jour et nous réveillera crûment.
> https://www.hubone.fr/oneblog/sd-wan-vagues/
>
> Je rappelle que nous avons lancé une formation sur cette technique de
> gestion des réseaux :
>
> https://www.telecom-evolution.fr/fr/formations-courtes/la-revolution-sd-wan-chez-les-operateurs-de-transport-de-donnees
>
> Cordialement, Michel
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Nouvelle offre OWF : "Just Revendeur"

[Fabien H]

Et attendez, sur la tarification y'a des choses très marrantes (je ne sais
pas si j'ai le droit de mettre les tarifs) :

- Frais de set up (donc on ne parle pas de porte de collecte hein) :
Supérieur à plusieurs milliers d'euro
(il va falloir en vendre du FTTH pour amortir !! Ou alors y'a un truc qui
m'échappe)

- Frais de Mise en service d'un lien  : supérieur à 100 euro
(alors qu'en face Orange ne facture pas de FAS à ses clients si je ne
m'abuse)

Je ne comprend pas la logique économique de cette offre, ou alors j'aurai
mal lu ?!!

Fabien



Le jeu. 6 juin 2019 à 20:30, Jérôme Nicolle  a écrit :

> Salut David,
>
> Le 06/06/2019 à 19:55, David Ponzone a écrit :
> > Mais non Jérôme, tu exagères, il y a une webconf fin Juin sur le
> > projet d’offre FTTH bitstream sur les RIP Orange (parce que là, je
> > suppose qu’ils sont contraints d’en proposer une dans pas trop
> > longtemps).
>
> C'est un des amendements Chaize au PL PACTE, qui s'est fait démonter pré
> CMP de façon franchement discutable, tendance très grave.
>
> > Ce que j’adore dans cette offre Just Fibre, c’est que c’est pas de le
> > collecte au niveau technique, mais par contre, au niveau
> > tarification, vu que tu paies au traffic 10€/mois/Mbps au delà du
> > seuil de 2Mbps, là c’est comme de la collecte  :)
>
> J'avais pas lu cette petite ligne. C'est pire qu'une honte, autant pour
> OWF que pour l'ARCEP. Tarifer 10€/Mbps avec un transit à moins de 0,25
> et un backbone qui coûte moins de 3% des OPEX globaux, c'est scandaleux.
>
> On se fout de la gueule de qui, franchement ?
>
> --
> Jérôme Nicolle
> +33 6 19 31 27 14
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Très sympa cette fonctionnalité !

Par contre dans mon cas, c'est pas bon, parce que j'ai a la fois un L2 et
un L3 qui passent sur chacun des liens. Mais pour un L2 pur, c'est le top !

Le mer. 12 juin 2019 à 09:20, David Ponzone  a
écrit :

> Ou sinon, tu peux tenter de livrer le service depuis ton ASR à base d’EVC.
>
>
> https://gblogs.cisco.com/fr/reseaux/jai-teste-pour-vous-les-evc-ou-comment-bridger-sur-un-asr-1000-et-bien-plus-encore/
>
> Très très simple à configurer par contre faut que les 2 liens arrivent sur
> le même ASR.
>
>
> Le 12 juin 2019 à 08:55, Fabien H  a écrit :
>
> Si je ne m'en sors pas, oui je vais partir sur Mikrotik.
>
> Le problème c'est que c'est un client assez exigeant sur le matériel, et il
> ne connait pas Mikrotik, il va falloir lui expliquer que c'est du bon
> produit, .. à suivre ..
>
> Le mer. 12 juin 2019 à 08:51, Michael Lima  a
> écrit :
>
> Salut
> Moi je te conseil mikrotik avec eoip + fastpath et tu auras du bon débit
> en l2z
>
>
> Sent from my iPhone
>
> On 11 Jun 2019, at 10:52, Fabien H  wrote:
>
> Entre les 2 sites, c'est notre backbone : routeurs ASR 1002-X  / liens
> CELAN Orange
>
> La topologie :
>
> LAN Client <--> Ge0/1  Xconnect l2tpv3 [C1921] Ge 0/0 (IP) <-- FIBRE 200M
> --> (IP) ASR1002-X (IP) <--- FIBRE 200M --> (IP) Ge 0/0 [C1921] Ge0/1
> Xconnect l2tpv3 <--> LAN Client
>
> Oui c'est ce qui me semblait pour le routeur CISCO client : un peu trop
> léger, mais d'habitude pour ce genre de problèmes de perf, le CPU est à
> 100% et le routeur laggue.. Ici ce n'est pas le cas
>
> J'ai du mal à trouver les specs Cisco pour le througput sur les tunnels
> L2TPV3. S'il faut investir sur un routeur plus gros, on le fera mais
>
> lequel
>
> ..
>
> Merci
>
>
> Le mar. 11 juin 2019 à 10:40, Radu-Adrian Feurdean <
> fr...@radu-adrian.feurdean.net> a écrit :
>
> On Tue, Jun 11, 2019, at 09:55, Fabien H wrote:
>
> routeurs client (des CISCO 1921). Nous livrons de part et d'autre le
>
> tunnel
>
>
> Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert
>
> de
>
> fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous avons
>
> essayé
>
> 60 Mbps via une xconnect sur C1921 c'est deja pas mal.
>
> Nous souhaiterions au moins atteindre 100 Mb/s en L2
>
> Avez-vous des pistes pour arriver à ce résultat ?
>
>
> Un CPE plus "muscle" cote CPU.
> Ou VXLAN, mais ils faut aussi changer le CPE.
>
> - Est-ce que le xconnect MPLS plutôt que l2tpv3 serait plus efficace au
> niveau bande passante ?
>
>
> Entre les 2 sites c'est *TON* backbone ou celui d'un FAI (autre que
>
> toi) ?
>
> Si ce n'est pas le tien (toi qui fait tourner le LDP ou SR), tu peux
> oublier toute fonctionalite MPLS (dont xconnect). Sinon, ca se tente,
>
> mais
>
> ca peut ne pas etre aussi simple que ca a l'air.
>
> - Le stacked Vlan semble intéressant mais j'ai du mal à voir si c'est
>
> pour
>
> faire du tunnel L2..
>
>
> NON !
>
> - Nos routeurs de coeur sont des ASR 1002-X
>
>
> C'est quoi ta topologie exacte ?
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

L'air de rien, avec un petit coup de peinture, et hop :-)

Le mer. 12 juin 2019 à 09:06, Olivier Lange  a écrit :

>
>
> Le mer. 12 juin 2019 à 08:57, Fabien H  a écrit :
>
>> Si je ne m'en sors pas, oui je vais partir sur Mikrotik.
>>
>> Le problème c'est que c'est un client assez exigeant sur le matériel, et
>> il
>> ne connait pas Mikrotik, il va falloir lui expliquer que c'est du bon
>> produit, .. à suivre ..
>>
>
> Au pire... https://www.redbubble.com/fr/shop/cisco+stickers :D
>
> Ok, je sors ;)
> Olivier
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Oui tout à fait, ça fragmente à mort.

J'ai essayé de modifier le MTU sur les interfaces LAN aux extrémités du
tunnel en les diminuant, puis en les augmentant on ne sait jamais, en
jouant sur le TCP MSS, mais la fragmentation a continué.

D'après ce que je lis, c'est bien au niveau de l'interface pseudowire qu'il
faut faire quelque chose pour le MTU. Je vois par contre que sur les
derniers versions du firmware c1900, l'option ip pmtu n'y est plus.. Je
vais downgrader le firmware pour tester avec cette option ..

Merci encore pour les retours

Le mar. 11 juin 2019 à 23:17, David Ponzone  a
écrit :

> Pas sûr, ça peut venir de la fragmentation/reassembly.
> Il y a apparement des problèmes de MTU propres à L2TPv3:
>
> http://www.mplsvpn.info/2009/05/mtu-problem-in-l2tpv3.html
>
> Ca vaut le coup de vérifier.
>
> Le 11 juin 2019 à 22:16, Fabien H  a écrit :
>
> Alors sur le CPE par lesquels les paquets iperf du LAN rentrent, le CPU est
> à 35%/34% assez constant.
>
> Par contre j'avais mal regardé mais sur le CPE par lesquels les paquets
> sortent, le CPU est à 99%/33%  !!
>
> Donc le problème vient clairement de là je pense..
>
> Le mar. 11 juin 2019 à 16:07, David Ponzone  a
> écrit :
>
> Sur un show proc c, tu as quoi comme valeur X/Y ?
> ->
>
> https://community.cisco.com/t5/switching/high-cpu-load-but-nothing-in-show-proce-cpu-why/td-p/1467781
>
> CEF activé ?
> Des features gourmands activés (PBR, ACL, tout en même temps ?)
>
>
> Le 11 juin 2019 à 15:59, Fabien H  a écrit :
>
> La débit commence à diminuer à partir d'une taille de paquet < 1100 octets
> à 80 Mb/s environ, donc si je calcule bien environ 9100 pps ...
>
>
>
> Le mar. 11 juin 2019 à 15:31, David Ponzone  a
> écrit :
>
> Essaie de réduire la taille des paquets UDP pour voir si c’est
> effectivement le routeur qui ne suit pas en PPS.
>
> Le 11 juin 2019 à 15:29, Fabien H  a écrit :
>
> Voici les résultats :
>
> En test UDP, j'arrive à 85 Mb/s avec les paramètres suivants (taille
>
> paquet
>
> = 1400) :
>
> iperf3 -c  -u -b 100M -t 10 -l 1400
>
> En test TCP, j'arrive à 65 Mb/s avec les paramètres suivants (taille
>
> paquet
>
> = 1450, TCP MSS = 1410)  :
>
> iperf3 -c  -t 10 -l 1450 -M 1410
>
> Le test TCP correspond à peu près au débit relevé lors du transfert SMB
>
> (60
>
> Mb/s)
>
> J'ai peur que ça vienne d'une limitation routeur (pourtant le CPU est à
>
> 50%
>
> environ pendant le test)...
>
>
>
> Le mar. 11 juin 2019 à 12:53, Arnaud BRAND 
>
> a
>
> écrit :
>
> Comme dit par plusieurs :
> - iperf UDP pour savoir combien ton tuyau/tunnel débite
> - iperf TCP pour voir si tes tailles de fenêtres windows sont limitantes
> par rapport au RTT (cf bandwidth-delay product)
> - autres protos (FTP, SMB, ...) pour valider ce que le client verra (et
> qui peut mener à du tuning de taille de fenêtre dans son
> registre/netsh/gpo windows)
>
> Comme dit par d'autres: Mikrotik avec de l'EoIP fera très bien le job.
> Pour du 100M et +, je mets en général des CCR1009 par sécurité
> (plusieurs tunnels, plusieurs queues et un peu de classification), mais
> en lab j'ai monté les hEX à 700/800M de mémoire.
> Attention, débit sans chiffrement, donc à réserver à du backbone privé.
> Pour 50 balles pièces, je réfléchis pas trop longtemps.
>
> Pense à passer les tests avec des paquets UDP à 1400 pour éviter la frag
> par le tunnel et à activer le clamp MSS sur le tunnel EoIP avec la bonne
> valeur pour que les connecs TCP s'adaptent bien au MTU réel.
>
> Bonne journée,
> AB
>
>
> Le 2019-06-11 11:05, CHENICLET, DAVID a écrit :
>
> Bonjour,
>
> +1
>
> Pour le test de débit il vaut mieux le faire avec FTP.
> La vitesse du transfert varie en fonction de la version du protocole
> CIFS (liée à la version de l'OS Windows).
> J'ai déjà eu le cas de transfert bridés avec le partage Windows...
>
>
> Cordialement,
> David C
>
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> David Ponzone
> Envoyé : mardi 11 juin 2019 10:18
> À : Fabien H
> Cc : frnog-t...@frnog.org
> Objet : Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3
>
> Hmm y a un temps où quand un Cisco tapait le 50% de CPU, c’était pas
> bon du tout et il était temps de l’upgrader.
> Je ne sais pas si Cisco a changé sa manière de calculer le CPU….
>
> Après tu as essayé de faire un test de perf avec iperf ?
> Parce que j’ai rarement vu un transfert SMB utilisé comme étalon de
> performance.
> D’autres sur la liste seront certainement aptes à nous dire si SMB est
> capable de débits wirespeed même si le RTT augmente.
>
> Le 11 juin 2019 à 09:54, Fabien H  a écri

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Alors là oui, c'est carrément dans la cible ! Merci je vais maquetter ..

je vous tiendrai au courant des résultats..


Le mer. 12 juin 2019 à 11:40, Alexis Lameire  a
écrit :

> Hello,
> le second-dot1q peut prendre comme paramétré any ;) donc pas forcément
> besoin de déclarer ça à l'avance !
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-3s/ce-xe-3s-book/ce-ether-vc-infra-xe.html#GUID-F8B4D13B-E8EE-449D-82C5-5C6FBFF7C743
>
> cette doc chez cisco t'en diras plus et te donnera la syntaxe complète.
> Clairement c'est bien plus puissant qu'un bête dot1q-tunnel
>
> Alexis
>
>
> Le mer. 12 juin 2019 à 11:38, Fabien H  a écrit :
>
>> Oui ça parait hyper puissant ..
>>
>> Mais comme je fournis un port trunk au client sans connaitre à l'avance
>> les
>> VLAN qu'il va utiliser je pense que je suis coincé ..
>>
>> Ou alors je lui impose de nous déclarer en amont les VLAN qu'il va
>> utiliser
>> et comme ça je fais la configuration au fur et à mesure. => Si je pars la
>> dessus, c'est pas trop contraignant pour le client à priori et on a une
>> configuration L2 super performante
>>
>> Merci pour les retours, je vais maquetter !!
>>
>> Le mer. 12 juin 2019 à 11:30, Alexis Lameire  a
>> écrit :
>>
>> > Hello Fabien
>> > Sur de l'ASR 1000 les services instances permettent de faire du QinQ (et
>> > aussi de le faire de facon selectif.
>> >
>> > dans ton service instance tu peut faire de la réecriture de vlan :
>> >
>> > encapsulation dot1q  second-dot1q
>> >  (si tu veux limiter les inner vlan du client, le
>> outer
>> > vlan sera le vlan de livraison sur ta porte de collecte
>> > rewrite ingress tag translate 1-to-1 dot1q 
>> symmetric
>> > (tu réecrit le vlan client dans ta pdc a un vlan propre a ton réseau)
>> >
>> > la tu peut faire passer ton niveau 2 dans ton coeur pour relier ton
>> > client. Si tu as un réseau plus gros et les ASR quivontbien, tu peut
>> tirer
>> > une vpls au sein de ton service instance en remplacent ton rewrite par
>> un
>> > xconnect.
>> >
>> > Alexis
>> >
>> > Le mer. 12 juin 2019 à 11:11, Fabien H  a
>> écrit :
>> >
>> >> Oui, c'est ma collecte.
>> >>
>> >> Le but est de fournir au client un port Ethernet L2 en mode trunk sur
>> >> chacun de ses sites. Il pourra donc faire passer tous les VLAN qu'il
>> >> souhaite sans restriction.
>> >>
>> >> Après le but serait de faire remonter ce "trunk" via le lien opérateur
>> au
>> >> niveau routeur de coeur ASR pour bridger avec l'autre lien. Donc au
>> niveau
>> >> routeur de coeur, je vais me retrouver avec le VLAN opérateur + les
>> sous
>> >> vlan du client dans les trames (= QinQ). Donc pour le service instance,
>> >> impossible d'utiliser un QinQ avec un vlan défini à l'avance ?
>> >>
>> >> En gros la question est : est-ce que je peux à la fois bridger en
>> coeur de
>> >> réseau les L2 du client configurés en mode trunk avec service
>> instance, et
>> >> à la fois définir sur ce même Vlan opérateur un niveau 3 (configuré en
>> >> QinQ) ?
>> >>
>> >>
>> >>
>> >>
>> >> Le mer. 12 juin 2019 à 09:54, David Ponzone 
>> a
>> >> écrit :
>> >>
>> >> > Si c’est ta collecte, tu peux créer un VLAN QinQ en plus sur chaque
>> >> lien,
>> >> > et faire le service instance entre les QinQ.
>> >> >
>> >> > Ou alors j’ai pas compris ce qui coince dans ton cas.
>> >> >
>> >> > > Le 12 juin 2019 à 09:45, Fabien H  a
>> écrit :
>> >> > >
>> >> > > Très sympa cette fonctionnalité !
>> >> > >
>> >> > > Par contre dans mon cas, c'est pas bon, parce que j'ai a la fois un
>> >> L2 et
>> >> > > un L3 qui passent sur chacun des liens. Mais pour un L2 pur, c'est
>> le
>> >> > top !
>> >> > >
>> >> > > Le mer. 12 juin 2019 à 09:20, David Ponzone <
>> david.ponz...@gmail.com>
>> >> a
>> >> > > écrit :
>> >> > >
>> >> > >> Ou sinon, tu peux tenter de livrer le service depuis ton ASR à
>> base
>> >> > d’EVC.
>> >> > >>
>> >> > >>
>> >> > >>

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Oui ça parait hyper puissant ..

Mais comme je fournis un port trunk au client sans connaitre à l'avance les
VLAN qu'il va utiliser je pense que je suis coincé ..

Ou alors je lui impose de nous déclarer en amont les VLAN qu'il va utiliser
et comme ça je fais la configuration au fur et à mesure. => Si je pars la
dessus, c'est pas trop contraignant pour le client à priori et on a une
configuration L2 super performante

Merci pour les retours, je vais maquetter !!

Le mer. 12 juin 2019 à 11:30, Alexis Lameire  a
écrit :

> Hello Fabien
> Sur de l'ASR 1000 les services instances permettent de faire du QinQ (et
> aussi de le faire de facon selectif.
>
> dans ton service instance tu peut faire de la réecriture de vlan :
>
> encapsulation dot1q  second-dot1q
>  (si tu veux limiter les inner vlan du client, le outer
> vlan sera le vlan de livraison sur ta porte de collecte
> rewrite ingress tag translate 1-to-1 dot1q  symmetric
> (tu réecrit le vlan client dans ta pdc a un vlan propre a ton réseau)
>
> la tu peut faire passer ton niveau 2 dans ton coeur pour relier ton
> client. Si tu as un réseau plus gros et les ASR quivontbien, tu peut tirer
> une vpls au sein de ton service instance en remplacent ton rewrite par un
> xconnect.
>
> Alexis
>
> Le mer. 12 juin 2019 à 11:11, Fabien H  a écrit :
>
>> Oui, c'est ma collecte.
>>
>> Le but est de fournir au client un port Ethernet L2 en mode trunk sur
>> chacun de ses sites. Il pourra donc faire passer tous les VLAN qu'il
>> souhaite sans restriction.
>>
>> Après le but serait de faire remonter ce "trunk" via le lien opérateur au
>> niveau routeur de coeur ASR pour bridger avec l'autre lien. Donc au niveau
>> routeur de coeur, je vais me retrouver avec le VLAN opérateur + les sous
>> vlan du client dans les trames (= QinQ). Donc pour le service instance,
>> impossible d'utiliser un QinQ avec un vlan défini à l'avance ?
>>
>> En gros la question est : est-ce que je peux à la fois bridger en coeur de
>> réseau les L2 du client configurés en mode trunk avec service instance, et
>> à la fois définir sur ce même Vlan opérateur un niveau 3 (configuré en
>> QinQ) ?
>>
>>
>>
>>
>> Le mer. 12 juin 2019 à 09:54, David Ponzone  a
>> écrit :
>>
>> > Si c’est ta collecte, tu peux créer un VLAN QinQ en plus sur chaque
>> lien,
>> > et faire le service instance entre les QinQ.
>> >
>> > Ou alors j’ai pas compris ce qui coince dans ton cas.
>> >
>> > > Le 12 juin 2019 à 09:45, Fabien H  a écrit :
>> > >
>> > > Très sympa cette fonctionnalité !
>> > >
>> > > Par contre dans mon cas, c'est pas bon, parce que j'ai a la fois un
>> L2 et
>> > > un L3 qui passent sur chacun des liens. Mais pour un L2 pur, c'est le
>> > top !
>> > >
>> > > Le mer. 12 juin 2019 à 09:20, David Ponzone 
>> a
>> > > écrit :
>> > >
>> > >> Ou sinon, tu peux tenter de livrer le service depuis ton ASR à base
>> > d’EVC.
>> > >>
>> > >>
>> > >>
>> >
>> https://gblogs.cisco.com/fr/reseaux/jai-teste-pour-vous-les-evc-ou-comment-bridger-sur-un-asr-1000-et-bien-plus-encore/
>> > >>
>> > >> Très très simple à configurer par contre faut que les 2 liens
>> arrivent
>> > sur
>> > >> le même ASR.
>> > >>
>> > >>
>> > >> Le 12 juin 2019 à 08:55, Fabien H  a écrit :
>> > >>
>> > >> Si je ne m'en sors pas, oui je vais partir sur Mikrotik.
>> > >>
>> > >> Le problème c'est que c'est un client assez exigeant sur le matériel,
>> > et il
>> > >> ne connait pas Mikrotik, il va falloir lui expliquer que c'est du bon
>> > >> produit, .. à suivre ..
>> > >>
>> > >> Le mer. 12 juin 2019 à 08:51, Michael Lima 
>> a
>> > >> écrit :
>> > >>
>> > >> Salut
>> > >> Moi je te conseil mikrotik avec eoip + fastpath et tu auras du bon
>> débit
>> > >> en l2z
>> > >>
>> > >>
>> > >> Sent from my iPhone
>> > >>
>> > >> On 11 Jun 2019, at 10:52, Fabien H  wrote:
>> > >>
>> > >> Entre les 2 sites, c'est notre backbone : routeurs ASR 1002-X  /
>> liens
>> > >> CELAN Orange
>> > >>
>> > >> La topologie :
>> > >>
>> > >> LAN Client <--> Ge0/1  Xconnect l2tpv3 [C1

[FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Bonjour,

un client a un besoin pour faire un tunnel L2 d'au moins 100Mb/s entre 2
sites équipés en fibre 200M (MPLS).

Nous avons essayé de mettre en place un Xconnect l2tpv3 entre les 2
routeurs client (des CISCO 1921). Nous livrons de part et d'autre le tunnel
L2 sur l'interface Gigabit Ethernet 0/1 du routeur client.

Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert de
fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous avons essayé
de tuner le mtu et le adjust tcp mss, les buffer de fragmention/defrag des
interfaces LAN du xconnect, mais sans succès..

Nous souhaiterions au moins atteindre 100 Mb/s en L2

Avez-vous des pistes pour arriver à ce résultat ?

- Est-ce que le xconnect MPLS plutôt que l2tpv3 serait plus efficace au
niveau bande passante ?
- Le stacked Vlan semble intéressant mais j'ai du mal à voir si c'est pour
faire du tunnel L2..
- Nos switch core (Cisco) ne gèrent pas le Vlan rewrite
- Nos routeurs de coeur sont des ASR 1002-X

Merci,
Cordialement,

Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Intéressant, je vais regarder les specs, merci !

Le mar. 11 juin 2019 à 09:59, Olivier Lange  a écrit :

> Sur ce genre de débit, j'ai pu le faire sans souci avec 2 Mikrotik
> https://mikrotik.com/product/rb1100ahx4. Un de chaque coté, et un EOIP en
> bridge entre les 2. Ca coute pas cher, et ca juste fonctionne.
>
> Après, sous Cisco, je ne sais pas comment ca fonctionne.
>
> Olivier
>
> Le mar. 11 juin 2019 à 09:57, Fabien H  a écrit :
>
>> Bonjour,
>>
>> un client a un besoin pour faire un tunnel L2 d'au moins 100Mb/s entre 2
>> sites équipés en fibre 200M (MPLS).
>>
>> Nous avons essayé de mettre en place un Xconnect l2tpv3 entre les 2
>> routeurs client (des CISCO 1921). Nous livrons de part et d'autre le
>> tunnel
>> L2 sur l'interface Gigabit Ethernet 0/1 du routeur client.
>>
>> Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert de
>> fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous avons
>> essayé
>> de tuner le mtu et le adjust tcp mss, les buffer de fragmention/defrag des
>> interfaces LAN du xconnect, mais sans succès..
>>
>> Nous souhaiterions au moins atteindre 100 Mb/s en L2
>>
>> Avez-vous des pistes pour arriver à ce résultat ?
>>
>> - Est-ce que le xconnect MPLS plutôt que l2tpv3 serait plus efficace au
>> niveau bande passante ?
>> - Le stacked Vlan semble intéressant mais j'ai du mal à voir si c'est pour
>> faire du tunnel L2..
>> - Nos switch core (Cisco) ne gèrent pas le Vlan rewrite
>> - Nos routeurs de coeur sont des ASR 1002-X
>>
>> Merci,
>> Cordialement,
>>
>> Fabien
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Non, j'ai pas essayé iperf : j'ai utilisé SMB parce que je sais que c'est
la 1ere chose que va voir le client quand il va tester le L2 : transfert de
fichier vers/du serveur SMB..

Je vais effectivement tester avec iperf en UDP et TCP...

Le mar. 11 juin 2019 à 10:17, David Ponzone  a
écrit :

> Hmm y a un temps où quand un Cisco tapait le 50% de CPU, c’était pas bon
> du tout et il était temps de l’upgrader.
> Je ne sais pas si Cisco a changé sa manière de calculer le CPU….
>
> Après tu as essayé de faire un test de perf avec iperf ?
> Parce que j’ai rarement vu un transfert SMB utilisé comme étalon de
> performance.
> D’autres sur la liste seront certainement aptes à nous dire si SMB est
> capable de débits wirespeed même si le RTT augmente.
>
> > Le 11 juin 2019 à 09:54, Fabien H  a écrit :
> >
> > Bonjour,
> >
> > un client a un besoin pour faire un tunnel L2 d'au moins 100Mb/s entre 2
> > sites équipés en fibre 200M (MPLS).
> >
> > Nous avons essayé de mettre en place un Xconnect l2tpv3 entre les 2
> > routeurs client (des CISCO 1921). Nous livrons de part et d'autre le
> tunnel
> > L2 sur l'interface Gigabit Ethernet 0/1 du routeur client.
> >
> > Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert de
> > fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous avons
> essayé
> > de tuner le mtu et le adjust tcp mss, les buffer de fragmention/defrag
> des
> > interfaces LAN du xconnect, mais sans succès..
> >
> > Nous souhaiterions au moins atteindre 100 Mb/s en L2
> >
> > Avez-vous des pistes pour arriver à ce résultat ?
> >
> > - Est-ce que le xconnect MPLS plutôt que l2tpv3 serait plus efficace au
> > niveau bande passante ?
> > - Le stacked Vlan semble intéressant mais j'ai du mal à voir si c'est
> pour
> > faire du tunnel L2..
> > - Nos switch core (Cisco) ne gèrent pas le Vlan rewrite
> > - Nos routeurs de coeur sont des ASR 1002-X
> >
> > Merci,
> > Cordialement,
> >
> > Fabien
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Entre les 2 sites, c'est notre backbone : routeurs ASR 1002-X  / liens
CELAN Orange

La topologie :

LAN Client <--> Ge0/1  Xconnect l2tpv3 [C1921] Ge 0/0 (IP) <-- FIBRE 200M
--> (IP) ASR1002-X (IP) <--- FIBRE 200M --> (IP) Ge 0/0 [C1921] Ge0/1
Xconnect l2tpv3 <--> LAN Client

Oui c'est ce qui me semblait pour le routeur CISCO client : un peu trop
léger, mais d'habitude pour ce genre de problèmes de perf, le CPU est à
100% et le routeur laggue.. Ici ce n'est pas le cas

J'ai du mal à trouver les specs Cisco pour le througput sur les tunnels
L2TPV3. S'il faut investir sur un routeur plus gros, on le fera mais lequel
..

Merci


Le mar. 11 juin 2019 à 10:40, Radu-Adrian Feurdean <
fr...@radu-adrian.feurdean.net> a écrit :

> On Tue, Jun 11, 2019, at 09:55, Fabien H wrote:
>
> > routeurs client (des CISCO 1921). Nous livrons de part et d'autre le
> tunnel
> >
> > Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert de
> > fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous avons
> essayé
>
> 60 Mbps via une xconnect sur C1921 c'est deja pas mal.
>
> > Nous souhaiterions au moins atteindre 100 Mb/s en L2
> >
> > Avez-vous des pistes pour arriver à ce résultat ?
>
> Un CPE plus "muscle" cote CPU.
> Ou VXLAN, mais ils faut aussi changer le CPE.
>
> > - Est-ce que le xconnect MPLS plutôt que l2tpv3 serait plus efficace au
> > niveau bande passante ?
>
> Entre les 2 sites c'est *TON* backbone ou celui d'un FAI (autre que toi) ?
> Si ce n'est pas le tien (toi qui fait tourner le LDP ou SR), tu peux
> oublier toute fonctionalite MPLS (dont xconnect). Sinon, ca se tente, mais
> ca peut ne pas etre aussi simple que ca a l'air.
>
> > - Le stacked Vlan semble intéressant mais j'ai du mal à voir si c'est
> pour
> > faire du tunnel L2..
>
> NON !
>
> > - Nos routeurs de coeur sont des ASR 1002-X
>
> C'est quoi ta topologie exacte ?
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

La débit commence à diminuer à partir d'une taille de paquet < 1100 octets
à 80 Mb/s environ, donc si je calcule bien environ 9100 pps ...



Le mar. 11 juin 2019 à 15:31, David Ponzone  a
écrit :

> Essaie de réduire la taille des paquets UDP pour voir si c’est
> effectivement le routeur qui ne suit pas en PPS.
>
> > Le 11 juin 2019 à 15:29, Fabien H  a écrit :
> >
> > Voici les résultats :
> >
> > En test UDP, j'arrive à 85 Mb/s avec les paramètres suivants (taille
> paquet
> > = 1400) :
> >
> > iperf3 -c  -u -b 100M -t 10 -l 1400
> >
> > En test TCP, j'arrive à 65 Mb/s avec les paramètres suivants (taille
> paquet
> > = 1450, TCP MSS = 1410)  :
> >
> > iperf3 -c  -t 10 -l 1450 -M 1410
> >
> > Le test TCP correspond à peu près au débit relevé lors du transfert SMB
> (60
> > Mb/s)
> >
> > J'ai peur que ça vienne d'une limitation routeur (pourtant le CPU est à
> 50%
> > environ pendant le test)...
> >
> >
> >
> > Le mar. 11 juin 2019 à 12:53, Arnaud BRAND 
> a
> > écrit :
> >
> >> Comme dit par plusieurs :
> >> - iperf UDP pour savoir combien ton tuyau/tunnel débite
> >> - iperf TCP pour voir si tes tailles de fenêtres windows sont limitantes
> >> par rapport au RTT (cf bandwidth-delay product)
> >> - autres protos (FTP, SMB, ...) pour valider ce que le client verra (et
> >> qui peut mener à du tuning de taille de fenêtre dans son
> >> registre/netsh/gpo windows)
> >>
> >> Comme dit par d'autres: Mikrotik avec de l'EoIP fera très bien le job.
> >> Pour du 100M et +, je mets en général des CCR1009 par sécurité
> >> (plusieurs tunnels, plusieurs queues et un peu de classification), mais
> >> en lab j'ai monté les hEX à 700/800M de mémoire.
> >> Attention, débit sans chiffrement, donc à réserver à du backbone privé.
> >> Pour 50 balles pièces, je réfléchis pas trop longtemps.
> >>
> >> Pense à passer les tests avec des paquets UDP à 1400 pour éviter la frag
> >> par le tunnel et à activer le clamp MSS sur le tunnel EoIP avec la bonne
> >> valeur pour que les connecs TCP s'adaptent bien au MTU réel.
> >>
> >> Bonne journée,
> >> AB
> >>
> >>
> >> Le 2019-06-11 11:05, CHENICLET, DAVID a écrit :
> >>> Bonjour,
> >>>
> >>> +1
> >>>
> >>> Pour le test de débit il vaut mieux le faire avec FTP.
> >>> La vitesse du transfert varie en fonction de la version du protocole
> >>> CIFS (liée à la version de l'OS Windows).
> >>> J'ai déjà eu le cas de transfert bridés avec le partage Windows...
> >>>
> >>>
> >>> Cordialement,
> >>> David C
> >>>
> >>> -Message d'origine-
> >>> De : frnog-requ...@frnog.org  De la part de
> >>> David Ponzone
> >>> Envoyé : mardi 11 juin 2019 10:18
> >>> À : Fabien H
> >>> Cc : frnog-t...@frnog.org
> >>> Objet : Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3
> >>>
> >>> Hmm y a un temps où quand un Cisco tapait le 50% de CPU, c’était pas
> >>> bon du tout et il était temps de l’upgrader.
> >>> Je ne sais pas si Cisco a changé sa manière de calculer le CPU….
> >>>
> >>> Après tu as essayé de faire un test de perf avec iperf ?
> >>> Parce que j’ai rarement vu un transfert SMB utilisé comme étalon de
> >>> performance.
> >>> D’autres sur la liste seront certainement aptes à nous dire si SMB est
> >>> capable de débits wirespeed même si le RTT augmente.
> >>>
> >>>> Le 11 juin 2019 à 09:54, Fabien H  a écrit :
> >>>>
> >>>> Bonjour,
> >>>>
> >>>> un client a un besoin pour faire un tunnel L2 d'au moins 100Mb/s entre
> >>>> 2 sites équipés en fibre 200M (MPLS).
> >>>>
> >>>> Nous avons essayé de mettre en place un Xconnect l2tpv3 entre les 2
> >>>> routeurs client (des CISCO 1921). Nous livrons de part et d'autre le
> >>>> tunnel
> >>>> L2 sur l'interface Gigabit Ethernet 0/1 du routeur client.
> >>>>
> >>>> Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert
> >>>> de fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous
> >>>> avons essayé de tuner le mtu et le adjust tcp mss, les buffer de
> >>>> fragmention/defrag des interfaces LAN du xconnect, mais sans succès..
> &

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Effectivement c'est une idée car à priori c'est un processeur multi-coeur
show proc cpu n'indique pas les coeurs par contre.. je vais refaire des
tests pour confirmer le 50%


Le mar. 11 juin 2019 à 15:43, Julien Escario  a
écrit :

> Le 11/06/2019 à 15:29, Fabien H a écrit :
> > Voici les résultats :
> >
> > En test UDP, j'arrive à 85 Mb/s avec les paramètres suivants (taille
> paquet
> > = 1400) :
> >
> > iperf3 -c  -u -b 100M -t 10 -l 1400
> >
> > En test TCP, j'arrive à 65 Mb/s avec les paramètres suivants (taille
> paquet
> > = 1450, TCP MSS = 1410)  :
> >
> > iperf3 -c  -t 10 -l 1450 -M 1410
> >
> > Le test TCP correspond à peu près au débit relevé lors du transfert SMB
> (60
> > Mb/s)
> >
> > J'ai peur que ça vienne d'une limitation routeur (pourtant le CPU est à
> 50%
> > environ pendant le test)...
>
> Si tu as un CPU deux cores et qu'un seul est utilisé pour ton l2tpv3,
> 50%, c'est la saturation. Peut être une explication ?
>
> Tu peux afficher le CPU par cœur ?
>
> Julien
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Voici les résultats :

En test UDP, j'arrive à 85 Mb/s avec les paramètres suivants (taille paquet
= 1400) :

iperf3 -c  -u -b 100M -t 10 -l 1400

En test TCP, j'arrive à 65 Mb/s avec les paramètres suivants (taille paquet
= 1450, TCP MSS = 1410)  :

iperf3 -c  -t 10 -l 1450 -M 1410

Le test TCP correspond à peu près au débit relevé lors du transfert SMB (60
Mb/s)

J'ai peur que ça vienne d'une limitation routeur (pourtant le CPU est à 50%
environ pendant le test)...



Le mar. 11 juin 2019 à 12:53, Arnaud BRAND  a
écrit :

> Comme dit par plusieurs :
> - iperf UDP pour savoir combien ton tuyau/tunnel débite
> - iperf TCP pour voir si tes tailles de fenêtres windows sont limitantes
> par rapport au RTT (cf bandwidth-delay product)
> - autres protos (FTP, SMB, ...) pour valider ce que le client verra (et
> qui peut mener à du tuning de taille de fenêtre dans son
> registre/netsh/gpo windows)
>
> Comme dit par d'autres: Mikrotik avec de l'EoIP fera très bien le job.
> Pour du 100M et +, je mets en général des CCR1009 par sécurité
> (plusieurs tunnels, plusieurs queues et un peu de classification), mais
> en lab j'ai monté les hEX à 700/800M de mémoire.
> Attention, débit sans chiffrement, donc à réserver à du backbone privé.
> Pour 50 balles pièces, je réfléchis pas trop longtemps.
>
> Pense à passer les tests avec des paquets UDP à 1400 pour éviter la frag
> par le tunnel et à activer le clamp MSS sur le tunnel EoIP avec la bonne
> valeur pour que les connecs TCP s'adaptent bien au MTU réel.
>
> Bonne journée,
> AB
>
>
> Le 2019-06-11 11:05, CHENICLET, DAVID a écrit :
> > Bonjour,
> >
> > +1
> >
> > Pour le test de débit il vaut mieux le faire avec FTP.
> > La vitesse du transfert varie en fonction de la version du protocole
> > CIFS (liée à la version de l'OS Windows).
> > J'ai déjà eu le cas de transfert bridés avec le partage Windows...
> >
> >
> > Cordialement,
> > David C
> >
> > -Message d'origine-
> > De : frnog-requ...@frnog.org  De la part de
> > David Ponzone
> > Envoyé : mardi 11 juin 2019 10:18
> > À : Fabien H
> > Cc : frnog-t...@frnog.org
> > Objet : Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3
> >
> > Hmm y a un temps où quand un Cisco tapait le 50% de CPU, c’était pas
> > bon du tout et il était temps de l’upgrader.
> > Je ne sais pas si Cisco a changé sa manière de calculer le CPU….
> >
> > Après tu as essayé de faire un test de perf avec iperf ?
> > Parce que j’ai rarement vu un transfert SMB utilisé comme étalon de
> > performance.
> > D’autres sur la liste seront certainement aptes à nous dire si SMB est
> > capable de débits wirespeed même si le RTT augmente.
> >
> >> Le 11 juin 2019 à 09:54, Fabien H  a écrit :
> >>
> >> Bonjour,
> >>
> >> un client a un besoin pour faire un tunnel L2 d'au moins 100Mb/s entre
> >> 2 sites équipés en fibre 200M (MPLS).
> >>
> >> Nous avons essayé de mettre en place un Xconnect l2tpv3 entre les 2
> >> routeurs client (des CISCO 1921). Nous livrons de part et d'autre le
> >> tunnel
> >> L2 sur l'interface Gigabit Ethernet 0/1 du routeur client.
> >>
> >> Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert
> >> de fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous
> >> avons essayé de tuner le mtu et le adjust tcp mss, les buffer de
> >> fragmention/defrag des interfaces LAN du xconnect, mais sans succès..
> >>
> >> Nous souhaiterions au moins atteindre 100 Mb/s en L2
> >>
> >> Avez-vous des pistes pour arriver à ce résultat ?
> >>
> >> - Est-ce que le xconnect MPLS plutôt que l2tpv3 serait plus efficace
> >> au niveau bande passante ?
> >> - Le stacked Vlan semble intéressant mais j'ai du mal à voir si c'est
> >> pour faire du tunnel L2..
> >> - Nos switch core (Cisco) ne gèrent pas le Vlan rewrite
> >> - Nos routeurs de coeur sont des ASR 1002-X
> >>
> >> Merci,
> >> Cordialement,
> >>
> >> Fabien
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> > This message contains information that may be privileged or
> > confidential and is the property of the Capgemini Group. It is
> > intended only for the person to whom it is addressed. If you are not
> > the intended recipient, you are not authorized to read, print, retain,
> > copy, disseminate, distribute, or use this message or any part
> > thereof. If you receive this message in error, please notify the
> > sender immediately and delete all copies of this message.
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Alors sur le CPE par lesquels les paquets iperf du LAN rentrent, le CPU est
à 35%/34% assez constant.

Par contre j'avais mal regardé mais sur le CPE par lesquels les paquets
sortent, le CPU est à 99%/33%  !!

Donc le problème vient clairement de là je pense..

Le mar. 11 juin 2019 à 16:07, David Ponzone  a
écrit :

> Sur un show proc c, tu as quoi comme valeur X/Y ?
> ->
> https://community.cisco.com/t5/switching/high-cpu-load-but-nothing-in-show-proce-cpu-why/td-p/1467781
>
> CEF activé ?
> Des features gourmands activés (PBR, ACL, tout en même temps ?)
>
>
> Le 11 juin 2019 à 15:59, Fabien H  a écrit :
>
> La débit commence à diminuer à partir d'une taille de paquet < 1100 octets
> à 80 Mb/s environ, donc si je calcule bien environ 9100 pps ...
>
>
>
> Le mar. 11 juin 2019 à 15:31, David Ponzone  a
> écrit :
>
> Essaie de réduire la taille des paquets UDP pour voir si c’est
> effectivement le routeur qui ne suit pas en PPS.
>
> Le 11 juin 2019 à 15:29, Fabien H  a écrit :
>
> Voici les résultats :
>
> En test UDP, j'arrive à 85 Mb/s avec les paramètres suivants (taille
>
> paquet
>
> = 1400) :
>
> iperf3 -c  -u -b 100M -t 10 -l 1400
>
> En test TCP, j'arrive à 65 Mb/s avec les paramètres suivants (taille
>
> paquet
>
> = 1450, TCP MSS = 1410)  :
>
> iperf3 -c  -t 10 -l 1450 -M 1410
>
> Le test TCP correspond à peu près au débit relevé lors du transfert SMB
>
> (60
>
> Mb/s)
>
> J'ai peur que ça vienne d'une limitation routeur (pourtant le CPU est à
>
> 50%
>
> environ pendant le test)...
>
>
>
> Le mar. 11 juin 2019 à 12:53, Arnaud BRAND 
>
> a
>
> écrit :
>
> Comme dit par plusieurs :
> - iperf UDP pour savoir combien ton tuyau/tunnel débite
> - iperf TCP pour voir si tes tailles de fenêtres windows sont limitantes
> par rapport au RTT (cf bandwidth-delay product)
> - autres protos (FTP, SMB, ...) pour valider ce que le client verra (et
> qui peut mener à du tuning de taille de fenêtre dans son
> registre/netsh/gpo windows)
>
> Comme dit par d'autres: Mikrotik avec de l'EoIP fera très bien le job.
> Pour du 100M et +, je mets en général des CCR1009 par sécurité
> (plusieurs tunnels, plusieurs queues et un peu de classification), mais
> en lab j'ai monté les hEX à 700/800M de mémoire.
> Attention, débit sans chiffrement, donc à réserver à du backbone privé.
> Pour 50 balles pièces, je réfléchis pas trop longtemps.
>
> Pense à passer les tests avec des paquets UDP à 1400 pour éviter la frag
> par le tunnel et à activer le clamp MSS sur le tunnel EoIP avec la bonne
> valeur pour que les connecs TCP s'adaptent bien au MTU réel.
>
> Bonne journée,
> AB
>
>
> Le 2019-06-11 11:05, CHENICLET, DAVID a écrit :
>
> Bonjour,
>
> +1
>
> Pour le test de débit il vaut mieux le faire avec FTP.
> La vitesse du transfert varie en fonction de la version du protocole
> CIFS (liée à la version de l'OS Windows).
> J'ai déjà eu le cas de transfert bridés avec le partage Windows...
>
>
> Cordialement,
> David C
>
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> David Ponzone
> Envoyé : mardi 11 juin 2019 10:18
> À : Fabien H
> Cc : frnog-t...@frnog.org
> Objet : Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3
>
> Hmm y a un temps où quand un Cisco tapait le 50% de CPU, c’était pas
> bon du tout et il était temps de l’upgrader.
> Je ne sais pas si Cisco a changé sa manière de calculer le CPU….
>
> Après tu as essayé de faire un test de perf avec iperf ?
> Parce que j’ai rarement vu un transfert SMB utilisé comme étalon de
> performance.
> D’autres sur la liste seront certainement aptes à nous dire si SMB est
> capable de débits wirespeed même si le RTT augmente.
>
> Le 11 juin 2019 à 09:54, Fabien H  a écrit :
>
> Bonjour,
>
> un client a un besoin pour faire un tunnel L2 d'au moins 100Mb/s entre
> 2 sites équipés en fibre 200M (MPLS).
>
> Nous avons essayé de mettre en place un Xconnect l2tpv3 entre les 2
> routeurs client (des CISCO 1921). Nous livrons de part et d'autre le
> tunnel
> L2 sur l'interface Gigabit Ethernet 0/1 du routeur client.
>
> Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert
> de fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous
> avons essayé de tuner le mtu et le adjust tcp mss, les buffer de
> fragmention/defrag des interfaces LAN du xconnect, mais sans succès..
>
> Nous souhaiterions au moins atteindre 100 Mb/s en L2
>
> Avez-vous des pistes pour arriver à ce résultat ?
>
> - Est-ce que le xconnect MPLS plutôt que l2tpv3 serait plus efficace
> au niveau bande passante ?
> - Le stacked Vlan semble intéressant mais j'a

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Si je ne m'en sors pas, oui je vais partir sur Mikrotik.

Le problème c'est que c'est un client assez exigeant sur le matériel, et il
ne connait pas Mikrotik, il va falloir lui expliquer que c'est du bon
produit, .. à suivre ..

Le mer. 12 juin 2019 à 08:51, Michael Lima  a
écrit :

> Salut
> Moi je te conseil mikrotik avec eoip + fastpath et tu auras du bon débit
> en l2z
>
>
> Sent from my iPhone
>
> > On 11 Jun 2019, at 10:52, Fabien H  wrote:
> >
> > Entre les 2 sites, c'est notre backbone : routeurs ASR 1002-X  / liens
> > CELAN Orange
> >
> > La topologie :
> >
> > LAN Client <--> Ge0/1  Xconnect l2tpv3 [C1921] Ge 0/0 (IP) <-- FIBRE 200M
> > --> (IP) ASR1002-X (IP) <--- FIBRE 200M --> (IP) Ge 0/0 [C1921] Ge0/1
> > Xconnect l2tpv3 <--> LAN Client
> >
> > Oui c'est ce qui me semblait pour le routeur CISCO client : un peu trop
> > léger, mais d'habitude pour ce genre de problèmes de perf, le CPU est à
> > 100% et le routeur laggue.. Ici ce n'est pas le cas
> >
> > J'ai du mal à trouver les specs Cisco pour le througput sur les tunnels
> > L2TPV3. S'il faut investir sur un routeur plus gros, on le fera mais
> lequel
> > ..
> >
> > Merci
> >
> >
> > Le mar. 11 juin 2019 à 10:40, Radu-Adrian Feurdean <
> > fr...@radu-adrian.feurdean.net> a écrit :
> >
> >>> On Tue, Jun 11, 2019, at 09:55, Fabien H wrote:
> >>>
> >>> routeurs client (des CISCO 1921). Nous livrons de part et d'autre le
> >> tunnel
> >>>
> >>> Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert
> de
> >>> fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous avons
> >> essayé
> >>
> >> 60 Mbps via une xconnect sur C1921 c'est deja pas mal.
> >>
> >>> Nous souhaiterions au moins atteindre 100 Mb/s en L2
> >>>
> >>> Avez-vous des pistes pour arriver à ce résultat ?
> >>
> >> Un CPE plus "muscle" cote CPU.
> >> Ou VXLAN, mais ils faut aussi changer le CPE.
> >>
> >>> - Est-ce que le xconnect MPLS plutôt que l2tpv3 serait plus efficace au
> >>> niveau bande passante ?
> >>
> >> Entre les 2 sites c'est *TON* backbone ou celui d'un FAI (autre que
> toi) ?
> >> Si ce n'est pas le tien (toi qui fait tourner le LDP ou SR), tu peux
> >> oublier toute fonctionalite MPLS (dont xconnect). Sinon, ca se tente,
> mais
> >> ca peut ne pas etre aussi simple que ca a l'air.
> >>
> >>> - Le stacked Vlan semble intéressant mais j'ai du mal à voir si c'est
> >> pour
> >>> faire du tunnel L2..
> >>
> >> NON !
> >>
> >>> - Nos routeurs de coeur sont des ASR 1002-X
> >>
> >> C'est quoi ta topologie exacte ?
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3

[Fabien H]

Oui, c'est ma collecte.

Le but est de fournir au client un port Ethernet L2 en mode trunk sur
chacun de ses sites. Il pourra donc faire passer tous les VLAN qu'il
souhaite sans restriction.

Après le but serait de faire remonter ce "trunk" via le lien opérateur au
niveau routeur de coeur ASR pour bridger avec l'autre lien. Donc au niveau
routeur de coeur, je vais me retrouver avec le VLAN opérateur + les sous
vlan du client dans les trames (= QinQ). Donc pour le service instance,
impossible d'utiliser un QinQ avec un vlan défini à l'avance ?

En gros la question est : est-ce que je peux à la fois bridger en coeur de
réseau les L2 du client configurés en mode trunk avec service instance, et
à la fois définir sur ce même Vlan opérateur un niveau 3 (configuré en
QinQ) ?




Le mer. 12 juin 2019 à 09:54, David Ponzone  a
écrit :

> Si c’est ta collecte, tu peux créer un VLAN QinQ en plus sur chaque lien,
> et faire le service instance entre les QinQ.
>
> Ou alors j’ai pas compris ce qui coince dans ton cas.
>
> > Le 12 juin 2019 à 09:45, Fabien H  a écrit :
> >
> > Très sympa cette fonctionnalité !
> >
> > Par contre dans mon cas, c'est pas bon, parce que j'ai a la fois un L2 et
> > un L3 qui passent sur chacun des liens. Mais pour un L2 pur, c'est le
> top !
> >
> > Le mer. 12 juin 2019 à 09:20, David Ponzone  a
> > écrit :
> >
> >> Ou sinon, tu peux tenter de livrer le service depuis ton ASR à base
> d’EVC.
> >>
> >>
> >>
> https://gblogs.cisco.com/fr/reseaux/jai-teste-pour-vous-les-evc-ou-comment-bridger-sur-un-asr-1000-et-bien-plus-encore/
> >>
> >> Très très simple à configurer par contre faut que les 2 liens arrivent
> sur
> >> le même ASR.
> >>
> >>
> >> Le 12 juin 2019 à 08:55, Fabien H  a écrit :
> >>
> >> Si je ne m'en sors pas, oui je vais partir sur Mikrotik.
> >>
> >> Le problème c'est que c'est un client assez exigeant sur le matériel,
> et il
> >> ne connait pas Mikrotik, il va falloir lui expliquer que c'est du bon
> >> produit, .. à suivre ..
> >>
> >> Le mer. 12 juin 2019 à 08:51, Michael Lima  a
> >> écrit :
> >>
> >> Salut
> >> Moi je te conseil mikrotik avec eoip + fastpath et tu auras du bon débit
> >> en l2z
> >>
> >>
> >> Sent from my iPhone
> >>
> >> On 11 Jun 2019, at 10:52, Fabien H  wrote:
> >>
> >> Entre les 2 sites, c'est notre backbone : routeurs ASR 1002-X  / liens
> >> CELAN Orange
> >>
> >> La topologie :
> >>
> >> LAN Client <--> Ge0/1  Xconnect l2tpv3 [C1921] Ge 0/0 (IP) <-- FIBRE
> 200M
> >> --> (IP) ASR1002-X (IP) <--- FIBRE 200M --> (IP) Ge 0/0 [C1921] Ge0/1
> >> Xconnect l2tpv3 <--> LAN Client
> >>
> >> Oui c'est ce qui me semblait pour le routeur CISCO client : un peu trop
> >> léger, mais d'habitude pour ce genre de problèmes de perf, le CPU est à
> >> 100% et le routeur laggue.. Ici ce n'est pas le cas
> >>
> >> J'ai du mal à trouver les specs Cisco pour le througput sur les tunnels
> >> L2TPV3. S'il faut investir sur un routeur plus gros, on le fera mais
> >>
> >> lequel
> >>
> >> ..
> >>
> >> Merci
> >>
> >>
> >> Le mar. 11 juin 2019 à 10:40, Radu-Adrian Feurdean <
> >> fr...@radu-adrian.feurdean.net> a écrit :
> >>
> >> On Tue, Jun 11, 2019, at 09:55, Fabien H wrote:
> >>
> >> routeurs client (des CISCO 1921). Nous livrons de part et d'autre le
> >>
> >> tunnel
> >>
> >>
> >> Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert
> >>
> >> de
> >>
> >> fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous avons
> >>
> >> essayé
> >>
> >> 60 Mbps via une xconnect sur C1921 c'est deja pas mal.
> >>
> >> Nous souhaiterions au moins atteindre 100 Mb/s en L2
> >>
> >> Avez-vous des pistes pour arriver à ce résultat ?
> >>
> >>
> >> Un CPE plus "muscle" cote CPU.
> >> Ou VXLAN, mais ils faut aussi changer le CPE.
> >>
> >> - Est-ce que le xconnect MPLS plutôt que l2tpv3 serait plus efficace au
> >> niveau bande passante ?
> >>
> >>
> >> Entre les 2 sites c'est *TON* backbone ou celui d'un FAI (autre que
> >>
> >> toi) ?
> >>
> >> Si ce n'est pas le tien (toi qui fait tourner le LDP ou SR), tu peux
> >> oublier toute fonctionalite MPLS (dont xconnect). Sinon, ca se tente,
> >>
> >> mais
> >>
> >> ca peut ne pas etre aussi simple que ca a l'air.
> >>
> >> - Le stacked Vlan semble intéressant mais j'ai du mal à voir si c'est
> >>
> >> pour
> >>
> >> faire du tunnel L2..
> >>
> >>
> >> NON !
> >>
> >> - Nos routeurs de coeur sont des ASR 1002-X
> >>
> >>
> >> C'est quoi ta topologie exacte ?
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> >>
> >>
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/