Re: [FRnOG] [TECH] Bgp sous FRR

[Lucas REYMOND]

Salut,

Je me plante peut être mais ton problème n'est pas lié au fait que ton
routeur tourne Frr. Mais plutôt aux applications sous jacente (mettre à
jour).

Une méthode pas très propre serait de faire un SNAT sur ton pare feu pour
les packet généré localement afin d'éviter qu'il source avec une ip non
routable (voir le module addrtype de iptables ?)

++

Le dim. 26 mai 2024, 18:33, Nicolas  a écrit :

> Non, mais l'ip n'est pas routé en publique donc elle ne passe pas : d'où
> mon pb
>
> Le 26/05/2024 à 17:25, David Ponzone a écrit :
> > Et ton lien avec ton opérateur de transit est en IP privée ?
> >
> > David
> >
> >> Le 26 mai 2024 à 16:44, Nicolas  a écrit :
> >>
> >> Dans mon cas réel, BGP01 est le routeur de mon opérateur de transit :
> donc je n'ai pas accès.
> >>
> >>
> >>
> >> Le 26/05/2024 à 12:20, David Ponzone a écrit :
> >>> Tu peux pas faire en sorte que bgp01 natte 250.2 ?
> >>>
> >>> Sinon la méthode propre est d’avoir une interface de chaque routeur
> dans un vrf de management qui peut sortir.
> >>>
> >>> David Ponzone
> >>>
> >>>
> >>>
>  Le 26 mai 2024 à 11:56, Nicolas  a écrit :
> 
>  Bonjour,
> 
>  J'ai remonté une infra de test pour reproduire mon soucis.
> 
>  L'architecture
> 
>  PC de Test <--> Routeur  BGP02
> <-> Routeur BGP01
> <--> Box
>  192.168.253.10   192.168.253.1   / 192.168.250.2
>  192.168/250.1  / 192.168.2.111
>192.168.2.1
> 
>  J'ai rajouté une route static pour la maquette dans la box pour le
> chemin de retour vers le réseau 192.168.253.0/24 par 192.168.2.111
> 
>  Conf Routeur BGP01 :
>  !
>  ip route 0.0.0.0/0 192.168.2.1
>  !
>  router bgp 65000
>    bgp router-id 192.168.250.1
>    neighbor 192.168.250.2 remote-as 65001
>    neighbor 192.168.250.2 description BGP02
>    !
>    address-family ipv4 unicast
> network 0.0.0.0/0
> network 192.168.2.0/24
> neighbor 192.168.250.2 prefix-list Transit-In in
> neighbor 192.168.250.2 prefix-list Peering-Out-BGP02 out
>    exit-address-family
>  exit
>  !
>  ip prefix-list Transit-In seq 35 permit any
>  ip prefix-list Peering-Out-BGP02 seq 5 permit any
>  !
> 
> 
>  Conf Routeur BGP02 :
>  router bgp 65001
>    bgp router-id 192.168.250.2
>    neighbor 192.168.250.1 remote-as 65000
>    neighbor 192.168.250.1 description BGP01
>    neighbor 192.168.251.1 remote-as 65002
>    neighbor 192.168.251.1 description BGP03
>    !
>    address-family ipv4 unicast
> network 192.168.253.0/24
> neighbor 192.168.250.1 weight 100
> neighbor 192.168.250.1 prefix-list Transit-In in
> neighbor 192.168.250.1 prefix-list Peering-Out-BGP01 out
> neighbor 192.168.251.1 weight 100
> neighbor 192.168.251.1 prefix-list Transit-In in
> neighbor 192.168.251.1 prefix-list Peering-Out-BGP01 out
>    exit-address-family
>  exit
>  !
>  ip prefix-list Peering-Out-BGP01 seq 5 permit 192.168.253.0/24
>  ip prefix-list Transit-In seq 35 permit any
>  !
> 
>  Donc :
>  * Depuis le réseau 192.168.253.0/24 => accès internet ok
>  * depuis le routeur bgp01 => accès internet ok
>  * depuis le routeur bgp02 => Internet KO
> 
>  Quand je sniffe au niveau box, je vois le ping avec une ip source
> 192.168.250.2 soit l'ip d'interco entre les deux routeurs bgp
> 
>  La question : sous frr / quagga, comment forcer l'ip de source afin
> que je puisse installer des paquets et/ou mettre à jour le routeur svp ?
> 
>  Merci d'avance
> 
> 
> 
> 
> 
> > Le 17/05/2024 à 11:30, Willy Manga a écrit :
> > .
> >> On 17/05/2024 13:19, Nicolas de Brou wrote:
> >> Bonjour
> >>
> >> J’ai identifié mon interface
> >> Que je force ou pas l’ip source, je passe toujours par ce
> >> Un traceroute montre que je passe à travers 4 routeurs
> supplémentaires de cet opérateur avant de perdre la suite.
> > Sans aucune donnée réelle, je dirais dans tous les cas:
> >
> > - le fait de passer par le même opérateur dépend à la fois de votre
> configuration de routage locale et la destination
> >
> > - après le 4è saut, un routeur ne sait ni comment joindre la
> destination ou bien ne sait pas comment vous joindre en retour ou bien les
> deux
> >
> >
> >
> >
>  ---
>  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] recherche introduction réseaux et systèmes

[Lucas REYMOND]

Salut,

Le bouquin "*Réseaux*" d'Andrew Tanenbaum est une mine d'or pour commencer.
Je le recommande vivement (je crois qu'ils en sont à la 6e édition).

C'est parfois un peu long sur des concepts obsolètes mais c'est utile pour
mieux introduire les raisons pour lesquelles les réseaux sont comme ils
sont aujourd'hui.

A+

Le ven. 1 mars 2024 à 23:03, Erik LE VACON  a écrit :

> Bonsoir
> Le cours TCP/IP de François Laissus, est une bonne ref bien qu'ancienne,
> constituant une bonne intro à mon sens.
> Il s'en ser(vai)t de support de cours à l'Ecole Centrale devenue
> CentraleSupelec depuis; tout en l'enrichissant durant les cursus.
> Côté systèmes, le Tannenbaum fait référence, au delà des pugilats
> historiques kernel monolithique vs micro kernel modulaire.
> Bonne lecture
>
>
> Le 1 mars 2024 22:39:28 " b.pouth...@icloud.com via frnog"
>  a écrit :
>
> > Bonjour,
> >
> > Les livres réseaux pour les nuls contiennent les bases permettant de
> > comprendre un livre comme le référentielle pujolle 2024-2026 sur les
> > réseaux, se livres à le mérite d'être très précis et évite d'apprendre
> des
> > bêtises par de la sur-vulgarisation, pour se qui est de l'administration
> > systèmes et Windows je laisse l'avis à d'autre personnes dans mes études
> > Google et quelque bonne recherche suffisaient, une introduction avec
> > openclassroom puis des cours en anglais en vidéo ou des annales
> d'examens
> > comme base.
> >
> > Cordialement,
> >
> > Béryl
> >
> >
> > 
> > From: frnog-requ...@frnog.org  on behalf of
> Vinz
> > Jumpertz via frnog 
> > Sent: Friday, March 1, 2024 9:28:38 PM
> > To: frnog-m...@frnog.org 
> > Subject: [FRnOG] [MISC] recherche introduction réseaux et systèmes
> >
> > Hello la liste,
> >
> > je cherche des livres/articles (en français de préférence) pour
> > introduire des personne au réseau (modèle OSI, NAT/PAT, routing, ...) en
> > donnant une bonne vue d'ensemble.
> > Est-ce que vous auriez des recommandations
> >
> > Bon dedri
> >
> > Vincent
> >
> >
> > ---
> > 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] LACP et EVPN

[Lucas REYMOND]

 Merci à tous pour vos réponses et la documentation apportées.

C'est à présent plus clair dans mon esprit ;)

Le jeu. 20 juil. 2023 à 22:54, Pierre LANCASTRE 
a écrit :

> Hello
>
> Pour un même LAG LACP côté PE EVPN, tu dois avoir :
>
> - le même ESI
> - le même lacp system id
>
> Par contre, en principe, tu as une élection d'un Designated Forwarder (DF)
> et de BDF (DF de backup) pour gérer le BUM (pour éviter la duplication des
> paquets)
>
> ex la prez
> https://www.sanog.org/resources/sanog33/SANOG33_Tutorials-EVPN_Tutorial-Paresh_Khatri.pdf
> (page 17)
>
> J'ai googlé vite fait, tu trouveras probablement d'autres prez/images/autre
>
> ++
>
> Pierre
>
>
>
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  Sans
> virus.www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> <#m_6966926589797531698_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Le jeu. 20 juil. 2023 à 16:35, Lucas REYMOND  a
> écrit :
>
>> Merci pour la réponse.
>>
>> Donc c'est bien que LACP n'a pas besoin de synchronisation entre les PEs.
>>
>> J'en profite pour poser ma question car j'ai terriblement de mal à trouver
>> une documentation claire à ce sujet. On sort un peu de l'EVPN pour le
>> coup.
>>
>> N'y a t'il pas une notion d'élection dans le processus 802.3ad entre les
>> switchs pour savoir qui déclare les liens à mettre dans le LAG ou non ?
>>
>> Car si je comprends bien, dans le cas où les PEs sont "masters", on a une
>> sorte de split brain où chaque PEs déclare ses propres liens comme actif
>> sans avoir aucune information sur les liens de l'autre PE. Et le CE ne
>> voyant qu'un seul system-id en face ne comprend même pas qu'il y a 2
>> systèmes en face.
>>
>> Est ce que je vois juste ?
>>
>> Je ne sais pas si je suis bien clair mais je fais de mon mieux ;)
>>
>> Le jeu. 20 juil. 2023 à 21:52, Vincent Bernat  a écrit :
>>
>> > On 2023-07-20 16:12, Lucas REYMOND wrote:
>> > > Ma question est la suivante et je pense découle d'une méconnaissance
>> du
>> > > protocole LACP, Comment les PEs peuvent monter un LACP "commun" alors
>> > > qu'ils n'échangent manifestement aucune information ?
>> >
>> > Ils n'ont besoin de rien échanger car tu configures le system-id
>> > manuellement sur chaque PE (pour qu'il soit identique). C'est la seule
>> > chose nécessaire à partager pour que deux ports soient considérés dans
>> > la même agrégation de lien.
>> >
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

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

Re: [FRnOG] [TECH] LACP et EVPN

[Lucas REYMOND]

Merci pour la réponse.

Donc c'est bien que LACP n'a pas besoin de synchronisation entre les PEs.

J'en profite pour poser ma question car j'ai terriblement de mal à trouver
une documentation claire à ce sujet. On sort un peu de l'EVPN pour le coup.

N'y a t'il pas une notion d'élection dans le processus 802.3ad entre les
switchs pour savoir qui déclare les liens à mettre dans le LAG ou non ?

Car si je comprends bien, dans le cas où les PEs sont "masters", on a une
sorte de split brain où chaque PEs déclare ses propres liens comme actif
sans avoir aucune information sur les liens de l'autre PE. Et le CE ne
voyant qu'un seul system-id en face ne comprend même pas qu'il y a 2
systèmes en face.

Est ce que je vois juste ?

Je ne sais pas si je suis bien clair mais je fais de mon mieux ;)

Le jeu. 20 juil. 2023 à 21:52, Vincent Bernat  a écrit :

> On 2023-07-20 16:12, Lucas REYMOND wrote:
> > Ma question est la suivante et je pense découle d'une méconnaissance du
> > protocole LACP, Comment les PEs peuvent monter un LACP "commun" alors
> > qu'ils n'échangent manifestement aucune information ?
>
> Ils n'ont besoin de rien échanger car tu configures le system-id
> manuellement sur chaque PE (pour qu'il soit identique). C'est la seule
> chose nécessaire à partager pour que deux ports soient considérés dans
> la même agrégation de lien.
>

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

[FRnOG] [TECH] LACP et EVPN

[Lucas REYMOND]

Bonjour à tous,

Petite question technique pour les spécialistes d'EVPN.
J'essaie de créer un ESI LAG entre 2 PE et un CE.

Globalement, la configuration du Po sur un des PE ressemble à ça et est
identique sur l'autre PE (Arista).







*interface Port-Channel5   description TEST_ESI_LACP_TEST_LACP   !   evpn
ethernet-segment  identifier ::0303:0202:0101  route-target
import 03:03:02:02:01:01   lacp system-id 0303.0202.0101*


Une fois cette configuration en place, j'ai bien mon LACP qui est UP côté
PEs et CE. Mais en regardant mes routes EVPNs sur mes RRs, je ne vois
aucune trace de route type 1 ou type 4.

Ces types routes apparaissent uniquement lorsque j'intègre mon interface à
une mac-vrf (en gros quand je tag un VLAN appartenant à une mac-vrf). Cela
semble logique car les routes type 1/4 ne donnent pas d'information
relative au LACP mais plutôt sur l'appartenance à un ESI (j'ai encore du
mal avec ces notions).

Ma question est la suivante et je pense découle d'une méconnaissance du
protocole LACP, Comment les PEs peuvent monter un LACP "commun" alors
qu'ils n'échangent manifestement aucune information ?


PS: Il est possible que je mélange certains termes/notions désolé si ce
n'est pas clair.


Merci

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

Re: [FRnOG] [MISC] Solution SD-WAN Cloud ?

[Lucas Viallon]

Bonjour,

En faite c'est plus la partie multi-lien des sites distants qui m'interesse
plus que l'equilibrage de charge.

En gros, j'ai des sites qui ont 1 Ftth et 1 SIM 5G et d'autres 1 FO 1 FTTH
et 1 SIM 5G

La bascule automatique quand un lien tombe c'est surtout cela

merci

Le mer. 4 janv. 2023 à 09:22, David Ponzone  a
écrit :

> Lucas,
>
> A mon avis, faudrait définir ce que tu attends de la partie SD-WAN.
> Moi ce que je comprends dans ton mail, c’est avoir une VM qui peut
> recevoir plusieurs tunnels d’un CPE (1 par WAN ou 1 par appli) pour avoir
> un VPN avec de la répartition de traffic (intelligente ou pas ?).
> Dans ce domaine, j’ai jamais trouvé grand chose qui ne soit pas
> propriétaire.
> Je suis un fan de VyOS mais c’est pas lui qui va te modifier les règles de
> routage parce qu’un des WAN du CPE est chargé.
> A la limite, RouterOS (en VM et sur le CPE) serait plus intéressant, car
> avec le scripting intégré qui est quand même redoutable, tu peux imaginer
> avoir un tunnel par application critique, et les déplacer de WAN en
> fonction de la charge sur chaque WAN.
>
>
> > Le 4 janv. 2023 à 09:09, Lucas Viallon  a
> écrit :
> >
> > Bonjour,
> >
> > Je cherche une solution qui pourrait s'installer sur une instance d'un
> > cloud public et qui permettrait de raccorder le réseau privée interne des
> > instances a des sites distants via SD-WAN
> >
> > quelqu'un a déjà réalisé cela ?
> >
> > Bon j'ai pas encore défini coté sites distant quel type de routeur
> j'allais
> > mettre mais cela sera lié
> >
> > merci
> > Lucas
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

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

[FRnOG] [MISC] Solution SD-WAN Cloud ?

[Lucas Viallon]

Bonjour,

Je cherche une solution qui pourrait s'installer sur une instance d'un
cloud public et qui permettrait de raccorder le réseau privée interne des
instances a des sites distants via SD-WAN

quelqu'un a déjà réalisé cela ?

Bon j'ai pas encore défini coté sites distant quel type de routeur j'allais
mettre mais cela sera lié

merci
Lucas

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

[FRnOG] [JOBS] Bordeaux Recherche alternance Administrateur Système et réseaux

[Lucas R.]

Bonjour,
Je me permet de contacter la liste a une heure si tardive, car je suis a 
la recherche d'une alternance en tant qu'administrateur système et réseaux.


Détenteur d'un BTS : Services Informatiques aux Organisations Option 
Solutions d’Infrastructures et Systèmes Réseaux au LYCEE GUSTAVE EIFFEL 
de BORDEAUX


J’intègre le Bachelor Administrateur Systèmes et réseaux au CESI de 
Bordeaux en Octobre 2022. Dans ce cadre, je suis actuellement disponible 
pour une alternance en tant qu'*Administrateur Systèmes et Réseaux.*

Je ne recherche pas pour octobre, *je suis disponible dès maintenant !*

Une vraie passion :
Passionné par l’informatique depuis plusieurs années maintenant, j’ai pu 
apprendre et enrichir mes connaissances ainsi que mon bagage technique. 
Je suis très investi dans ce domaine qui me tient à cœur.
Aujourd'hui, je cherche à approfondir mes connaissances mais surtout à 
les mettre en place en entreprise, grâce a ce Bachelor en Alternance.

Mon profil vous intéresse ? Contactez moi !

Cursus : *D'octobre 2022 à Septembre 2023*
Rythme d’alternance : *3 semaines en entreprise / 1 semaine de cours*
Lieu : Région Bordelaise

*N'hésitez pas à me contacter !*
Mail : j...@lucasr.fr
Téléphone sur demande par mail

Bien cordialement,
Lucas R.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] ICMP "Communication Administratively Prohibited" en 4G entre EuroInformation Telecom et Neo Telecoms

[Lucas]

On 23/06/22 at 11:49 +0200, Matthieu Racine wrote:
> Je vais peut être dire une énorme bêtise, mais il me semble que le problème
> vient du fait que le nombre de connexions actives par client est limité par
> les routeurs CGNAT de BTBD (ex EIT). Vu le nombre de clients derrière chaque
> IP, ils "protègent" les ressources en mémoire de leurs équipements en
> restreignant ces connexions.

Effectivement, j'arrive à établir (et à maintenir) environ 230
connexions TCP en parallèle, mais quand j'en rajoute, je reproduis le
problème. Donc c'est effectivement plutôt un problème de nombre max de
connexions autorisées.

> Je ne sais pas si cette restriction est également active sur les autres
> opérateurs avec CGNAT...

Avec un abonnement Sosh, je ne reproduis pas le problème (ça fonctionne
jusqu'à au moins 1000 connexions)

Lucas


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

Re: [FRnOG] [BIZ] SIM Bouygues MVNO: pas neutre ?

[Lucas]

On 23/06/22 at 03:04 +0200, David Ponzone wrote:
> > Le 22 juin 2022 à 21:31, Lucas  a écrit :
> > 
> > Bonjour David,
> > 
> > On 22/06/22 at 20:53 +0200, David Ponzone wrote:
> >> Petite question aux utilisateurs d’une offre MVNO(-light) Bouygues:
> >> 
> >> Vous avez remarqué qu’il y avait des restrictions IP sur le traffic data ?
> > 
> > Ton mail me fait remarquer qu'un mail que j'avais essayé d'envoyer il y
> > a quelques jours, concernant un MVNO Bouygues, n'est pas passé. Je viens
> > de le renvoyer.
> > 
> > Tu constates ça avec quel MVNO ? Attention, je crois que certains MVNO
> > Bouygues (ceux de ex-EuroInformation Telecom) conservent un coeur de
> > réseau spécifique (c'est mon cas avec NRJ Mobile).
> 
> EIT est un full-MVNO. A ce titre, on peut imaginer qu’ils ont fait un choix 
> différent pour le CGNAT.
> A priori, tous les MVNO(-light) de Bouygues devraient avoir le problème 
> puisqu’ils se reposent totalement sur l’infra Bouygues.
> 
> >> Du genre les communications TCP sur certains ports qui passent mais sont 
> >> altérées par le CGNAT.
> > 
> > Que constates-tu exactement comme altération ?
> 
> L’outil Speedtest de Mikrotik permet de tester la bande passante up/down 
> entre 2 Mikrotiks.
> Et bien ça échoue.
> Le début de la connexion se fait normalement.
> Si A est le Mikrotik derrière le CGNAT, ça donne:
> A (TCP RANDOM)  — — —SYN—— — —>  B (TCP 2000)
> A ((TCP RANDOM) <———SYN ACK——— B (TCP 2000)
> A (TCP RANDOM)  — — — ACK —— — —> B (TCP 2000)
> 
> Ensuite B envoie un TCP PSH à A.
> Avec le CGNAT Bouygues, A ne reçoit jamais ce PSH.
> 
> Ce qui est rigolo, c’est que si à la place du CGNAT Bouygues, j’ai un FTTO 
> propre mais qui traverse ensuite un Fortinet , j’ai le MÊME comportement.
> Et justement, il est connu que FortiOS reconnait l’échange du protocole 
> Speedtest de MK sur le port TCP 2000 comme du SCCP, et fout le boxon à cause 
> d’un ALG à la con (j’ai à ce jour pas réussi à le désactiver, j’ai pas 
> cherché très très fort ceci dit, mais c’est plus compliqué que pour couper le 
> SIP ALG).
> 
> De là à penser que le CGNAT Bouygues, c’est du Fortinet, il n’y a qu’un pas.
> Vu en plus que Bouygues et Fortinet ont communiqué il y a quelques années sur 
> un partenariat sur du Fortigate-VM...
> 
> Sur le fond, je vais pas faire un cake pour un port TCP mais comme je peux 
> pas savoir s’il y en a pas (plein) d’autres, ça va être bye-bye Bouygues.

Intéressant. Je reproduis le problème avec mon abonnement NRJ Mobile
(EIT), par exemple avec:
server$ nc -l -p 2000 > t
client$ dd if=/dev/urandom bs=5k count=1 > t
client$ nc -N server 2000 < t

Ce qui est amusant, c'est que le client recoit bien des ACK en échange
des données, mais ce n'est pas le serveur qui les envoie.  D'ailleurs le
TTL des ACK est de 62, contre un TTL de 51 pour les ACK d'un échange
normal (sur un autre port).

La fin de connexion n'est pas filtrée, mais est réécrite pour que les
données qui ont été interceptées mais acquittées par la middlebox ne
perturbent pas l'échange.
Vu du client, ça donne:
53160 → 2000 [FIN, ACK] Seq=5121 Ack=1 Win=64256 Len=0 TSval=3941021092 
TSecr=1817006976
2000 → 53160 [FIN, ACK] Seq=1 Ack=5122 Win=180224 Len=0 TSval=1817006982 
TSecr=3941021091
53160 → 2000 [ACK] Seq=5122 Ack=2 Win=64256 Len=0 TSval=3941021152 
TSecr=1817006982
mais vu du serveur, ça donne:
2612 → 2000 [FIN, ACK] Seq=1 Ack=1 Win=180224 Len=0 TSval=1817006982 
TSecr=2630718538
2000 → 2612 [FIN, ACK] Seq=1 Ack=2 Win=65280 Len=0 TSval=2630718559 
TSecr=1817006982
2612 → 2000 [ACK] Seq=2 Ack=2 Win=180224 Len=0 TSval=1817006984 TSecr=2630718559
=> le numéro de séquence ("relatif", c'est ce que wireshark affiche) est
5121 vu du client, mais 1 vu du serveur.

Le TTL élevé (62) fait penser que c'est l'un des premiers équipements
qui réalise cette opération, ce qui expliquerait pourquoi on voit le
problème à la fois avec Bouygues et EIT.

Lucas


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

Re: [FRnOG] [BIZ] SIM Bouygues MVNO: pas neutre ?

[Lucas]

Bonjour David,

On 22/06/22 at 20:53 +0200, David Ponzone wrote:
> Petite question aux utilisateurs d’une offre MVNO(-light) Bouygues:
> 
> Vous avez remarqué qu’il y avait des restrictions IP sur le traffic data ?

Ton mail me fait remarquer qu'un mail que j'avais essayé d'envoyer il y
a quelques jours, concernant un MVNO Bouygues, n'est pas passé. Je viens
de le renvoyer.

Tu constates ça avec quel MVNO ? Attention, je crois que certains MVNO
Bouygues (ceux de ex-EuroInformation Telecom) conservent un coeur de
réseau spécifique (c'est mon cas avec NRJ Mobile).

> Du genre les communications TCP sur certains ports qui passent mais sont 
> altérées par le CGNAT.

Que constates-tu exactement comme altération ?

Lucas


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

[FRnOG] [TECH] ICMP "Communication Administratively Prohibited" en 4G entre EuroInformation Telecom et Neo Telecoms

[Lucas]

Bonjour,

J'ai un abonnement 4G NRJ Mobile (une des marques de EuroInformation
Telecom -- maintenant Bouygues Telecom Business-Distribution) que
j'utilise dans un routeur 4G.

De manière aléatoire, je recois des ICMP type 3 / code 13
("Communication Administratively Prohibited") en réponse à des SYN
TCP, a priori surtout lorsque je navigue sur des sites qui génèrent
beaucoup de connexions.

Je le reproduis de manière systématique au bout de quelques secondes avec:
mtr --tcp -P 443 www.nrjmobile.fr

Un traceroute avant l'apparition du problème:

$ tcptraceroute -q 1 www.nrjmobile.fr 443
Tracing the path to www.nrjmobile.fr (145.226.174.108) on TCP port 443 (https), 
30 hops max
 1  192.168.11.1  0.570 ms
 2  *
 3  *
 4  10.64.96.62  33.906 ms
 5  *
 6  ei-telecom-gw2.tcr2.th2.par.cust.as8218.eu (83.167.60.227)  40.152 ms
 7  ae25.tcr2.th2.par.core.as8218.eu (83.167.60.226)  38.294 ms
 8  ae24.ter4.eqx2.par.core.as8218.eu (83.167.56.193)  37.433 ms
 9  193.253.13.102  38.469 ms
 [...]
22  lil-www.nrjmobile.fr (145.226.174.108)  45.029 ms
23  lil-www.nrjmobile.fr (145.226.174.108) [open]  39.315 ms

Un traceroute quand le problème se produit:

Tracing the path to www.nrjmobile.fr (145.226.174.108) on TCP port 443 (https), 
30 hops max
 1  192.168.11.1  0.526 ms
 2  *
 3  10.64.35.94  34.028 ms
 4  10.64.96.62  30.197 ms
 5  10.64.96.57  29.182 ms
 6  ei-telecom-gw2.tcr2.th2.par.cust.as8218.eu (83.167.60.227)  43.163 ms
 7  185.228.229.172  37.179 ms !A

Le routeur qui renvoie l'erreur est toujours dans la plage
185.228.229/24, qui appartient à EuroInformation Telecom.

Je le reproduis sur toutes les destinations qui transitent par Neo
Telecoms (as8218.eu), mais pas sur les autres (celles qui peer
directement avec EIT ? mais il y en a peu, par exemple www.google.com).

Ca ressemble à un problème de rate limiting trop agressif (?).

J'ai contacté l'assistance technique, mais sans réponse satisfaisante
("la couverture est OK, ça doit être un problème du routeur").

Je pense que je vais juste changer d'opérateur, mais je suis curieux de
savoir si quelqu'un a une explication.

Je me demandais aussi s'il y avait un site qui référence les atteintes à
la neutralité du net par les opérateurs mobiles, histoire de savoir à
quoi m'attendre (j'ai l'impression que Sosh est mieux de ce côté là,
mais je me demande comment se positionnent les autres).

Lucas


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

Re: [FRnOG] [MISC] upgrade du routeur Cisco perso

[Christophe LUCAS]

Salut,

C ou un truc de la gamme, tiens entre 500M et 1G sans fioriture.

Cdt,
---
Christophe Lucas


- Mail original -
De: "Michel Py via frnog" 
À: frnog@frnog.org
Envoyé: Lundi 4 Octobre 2021 11:12:50
Objet: [FRnOG] [MISC] upgrade du routeur Cisco perso

Bonjour à toutes et à tous,

Je viens d'hériter de 2U dans un rack pas trop pourri et il faut que j'y mette 
un router pour mes petits besoins perso. Le claoude privé, les sauvegardes de 
mes fichiers de reproduction humaine, toussa.
J'écoute les suggestions même con; pas cher mon fils c'est toujours à l'ordre 
du jour; c'est pas de la prod mais d'un autre coté faut pas que ça devienne un 
boulot à temps plein.

Pas Cisco : j'ai plein d'options; ne pas suggérer. EIGRP nécessaire et j'ai pas 
envie de débogger FRR.

Bande passante : 1G ça serait sympa mais pas nécessaire. 100M pas suffisant.
Le routeur maison aujourd'hui c'est un 2851; avec ma config ça plafonne entre 
30M et 40M.

- 3951 pas cher mais un peu lent sur les bords; vu ce que je sors péniblement 
d'un 2851 je ne m'attends pas à un miracle avec n'importe quel modèle ISR G2 
avec un CPU de ZX81.
- 4451 un peu cher.
- 4431 ça ferait l'affaire.

IOU avec une bidouille ?
XRv 9000 avec une bidouille ?

J'écoute les bidouilleuses et bidouilleurs ?

Merci,
Michel.


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


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

[FRnOG] [TECH] Cisco/Teltonika RUT950 et Bouygues

[Lucas Viallon]

Bonjour,

est ce que quelqu'un a deja configuré une solution PPPoE a partir d'un
cisco connecté a un Teltonika RUT950 avec une carte SIM 4G Bouygue (leur
offre PPP, pas un accès internet avec VPN)

je cherche a savoir comment configurer le Teltonika, la conf type cisco
pour que cela fonctionne avec les forwarder bouygues je l'ai

merci d'avance

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

[FRnOG] [TECH] QoS 2 sur un cisco 1841 ?

[Lucas Viallon]

Bonjour,

Pour connecter un petit site via une FTTH, je dois mettre un routeur avec
un tag 802.1Q a 2900 et un 802.1P a 2, j'ai donc fait une config type:

policy-map 802.1p
 class class-default
  set cos 2
  set cos-inner 2
  set qos-group 2

interface GigabitEthernet0/0.2900
encapsulation dot1Q 2900
 pppoe-client dial-pool-number 1
 service-policy output 802.1p


interface Dialer0
 ip address negotiated
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1450
 encapsulation ppp
 ip tcp adjust-mss 1410
 dialer pool 1
 dialer-group 1
 ppp authentication chap callin
 ppp chap hostname x
 ppp chap password 0 x
 no cdp enable




Tous ce qui est pas taggué en 802.Q a 2900 ET 802.1P a 2 est droppé

ne recevant pas de trafic/flux de mon routeur cisco, j'en deduis qu'il
n'envoit pas les tag

quelqu'un a déjà fait une config de ce type sur un cisco et qui fonctionne
pour me donner un exemple ?

merci

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

Re: [FRnOG] [FRNOG] [TECH] policy-map not applicate on PPP

[Christophe LUCAS]

Bonjour,

De ma connaissance, l'application se fait en deux phases (du moins dans mon cas 
cela fonctionne parfaitement) sur de l'IOS XE : 

ip:qos-policy-out=add-class(sub,(class-default),shape(200))
ip:sub-qos-policy-out=SHAPER-QOS-2M

Avec un truc du genre : 

policy-map SHAPER_QOS_2M
 class class-default
  shape average 1
   service-policy PM_QOS-2M

A plus,

~Christophe

- Mail original -
De: "Tony" 
À: frnog-t...@frnog.org
Envoyé: Jeudi 27 Mai 2021 09:00:22
Objet: [FRnOG] [FRNOG] [TECH] policy-map not applicate on PPP

Bonjour la liste,
Je me rapproche de vous car je recherche un expert cisco :-) car en effet,
ça fait un moment que j'essaye de débug un problème.
Ce problème est que je n'arrive pas à appliquer mes policy-map lorsque
une PPP monte.

Au niveau radius j'ai simple un :
Cisco-avpair += "ip:sub-qos-policy-out=PM-QOS-2M",

J'ai essayé 3 IOS différent pas mieux, j'ai actuellement l'IOS
: asr1002x-universalk9.16.09.07.SPA.bin

Je ne pense pas que le problème provienne de la policy-map, car j'arrive à
l'appliquer sur des sub-interface.

Voici l'erreur que j'ai en débug :
May 27 06:51:35.599: PPPoE handle inconsistency: handle 0x580003AF returns
session 0x7FEB6F0BE280 with handle 0x0
May 27 06:51:35.599: SSS PM: SSS PM: Added peruser feature infos when
config_applied already setuser-defined classes with queueing features are
not allowed in a service-policy at sub-interface/pvc/service-group

May 27 08:51:35: %QOS-6-POLICY_INST_FAILED: Service policy installation
failed on
 SSS session identifier 381 -. service-policy not applicable for interface
features. policy:PM-QOS-2M, dir:OUT, ptype:, ctype:DEFAULT

Nous pouvons en discuter en privé si besoin.
Merci

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


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

Re: [FRnOG] [BIZ] Boitier Multi-ISP

[Lucas Viallon]

merci je vais regarder Fortinet et  Ubiquiti

Justement non on ne peut pas splitter le LAN en plusieurs subnets, une des
raisons est que la livebox n'a pas la possibilité de router une classe en
interne du coup on aurait un double NAT
ensuite le second routeur on ne peut pas le mettre dans un autre range que
celui des postes lan (c'est assez specifique)



Le mar. 4 mai 2021 à 14:15, Guillaume Tournat  a
écrit :

> un petit FortiGate fera cela très bien. c'est quoi les débits des liens ?
>
> par contre, ce serait mieux de faire des subnets d'interco distincts
> pour les routeurs opérateurs, différents du lan
>
>
> Le 04/05/2021 à 12:02, Lucas Viallon a écrit :
> > Bonjour,
> >
> > Je recherche un bon boitier pour faire du routage/équilibrage de charge
> sur
> > deux accès internet.
> > Quelqu'un pourrait me conseiller ?
> >
> > En gros, j'ai deux routeurs:
> >
> > 192.168.0.250 et 192.168.0.251
> > je voudrais que le boitier soit en 192.168.0.254 et fasse un équilibrage
> de
> > charge entre les deux passerelles.
> >
> > merci
> > Lucas
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>

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

Re: [FRnOG] [BIZ] Boitier Multi-ISP

[Lucas Viallon]

Justement non, je ne peux pas couper l'un des deux routeurs du lan.


Pfsense, bof pas trop un truc soft bricolé sur un mini pc et bien sur pas
de VM y a pas de serveur sur le site.

Il s'agit d'un lien FTTH Orange d'un coté avec une livebox qui ne dispose
pas de 'l'option' permettant de creer des routes internes
2x1gbits il me semble ...

Et coté second routeur, il y a un lien FTTB avec un vlan a 10Mbits garantie
et un vlan a 1Gbits sans garantie




Le mar. 4 mai 2021 à 12:49, David Ponzone  a
écrit :

> Tu peux pas mettre ton nouveau routeur en coupure entre le LAN et les 2
> routeur existants, ça serait quand même plus propre.
> Faut voir le débit des 2 liens, mais si tu aimes gérer à la Mano: un
> Mikrotik à 40€.
> Sinon: pf ou Edge aussi
> Ou carrément Fortinet
> Ou 20 ou 30 autres solutions :)
>
> > Le 4 mai 2021 à 12:02, Lucas Viallon  a écrit :
> >
> > Bonjour,
> >
> > Je recherche un bon boitier pour faire du routage/équilibrage de charge
> sur
> > deux accès internet.
> > Quelqu'un pourrait me conseiller ?
> >
> > En gros, j'ai deux routeurs:
> >
> > 192.168.0.250 et 192.168.0.251
> > je voudrais que le boitier soit en 192.168.0.254 et fasse un équilibrage
> de
> > charge entre les deux passerelles.
> >
> > merci
> > Lucas
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

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

[FRnOG] [BIZ] Boitier Multi-ISP

[Lucas Viallon]

Bonjour,

Je recherche un bon boitier pour faire du routage/équilibrage de charge sur
deux accès internet.
Quelqu'un pourrait me conseiller ?

En gros, j'ai deux routeurs:

192.168.0.250 et 192.168.0.251
je voudrais que le boitier soit en 192.168.0.254 et fasse un équilibrage de
charge entre les deux passerelles.

merci
Lucas

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

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Lucas]

On 18/03/21 at 10:41 +0100, Philippe ASTIER via frnog wrote:
> >> 99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.
> > Tu connais les contraintes de dispo de mon client et ce qu'il a lui-même
> > vendu à ses clients ?
> 
> Non. Je sais juste que 99,99%, ça fait classe, il y a beaucoup de
> chiffres. Je voulais juste faire remarquer que ça fait près de 3,65
> jours de downtime. Si c’est pour faire de l’argent ça a un coût.

99.99%, ça fait 3.65 jours par an seulement les années qui durent 100 ans.
Les années normales, ça fait plutôt 52 minutes.

L.


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

[FRnOG] [MISC] Outils pour surveillance ping

[Lucas Viallon]

Bonjour,

Comme tous le monde, nous devons de temps en temps placer une liaison en
surveillence car nos clients on des "micro coupures".

Le genre de micro coupure que quand vous testez vous ne voyez rien car il
faut le faire sur 24 a 48h.

Jusqu'ici on lance un ping sur une machine et on regarde 24h plus tard
combien on a perdu de ping. Pas tres fiable et pratique.

Notre supervision Centreon fait un test de quelques pings toutes les 5mn
donc on ne peut pas voir.

Quelqu'un sait si il y a un outils opensource style une interface web, on
indique l'ip a surveiller, cela lance un ping permanent (ou qui ce
renouvelle toutes les x minutes sans periode de blanc)  et ou l'on peut
retrouver dans l'interface un mini compte rendu  ?

merci

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

[FRnOG] [TECH] Lantolan avec nexus 31108 ?

[Lucas Viallon]

Bonjour

Quelqu’un dans son réseau a déjà réussi à faire un lantolan entre deux
ports de deux nexus 31108 ?

J’ai dans mon réseau deux nexus 31108 raccordé via une FON à 100gbits, je
voudrais dessus faire un lien layer deux qui transporte tous les protocoles
(802.1q ,cdp, bpu etc ..) j arrive à transporter les vlan mais pas le reste
du coup je me demande si c’est possible

Merci d’avance pour vos suggestions :)
Lucas

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

[FRnOG] [TECH] Testeur de ligne sous linux ?

[Lucas Viallon]

Bonjour a tous,

Comme tous fournisseur de lien internet, je suis soumis régulièrement a des
tickets d'incidents portant sur la qualité de la ligne que je fournis. Le
traditionnel j'ai pas le débit souscrit 

Dans 99% des cas, le problème n'en n'ai pas un ... Malheureusement le
client qui achète une fibre 500 Mbits veut avoir de multiples liens point a
point atteignant 500 mbits a chaque fois ...

Cette activité de "démontrer" qu'il a le débit et la pédagogie nécessaire
pour leur faire comprendre qu'au dehors de notre réseau nous n'étions plus
maitre des débits est très chronophage, et même si on serait en droit de
facturer des interventions a tords comme le fond les gros du secteurs, chez
nous cela casse la relation commercial avec le client qui, pour lui, c'est
du "tout compris" dans la prestation.

Bref, pour réduire la nécessité d'intervenir sur site, j'ai commencé a
envoyer des boitiers sous linux avec un simple iperf et cela réduit quand
même notre charge de travail.

Pour le moment c'est un peu du bricolage, un linux monté en 10mn et un
iperf, je cherche a savoir si d'autres fournisseurs utilisent cette
méthodologie de test, principalement pour savoir si ils auraient trouvé des
outils capable de pousser plus loin les tests et pourquoi pas de générer
des rapports ?

merci d'avance
Lucas

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

Re: [FRnOG] [TECH] probleme de TTL-security sur une session BGP

[Guillaume LUCAS]

Bonjour,

Le 13/12/2020 à 10:18, Raphaël Jacquot a écrit :

quelqu'un aurait une idée ?


Je n'ai pas d'idée sur la session qui ne monte pas. En revanche, voici 
ce que j'ai écrit, en 2014, sur ttl-security :


« Le TTL est décrémenté uniquement en cas de forward. Un routeur reçoit 
un paquet, se rend compte qu'il ne lui est pas destiné, cherche une 
entrée dans sa FIB, décrémente le TTL. Si TTL = 0, il détruit le paquet 
et envoie un message ICMP « Time to Live exceeded in Transit » (type 11, 
code 0  ) à celui qui prétend en être l'expéditeur. Si TTL > 0, le 
routeur forward le paquet.


Le RFC 5082 - The Generalized TTL Security Mechanism (GTSM) 
[https://tools.ietf.org/rfc/rfc5082.txt] explique clairement que le 
paquet doit avoir un TTL fixé à 255 à l'émission et qu'il doit être 
inchangé à la réception. On lit souvent, y compris dans la CLI Cisco[1], 
que l'on doit avoir un TTL supérieur ou égal 254 à la réception : c'est 
une erreur ou plutôt, d'après mes recherches, un sacrifice de la 
sécurité sur l'autel de la compatibilité avec de vieilles architectures 
qui ne devaient pas gérer correctement la décrémentation du TTL (source 
: le plus loin que j'ai pu remonter, la présentation de cette 
proposition de TTL à 255 lors de la 27e rencontre NANOG : The BGP TTL 
Security Hack (BTSH) 
[http://www.nanog.org/meetings/nanog27/presentations/meyer.pdf]). »


Source : 



Bonne journée.


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

Re: [FRnOG] [MISC] Appli orientation antenne 4G : GEORADIO

[Lucas G.]

Coucou !

Très belle découverte, l'appli est vraiment très propre et intuitive !

Merci pour ce partage :)

Le 11/20/2020 à 12:52 PM, Julien GONTARD a écrit :
> Hello la liste,
>
> Pour ceux qui cherchent une appli pour orienter les antennes pour de la 4G, 
> je suis tombé sur Georadio.
>
> Pourquoi l'essayer:
>
> 1) Développée par un Français: Hugo Martin, et ce gracieusement pour aider 
> les particuliers (et les pro )
>
> 2) Elle est super bien foutue et très lisible
>
> 2) Fonctionnalités : ++ : Permet d'avoir l'équivalent de cartoradio sur 
> mobile en mieux + fonction boussole + couplé aux données altimétriques.
> -   :  Disponible uniquement sur iphone / 
> Pas de données de relevées dispo type nperf car faudrait les ressources pour 
> stocker (Peut-être des IT Angel pourront lui donner de la ressource pour 
> continuer d'améliorer ce joli projet?)
>   
> Je vous laisse la télécharger pour vous rendre compte qu’elle est top (et 
> j'espère lui mettre le petit commentaire qui va bien)
>
> Nb Opensignal une autre appli semble orienter la boussole dans l'orientation 
> de l'antenne de la sim en place. Avez-vous vous des retours d'expérience sur 
> la fiabilité? 
>
>
> Cordialement,
>  
> Julien GONTARD
> ICOW SYSTEMS
> Mail :  jgont...@icow-systems.com
> Web : www.icow-systems.com/
> Hotline support : 0811656500 
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
-- 

Lucas G.
Développeur Web / Web developper
Site:  lourys.fr <http://lourys.fr>
Email:  m...@lourys.fr <mailto:m...@lourys.fr>
GPG fingerprint:  |D543 7133 B992 E1E5 5122 A60E 2D42 637C 20CF 3638|



IMPORTANT : Le contenu de cet e-mail et les éventuelles pièces jointes
sont confidentiels. Il est strictement interdit de partager toute partie
de ce message avec des tiers, sans le consentement écrit de
l'expéditeur. Si vous avez reçu ce message par erreur, merci de le
signaler en y répondant, puis de les supprimer afin que nous puissions
nous assurer qu'une telle erreur ne se reproduise plus.

IMPORTANT: The contents of this email and any attachments are
confidential. It is strictly forbidden to share any part of this message
with any third party, without a written consent of the sender. If you
received this message by mistake, please reply to this message and
follow with its deletion, so that we can ensure such a mistake does not
occur in the future.


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

[FRnOG] [TECH] Equinix Exchange Paris / Google ?

[Lucas Viallon]

Bonjour,

J'ai des pertes de paquets sur l'Equinix Exchange Paris vers google
notamment:

ping
Protocol [ip]:
Target IP address: 195.42.145.65
Repeat count [5]: 50
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 50, 1500-byte ICMP Echos to 195.42.145.65, timeout is 2 seconds:
!!.!!.!!.!!.!!
Success rate is 92 percent (46/50), round-trip min/avg/max = 1/1/3 ms

cela varie entre 10 et 20%

je suis le seul ?

a+

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

[FRnOG] [MISC] Routeur 4G ?

[Lucas Viallon]

Bonjour,

Besoin d'un nouveau conseil, je dois fournir des accès via le réseau 4G.

Mon opérateur m'a fourni pour tester une carte SIM et un routeur type
Huawei B525.
d'abord enchanté, je me suis trouvé vite bloqué par le manque de fonction
de ce routeur.

J'arrive sans soucis a le connecter en VPN via l'interface a mon reseau,
mais impossible de prendre la main dessus a distance (ne serait ce que pour
manager le routeur Huawei)

Donc deux petites questions:

1- Quelqu'un utilise régulièrement les Huawei B525 et peut me confirmer que
l'on a aucune possibilité de:
   * le manager à distance via l'IP WAN 4G ou l'IP VPN ?
   * avoir accès a un CLI SSH pour avoir des fonctions routeurs evolués ?

2- Si effectivement le B525 est beaucoup trop limité, quelqu'un pourrait me
conseiller un autre routeur 4G qui aurait une fonction VPN L2TP et des
fonctions de routage ?

merci d'avance

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

[FRnOG] [MISC] Saisi de l'ARCEP ?

[Lucas Viallon]

Bonjour,

Je ne sais pas si c'est que pour nous, mais depuis 3 à 4 mois le support
GAMOT d'Orange
pour les Adsl/Vdsl, c'est vraiment invivable 

Bon certe c'est du GP, mais quand même ... des coupures de 15j a plusieurs
semaines ..
3 voir 4 tickets pour avoir la résolution ...
J'ai 90% de mes tickets qui sont à >10j de résolution.

Bref, on perd des clients car ils pensent qu'aller directement chez OBS le
délais sera beaucoup plus courts.

Les courriers à Orange, cela sert à rien, cela reste lettre morte.

ALors je cherche a savoir si on peut notifier l'Arcep des
dysfonctionnements qui crées une concurrence déloyale.

merci pour vos conseils
Lucas

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

Re: [FRnOG] [MISC] cas d'utilisation 5G

[Lucas]

On 29/09/20 at 09:33 +0200, Emmanuel Jacquet wrote:
> Bonjour
> 
> Le lun. 28 sept. 2020 à 23:08, Lucas  a écrit :
> 
> > La télémédecine
> > ===
> > Il y a vraiment des hopitaux qu'on envisage d'utiliser pour de la
> > télémédecine et qui ne sont pas connectés à Internet par de la fibre
> > et/ou par un réseau FH ?
> >
> 
> 
> Non, le cas d'usage télémédecine, c'est dans l'autre sens. Imagine un
> patient âgé au fin fond de la campagne, l'infirmière qui passe
> habituellement peut mettre en place un système de monitoring/visio/whatever
> qui a besoin de 4/5G pour que le médecin puisse checker à distance.

OK, ce cas (maintien à domicile via monitoring) est intéressant, et
généralisable en dehors de la campagne.

Pour le cas de la campagne, j'ai l'impression que ce qui est surtout
important, c'est d'avoir une connexion. Que ça passe en 4G, 5G ou ADSL
ne change pas grand chose, non ?

Lucas


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

[FRnOG] [MISC] cas d'utilisation 5G

[Lucas]

Bonjour,

Dans le débat sur la 5G, j'avoue avoir un peu de mal à faire le tri
entre les arguments sur les cas d'utilisation. Je vais tenter d'en
résumer ce que j'en comprends (et aussi ce que je ne comprends pas).
N'hésitez pas à me corriger ou à me compléter, je suis très loin d'être
un spécialiste.

Saturation
==
L'argument pour la 5G qui me semble le plus défendable est celui de la
saturation dans certaines zones. Les fréquences actuelles sont
saturées. Ajouter des fréquences (utilisées par la 5G) avec la bande des
3.5 GHz permetta de soulager les fréquences actuelles. De plus, le
protocole est plus efficace, donc aidera aussi à limiter la saturation.

L'IoT généralisé

C'est un argument que je ne comprends pas.
Les opérateurs proposent déjà des réseaux pour l'IoT, en LORA, en LTE-M
(Orange, Bouygues), ou en NB-IoT (SFR), avec des couvertures pas
ridicules. Je ne comprends pas ce que la 5G change à ça.
Dans la 5G, il y a "Industrial IoT" qui semble être l'évolution de
LTE-M. Mais il n'y a rien de révolutionnaire ?
Par ailleurs, si je vois bien l'intérêt de reposer sur le réseau d'un
opérateur pour tracker des véhicules à travers la France, j'ai du mal à
comprendre les exemples de contrôle de machines-outils dans un hangar.
Pourquoi ne pas se servir d'un réseau local filaire ou sans fil dans ce
cas ?

La télémédecine
===
Il y a vraiment des hopitaux qu'on envisage d'utiliser pour de la
télémédecine et qui ne sont pas connectés à Internet par de la fibre
et/ou par un réseau FH ?

Le médecin en campagne
==
C'est un autre argument que je ne comprends pas (surtout que ce use case
n'est pas présenté de manière très précise, d'habitude).
J'ai l'impression que:
- soit ce médecin est déjà fibré (ce qui n'est pas impossible avec un
  déploiement via RIP)
- soit il est déjà couvert par la 4G, et peut avoir un débit très
  convenable avec un routeur 4G LTE cat 6; il est possible qu'il soit
  couvert bientôt par la 5G, et ça sera marginalement mieux, mais ça ne
  va pas lui changer la vie.
- soit il n'est pas couvert par la 4G, et donc il y a peu de chances
  qu'il soit couvert rapidement par la 5G

Question annexe: l'ADSL
===
Je me demandais quel est l'intérêt aujourd'hui d'utiliser encore de
l'ADSL (au lieu d'un routeur 4G), à part le fait qu'il n'y a que peu
d'abonnements avec un volume illimité. Y a-t-il encore des zones mieux
couvertes en ADSL qu'en 3G/4G ?

Merci :)

Lucas


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

Re: [FRnOG] [MISC] Un autre thread sur la 5G

[Lucas Nussbaum]

Bonjour Jérôme,

On 09/09/20 at 16:42 +0200, Jérôme Nicolle wrote:
> Plop,
> 
> La semaine dernière, j'ai publié un thread sur la 5G qui a dépassé
> mes high-scores de vues. Over 120k.
> https://twitter.com/chiwawa_42/status/1301209720808787970

Merci pour tes threads qui sont très éclairants.

Je trouve très intéressante la lecture découplant la question du
protocole et celle des fréquences. Mais du coup, je me pose quelques
questions:

Qu'est-ce qui lie vraiment la question de la bande de 3.5 GHz, et la
question de la 5G ? Qu'est-ce qui empêche les opérateurs de déployer
aujourd'hui de la 5G sur leurs fréquences actuelles ?

À l'inverse, est-ce que les licences pour la bande des 3.5 GHz
permettront aussi de l'utiliser en 4G ? D'après
https://en.wikipedia.org/wiki/LTE_frequency_bands cette bande est
utilisée en 4G en Slovaquie par exemple ?


J'en profite: un des arguments pro-5G qui revient régulièrement est
celui de la saturation à venir du réseau 4G. Je n'ai pas compris
pourquoi la 5G permettait de résoudre ce problème (est-ce grâce au
protocole ? aux fréquences supplémentaires ?). Et je n'ai pas
compris non plus pourquoi ce problème ne pouvait pas être résolu par
l'ajout d'antennes dans les zones à problème.

Merci :)
-- 
| Lucas Nussbaum  Associate professor @ Univ. de Lorraine |
| lucas.nussb...@loria.fr  LORIA / RESIST |
| http://members.loria.fr/lnussbaum/+33 3 54 95 86 19 |


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

Re: [FRnOG] [MISC] Kosc FTTH - Des avis ?

[Lucas Viallon]

Bonjour,

Concernant Kosc, globalement cela marche bien techniquement, niveau support
j'ai pour le moment pas eu de problème non plus
donc je croise les doigts

 Par contre, c'est vrai que au niveau production, c'est pas tip top, tu as
très peu d'information et les délais sont plutôt assez
long et l'installation des moments bâclés.

J'ai justement discuté ce matin avec mon fournisseur (Phibee) sur le sujet,
ce problème de production est lié à leur ancien prestataire
(ils étaient mono prestataire sniff), avec la reprise par Altitude, ils
sont en train de tout basculer sur les prestataire d'AI donc
cela devrait rapidement se resorber vu qu'AI utilisent plusieurs
prestataires.

Concernant Bouygues, la porte etait trop chère pour nous vu notre volume,
mais on devrait y avoir accès à la fin du mois via
la porte de notre prestataire.

espérant que cela t'aide

a+
Lucas

Le mer. 16 sept. 2020 à 09:40, Frank ALEXIS  a
écrit :

> Bonjour à tous les geeks,
>
> On revend de la FTTH couleur presque d'un fruit, via Sewan, qui
> rencontrent les pires galères depuis Juillet et le changement du modèle
> imposé par le même fruit d'une offre qui marchait bien (LB V4 Pro / IP
> publique / je branche ça marche) à une merde appelée "Just Fibre" (ou "Just
> Rien") qu'ils ne sont même pas capable de venir installer chez le client :-(
>
> Kosc en FTTH, vous avez des retours ?
>
> Le flottement économique de la structure, ça n'a pas tout fait partir en
> cacahouètes ?
>
> Merci des lumières divines :-D
>
> Frank
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Equipement de terminaison T0/T2

[Lucas Viallon]

Bonjour,

Je dois fournir une centaine de raccordement T0/T2 au sein d'un reseau MPLS
IP VPN.

Jusqu'ici, j'ai déployé que des trunk sip raccordé directemement a mon
operateur de gros et une centaine de Linksys PAPT qui fournissait 1 a 2
lignes type analogique raccordé a un simple asterisk.

La on me demande de fournir des T0 et des T2.

Pouvez vous me donner des marques/modèles d'équipement fiable et facilement
manageable (avec une supervision Centreon)

merci d'avance
Lucas

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

[FRnOG] [TECH] FOG + multicast inter-VLANs avec PFSense ?

[Guillaume LUCAS]

Bonjour tout le monde,

Nous utilisons le logiciel FOG ( https://fogproject.org/ ) pour 
déployer, en multicast, des images disque sur un parc informatique.


Nous avons plusieurs VLANs. Notre serveur FOG n'est pas dans le même 
VLAN que les machines du parc. Sur notre routeur actuel, un HP 
HSR6602-XG avec Comware 7, nous activons « pim sm » sur l'interface du 
réseau qui contient le serveur FOG ainsi que « pim sm » et « igmp enable 
» sur l'interface des réseaux dans lesquels se trouvent les PCs à 
déployer. Ça fonctionne ainsi depuis des années.


Nous allons remplacer notre HP 6600 par un boîtier PFSense ( 
https://www.netgate.com/products/appliances/ ). Avec cet équipement, le 
multicast inter-VLANs ne fonctionne plus.


Nous avons activé l'IGMP proxy de PFsense, désactivé PF (pfctl -d) et 
installé le paquet logiciel pimd. Nous n'avons pas configuré pimd. Nous 
avons essayé igmp proxy sans conf' supplémentaire puis en configuration 
upstream = WAN (voir la raison à la fin de ce message) + downstream = 
VLANs des PCs à déployer. Nous avons aussi tenté de configurer une IP de 
rendez-vous multicast dans FOG. Sans succès.


Quand les PCs à déployer tentent de joindre le groupe multicast, l'IGMP 
proxy de PFSense journalise ceci pour chaque PC (10.4.251.11 est l'un de 
ces PCs) :

« No interfaces found for source 10.4.251.11
RECV V3 member report from 10.4.251.11 to 224.0.0.22 »

Mes questions :
  * Est-ce qu'un « igmp enable » (sans autre conf') et un « pim sm » 
(idem) sur un HP 6600 activent les mêmes fonctionnalités techniques que 
l'IGMP proxy (sans conf') + le pimd (idem) d'un PFSense ?


* Notamment, le proxy IGMP de PFSense autorise la saisie d'une 
seule interface upstream. Nous avons deux serveurs FOG situés dans deux 
VLANs différents. Donc, si je comprends bien, un seul serait utilisable… 
Pourtant, notre routeur HP fait le boulot, lui, d'où je doute que igmp 
enable = igmp proxy.


  * Le proxy IGMP refuse de démarrer si l'interface WAN n'est pas 
configurée comme upstream. Or, le serveur FOG n'est pas sur l'interface 
WAN. Ceci explique le message d'erreur  « No interfaces found for source 
», non ? Je ne comprends pas comment PFSense fait la différence entre 
l'interface WAN et les autres : toutes mes interfaces (même la WAN) sont 
des VLANs sur une agrégation. Déplacer la route par défaut sur une autre 
interface que WAN ne permet pas d'ajouter ladite interface en upstream 
dans la conf' IGMP (le proxy IGMP refuse toujours de démarrer)…


  * IGMP proxy et PIM sont-ils nécessaires ou seul IGMP (ou pimd) suffit ?

  * Quelqu'un a-t-il un PFSense + un FOG avec du multicast inter-VLANs 
fonctionnel ? Avec quels paramètres ?


Bonne journée.


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

Re: [MISC] RE: [FRnOG] [ALERT] Retour

[Lucas Dousse]

Je crois que c'est un GROS troll :)

On 8/4/20 2:53 PM, Oliver varenne wrote:
> Super.
> Ça valait l'envoi de 10 mails dont une partie en "ALERT" pour de la politique 
> ou de la discussion de voiture ?
> C'est une blague ?
>
>
>
>
> Cordialement,
>  
>
>
> Olivier Varenne
> Co-gérant, Commercial & Développeur
> T +33 (0)4 27 04 40 00 | ipconnect.fr
>
> Suivez-nous ! 
>
>
>
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de
>> Thomas
>> Envoyé : mardi 4 août 2020 14:37
>> À : frnog-al...@frnog.org
>> Objet : [FRnOG] [ALERT] Retour
>>
>> Je suis de retour après un stage chez ProtonMail sur la partie audit de
>> sécurité VPN.
>>
>> Thomas
>>
>>
>> ---
>> 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] remplacement stack réseau StoneSoft

[Christophe LUCAS]

Plutôt SRX.

Christophe

- Mail original -
De: "Guillaume Tournat via frnog" 
À: "x roca" , "Mathieu Poussin" 
Cc: "frnog-tech" 
Envoyé: Mardi 23 Juin 2020 11:34:33
Objet: Re: [FRnOG] [TECH] remplacement stack réseau StoneSoft

Routage => Juniper MX


Le 23/06/2020 à 11:31, x.r...@sipleo.com a écrit :
> Oui merci, on y penser mais pas retenu.
>
>   
>
> Donc ni Fortinet, ni Stormshield, SonicWall, Sophos et Watchguard tous trop 
> orienté sécurité pas assez fort sur le routage.
>
>
> Xavier
>
>   


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


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

[FRnOG] [TECH] Cisco Route Reflecteur

[Lucas Viallon]

Bonjour,

Toujours a fond dans la rénovation de notre réseau, je me penche maintenant
sur les routes réflecteur.

Actuellement j'utilise un cisco 7201 et un ASR1002 avec un classic
  neighbor BACKBONE-CORE route-reflector-client

Quand cela a été fait, il y avait une 15 ene de routeur et 2 transitaires,
aujourd'hui il y a 130 équipements connectés dont plusieurs avec la full
table.

Je pensais donc les renouveler et je me posais la question par quoi ?

Vos avis mettant précieux ;=) qu'utilisez vous ?

merci
lucas

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

[FRnOG] [TECH] Cisco Nexus N9K

[Lucas Viallon]

Bonjour,

Quelqu'un utilise dans son reseau des Cisco Nexus de la gamme N9K ?
(style N9K-C93180YC-EX)

Je cherche a savoir si cela tourne bien avec du IS-IS et si ils supportent
le EoMPLS (port mode et vlan mode)

je vais aussi avoir un Cisco C9500 (un C9500-24Y4C) mais je crois qu'il ne
fait que du port mode, pas de mode vlan en EoMPLS

merci d'avance
Lucas

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

Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

[Christophe LUCAS]

Bonjour,


Non non,
Cette commande concerne bien le traffic généré par le CPE.

Christophe

- Mail original -
De: "Jérôme BERTHIER via frnog" 
À: frnog@frnog.org
Envoyé: Lundi 18 Mai 2020 10:06:19
Objet: Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

Le 18/05/2020 à 09:36, Jérôme BERTHIER via frnog a écrit :
> Bonjour,
>
> Le 16/05/2020 à 11:37, Sébastien 65 a écrit :
>> Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou 
>> bien class class-default ?
>
> Parce qu'il faut lui appliquer une politique locale "ip local policy 
> route-map map-tag " :
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-mt/iri-15-mt-book/iri-pbr.html#GUID-0BE1EBC5-C95F-43BE-92D1-0A341D6208A4
>  
>
>
> Bonne journée
>
Oups j'ai fait un magnifique HS, désolé.

ça marche pour du PBR, pas du marking COS

Je vais reboire un café.

Bonne journée

-- 
Jérôme BERTHIER


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


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

Re: [FRnOG] [TECH] - Il a Free, il a pas tout compris

[Lucas Nussbaum]

Bonjour,

On 30/04/20 at 13:08 +0200, Frédéric de Villepreux wrote:
> J’ai aussi considéré l’usage du DynHost d’OVH, sans pour autant le mettre en 
> place, car je pense que c’est du même tabac.
> 
> Auriez-vous une idée ? Pensez-vous que Free ne permet pas de rétro-accès à 
> travers des IP mobiles ?
> 
> Dans tous les cas, merci d’avoir pris de votre temps de confinement pour me 
> lire et, éventuellement, de l’autre temps que vous consacrerez à me sortir de 
> l’embarras si cela est possible. Je reste confiant qu’ici, on a pas de 
> pétrole mais qu’on a des idées !

My 2 cents: dans des situations similaires, je mets en place un bête
openvpn qui se connecte depuis une machine sur le réseau local
(typiquement la passerelle domotique), vers une machine à l'extérieur.
Pour me connecter sur le réseau local, je rebondis sur cette machine
extérieure (via un reverse proxy pour HTTP, ou via un ProxyJump SSH).
Ça fonctionne très bien.
-- 
| Lucas Nussbaum  Associate professor @ Univ. de Lorraine |
| lucas.nussb...@loria.fr  LORIA / RESIST |
| http://members.loria.fr/lnussbaum/+33 3 54 95 86 19 |


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

Re: [FRnOG] [TECH] Changement Cisco ?

[Lucas Viallon]

Merci pour ta réponse,

Dans mon cas, j'ai vraiment tendance a rester cisco que je connais et dont
le taux de satisfaction chez nous et de l'ordre de 99%,
j'ai déjà essayé d'aller vers du juniper, du mikrotik ou du libre et
sincèrement je m'en suis toujours mordu les doigts.

Au niveau budget, je suis justement en train de le définir, on s'adaptera
mais on préférera payer un peu plus chère pour du cisco
que perdre du temps a retester d'autres plateformes

au vu des conseils, je pense commander un ASR en 9900 pour tester, on verra
bien

Le mer. 25 mars 2020 à 12:43, Jérôme Nicolle  a écrit :

> Salut Lucas,
>
> Le 25/03/2020 à 11:39, Lucas Viallon a écrit :
> > Il y a quelqu'un qui a deja fait ce genre de changement ? vous etes
> partie
> > sur sur quelle gamme ?
>
> Juniper MX / ACX / QFX le plus souvent, Arista ou Cumulus par ailleurs.
>
> Su tu restes en Cisco, de toute façon tu vas changer d'OS en passant à
> IOS-XR donc quitte à refaire tout ton design autant en profiter pour
> regarder à coté. En fonction de ce que tu veux en faire, il peut y avoir
> un réel intérêt à changer de fabricant.
>
> N'oublies pas d'évaluer les NCS5500 aussi, ils en ont gros sous le pied.
>
> @+
>
> --
> 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/

[FRnOG] [TECH] Changement Cisco ?

[Lucas Viallon]

Bonjour,

Je cherche quelques conseils, je dois changer des Cisco 6503/6504/6509
cette année, ils ont des cartes Sup2T.

Il y a quelqu'un qui a deja fait ce genre de changement ? vous etes partie
sur sur quelle gamme ?
ASR 9000 ? ASR 9900 ?

J'ai pas besoin des tout dernier modele mais bon ..

merci d'avance
Lucas

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

Re: [FRnOG] [TECH] Petit problème de routage SFR ?

[Christophe LUCAS]

Salut,

Bah tu as un problème potentiel d'overlap sur un autre client => tt SFR 
Business.

Christophe

- Mail original -
De: "Joffrey Fontaine" 
À: frnog-t...@frnog.org
Envoyé: Vendredi 20 Mars 2020 09:01:27
Objet: [FRnOG] [TECH] Petit problème de routage SFR ?

Hello à tous,
A $job on a une SDSL 4Mbits SFR avec 4 ip publique utilisable pour nous.
L'ip du routeur c'est 89.227.238.113 et elle répond au ping sans soucis.
Par contre nos ip derrière ne réponde plus. Si je fais un mtr du routeur j'ai
|--|
|  WinMTR statistics
   |
|   Host  -   %  | Sent | Recv | Best | Avrg | 
Wrst | Last |
||--|--|--|--|--|--|
|  172.20.5.1 -0 |4 |4 |0 |0 |  
  1 |0 |
|   192.168.1.254 -0 |4 |4 |1 |1 |  
  1 |1 |
|   176-147-xxx-xxx.abo.bbox.fr -0 |4 |4 |7 |8 
|   11 |7 |
|   No response from host -0 |0 |0 |0 |0 |  
  0 |0 |
|  62.34.2.44 -0 |4 |4 |   14 |   14 |  
 14 |   14 |
|   be5.cbr01-cro.net.bbox.fr -0 |4 |4 |   14 |   14 |  
 16 |   14 |
|   No response from host -0 |0 |0 |0 |0 |  
  0 |0 |
|   No response from host -0 |0 |0 |0 |0 |  
  0 |0 |
|   221.10.136.77.rev.sfr.net -0 |4 |4 |   16 |   16 |  
 16 |   16 |
|   221.10.136.77.rev.sfr.net -0 |4 |4 |   16 |   16 |  
 16 |   16 |
|   46.218.128.77 -0 |4 |4 |   16 |   17 |  
 20 |   16 |
|  92.103.121.247 -0 |4 |4 |   23 |   23 |  
 24 |   23 |
|  89.227.238.113 -0 |4 |4 |   31 |   31 |  
 32 |   32 |
||__|__|__|__|__|__|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Par contre, une de nos ip derriere :

|--|
|  WinMTR statistics
   |
|   Host  -   %  | Sent | Recv | Best | Avrg | 
Wrst | Last |
||--|--|--|--|--|--|
|  172.20.5.1 -0 |3 |3 |0 |0 |  
  1 |1 |
|   192.168.1.254 -0 |3 |3 |2 |2 |  
  2 |2 |
|   176-147-xxx-xxx.abo.bbox.fr -0 |3 |3 |8 |   10 
|   14 |   14 |
|   No response from host -0 |0 |0 |0 |0 |  
  0 |0 |
|  62.34.2.44 -0 |3 |3 |   14 |   14 |  
 15 |   15 |
|   be5.cbr01-cro.net.bbox.fr -0 |3 |3 |   14 |   16 |  
 18 |   14 |
|   No response from host -0 |0 |0 |0 |0 |  
  0 |0 |
|   No response from host -0 |0 |0 |0 |0 |  
  0 |0 |
|   221.10.136.77.rev.sfr.net -0 |3 |3 |   17 |   17 |  
 18 |   17 |
|   221.10.136.77.rev.sfr.net -0 |3 |3 |   16 |   16 |  
 17 |   16 |
|   46.218.128.77 -0 |3 |3 |   17 |   18 |  
 20 |   17 |
|  92.103.121.247 -0 |3 |3 |   23 |   24 |  
 25 |   23 |
|  89.225.196.186 -0 |3 |3 |   30 |   31 |  
 32 |   30 |
|   No response from host -0 |0 |0 |0 |0 |  
  0 |0 |
|   No response from host -0 |0 |0 |0 |0 |  
  0 |0 |
|   No response from host -0 |0 |0 |0 |0 |  
  0 |0 |
|   No response from host -0 |0 |0 |0 |0 |  
  0 |0 |
||__|__|__|__|__|__|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Est-ce qu'on peut dire que le routage merde au niveau de 92.103.121.247 ? et 
que le soucis est chez sfr ?
Merci


Joffrey



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


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Adrien Rivas" 


> Niveau réseau, l'ASA est dgw ou pas ? 

Non. Il donne assez uniquement à nos réseaux. Et les routes ajoutés sur un 
client VPN Linux sont de la forme "10.10.0.0/16 dev tun0".


> Les routes de VPN sont déclarées sur l'Asterisk si ASA pas dgw ? 

Non. Ni dans la table de routage système, ni dans localnet de XiVo. Dans la 
table de routage, il y a une route par défaut vers le routeur de site, qui, lui 
a une route statique pour le réseau des VPN.


> Au niveau des ACL on a bien la règle net_vpn/16 vers net_vpn/16 ?

Heu non ? On a vpn/16 <-> OUTSIDE


> Parce que ça pourrait ressembler à du routage asymétrique aussi. 

Huuum.


> ALG c'est effectivement mal, ça prend des initiatives qu'on lui a pas
> demandé de prendre et si c'est pas pour faire de la téléphonie via wan ça
> complique pour rien le debug.

A priori, on l'a désactivé depuis vendredi avec un « no inspect sip » et les 
timeout udp/sip configurés sont en dizaines de minutes (juste pour essayer, on 
est d'accord).
Après, comme écrit hier soirr, passer à un OpenVPN sans NAT ni filtrage, ça ne 
résout pas tous les cas d'échecs, donc le VPN ASA n'est pas le seul coupable.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> pour que ca fonctionne il faut que les ports 1-2 (par default
asterisk rtp soit permis au niveau du asterisk).

C'est OK.


> Par experience si tu te fais trop chier tu peux essayer l'ipv6 donc tu
elimines tous les problemes de nat.

J'ai ni l'un, ni l'autre. :)


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Le 18/03/2020 à 21:21, Daniel via frnog a écrit :
Essaye alors Twinkle. 


Je crois que ça a été fait et que ça ne fonctionnait pas.
Je parle avant nat=yes et directmedia=no, bien entendu.



Au passage, nat=yes est déprécié, mets nat=force_rport,comedia


XiVo le fait tout seul. Je dis nat=yes pour gagner du temps.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Le 18/03/2020 à 14:27, Guillaume LUCAS a écrit :

Je vais tester avec du Linphone 4.1.1 winwin, etc. Si pas d'amélioration, ça 
validera que le VPN ASA n'est pas coupable.


Je retiens :
  * OpenVPN (+ garantie d'absence de filtrage et de NAT) apporte rien 
par rapport à ASA pour des conversation Linphone GNU/Linux. Le RTP 
learning se fait tout pareil, relais RTP tout pareil, et si ça échoue, 
P2P tout pareil ;


  * OpenVPN fait fonctionner Linphone 4.1.1 winwin. Je ne l'ai jamais 
vu fonctionner avec l'ASA. Le RTP learning échoue donc ça bascule en P2P 
et ça marche. Plus de coupure après 30 secs sur Linphone version winwin 
store ;


  * Mais OpenVPN ne suffit pas à faire fonctionner toutes les 
conversations Linphone winwin <> Linphone GNU/Linux. À versions 
identiques, certains collègues ne s'entendent pas. Puis s'entendent lors 
d'un essai 2 minutes plus tard puis ne s'entendent plus lors d'un autre 
essai, puis… Bref, très aléatoire.


Synthèse : ce que dit Raphaël => un ASA ça se comporte bizarrement, mais 
son absence ne résout pas tout.



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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Le 18/03/2020 à 14:06, Raphael Mazelier a écrit :

Sinon si tu peux centraliser la conf de tes linphones ca serait aussi
pour toi le meilleur, avec pareil l'option qui va bien.


Je n'ai pas compris ? Comment centralises-tu la conf' des linphones ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Le 17/03/2020 à 22:21, Daniel via frnog a écrit :

. tester avec csipsimple qui est très stable


Mais plus maintenu, plus dispo sur f-droid, etc.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Le 17/03/2020 à 22:04, Michel Py a écrit :

Guillaume LUCAS a écrit :
C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent sur le 
choix de
l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.


Maintenant je comprends. Je ne me doutais pas que les clients softphone avaient 
ce genre de limitation; c'est bizarre que personne n'ait pensé a çà avant.


De ce que j'ai compris, ce problème est censé être résolu par nat=yes 
dans Asterisk (Asterisk réécrit le SDP avec l'IP source effective du 
paquet SIP qu'il reçoit, entre autres) et/ou par ICE dans lequel le 
principe est de donner tous les couples IP+port permettant de te joindre 
et que l'interlocuteur les essayent, un à un. Sauf que ICE n'a pas 
fonctionné avec moi…


Notons que les navigateurs web sont bien équipés pour ça dans le cadre 
de webrtc. Dans la config' de Firefox, la clé « 
media.peerconnection.ice.force_interface » permet de sélectionner 
l'interface à utiliser… Ça a aussi ses inconvénients genre quelqu'un qui 
voudrait faire de la téléphonie pro (supposons avec VPN) et perso (sans 
VPN) devrait en changer la valeur en permanence…



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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Raphael Mazelier" 

> Le rtp learning c'est une invention d'asterisk j'imagine qui doit être 
> une fonctionnalité qui essaie de découvrir la topologie réseau et donc 
> setter les adresses ip dans le rtp.

Ouki.


> Une bonne manière de bien comprendre c'est de démarrer avec un 
> opensips/kamailio et du rtpproxy/mediaproxy.

J'aurais aimé, mais je dois faire avec l'existant.


J'ai mis nat=yes et directmedia=no et viré STUN sur deux comptes SIP. 
=> Ça marche, y compris Linphone 3.11, y compris Linphone 4.1.1 windows avec 
VPN ASA (ça n'a jamais fonctionné avant, jamais jamais jamais).
=> J'attends que d'autres collègues testent et si c'est positif, OK pour 
généraliser ça sur les comptes SIP associées à des softphones (non, pas touche 
au reste pour l'instant).


Je retiens :
  * RTP autolearn est chatouilleux, même sans filtrage/NAT sur le réseau et aux 
extrémités, il peut foirer et donc faire basculer une conversation en P2P ;

  * Lors de cette "bascule" P2P, on peut se retrouver avec un interlocuteur qui 
envoie son flux RTP au PABX et l'autre qui l'envoie en direct, ce qui est en 
contradiction avec derniers SDP échangés ;
  => Je pense qu'il y a un bug dans certains softphones genre Linphone qui 
envoie son RTP à l'Asterisk, reçoit le SDP "non en fait envoie en direct", qui 
journalise « Change audio stream destination: RTP=10.30.1.24:7078 » (c'est la 
bonne IP de l'interlocuteur, celle du dernier SDP échangé, donc le SDP 
est parsé) mais qui cesse d'envoyer du RTP…

  * Les implémentations rattrapent certains coups comme elles le peuvent genre 
pas de coupure après 30 secs avec Linphone 4.1.1 alors qu'il y en a sur 
Linphone 3.11, le reste (réseau, PABX, terminaux) étant inchangé. Linphone 
GNU/linux semble être moins chatouilleux que Linphone winwin à version 
équivalente ;

  * Il y a quand même des bugs curieux dans les implémentations.
  => Réduire la fenêtre d'appel de Linphone winwin = plus de son dans les 
deux sens, l'agrandir à nouveau fait revenir le son ;
  => Linphone 4.1.1 winwin ne peut pas être appelé pendant quelques 
dizaines de secondes après avoir raccroché un appel (même quand c'est lui qui 
raccroche, Asterisk voit bien le hangup) ;
  => Linphone ne signale pas un appel entrant ;
  => Réponse STUN ignorée (IP obtenue pas inséré dans le SDP) ;
  => Etc.








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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

- Mail original -
> De: "David Ponzone" 

> Mais Guillaume veut pas nous avouer que son * tourne sur un RaspPi 1 et que 
> donc le rte-proxy….:)

Si tu savais… :D

Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le 
RTP learning foire ? Fin des appels ?
Parce que là, je viens de tester entre du Linphone winwin et Linux. Ça ne 
fonctionnait pas avant (donc le VPN OpenVPN apporte quelque chose) et, surtout, 
je constate que le RTP learning n'arrive pas au stade 
« Complete » et que les softphones échangent en P2P. Que va-t-il se passer pour 
eux si je force un relais RTP ? Moi je comprends qu'ils ne pourront plus se 
téléphoner… Pas cool.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Le plus lourd, c’est les appels vers et depuis l’extérieur, qui seront plus 
> autour de 100 et qui sont obligatoirement relayés par l’*.

Quand RTP learning fonctionne. Sinon c'est p2p, entre le softphone/SNOM et la 
passerelle T2, non ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

Vérifie si Linphone 3 a pas besoin que tu lui dises de mettre le paramètre 
rport.

=> use_rport=1 dans la section sip de linphonerc = pas d'amélioration.

Pour la coupure après 31/32/36 secs de conversation, j'ai (re)mis 
session-timers=refuse sur les deux comptes SIP impliqués. Pas de changement.

Comme dit dans mon précédent mail, je suis désormais certain de pas avoir de 
filtrage aux extrémités (iptables -L -n -v) ni sur le VPN (pfctl -d) ni de NAT 
(pfctl -d).

J'arrive à la conclusion que y'a un bug sur Linphone 3.11. Une autre 
explication m'échappe-t-elle ?

Je vais tester avec du Linphone 4.1.1 winwin, etc. Si pas d'amélioration, ça 
validera que le VPN ASA n'est pas coupable. 
Partant de là, si je comprends bien, soit je reste borné et donc il n'y a pas 
de solution évidente, soit je force Asterisk comme relais RTP.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> Et rajoute directmedia = no

Côté Asterisk, donc.
J'suis pas encore chaud pour qu'Asterisk soit relais RTP de tout le monde… D'un 
autre côté… avec le RTP autolearn, il l'est implicitement depuis longtemps, si 
je comprends bien ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Denis Fondras" 

pfctl -d désactive PF donc... les règles de NAT.

J'ai été trop vite… J'ai mélangé présentation du bidule et état actuel.
Donc, au début, et jusqu'à la fin de mon premier test hier soir, PF était 
activé (+ règle "tout autoriser"), il y avait du NAT. Après mon test, j'ai viré 
la règle de NAT puis je me suis dit autant faire pfctl -d. Donc depuis hier 
soir jusqu'à maintenant, PF est désactivé, donc absence de NAT et de filtrage.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Je me suis souvenu que j'avais un PFSense de test dans un coin avec un OpenVPN 
déjà tout prêt.
Lui fait du NAT. Il a aucune règle de filtrage et j'ai pfctl -d. Utilisation de 
TUN + un même réseau pour tous les clients. Aucun pare-feu sur les clients. 

Premier test : je monte ce VPN OpenVPN, je démarre Linphone, il m'enregistre 
sur le PABX : ip src = IP du PFSense (donc NAT). Je tél à la chambre de 
conférence. Je n'ai pas de son. Environ normal sauf que STUN aurait du faire le 
job puisque l'IP retournée par le serveur STUN était bien l'IP de NAT. Donc 
STUN fail. Sur mon compte SIP, je mets nat=yes. Restart Linphone. Ça fonctionne.
=> conclusion : nat=yes produit bien un effet quand y'a du NAT. J'en doutais 
pas, mais j'étais surpris que ça ne fonctionne pas hier.

Deuxième test : je vire le NAT du PFSense. Je teste avec mtr, netcat, etc. que 
j'peux faire du client<->client. Je vire nat=yes. Appel entre collègues avec 
Linphone 4.1.1. Ça marche. Pas de bug des 30 secondes. Mais, avec cet 
interlocuteur, ça a souvent fonctionné, donc ça veut rien dire. 

Troisième test : Même que deuxième test, mais avec Linphone 3.11 d'un côté. On 
s'entend, mais coupure auto après 36 secondes (et plus 31/32 :D).
=> conclusion : le VPN ASA est pas le seul fautif, on dirait.

J'ai analysé les captures réseau des 3 tests et le journal Asterisk.
  * Quand ça fonctionne avec Linphone 4.1.1 des deux côtés, l'Asterisk est en 
relais RTP.
  * Dans le journal Asterisk, je vois un « Strict RTP learning complete » pour 
mon collègue et pour moi.

  * Quand ça fonctionne durant 30 secs avec Linphone 4.1.1 d'un côté et 3.11 de 
l'autre, Asterisk n'est pas en relais RTP.
  * Dans le journal Asterisk, je vois un aucun « Strict RTP learning complete » 
pour qui que ce soit. Il y a bien les « Strict RTP learning after remote 
address set to », mais ça s'arrête là.

  * Quand un seul interlocuteur entend l'autre avec Linphone 3.11 (car je 
triche), je vois un flux RTP envoyé à Asterisk, l'autre envoyé en direct. Je 
vois un « Strict RTP learrning complete » pour moi, et que du « Strict RTP 
learning after remote address set to » avec l'IP de VPN du collègue, mais pas 
de « Complete ». Donc je n'entends pas le collègue et son flux RTP arrive en 
direct, sans passer par Asterisk et se fait probablement jeter par un contrôle 
d'intégrité de Linphone.


J'en déduis qu'il est difficile d'accuser l'ASA. 

On dirait qu'il y a un fail de RTP autolearn avec Linphone 3.11, tout le reste 
étant identique par ailleurs. Pourquoi ?

Je vais faire tester le VPN OpenVPN garanti sans NAT ni filtrage à plus de 
collègues.


- Mail original -
De: "Stéphane Rivière" 
À: "frnog" 
Envoyé: Mardi 17 Mars 2020 20:32:09
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

> Merci pour ce diag. :)

On est tous arrivé au même.

> Quand la colère va me prendre, 

Ou la lassitude...

>je vais monter un VPN OpenVPN tout neuf sur lequel je serai sûr que y'a pas 
>d'ACL ni rien et hop hop >hop. Pas envie de démerder un Cisco ASA.

La VOIP en SIP/RTP, ça marche. Mais dans ta config (et beaucoup 
d'autres), c'est avec un VPN qu'on fait de la VOIP en mode KISS qui 
tombe en marche à tous les coups.

Parce qu'à la base c'est aussi foireux qu'un FTP passif (comme déjà dit 
par un colistier). C'est ainsi. Et au moins, on est désormais dans une 
techno unique. Du temps de l'ISDN y'avait aussi des trucs pourris.

-- 
Stéphane Rivière
Ile d'Oléron - France


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


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Michel Py" 

> Je comprends que tu veux rester sur le softphone, mais çà vaudrait peut-être 
> le coup de dépenser 50 balles pour essayer un téléphone de bureau qui a 
> support de VPN. Je promets pas que çà marcherait mieux (j'ai jamais essayé), 
> mais les Grandstream ont une option OpenVPN.

C'est un point qui revient souvent alors je vais répondre.

1) Je ne pense pas qu'on ait les épaules assez solides pour gérer de la 
diffusion de SNOM. En termes d'inventaire, de suivi, etc.
2) Nous distribuons des 06 à nos VIP (c'est-à-dire des gens reponsables 
comme on nous le vend à longueur de journée). Nous constatons une corrélation 
entre chaque date de sortie du nouvel iPhone/Samsung et un taux de casse plus 
élevé des écrans des 06 déjà en circulation. Corrélation ne fait pas causalité, 
bien entendu. Peut-être que l'excitation procurée par la sortie d'un tel joujou 
rend les mains moites. Mais c'est fâcheux.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Ouki, merci.

Du coup, je retiens :
  * nat=yes n'a pas fonctionné, c'est très bizarre, donc sortir tcpdump ;
  * session-timers=refuse n'a pas fonctionné, c'est bizarre, preuve 
supplémentaire d'un filtrage ;
  * monter un autre VPN vite-fait ;
  * désactiver RTP learning pour voir. J'ai déjà vu un interlocuteur envoyer 
son RTP à Asterisk et pas l'autre, du coup, ça ne fonctionnait pas.


- Mail original -
De: "David Ponzone" 
À: "Guillaume LUCAS" 
Cc: "frnog" 
Envoyé: Mardi 17 Mars 2020 20:55:48
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

Faut fouiner, je connais pas assez Asterisk et encore moins les versions 
récentes. Et côté doc, c’est comment dire….

> Le 17 mars 2020 à 20:53, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "David Ponzone" 
> 
>>> Qu'est-ce qui peut expliquer les échecs de l'autolearn ?
> 
>> Que l’IP que présente le softphone est une IP que Asterisk a dans son 
>> localnet.
> 
> Mon localnet est vide. Si tu m'avais dit « Que l’IP que présente le softphone 
> N'EST PAS une IP que Asterisk a dans son localnet. », ça expliquait ce 
> scénario que j'ai pas compris.
> 
> 
> ---
> 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] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> > Qu'est-ce qui peut expliquer les échecs de l'autolearn ?

> Que l’IP que présente le softphone est une IP que Asterisk a dans son 
> localnet.

Mon localnet est vide. Si tu m'avais dit « Que l’IP que présente le softphone 
N'EST PAS une IP que Asterisk a dans son localnet. », ça expliquait ce scénario 
que j'ai pas compris.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

- Mail original -
De: "David Ponzone" 

> Ah non, en autolearn, il est forcément dans le path RTP.

Attends, attends, attends.

Il se passe quoi quand l'autolearn marche que pour l'un des deux interlocuteurs 
? Ça donnerait pas une conversation où un seule interlocuteur entend l'autre, 
par hasard ?
Genre là, dans le journal, je vois un Strict learning complete pour un 
interlocuteur sur les deux (on va le nommer Toto). Pour l'autre interlocuteur 
(Titi), le learning voit qu'une IP 192.168.0.X… . Et ça correspond pile à un 
essai où l'un des deux ne s'entendait pas. Juste après, Toto m'a téléphoné. À 
nouveau, il a eu un Strict learning complete et moi aussi, donc on pouvait 
converser… 

Qu'est-ce qui peut expliquer les échecs de l'autolearn ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Ah non, en autolearn, il est forcément dans le path RTP.

Moi je parle de ça dans le journal :
« Strict RTP learning after remote address set to: 10.30.1.4:7078
Strict RTP learning complete - Locking on source address 10.30.1.4:7078 »

À ce moment-là, il me semble que les flux RTP étaient directs.

Comment puis-je activer/désactiver l'autolearn ? Juste pour voir la diff'…


> Mais du relais RTP sans transcoding, ça prend que dalle.
> T’as beaucoup de monde comme ça ?

Si on généralisait le télétravail au max du max (ce qui n'arrivera pas 
puisqu'on a un écrit officiel nous informant qu'il n'y aura pas de perte de 
rémunération si refus du télétravail, donc autant rien faire), on aurait 800 
personnes.


J'aimerais bien l'avis de la liste : un TURN résoudrait à coup sûr mon 
problème, mais, c'est crade, non ? :(


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Michel Py" 

> Installer une route vers le réseau local c'est pas une solution, car tu vas 
> de retrouver avec une ribambelle de 192.168.0.0.

Et il faut ajouter ces routes chez tous les clients VPN, et donc avoir des 
collisions (genre si on dit à un usager avec une connexion Numericable 
d'envoyer 192.168.0.0/24 dans le VPN, vlam).


> Il faut donc que ton softphone soit assez intelligent pour comprendre qu'il 
> est lié à l'interface VPN et qu'il prenne l'adresse dynamique que le serveur 
> VPN lui envoie.

C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent  sur le 
choix de l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans 
> tous les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et 
> faisant le relais RTP.

Idem. Dans le journal d'Asterisk, je vois bien qu'il autolearn et tout, mais ça 
marche pas.
De même, l'activation infructueuse de nat=yes me laisse très dubitatif. Si 
Asterisk réécrit les SDP, ça devrait fonctionner, sauf si les softphones sont 
bind() uniquement sur l'IP RFC1918 locale (non VPN). Je vais revenir sur ça 
demain.

Quand tu parles de relais RTP, tu veux parler de relais SDP, non ?
Perso, je ne veux pas qu'Asterisk soit relais RTP, car il faut dimensionner le 
serveur pour la montée en chargée.
C'est aussi pour ça que je n'ai pas installé de serveur TURN, qui serait une 
solution vite-fait-bien-fait à mon problème.


> Je pense qu’il faut explorer cette piste, en prenant des traces côté Asterisk 
> si nécessaire, et comprendre ce qui merde.

Je n'ai pas de capture réseau des essais avec nat=yes, et oui, c'est 
problématique.


> Ca permettrait au moins d’incriminer l’ASA une fois pour toute.

Ben ça, j'ai du wireshark sur les clients et du tcpdump sur l'Asterisk donc 
j'vois bien que la SDP part avec une IP "invalide" d'un softphone, qu'Asterisk 
la relaie et que le client la reçoit. Et inversement, quand ça marche, je vois 
des SDP avec la "bonne" IP. Ces captures datent d'avant l'activation de nat=yes 
sur quelques comptes SIP, bien entendu.

Ce qui m'étonne le plus, c'est le softphone qui utilise STUN, puis en fait non, 
puis qui ne tient plus compte de la réponse STUN pour forger sa SDP, puis si, 
puis non, puis après il ne tient pas compte d'une SDP valide reçue donc il 
envoie le flux audio au mauvais endroit, puis ça marche, puis retour case 
départ…


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Thierry Chich" 


> Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN 
> ne se voient pas entre elles, ou partiellement ? On vient d’avoir le coup 
> avec du jitsi. Le p2p, c’est bien joli, mais bon.

À mon avis, une partie du problème est dans le mot « partiellement », en effet.
 Quand ça fonctionne, les flux RTP circulent bien d'IP attribuée par le VPN à 
IP attribuée par le VPN ;
 ping entre deux clients VPN OK ;
 http entre deux clients VPN OK ;
 netcat udp entre deux clients VPN OK.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> Définitivement pour moi problème de NAT ou Pare-Feu

Merci pour ce diag. :)
Quand la colère va me prendre, je vais monter un VPN OpenVPN tout neuf sur 
lequel je serai sûr que y'a pas d'ACL ni rien et hop hop hop. Pas envie de 
démerder un Cisco ASA.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> J'avais bien compris que tu ne veux pas le faire, tu comprends donc que 
> ton rtp se perd si le client envois une IP injoignable au PABX

Tout à fait, je comprends.
Je corrige un truc : le client envoie, en SDP, une IP injoignable au PABX, mais 
aussi à son interlocuteur.
Donc en fait, tous nos clients VPN devraient avoir une route pour (dans 
l'exemple que je prends depuis le début) 192.168.0.24, ce qui va forcément 
faire collision avec des réseaux domestiques qui utilisent cette plage. D'où 
l'ajout de routes n'est pas une bonne idée, c'est au softphone de sélectionner 
la bonne IP pour la filer en SDP, avec ICE, STUN, autre…

Ce qui me dépasse, c'est quand le softphone fait des requêtes STUN, mets bien 
son IP VPN dans SDP (donc l'appel fonctionne) puis, des heures plus tard, sans 
aucun changement de conf' ni redémarrage du softphone ni… cesse de faire du 
STUN ou émet des requêtes STUN, reçoit la réponse, mais n'intègre pas l'IP dans 
SDP… ou autre… Si y'avait pas ça, la solution STUN, bien que crade, 
fonctionnerait.


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

Re: [FRnOG] [TECH] RE: Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Oliver varenne" 

> A mon avis, linphone liste les interfaces accessibles, et du coup si ton VPN 
> monte apres, linphone n'utilise pas cette interface.

Yep. Mais, comme dit : durant mes tests, j'ai bien demandé à tous les 
participants d'être vigilants, de bien monter le VPN avant. Et quand j'avais un 
doute, j'ai fait redémarrer Linphone.

En vrai, depuis le début, le comportement de Linphone ne me semble pas absurde 
: sélectionner l'interface qui a la route par défaut, ça va faire le job pour > 
80 % des utilisateurs.


> Si ça fonctionne avec d'autres softphone, et que seul linphone est impacté, 
> tu as ta réponse 

Comme dit, Zoiper, Blink et Jitsi se prennent aussi les pieds dans le tapis de 
manière aléatoire (ça marche puis des heures après non, puis oui… alors que le 
logiciel a pas été touché, ni sa conf' et que le PC n'a pas changé de réseau, 
ne s'est pas déconnecté du VPN, n'a pas été arrêté/mis en veille prolongée…).


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non. Et surtout, je ne veux pas ping les réseaux domestiques de mes usagers. Ce 
n'est pas mon rôle d'utiliser notre VPN pour accéder à leur réseau local.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Tu veux pas modifier la nat.address dans le fichier de conf de linphone (voir 
> le lien que j’ai envoyé il y a quelques minutes), pour voir si ça aide 
> linphone à envoyer un SDP correct ?

J'essaye de dépiler mes mails dans l'ordre.

Alors ça, c'est la première chose que j'ai testé vendredi. Avant STUN, ICE et 
compagnie. Et ça marchait. Il restait le problème de "ça raccroche auto après 
30 secs" mais au moins les flux RTP montaient. J'ai pas testé aussi longuement 
que ICE et STUN, donc si ça se trouve, ça marche pas sur le long terme, comme 
STUN.

Pourquoi j'ai pas gardé ? Parce que l'adressage IP de notre VPN est dynamique. 
Pas statique. Pas d'IP préférée. Rien, du pur dynamique. J'ai oublié de le dire 
ici.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

Le 17/03/2020 à 13:32, Guillaume LUCAS a écrit :
> Et cela te parait normal? Il y a déjà un problème au départ, Linphone ou 
> autre.

Ben, comme j'ai vu ça en cours et en pratique, je me dis implémentation 
foireuse et comme ça me semble quand même trop gros, j'viens demander ici si 
c'est normal.
En vrai, ça me semble aberrant… Mais comme j'ai déjà vu ces 10 dernières années 
de la part de plusieurs softphones…



> Une solution serait de mettre le réseau 192.168.0/24 dans localnet et de 
> faire une route sur le PABX qui enverrait le trafic vers l'interface VPN. 
> C'est du bricolage

Oui et non. Je ne sais pas comment marche un Cisco ASA, mais, avec OpenVPN, si 
tu routes, vers un client, une IP/réseau que tu n'as pas défini dans la conf' 
OpenVPN (iroute, etc.), le trafic arrivera pas au client. Donc, si je faisais 
ça, faudrait vérifier ça.

Et oui, ça serait du bricolage… Mais ça fonctionnerait très probablement…



> Comme dit par d'autres STUN ou ICE ne devriaent pas être nécessaires

Ce qui pré-suppose que le softphone sélectionne la "bonne IP" pour la mettre 
dans SDP. Linphone, Jitsi, Zoiper, Blink, tous échouent par moments (Jitsi) ou 
tout le temps sans STUN (Linphone) ou tout le temps même avec STUN (Zoiper).



> As tu fais les modifs au niveau localnet ?

Nope, du coup.



> Soit tu as 2 problèmes, Pare-Feu et Softphone

Vrai…


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

- Mail original -
De: "frnog" 

> Donc session timeout: Essaye en mettant session-timers=refuse dans la  config 
> d'un client qui génère cette erreur

J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça ne 
fonctionne pas, ça coupe toujours après 32 secs.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Ok, un truc couillon: ça fait une différence si tu montes le VPN AVANT et 
> APRÈS de lancer Linphone ?

Alors, ça ne m'était pas venu à l'idée d'ouvrir Linphone avant de monter le 
VPN, pour moi c'était sûr qu'il ne faut pas faire ça. J'ai testé pour toi et, 
forcément, ça foire bien. Au début impossible d'être destinataire d'un appel, 
le PABX dit que le user n'est pas là. En laissant Linphone se rendre compte de 
la réalité (> 10 minutes), il s'enregistre à nouveau. Les appels ne 
fonctionnent pas (personne s'entend ou un des deux seulement et vu l'IP RFC1918 
hors VPN dans le message SDP… … …), même avec les personnes avec lesquelles 
cela fonctionnait juste avant et avec lesquels ça a fonctionné après avoir 
redémarré Linphone pour conclure le test.

Donc oui, il faut bien monter le VPN avant d'ouvrir Linphone.
Et ça pose un souci. En cas de coupure ADSL (ou autre), notre VPN va remonter 
auto. L'utilisateur changera d'IP. Linphone sera perdu. Je me vois mal demander 
à mes utilisateurs de redémarrer Linphone en permanence.


> Si c’est un problème de SDP, ça peut aider de dire à Asterisk que ces clients 
> là sont derrière du NAT, donc il va utiliser l’autoNAT (RTP auto learn) et ne 
> pas faire confiance au SDP.

A priori, c'est ce que j'ai testé en activant nat = « Oui (force rport + 
comedia) » dans XiVo + redémarrer les softphones puis tester, non ?



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

Re: [FRnOG] [TECH] RE: Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Oliver varenne" 
> À: "frnog-tech" 
> Envoyé: Mardi 17 Mars 2020 15:52:23
> Objet: [FRnOG] [TECH]  RE: Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Mais tu as mis l'option force,comedia sur tes extensions distantes? 
> (nat=force,comedia)
> Si ton softphone envoie une IP locale au lieu de mettre l'IP de ton VPN, ça 
> résoudra normalement tes soucis.

Dans l'interface web XiVo, à la recherche du nat = yes proposé par Florent, 
j'ai mis nat = « Oui (force rport + comedia) » sur les quatre comptes SIP de 
test. J'ai demandé à tout le monde de redémarrer son Linphone. Ça ne fonctionne 
pas… Deux personnes ne s'entendent pas, comme avant. Deux personnes s'entendent 
mais s'entendaient déjà avant.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 
> À: "frnog" 
> Envoyé: Mardi 17 Mars 2020 14:24:12
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Tu pars du principe de ta configuration. Asterisk doit connaitre son  
> external IP qu'il met dans les entêtes SIP/RTP si l'IP du client n'est 
> pas définie dans ses localnet

Ben il a une seule IP, lui. Et elle est joignable depuis les VPN et depuis les 
SNOM. J'ai mtr, netcat, etc.



> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 pour 
NC-SFR, 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 172.16 
pour MacDo, etc. etc. On ne s'en sort plus. Je ne vais pas définir tous les 
réseaux privés que chacun peut avoir chez soi ou au cybercafé dans mes 
localnets, si ? Pour moi le softphone doit prendre l'IP qu'il a dans notre VPN, 
pas l'IP qu'il a à sa maison.



> Mets le sur tous les clients

D'acc.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 
> À: "frnog" 
> Envoyé: Mardi 17 Mars 2020 09:23:08
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)


> Je pense que Linphone est à mettre en cause. Le problème n'est pas que 
> le routage, Asterisk doit savoir quelle IP mettre dans les entêtes SIP.

Peux-tu expliquer, stp ? Dans mes souvenirs. Un interlocuteur lance un appel. 
SIP INVITE vers le PABX qui transmet à l'interlocuteur (je passe 
trying/ringing, etc.). Si ça décroche, y'a échange des SDP en passant par le 
PABX. Au début, le PABX connecte chaque interlocuteur à lui (donc la 
connaissance de sa propre IP suffit pour dire "viens me causer sur cette 
IP+port avec tels codecs), puis il connecte les deux interlocuteurs directement 
en relayant simplement le SDP émis par chaque softphone. Dedans y'a l'IP+port 
et les codecs à utiliser. Pour moi Asterisk devient neutre à ce stade-là.



> Dans l'interface Waxo/Xivo => Services => protocol SIP => Réseau il y a 
> une zone réseau local: le VPN en /16 doit y être défini

On a rien défini. Pas même le /16 RFC1918 qui héberge nos SNOM. Pas même le 
VLAN des passerelles T2.
Au niveau système, il y a une route par défaut, pas de routes vers les VLANs 
(VPN, SNOM, passerelles T2, etc.).



> Donc session timeout: Essaye en mettant session-timers=refuse dans la  config 
> d'un client qui génère cette erreur

D'acc. Mais… Comment j'identifie ce client ? Comme dit, y'a trop de bruit, je 
n'arrive pas à corréler…
La modif' se fait côté Asterisk, on est d'accord ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Ça dit que à chaque fois que j'ai vu de la VOIP ne pas fonctionner, c'était 
toujours parce que les softphones ne mettaient pas leur "bonne" IP dans le 
message SIP/SDP, forcément que le softphone d'en face ne pourra pas leur 
envoyer de RTP. Genre "viens me causer sur 127.0.0.1" ça va pas marcher. "Viens 
me causer sur 192.168.0.14" non plus. Je dis la même chose que toi quand tu 
écris « problème de binding ».


- Mail original -
De: "David Ponzone" 
À: "Guillaume LUCAS" 
Cc: "frnog" 
Envoyé: Mardi 17 Mars 2020 13:42:12
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

> 
> En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente de 
> la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses IP 
> qui sont échangées dans SDP…
> 


Je ne comprends pas le sens de cette phrase (put…je vieillis) :)

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


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 
> À: "Guillaume LUCAS" 
> Cc: "frnog" 
> Envoyé: Mardi 17 Mars 2020 07:34:53
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Tu es visiblement pas le seul à avoir ce problème de binding.

En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente de 
la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses IP 
qui sont échangées dans SDP…


> Ca vaut quand même le coup de tester Zoiper ou Bria au moins pour avoir la 
> confirmation que ça vient bien de Linphone, et ensuite tu pourras déterminer 
> si t’as envie de debugguer leur truc.

Mes collègues ont testé Zoiper sous winwin : ça ne chemar pas, personne 
s'entend, y compris quand STUN est activé. Je n'ai pas plus d'éléments, 
notamment pas de capture réseau des SDP.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Michel Py" 
> À: "Daniel" , "frnog" 
> Envoyé: Mardi 17 Mars 2020 01:19:26
> Objet: RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Je ne vois pas pourquoi. Si le VPN marche, tout devrait se passer avec 
> RFC1918, donc l'adresse du softphone est bien celle du lien physique. 
> Je ne comprends pas pourquoi tu t'enquiquines avec STUN, si tu as un VPN il 
> ne devrait pas y avoir de NAT donc aucun besoin d'avoir STUN.

Raisonnement :
1) Notre PABX n'est pas joignable en IP depuis Internet ;

2) D'où il faut le VPN pour s'enregistrer sur le PABX et plus si affinité ;

3) Donc l'ordi sur lequel est installé un softphone a au moins deux interfaces 
: eth0|wlan0 et vpn0 ;

4) Notre VPN n'installe pas de route par défaut, juste les routes vers nos 
réseaux internes ;

5) Sur vpn0, il y aura une IP 10.30.x.x/16, réseau de tous nos clients VPN ;

6) Sur eth0|wlan0, il aura l'IPv4 RFC1918 attribuée par le DHCP de sa box genre 
192.168.0.14/24 ;

7) Lors de l'enregistrement sur le PABX, le softphone va émettre un SIP 
REGISTER avec ip dst=. Le VPN offre une route /24 pour le réseau qui 
contient le PABX, donc ça passe forcément par le VPN, donc le système 
d'exploit' va sélectionner l'IP sur l'interface vpn0 pour la mettre dans ip src 
du paquet IP ;

8) Lors d'un appel, je constate, avec wireshark/tcpdump, que le softphone met 
parfois l'IP de vpn0 (10.30.x.x) dans le paquet SDP et donc, là, ça marche de 
base (comme ça semblait fonctionner depuis 6 mois pour les quelques 
utilisateurs), car c'est du routage de base. Mais, souvent, il met l'IP de 
eth0. Forcément, l'interlocuteur à l'autre bout ne peut pas envoyer de RTP avec 
ip dst=192.168.0.14…

9) Avec un serveur STUN sur le réseau local, la requête STUN sera contrainte, 
par le routage, de passer dans le VPN (comme le SIP vers le PABX, voir point 7) 
donc retournera toujours l'IP RFC1918 de vpn0. Et donc les flux RTP monteront. 
Et c'est ce qui se passe quand les softphones ne choisissent pas 
d'ignorer la réponse qu'ils ont eu du serveur STUN et/ou qu'ils n'ignorent pas 
la dernière SDP reçue et/ou…


Je sais qu'il ne faut plus utiliser seulement STUN, que ICE c'est mieux. Mais 
avant d'installer un serveur STUN à l'arrache, j'ai testé ICE et ça ne 
fonctionnait pas. Dans mes souvenirs, ICE est une méthodo qui consiste à 
s'échanger, dans SDP, tous les couples IP+port possibles, qu'on nomme 
candidats. On a activé ça sur les softphones et c'est activé de base dans XiVo. 
Quand j'analyse les SDP avec tcpdump, je vois qu'une seule proposition dans 
SDP, l'IP RFC1918 de eth0…


> Faire marcher SIP à travers NAT çà a toujours été une galère, mais au travers 
> d'un VPN je ne vois pas pourquoi çà ne marcherait pas.

Idem ! C'est bien ce qui me prend la tête ! :)


> Exactement ! Daniel a raison de dire que les problèmes que tu as sentent NAT 
> a plein nez, ceci dit.
> Si t'es sur qu'il n'y a pas de NAT (faire un traceroute) çà sent le pare-feu.

Je donne les preuves suivantes :
  * Dans le journal de mon Asterisk, j'ai bien des « chan_sip.c: Registered SIP 
'bczhcigi' at 10.30.1.175:62633 ». 10.30.X.X est bien une IP VPN. Je vois bien 
une IP 10.30/16 différente par softphone ;
  * Quand ils fonctionnent, les flux RTP circulent bien entre deux IP 
10.30.x.x, et c'est bien les IPs attribuées, par le VPN, aux deux clients VPN ;
  * mtr depuis mon ordi+VPN vers un de nos serveurs : un seul saut, le serveur 
lui-même. mtr entre le serveur et mon ordi+VPN : un seul saut, mon IP VPN 
(10.30.1.175).


Pare-feu, je commence à y croire vu le merdier dans nos ACL Cisco ASA… Mais 
comment expliquer que, sans y toucher, nos tests soient concluants de temps en 
temps avec Linphone GNU/Linux ? Là, pour moi, ça échappe à toute rationalité. 
Soit tu bloques constamment, soit tu laisses passer, mais pas les deux.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Bonsoir Daniel,

Version d'Asterisk : 13.22.0-1~xivo3+deb9+20181129.142257.a8a0975 .
A priori, dans le journal, ça cause de chan_sip partout et jamais de pjsip.

Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un 
autre. Nos utilisateurs VPN sont dans un /16. Une route par défaut existe sur 
le VPN avec next hop le routeur de site. Une route statique avec next hop = VPN 
existe sur le routeur de site. Pour moi, tout n'est que routage. Surtout, ce 
qui m'étonne, c'est qu'il suffit de changer de version d'un même softphone 
(Linphone) pour que ça fonctionne… mais que sur un seul système d'exploitation.

Dans le journal Asterisk, j'ai bien des « Packet timed out after 32000ms with 
no response », mais je ne vois pas comment les corréler avec nos essais ? Je ne 
vois pas d'ID / chaînes de caractères en commun avec le reste du journal. Y'a 
trop de bruit autour pour dépatouiller avec un grep -C. Comment faire ?

Définition du réseau /16 VPN dans la conf' XiVo : aucune idée, j'appelle un 
collègue à la rescousse.

Je confirme que nos postes SNOM juste marchent depuis 5 ans.

Merci.

Bonne nuit.


- Mail original -
De: "Daniel via frnog" 
À: frnog@frnog.org
Envoyé: Lundi 16 Mars 2020 22:53:47
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

Bonsoir,

tout d'abord la version de Xivo/Asterisk n'étant pas connu, il y a des 
différences importantes entre chan_sip et pjsip.

. les problèmes de sons qui ne passent pas d'un côté et/ou de l'autre 
sont dus à des problèmes de NAT

. les timeout peuvent être dus au session-timer et doivent se voir dans 
les logs du type no response received [bla bla]

. concernant les différents échanges, les réseaux VPN sont ils définis 
dans localnet (chan_sip) local_net (pjsip) ?

. j'ai rencontré pas mal de soucis à une certaine époque avec Linphone, 
j'ai abandonné. Je passe en iax dès que c'est possible (zoiper). Il 
semble que les problèmes rencontrés viennent de softphone, j'installe du 
SNOM (sauf DECT) et du GrandStream et n'ai jamais rencontré de tels 
problèmes, poste en interne ou externe.

. en dehors de cela oui, SIP est un protocole que chacun peut mettre à 
sa sauce qui fait que infine la compatibilité n'est plus au RDV 
(Alcatel, Mitel. fibre Orange dédiée SIP (si elle existe encore), ...)

Le 16/03/2020 à 22:05, Guillaume LUCAS a écrit :
> Bonjour à tous,
>
> Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et 
> j'aimerais un avis et surtout être réconforté.
> => Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me 
> souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime > 
> 1645 octets arrivait du WAN. Je me souviens des erreurs de segmentation 
> aléatoires de Jitsi/Ekiga. Je me souviens des messages SIP pas trop conformes 
> à la norme et à la validation approximative des messages SIP reçus. Etc.
> => Mais je doute que le nombre de problèmes que nous rencontrons (et leur 
> amplitude) soit normal.
> => Je suis dans une démarche de compréhension technique des problèmes 
> rencontrés, donc je ne suis pas intéressé par des alternatives à des 
> softphones.
>
>
> Depuis 5 ans, nous utilisons le PABX Asterisk empaqueté dans la solution 
> XiVo. Nous avons des postes téléphoniques SNOM, des téléphones analogiques, 
> des T2, etc. IPv4 uniquement. Ce PABX n'est pas joignable depuis l'extérieur 
> (en IP).
>
> Nous avons aussi un VPN Cisco ASA. Adressage IPv4 RFC1918 (les réseaux 
> internes sont plutôt adressés avec des IPv4 publiques, pas de v6). Pas 
> d'IPv6. Accès aux réseaux internes, pas d'accès à Internet. Pas de filtrage 
> particulier (oui, n'importe quel utilisateur du VPN peut se promener dans 
> tous les réseaux internes, ça va changer).
>
> Depuis 6 mois environ, nous avons de très rares softphones Linphone 
> majoritairement sous winwin 7/10. Ils sont utilisés conjointement avec le VPN.
>
> Jusque-là, personne nous a fait remonter des problèmes sur les 
> softphones+VPN. Mais vu le peu d'utilisateurs…
> Le coronavirus débarque et nous voilà priés de fournir un softphone à tout le 
> monde. Et là, surprise, ça ne marche plus. Ou plus tout le temps. Ou plus 
> pour tout le monde.
>
>
> Le premier problème est un classique. Entre un softphone+VPN à domicile et un 
> poste SNOM du bureau, soit les deux interlocuteurs ne s'entendent pas, soit 
> un seul entend l'autre.
> => Dans ses SDP, Linphone insère l'IP RFC1918 de l'interface physique (eth0, 
> Wi-Fi, etc.) plutôt que celle du VPN. Forcément, ça ne fonctionne pas.
> => On installe un serveur STUN dans le réseau de l'organisation. On configure 
> STUN dans les paramètres de Linphone et ça fonctionne.
> => Notons que certains Linphone fonctionnent aléatoirement et te

[FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Bonjour à tous, 

Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et 
j'aimerais un avis et surtout être réconforté. 
=> Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me 
souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime > 
1645 octets arrivait du WAN. Je me souviens des erreurs de segmentation 
aléatoires de Jitsi/Ekiga. Je me souviens des messages SIP pas trop conformes à 
la norme et à la validation approximative des messages SIP reçus. Etc. 
=> Mais je doute que le nombre de problèmes que nous rencontrons (et leur 
amplitude) soit normal. 
=> Je suis dans une démarche de compréhension technique des problèmes 
rencontrés, donc je ne suis pas intéressé par des alternatives à des 
softphones. 


Depuis 5 ans, nous utilisons le PABX Asterisk empaqueté dans la solution XiVo. 
Nous avons des postes téléphoniques SNOM, des téléphones analogiques, des T2, 
etc. IPv4 uniquement. Ce PABX n'est pas joignable depuis l'extérieur (en IP). 

Nous avons aussi un VPN Cisco ASA. Adressage IPv4 RFC1918 (les réseaux internes 
sont plutôt adressés avec des IPv4 publiques, pas de v6). Pas d'IPv6. Accès aux 
réseaux internes, pas d'accès à Internet. Pas de filtrage particulier (oui, 
n'importe quel utilisateur du VPN peut se promener dans tous les réseaux 
internes, ça va changer). 

Depuis 6 mois environ, nous avons de très rares softphones Linphone 
majoritairement sous winwin 7/10. Ils sont utilisés conjointement avec le VPN. 

Jusque-là, personne nous a fait remonter des problèmes sur les softphones+VPN. 
Mais vu le peu d'utilisateurs… 
Le coronavirus débarque et nous voilà priés de fournir un softphone à tout le 
monde. Et là, surprise, ça ne marche plus. Ou plus tout le temps. Ou plus pour 
tout le monde. 


Le premier problème est un classique. Entre un softphone+VPN à domicile et un 
poste SNOM du bureau, soit les deux interlocuteurs ne s'entendent pas, soit un 
seul entend l'autre. 
=> Dans ses SDP, Linphone insère l'IP RFC1918 de l'interface physique (eth0, 
Wi-Fi, etc.) plutôt que celle du VPN. Forcément, ça ne fonctionne pas. 
=> On installe un serveur STUN dans le réseau de l'organisation. On configure 
STUN dans les paramètres de Linphone et ça fonctionne. 
=> Notons que certains Linphone fonctionnent aléatoirement et temporairement 
sans STUN. Même chose avec Jitsi. Comment est-ce possible ? 
=> Un Wireshark nous montre qu'une fois l'échange SIP initié, le client cause 
en STUN au PABX et que celui-ci répond. Pourquoi ça ne suffit pas toujours ? 
C'est d'ailleurs bizarre, car aucun serveur STUN écoute en permanence, on 
dirait que c'est fait à la demande ? 


Deuxième problème. Lors d'une conversation entre un Linphone 3.11 empaqueté 
dans Debian GNU/Linux ou Ubuntu GNU/Linux et un Linphone 4.1.1 GNU/Linux 
distribué via Flatpak, si c'est le Linphone 4.1.1 qui initie la conversation, 
la conversation durera 31/32 secs au maximum avant raccrochage auto. 
=> Pas de soucis si c'est le Linphone 3.11 qui initie la conversation. 
=> Pas de problème quand le Linphone 4.1.1 cause à un SNOM ou à un 06/09 
externe. 
=> Rien d'évident dans le journal des deux Linphone. 
=> Côté Asterisk, on voit que le Linphone 4.1.1 quitte le « 'native_rtp' 
basic_bridge », donc Asterisk nettoie, à raison, avec code retour != 0. 
=> Wireshark montre un Asterisk qui envoie, au Linphone 4.1.1, un SIP BYE avec 
un entête « X-Asterisk-HangupCause: no user responding ». 
=> Pas de pare-feu, pas de NAT. 
=> Nous pensons que le Linphone 3.11 n'envoie pas un message SIP attendu par 
son interlocuteur. Ou paquet malformé. Ou Linphone 4.1.1 plus strict. Ou… 
==> Solution : sur GNU/Linux, utiliser Linphone 3.12 (+STUN, bien entendu) 
partout. Ça fonctionne impec', sans exception. 


Troisième problème. Le journal du VPN nous montre parfois des paquets UDP 
bloqués entre le serveur Asterisk et un client VPN. C'est très peu (moins de 10 
paquets bloqués sur les 5 comptes utilisateurs surveillés pendant la matinée, 
mais quand même. 
=> « no inspect sip » => plus de blocage. 


Quatrième problème. Linphone 4.1.1 pour GNU/Linux arrête subitement d'émettre 
des requêtes STUN. 
=> Wireshark installé sur la machine est formel. 
=> STUN est toujours activé dans la conf'. 
=> Linphone n'a pas été stoppé entre le moment "ça marche" et le moment "ça 
marche plus". 
=> L'ordinateur n'a changé de réseau, n'a pas été redémarré ni autre. 
=> Après plusieurs redémarrages de Linphone, celui-ci émet à nouveau des 
requêtes STUN, reçoit une réponse… mais choisi d'envoyer l'IPv4 RFC1918 de 
l'interface eth0 dans sa SDP… … … Forcément, son utilisateur n'entendra pas son 
correspondant… 
=> Entre le "ça marche" et "ça marche plus", l'ordinateur a obtenu une IPv6 sur 
son réseau local. 
=> Dans les paramètres de Linphone, décocher « Autoriser IPv6 » conduit 
Linphone à intégrer l'IPv4 obtenue via STUN dans sa SDP, et donc à rétablir le 
fonctionnement. Aucun dysfonctionnement constaté cet 

[FRnOG] [MISC] Datacenter sur Annecy ?

[Lucas Viallon]

Bonjour,

Quelqu'un connaîtrait un Datacenter sur Annecy/Annecy le vieux autre qu'une
salle de tutor/covage ?

Il me semble qu'il y a une solution sous Modulo mais impossible de trouver
sur google, il est bien caché

merci

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

[FRnOG] [MISC] Boitier Accès Console via 3G

[Lucas Viallon]

Bonjour,

Je cherche un terminal de port console (2/4/6/8 ports consoles par exemple)
pour acceder a mes cisco distant via une carte SIM et un abonnement simple

Quelqu'un pourrait me conseiller ? j'aimerais un truc simple et pas un
bricolage de solution, un accès SSH et hop je selectionne le port console.


Cordialement
Lucas

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

[FRnOG] [TECH] Quelles catégories de VPN multi-systèmes en 2019 ?

[Guillaume LUCAS]

Bonsoir, 

Quelles sont, en 2019, les grandes catégories de VPN multi-systèmes permettant 
de connecter des utilisateurs distants faiblement technophiles et motivés [1] 
au réseau d'une entité ? Évidemment, le service info n'a pas la main sur le 
terminal de l'utilisateur, sinon c'est trop facile, donc il faut que ce soit 
facile à installer et à utiliser. 

Depuis de (trop nombreuses ?) années, j'en suis resté à : 
* L2TP/IPSec, mais ça ne passe pas le NAT, sauf la version encapsulée en UDP, 
mais, pour l'activer sous un winwin 10, il faut modifier la base de registre, 
ce qui réduit drastiquement la facilité d'utilisation ; 
* PPTP, mais c'est non-sécurisé (on retrouve MS-CHAPv1, v2, etc.) ; 
* TLS et TLS-like (Cisco, Fortinet, OpenVPN, Wireguard, etc.) mais chaque 
équipementier a son implémentation et il faut télécharger le binaire (voire la 
conf) kiVaBien pour chaque système. De plus, les binaires non-signés (comme le 
binaire OpenVPN+conf' généré par un PFSense) sont décriés par le SmartScreen 
d'un winwin 10, ce qui réduit la facilité d'utilisation et ferme le jeu. 

Cela a-t-il évolué ? Je ne vois rien de natif aux principaux systèmes (winwin, 
mac os, GNU/Linux, Android) ? 

Bonne fin de soirée. 

[1] Moins motivés que pour accéder à des newsgroups ou autre activité 
passionnante, quoi ; 

[2] « Windows a protégé votre ordinateur - Windows Defender SmartScreen a 
empêché le démarrage d'une application non reconnue. L'exécution de cette 
application peut mettre votre ordinateur en danger. […] Éditeur inconnu » 

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

Re: [FRnOG] [TECH] Remplacement Smartedge SE600

[Christophe LUCAS]

Salut,

ASR1004/ASR1006 ESP40 

++Christophe

- Mail original -
De: "Kevin Thiou" 
À: "frnog-tech" 
Envoyé: Jeudi 5 Septembre 2019 16:17:03
Objet: [FRnOG] [TECH] Remplacement Smartedge SE600

Bonjour,

je commence à réfléchir au remplacement de mes routeurs Ericsson SmartEdge
SE600.
Ils font bien le travail que je leur demande (LNS), le principal problème
est la bande passante.

Etant donné que je n'ai que des interfaces 1Gbps dessus, je suis obligé de
multiplié les LAG.
Il existe des cartes 10G en refurbished, j'y pense c'est pour comparer les
couts/risque/possibilité d'évolution

Quelles modèle de routeur de remplacement me suggéreriez vous ?

Il me faut :
- 3 ports 10Gbps minimum
- capacité de gérer 20Gbps de trafic au moins
- forcément double alim
- pas forcément double carte de management

Je ne donne pas le matériel auquel je pense pour ne pas aiguiller les
réponses.

Merci

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


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

[FRnOG] [MISC] ISO Passerelle IPSec

[Lucas Viallon]

Bonjour,

Je continue dans mes questions ;=) je dois mettre en place une connexion
IPSec pour un client,

j'ai la solution "simpliste" de mettre un boitier type watchguard ou
fortinet  ..
Mais cela prend de la place dans ma baie.

Il me semble qu'il y avait des images ISO de routeur "virtuel" capable de
faire un petit IPSec facilement, quelqu'un a déjà essayé ce type de
solution ?

merci
Lucas

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

[FRnOG] [MISC] Orange & SS7

[Lucas Viallon]

Hello,

Je sais que c'est pas trop reseau mais je recherche des infos sur le SS7
que fournis Orange
car j'ai pas réussi a mettre la main sur des STAS

Quelqu'un a déjà connecté les TDM SS7 Orange sur des carte Sangoma A108
géré avec Asterisk ?

Ce que je cherche a savoir, c'est la config de Wanpipe, notamment les line
coding (HDB3 je pense), le framing (NCRC4) etc ... et aussi que choisir
dans le type de signaling (PRI CPE, PRI NET etc ..)

L'idée n'est pas d’être en grosse prod, mais de gérer le temps de passer en
SIP complet
je pense pas que coté Asterisk cela soit très différent

Actuellement, cela semble up mais orange me dit qu'ils voyent down :=)
Description  Alarms  IRQbpviol CRCFra
Codi Options  LBO
wanpipe3 card 2  OK  0  0  0  CCS
HDB3  0 db (CSU)/0-133 feet (DSX-1)
wanpipe4 card 3  OK  0  0  0  CCS
HDB3  0 db (CSU)/0-133 feet (DSX-1)
wanpipe5 card 4  RED 0  0  0  CCS
HDB3  0 db (CSU)/0-133 feet (DSX-1)


merci d'avance
Lucas

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

[FRnOG] [MISC] Mikrotik Admin password

[Lucas Viallon]

Bonsoir,

Quelqu'un sait si on peut changer le mot de passe admin (password recovery)
sans perdre toutes la config ?

merci

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

[FRnOG] [MISC] Rack Schroff

[Lucas Viallon]

Bonjour,

Quelqu’un sait si les baies Schroff, c'est comme les baie APC, c'est la
même clefs pour toutes les serrures ou si il y a une sorte de passe partout
?

merci

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

Re: [FRnOG] [TECH] Quel hardware pour un routage soft ?

[Lucas Viallon]

+1

Intéressé par les réponses sauf virtualisation ;=)

On me demande de plus en plus de faire une session BGP full table en backup
..
je le fais mais cela me fait flique de le faire sur mes asr 

Du coup, j'envisageais de mettre comme toi un serveur Linux dédié a cela
avec une/des cartes 2 ports 10Gbis SFP+

Bon j'ai pas encore regardé ce que cela donne en software notamment si
l'ISIS
a bien été implanté ...




Le mar. 28 mai 2019 à 09:53, Julien Escario  a
écrit :

> Bonjour la liste,
> Nous cherchons depuis quelques temps à virer nos bordures à base de
> Mikrotik qui ne convient plus à nos besoins (convergence, features, etc
> ...). On va éviter les trolls : ça a bien fait le job à une époque, on
> passe à autre chose, fin du bal.
>
> Je sais qu'un certain nombre d'entre vous ne jurent que par les babasses
> qui bouffent 2kW. On est plutôt orientés système donc je regarde très
> prêt les avancées de FRR, notamment pour disposer d'un stack moderne
> (enfin pouvoir jouer avec IS-IS, faire de la validation RPKI, ...).
>
> Ceci étant, est-ce que certains d'entre vous ont déjà pensé ou mieux,
> déployé, le matos qu'il faut pour mettre un routeur soft ?
> * Niveau CPU, à peu près n'importe quoi de moderne fera le job
> * RAM forcément ECC (on va éviter les emmerdes) et même 16Go feront le job
> * Double alim
> * SSD en RAID1, je doute que le DWPD soit un gros soucis
>
> Jusque là, ça se trouve chez Supermicro 'à pas cher', même en incluant
> le spare.
>
> C'est surtout niveau interfaces. Mon but est d'avoir au moins ce que mon
> CCR1036 fait aujourd'hui : 4 SFP et un port cuivre mais c'est plein donc
> quelques SFP de plus seraient les bienvenus.
>
> Maintenant, et tant qu'à désigner un truc en 2019, j'aimerais bien avoir
> la possibilité d'avoir des ports SFP+ qui supportent aussi des SFP.
> Comme ça, on upgrade en 10G sans tout changer dans un an.
> Et pas moyen de trouver une carte PCIe 4xSFP+ qui supporte des optiques 1G.
>
> Et la question qui tue : virtualisé ou pas ? On a de gros doutes sur
> l'intérêt de la virtu dans ce cas très précis et pourtant, on en met
> partout.
>
> Bref, quelqu'un a t'il déjà fait ça en lab/prod et quel est son retour ?
>
> Merci !
> Julien
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [MISC] Re: Solution de virtualisation

[Lucas Viallon]

Bonjour,

Beaucoup m'ont demandé pourquoi je voulais revenir en arrière. Je vais
expliquer en deux ou trois lignes.

Nous avons migré au cloud il y a 3 ans environs, nous avons un peu galéré
car
nous avions besoin d'un Direct Connect et la possibilité de travailler avec
des Vlans
dans ce Direct Connect.

Il nous a fallu 1 an pour y arriver car malheureusement il y a souvent une
différence entre
les informations que transmet le commercial ou le chef de projet et la
réalité. Donc
après avoir fait tirer des cross connect pour valider, nous avons du
revenir a chaque fois
au constat que ce n’était pas possible. AWS,Google et même le cloud d'un
très gros
opérateur historique aucun n'avait les bonnes fonctionnalité (ou alors
c'etait dans la roadmap).

Au bout d'1 an, nous avons réussi a faire ce que l'on voulait sur un autre
acteur du cloud français,
malheureusement la stabilité n'est pas au rendez-vous.

On peut juste parler des instances qui s’arrête on ne sait pas pourquoi et
qui ce mettent en erreur,
impossible de les redémarrer en mode CLI ou Web, obligé de passer par le
support openstack du
fournisseur. Bon ce n'est pas souvent mais sur une 30 ene d'instance 3 a 4
cas par an c'est gênant

Ensuite, on ne maîtrise pas la partie réseau, nous avons des pertes de
paquet entre les instances
et le routeur d'interco (donc logiquement sur le même lan) et impossible de
trouver pourquoi.
La par contre c'est mortelle, et quand le ticket est ouvert depuis 20j et
que tu n'as toujours pas de
solution ...

Ce n'est pas le coût en lui même du cloud, certes cela fait plusieurs
milliers d'euro par mois mais
je pense pas que l'on migre sur le cloud pour faire des économies ... Nous
c'est plus que au final nous
avons un service beaucoup moins performant que ce que l'on avait avant avec
un simple bricolage de
VMWare version gratuite. On a rien gagné a passer au cloud donc on préfère
réinvestir dans une bonne
plateforme interne.

Voila en gros la raison d'un retour en arrière.

Attention, on ne vends pas du cloud a nos clients, ce sont des instances
pour des serveurs internes
donc le contexte peut être différent pour d'autres. On ne regrette pas
cette expérience même si on
ne la trouve pas bénéfique pour nous.

Le ven. 24 mai 2019 à 13:21, Lucas Viallon  a
écrit :

> Bonjour,
>
> Bon je sais ce n'est pas trop réseau mais je pose quand même la question,
> n’hésitez pas a faire des retours en privés pour ne pas ennuyer.
>
> Après avoir externalisé nos serveurs dans des cloud de grand nom, nous
> souhaitons maintenant les ré-internaliser. Nous avons eu de trop mauvaise
> expérience (Attention, on ne cherche pas de nouveau prestataire ou cloud).
>
> Nous avons donc un NAS haut de gamme bourré de SSD et supportant ISCSI,
> plusieurs serveurs pour faire des nodes, des switch cisco nexus 100% 10G
> bref que du bonheur pour moi en terme d’équipement.
>
> Aujourd'hui je dois choisir la solution software, de base j'ai ProxMox
> dans la tête mais je voulais connaitre l'avis de ceux qui comme moi on
> rapatrié ou on gardé en interne.
>
> Proxmox, OVirt, OpenStack que choisir ? sachant que nous aimerions
> disposer de la Haute Disponibilité avec si possible déplacement des VM a
> chaud.
>
> merci d'avance
> Lucas
>
>
>
>
>

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

[FRnOG] [MISC] Solution de virtualisation

[Lucas Viallon]

Bonjour,

Bon je sais ce n'est pas trop réseau mais je pose quand même la question,
n’hésitez pas a faire des retours en privés pour ne pas ennuyer.

Après avoir externalisé nos serveurs dans des cloud de grand nom, nous
souhaitons maintenant les ré-internaliser. Nous avons eu de trop mauvaise
expérience (Attention, on ne cherche pas de nouveau prestataire ou cloud).

Nous avons donc un NAS haut de gamme bourré de SSD et supportant ISCSI,
plusieurs serveurs pour faire des nodes, des switch cisco nexus 100% 10G
bref que du bonheur pour moi en terme d’équipement.

Aujourd'hui je dois choisir la solution software, de base j'ai ProxMox dans
la tête mais je voulais connaitre l'avis de ceux qui comme moi on rapatrié
ou on gardé en interne.

Proxmox, OVirt, OpenStack que choisir ? sachant que nous aimerions disposer
de la Haute Disponibilité avec si possible déplacement des VM a chaud.

merci d'avance
Lucas

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

[FRnOG] [BIZ] Recherche prestation d'infogérance MAN PACA

[Guillaume LUCAS]

Bonjour,

À l'université d'Avignon, nous recherchons une prestation d'infogérance 
(télé-supervision* + télé-exploitation** + AMOA***) pour un petit MAN 
(10 sites géographiques, commutateurs HP, IMC, < 10 VLANs, QinQ, RRPP, 
routage BGP sur un seul site) qui existe depuis plusieurs années à 
Avignon et alentours.


Nous recherchons plutôt une petite PME locale (PACA, Gard, Hérault).

Avez-vous des noms de structures à nous suggérer ?

Bonne journée.


* : "hého, vous avez un commut' ou une liaison ou… HS".

** : modifications qui ne changent pas l'architecture du réseau (ajout / 
retrait d'une entité / d'un site géographique, ajout / retrait d'un 
VLAN, ajout / retrait d'un peering BGP, etc.).


*** : conseils et expertise pour d'éventuelles refontes et évolutions 
conséquentes de l'architecture du réseau.



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

[FRnOG] [MISC] Contact APNF

[Lucas Viallon]

Bonjour,

J'arrive pas a trouver un contact où le moyen de contacter l'Association de
la Portabilité des Numéros Fixes (APNF)

Quelqu'un aurait une solution a me donner ?

merci d'avance
Cordialement
Lucas

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

[FRnOG] [TECH] Question bete d'un novice en CWDM

[Lucas Viallon]

Bonjour,

Alors la question bete d'un novice en CWDM:

Il me semble que l'on ne peut pas regénéré/amplifié un channel CWDM,

La seul solution est de mettre un equipment actif style SWITCH ?

merci

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

Re: [FRnOG] [TECH] Autre que Mikrotik pour du BGP Full table

[Lucas Viallon]

Cela a pas l'air très très performant les One2510 2520 ou 2540
je vois même pas de port 10Gbits


je me trompe ?


Le ven. 12 avr. 2019 à 14:38, stéphane augis  a écrit :

> Bonjour Lucas,
>
> Sérieusement si tu veux rester dans la zone "je prend un routeur reconnu
> qui se rapproche d'un Cisco mais en bcp moins cher en terme de
> programmation , en terme de fiabilité et reconnu par les opérateurs
> français Tier1 " alors je rejoins Valentin sur le choix d'un OneAccess
> du style ONE2510 ou 2520
>
>
> Stéphane
>
> Le 12/04/2019 à 14:20, Lucas Viallon a écrit :
> > J'y ai pensé mais j'aime vraiment pas mettre cela sur un simple serveur
> 1U,
> > le taux de panne
> > est quand même + important
> >
> > Le ven. 12 avr. 2019 à 13:20, Xavier Lemaire 
> a
> > écrit :
> >
> >> Question : Vous n'avez jamais pensé à faire du FRR avec des pfsenses ?
> >>
> >> Le ven. 12 avr. 2019 à 12:56, Raphael Jacquot  a
> écrit
> >> :
> >>
> >>>
> >>> On 4/12/19 10:14 AM, Xavier Beaudouin wrote:
> >>>
> >>>> J'ai un EdgeRouter Pro avec 2Go de RAM et une full view : j'ai 50% de
> >>> RAM dispo.
> >>>
> >>> et on doit pouvoir lui remplacer la ram pour en mettre plus...
> >>>
> >>>
> >>> ---
> >>> Liste de diffusion du FRnOG
> >>> http://www.frnog.org/
> >>>
> >>
> >> --
> >>
> >>
> >> FR 00 33 222 06 41 05
> >> ES 00 34 951 820 240
> >> ES 00 34 683 14 39 64
> >>
> >> xav...@amassi-network.com
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations
> >> confidentielles ou privilegiees et ne doivent donc
> >>
> >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu
> >> ce message par erreur, veuillez le signaler
> >>
> >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> >> electroniques etant susceptibles d'alteration,
> >>
> >> Amassi-network decline toute responsabilite si ce message a ete altere,
> >> deforme ou falsifie. Merci.
> >>
> >>
> >>
> >> This message and its attachments may contain confidential or privileged
> >> information that may be protected by law;
> >>
> >> they should not be distributed, used or copied without authorisation.
> >>
> >> If you have received this email in error, please notify the sender and
> >> delete this message and its attachments.
> >>
> >> As emails may be altered, Amassi-network is not liable for messages that
> >> have been modified, changed or falsified.
> >>
> >> Thank you.
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Cet email a fait l'objet d'une analyse antivirus par AVG.
> http://www.avg.com
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Autre que Mikrotik pour du BGP Full table

[Lucas Viallon]

J'y ai pensé mais j'aime vraiment pas mettre cela sur un simple serveur 1U,
le taux de panne
est quand même + important

Le ven. 12 avr. 2019 à 13:20, Xavier Lemaire  a
écrit :

> Question : Vous n'avez jamais pensé à faire du FRR avec des pfsenses ?
>
> Le ven. 12 avr. 2019 à 12:56, Raphael Jacquot  a écrit
> :
>
> >
> >
> > On 4/12/19 10:14 AM, Xavier Beaudouin wrote:
> >
> > > J'ai un EdgeRouter Pro avec 2Go de RAM et une full view : j'ai 50% de
> > RAM dispo.
> >
> > et on doit pouvoir lui remplacer la ram pour en mettre plus...
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
>
> --
>
>
> FR 00 33 222 06 41 05
> ES 00 34 951 820 240
> ES 00 34 683 14 39 64
>
> xav...@amassi-network.com
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
>
> Amassi-network decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
>
> As emails may be altered, Amassi-network is not liable for messages that
> have been modified, changed or falsified.
>
> Thank you.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [BIZ] Datacenter alternatif à Caen ?

[Christophe LUCAS]

Bonjour,

Covage il me semble.

Christophe

- Mail original -
De: "GreG" 
À: frnog@frnog.org
Envoyé: Vendredi 12 Avril 2019 09:48:13
Objet: Re: [FRnOG] [BIZ] Datacenter alternatif à Caen ?

Pour fréquenter régulièrement le netcenter de Caen il y a tous les FAIs 
nationaux présent sur place + tdf, covage, 
Sinon tu as celui que normhost utlise (je ne me souviens plus du vrai 
proprio) . Pas d'autres à ma connaissance .

Le 11/04/2019 à 18:48, Culeron, Sylvain a écrit :
> Cogent présent sur ce NetCenter...
>
> Donc au moins deux opérateurs :-)
>
> -Original Message-
> From: frnog-requ...@frnog.org  On Behalf Of 
> Radu-Adrian Feurdean
> Sent: Thursday, April 11, 2019 5:15 PM
> To: frnog@frnog.org
> Subject: Re: [FRnOG] [BIZ] Datacenter alternatif à Caen ?
>
> Il semblerait qu'il y a un NetCenter Caen ( https://www.peeringdb.com/fac/719 
> ), mais avec aucun operateur (autre que SFR - et encore) present.
>
> Sinon, si c'est juste pour de la presence telco, voir peut-etre avec Covage 
> qui ont des choses dans le coin.
>
> On Thu, Apr 11, 2019, at 17:01, David Ponzone wrote:
>> Tu veux dire alternatif à NormHost ? :)
>>
>>> Le 11 avr. 2019 à 16:55, Julien Ducros  a 
>>> écrit :
>>>
>>> Bonjour la liste,
>>>
>>> Dites, vous connaissez ou exploitez un datacenter alternatif à Caen ? cela 
>>> m’intéresse..
>>>
>>> Merci !
>>>
>>> Jul
>>>
>>> —
>>> Groupe IELO-LIAZO
>>> Mobile CH +41 78 615 03 33
>>> Mobile FR +33 678 000 694
>>> http://ielo-liazo.com/
>>>
>>>
>>> ---
>>> 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] [TECH] Autre que Mikrotik pour du BGP Full table

[Lucas Viallon]

Donc si cela tiens la route avec 2GO de ram, le Infinity avec 16G devrait
etre
cool non ?

au niveau CLI c'est correcte ?

3 session Full, 2 vers mes routes server et 1 vers mon transitaire.

d'apres le datasheet, cela permet
  Layer 3 Forwarding Performance
Packet Size: 64 Bytes18,000,000 pps
Packet Size: 1514 Bytes 80 Gbps (Line Rate)

donc deja pas mal



Le ven. 12 avr. 2019 à 10:16, Xavier Beaudouin  a écrit :

> Salut Lucas,
>
>
> > Je suis donc en train de tester un mikrotik sur une session BGP Full
> Table
> > Bon j'avoue que le CLI/GUI n'est pas trop mon truc sur le Mikrotik, c'est
> > pas
> > très très claire.
>
> J'ai un peu de mal aussi... L'impression de registry de Win95... :)
>
> > Il y a quoi d'autre comme routeur de ce type qui permettrait de tenir la
> > route avec la full table ?
> > j'ai vu le Ubiquiti EdgeRouter Infinity mais y en a t'il d'autre ?
>
> J'ai un EdgeRouter Pro avec 2Go de RAM et une full view : j'ai 50% de RAM
> dispo.
>
> > Je suis familiarisé avec le cli cisco, mais je recherche dans une gamme a
> > ~2500 euro
>
> La question qui se pose c'est surtout :
> - combien de full
> - combien de pps
>
> :)
> Xavier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Autre que Mikrotik pour du BGP Full table

[Lucas Viallon]

Bonjour

Je suis donc en train de tester un mikrotik sur une session BGP Full Table
Bon j'avoue que le CLI/GUI n'est pas trop mon truc sur le Mikrotik, c'est
pas
très très claire.

Il y a quoi d'autre comme routeur de ce type qui permettrait de tenir la
route avec la full table ?
j'ai vu le Ubiquiti EdgeRouter Infinity mais y en a t'il d'autre ?

Je suis familiarisé avec le cli cisco, mais je recherche dans une gamme a
~2500 euro

merci

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