[JOBS] [FRnOG] [JOB] Ingénieur réseau

2019-12-12 Par sujet Mamadou Lamine Diallo
Bonjour,

Je suis à la recherche d’un poste d’ingénieur réseau en IDF.
Je travaille depuis 2 ans dans la supervision réseau avec des outils
microfocus (NNMi OMi Network Automation) et open source (prometheus,
grafana).
J’ai de bonnes connaissance en routing et le swiching et l’automatisation
réseau avec Ansible notamment.
J’ai la certification ccna routing and swiching et regarde de temps en
temps  le ccnp 
Je connais la techno IP Fabric Juniper basée sur les protocoles EVPN et
VxLan dont j’ai participé à la qualification dans une équipe Orange en 2017

L’idéal pour moi serait de travailler dans une équipe build qui test et
valide de nouvelles fonctions réseau, après je suis ouverts à d autres
propositions.

Je suis dispo pour plus d infos sur mon parcours.

À très bientôt 
Lamine

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


Re: [FRnOG] [MISC] [FUN] You Down With BGP ?

2019-12-12 Par sujet Refuznik
Bah le classique https://www.youtube.com/watch?v=zi8VTeDHjcM

Le ven. 13 déc. 2019 à 00:32, Clement Cavadore  a
écrit :

> La mienne... plus de douze ans plus tard, je m'en souviens encore
> (même si je n'étais pas présent à ce meeting)
>
> https://www.youtube.com/watch?v=_y36fG2Oba0
>
> :-)
>
> On Thu, 2019-12-12 at 22:18 +0100, Romain wrote:
> > Ma petite participation :)
> >
> > https://youtu.be/k_y1OvEhZvg
> >
> > Le jeu. 12 déc. 2019 à 21:12, Alexis Lameire  > m> a
> > écrit :
> >
> > > https://www.youtube.com/watch?v=aPtr43KHBGk
> > >
> > > Bon, c'est toujours aussi drôle !
> > >
> > > Alexis
> > >
> > > Le jeu. 12 déc. 2019 à 20:18, Laurent GUINCHARD
> > >  a écrit :
> > > >
> > > >
> > > > https://www.youtube.com/watch?v=RT-1DU33xIk=youtu.be
> > > >
> > > > 
> > > > Laurent GUINCHARD
> > > > Responsable d'Equipe
> > > > Ingénierie Réseau et Sécurité
> > > > Infrastructures
> > > > 
> > > > LINKBYNET
> > > > 5-9, rue de l'industrie - 93200 Saint-Denis
> > > > Email : l.guinch...@linkbynet.com > > > m>-
> > >
> > > Web : www.linkbynet.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/


Re: [FRnOG] [MISC] [FUN] You Down With BGP ?

2019-12-12 Par sujet Arnaud Launay
Le Fri, Dec 13, 2019 at 12:05:03AM +0100, David Ponzone a écrit:
> Un peu off-topic mais bon, c’est vendredi depuis 4 min:
> https://www.youtube.com/watch?v=_Qyu8iaqcfk

Sont mignons vos trucs, mais ya mieux:

https://www.youtube.com/watch?v=K8Tvs51UQsE

Arnaud.


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


Re: [FRnOG] [MISC] [FUN] You Down With BGP ?

2019-12-12 Par sujet Clement Cavadore
La mienne... plus de douze ans plus tard, je m'en souviens encore 
(même si je n'étais pas présent à ce meeting)

https://www.youtube.com/watch?v=_y36fG2Oba0

:-)

On Thu, 2019-12-12 at 22:18 +0100, Romain wrote:
> Ma petite participation :)
> 
> https://youtu.be/k_y1OvEhZvg
> 
> Le jeu. 12 déc. 2019 à 21:12, Alexis Lameire  m> a
> écrit :
> 
> > https://www.youtube.com/watch?v=aPtr43KHBGk
> > 
> > Bon, c'est toujours aussi drôle !
> > 
> > Alexis
> > 
> > Le jeu. 12 déc. 2019 à 20:18, Laurent GUINCHARD
> >  a écrit :
> > > 
> > > 
> > > https://www.youtube.com/watch?v=RT-1DU33xIk=youtu.be
> > > 
> > > 
> > > Laurent GUINCHARD
> > > Responsable d'Equipe
> > > Ingénierie Réseau et Sécurité
> > > Infrastructures
> > > 
> > > LINKBYNET
> > > 5-9, rue de l'industrie - 93200 Saint-Denis
> > > Email : l.guinch...@linkbynet.com > > m>-
> > 
> > Web : www.linkbynet.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/


Re: [FRnOG] [MISC] [FUN] You Down With BGP ?

2019-12-12 Par sujet David Ponzone
Un peu off-topic mais bon, c’est vendredi depuis 4 min:

https://www.youtube.com/watch?v=_Qyu8iaqcfk


> Le 12 déc. 2019 à 22:18, Romain  a écrit :
> 
> Ma petite participation :)
> 
> https://youtu.be/k_y1OvEhZvg
> 
> Le jeu. 12 déc. 2019 à 21:12, Alexis Lameire  a
> écrit :
> 
>> https://www.youtube.com/watch?v=aPtr43KHBGk
>> 
>> Bon, c'est toujours aussi drôle !
>> 
>> Alexis
>> 
>> Le jeu. 12 déc. 2019 à 20:18, Laurent GUINCHARD
>>  a écrit :
>>> 
>>> 
>>> https://www.youtube.com/watch?v=RT-1DU33xIk=youtu.be
>>> 
>>> 
>>> Laurent GUINCHARD
>>> Responsable d'Equipe
>>> Ingénierie Réseau et Sécurité
>>> Infrastructures
>>> 
>>> LINKBYNET
>>> 5-9, rue de l'industrie - 93200 Saint-Denis
>>> Email : l.guinch...@linkbynet.com-
>> Web : www.linkbynet.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/


Re: [FRnOG] [ALERT] Incident interco OTI / Cogent Paris ?

2019-12-12 Par sujet Anthony Frnog
Bonsoir,

Problème similaire pour moi mais depuis Alphalink vers Cogent, avec des
pertes de paquets sur des routeurs (saut) opentransit



Le jeu. 12 déc. 2019 17:28, Quentin Leconte  a
écrit :

> Bonsoir la liste,
>
> Depuis quelques jours, nous avons des clients sur des opérateurs
> transitant par OTI/AS5511 qui rencontre des lenteurs et des pertes pour
> nous joindre au travers de notre transit Cogent.
>
> Il semblerait que l'échange entre OTI et Cogent ne se fasse plus sur Paris
> mais sur FRA3. Et visiblement, de Toulouse à Francfort, les packets
> semblent aimer faire un détour par le soleil.
> Certaines personnes auraient des infos ou ont pu observer des saturations
> sur cet interco ?
>
> Traceroute depuis chez nous :
>
> Host
>
> Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. AS41652 xxx.core.tls.shpv.network
>
> 0.0%720.4   0.3   0.2   0.7   0.0
>  2. AS174   te0-0-2-2.rcr11.tls01.atlas.cogentco.com
>
> 0.0%721.0   1.1   0.8   3.5   0.4
>  3. AS174   te0-2-1-2.rcr21.bod01.atlas.cogentco.com
>
> 0.0%724.3   4.4   4.2   4.6   0.0
>  4. AS174   be2840.rcr21.eas02.atlas.cogentco.com
>
>  0.0%728.0   7.9   7.6   8.1   0.0
>  5. AS174   be2839.ccr52.bio02.atlas.cogentco.com
>
>  0.0%729.1   8.7   8.6   9.1   0.0
>  6. AS174   be3358.ccr32.mad05.atlas.cogentco.com
>
>  0.0%72   13.8  13.5  13.2  13.9   0.0
>  7. AS174   ft.fra03.atlas.cogentco.com
>
>  0.0%72   27.5  27.3  26.9  27.6   0.0
>  8. ???
>  9. ???
> 10. ???
> 11. AS5511  81.52.200.197
>
>  0.0%71   44.0  28.0  26.8  52.3   3.7
> 12. ???
> 13. AS25540 xxx.reverse.alphalink.fr
>   0.0%
> 71   27.1  27.1  26.9  27.5   0.0
>
> Merci !
>
> --
>
> Quentin Leconte
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


Re: [FRnOG] [MISC] [FUN] You Down With BGP ?

2019-12-12 Par sujet Romain
Ma petite participation :)

https://youtu.be/k_y1OvEhZvg

Le jeu. 12 déc. 2019 à 21:12, Alexis Lameire  a
écrit :

> https://www.youtube.com/watch?v=aPtr43KHBGk
>
> Bon, c'est toujours aussi drôle !
>
> Alexis
>
> Le jeu. 12 déc. 2019 à 20:18, Laurent GUINCHARD
>  a écrit :
> >
> >
> > https://www.youtube.com/watch?v=RT-1DU33xIk=youtu.be
> >
> > 
> > Laurent GUINCHARD
> > Responsable d'Equipe
> > Ingénierie Réseau et Sécurité
> > Infrastructures
> > 
> > LINKBYNET
> > 5-9, rue de l'industrie - 93200 Saint-Denis
> > Email : l.guinch...@linkbynet.com-
> Web : www.linkbynet.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/


Re: [FRnOG] [TECH] BGP best practice

2019-12-12 Par sujet Alexis Lameire
Pour répondre à Michel Py

Je suis pas forcément fan du null routing. C'est bien pour se dépanner
mais explicité un truc qui vas déjà être discard, borf

un bon filtrage des bogons et le respect de la BCP38 ca aide. Le bon
usage des VRF est aussi a recommander. Perso je tente de limiter la
VRF par défaut au "controle plane" où tout les truc qui pour on ne
sait quel raison ne peut pas être passé dans une VRF.

Voilà voila
Alexis


Le jeu. 12 déc. 2019 à 15:39, David Ponzone  a écrit :
>
> C’est quoi la route pour joindre 8.8.8.8 depuis R2 ?
> Si c’est R1 et que tu précises pas l’ip source, ton Ping va venir de l’ip 
> privée du FE de R2.
> Donc...
>
> David Ponzone
>
>
>
> > Le 12 déc. 2019 à 15:31, Antoine DURAND  a écrit :
> >
> > 
> > Je viens de monter un lab pour mon histoire de deny/permit ! J'arrive enfin 
> > à quelque chose qui me convient ! Je posterai ici la version finale pour 
> > ceux qui sont interessés...
> >
> > Par contre j'ai un problème avec l'utilisation iBGP que je ne m'explique 
> > pas.
> > ISP-1 connecté sur R1
> > ISP-2 connecté sur R2
> >
> > Je préfère la sortie ISP-1 pour joindre 8.8.8.8 (local pref 200) via R1, 
> > sur R2 je suis à 100.
> > Depuis R1 je ping sans problème 8.8.8.8 mais pas possible depuis R2 SAUF si 
> > je passe OFF R1 !!
> >
> > Même chose pour toutes les IPs ayant une local pref 200 depuis R2 !
> >
> > J'utilise pourtant bien une IP publique (lo0) et également next-hop-self + 
> > update-source Loopback0 sur iBGP
> >
> > Voici la conf :
> >
> > R1 :
> > interface Loopback0
> >  ip address A.A.A.1 255.255.255.252
> > !
> > interface FastEthernet2/0
> >  description link vers R2
> >  ip address 10.0.0.1 255.255.255.252
> >  duplex auto
> >  speed auto
> >  !
> > !
> > router bgp 65001
> >  no synchronization
> >  bgp router-id 10.0.0.1
> >  bgp log-neighbor-changes
> >  network A.A.A.0 mask 255.255.255.0
> >  network B.B.B.0 mask 255.255.254.0
> >  network C.C.C.0 mask 255.255.255.0
> >  neighbor 10.0.0.2 remote-as 65001
> >  neighbor 10.0.0.2 update-source Loopback0
> >  neighbor 10.0.0.2 next-hop-self
> >  neighbor 10.0.0.2 soft-reconfiguration inbound
> > !
> > ip route A.A.A.2 255.255.255.255 10.0.0.2
> > !
> > R2 :
> > interface Loopback0
> >  ip address A.A.A.2 255.255.255.252
> > !
> > interface FastEthernet2/0
> >  description link vers R1
> >  ip address 10.0.0.2 255.255.255.252
> >  duplex auto
> >  speed auto
> >  !
> > !
> > router bgp 65001
> >  no synchronization
> >  bgp router-id 10.0.0.2
> >  bgp log-neighbor-changes
> >  network A.A.A.0 mask 255.255.255.0
> >  network B.B.B.0 mask 255.255.254.0
> >  network C.C.C.0 mask 255.255.255.0
> >  neighbor 10.0.0.1 remote-as 65001
> >  neighbor 10.0.0.1 update-source Loopback0
> >  neighbor 10.0.0.1 next-hop-self
> >  neighbor 10.0.0.1 soft-reconfiguration inbound
> > !
> > ip route A.A.A.1 255.255.255.255 10.0.0.1
> > !
> >
> > Je tourne en rond depuis hier sans trouver, une idée de quoi j'oubli ?
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [MISC] [FUN] You Down With BGP ?

2019-12-12 Par sujet Alexis Lameire
https://www.youtube.com/watch?v=aPtr43KHBGk

Bon, c'est toujours aussi drôle !

Alexis

Le jeu. 12 déc. 2019 à 20:18, Laurent GUINCHARD
 a écrit :
>
>
> https://www.youtube.com/watch?v=RT-1DU33xIk=youtu.be
>
> 
> Laurent GUINCHARD
> Responsable d'Equipe
> Ingénierie Réseau et Sécurité
> Infrastructures
> 
> LINKBYNET
> 5-9, rue de l'industrie - 93200 Saint-Denis
> Email : l.guinch...@linkbynet.com- Web : 
> www.linkbynet.com
> _
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


[FRnOG] [MISC] [FUN] You Down With BGP ?

2019-12-12 Par sujet Laurent GUINCHARD


https://www.youtube.com/watch?v=RT-1DU33xIk=youtu.be


Laurent GUINCHARD
Responsable d'Equipe
Ingénierie Réseau et Sécurité
Infrastructures

LINKBYNET
5-9, rue de l'industrie - 93200 Saint-Denis
Email : l.guinch...@linkbynet.com- Web : 
www.linkbynet.com
_


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


[FRnOG] [TECH] Réduction considérable des bogons de Team Cymru

2019-12-12 Par sujet Michel Py
Bonjour la liste,

Depuis environ 2 mois (début Octobre) le nombre des bogons dans le full-feed de 
Team Cymru est passé d'environ 3.500 à 205 aujourd'hui, juste au-dessus de 200 
pour les 2 dernières semaines.

Est-ce que quelqu'un sait quelque chose ?

Michel.


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


Re: [FRnOG] [ALERT] Incident interco OTI / Cogent Paris ?

2019-12-12 Par sujet Pierre Emeriaud
Le jeu. 12 déc. 2019 à 17:28, Quentin Leconte
 a écrit :
>
> Bonsoir la liste,
>
> Depuis quelques jours, nous avons des clients sur des opérateurs transitant 
> par OTI/AS5511 qui rencontre des lenteurs et des pertes pour nous joindre au 
> travers de notre transit Cogent.

> Il semblerait que l'échange entre OTI et Cogent ne se fasse plus sur Paris 
> mais sur FRA3. Et visiblement, de Toulouse à Francfort, les packets semblent 
> aimer faire un détour par le soleil.
> Certaines personnes auraient des infos ou ont pu observer des saturations sur 
> cet interco ?


trop aimable de fourni les ip sources et dest. Le diagnostic en sera
facilité ! /s

Y'a au moins 5 intercos en europe entre 5511 et 174. vu que j'ai qu'un
looking glass (telnet route-server.opentransit.net) et pas une boule
de cristal, on va attendre avant de regarder plus que ça hein.


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


[FRnOG] [ALERT] Incident interco OTI / Cogent Paris ?

2019-12-12 Par sujet Quentin Leconte
Bonsoir la liste,

Depuis quelques jours, nous avons des clients sur des opérateurs transitant par 
OTI/AS5511 qui rencontre des lenteurs et des pertes pour nous joindre au 
travers de notre transit Cogent.

Il semblerait que l'échange entre OTI et Cogent ne se fasse plus sur Paris mais 
sur FRA3. Et visiblement, de Toulouse à Francfort, les packets semblent aimer 
faire un détour par le soleil. 
Certaines personnes auraient des infos ou ont pu observer des saturations sur 
cet interco ?

Traceroute depuis chez nous :

Host
Loss%   Snt 
  Last   Avg  Best  Wrst StDev
 1. AS41652 xxx.core.tls.shpv.network   
 0.0%72 
   0.4   0.3   0.2   0.7   0.0
 2. AS174   te0-0-2-2.rcr11.tls01.atlas.cogentco.com
  0.0%
721.0   1.1   0.8   3.5   0.4
 3. AS174   te0-2-1-2.rcr21.bod01.atlas.cogentco.com
  0.0%
724.3   4.4   4.2   4.6   0.0
 4. AS174   be2840.rcr21.eas02.atlas.cogentco.com   
  0.0%
728.0   7.9   7.6   8.1   0.0
 5. AS174   be2839.ccr52.bio02.atlas.cogentco.com   
  0.0%
729.1   8.7   8.6   9.1   0.0
 6. AS174   be3358.ccr32.mad05.atlas.cogentco.com   
  0.0%
72   13.8  13.5  13.2  13.9   0.0
 7. AS174   ft.fra03.atlas.cogentco.com 
  0.0%
72   27.5  27.3  26.9  27.6   0.0
 8. ???
 9. ???
10. ???
11. AS5511  81.52.200.197   
  0.0%
71   44.0  28.0  26.8  52.3   3.7
12. ???
13. AS25540 xxx.reverse.alphalink.fr
0.0%71   27.1  
27.1  26.9  27.5   0.0

Merci !

--

Quentin Leconte




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


Re: [FRnOG] [TECH] BGP best practice

2019-12-12 Par sujet David Ponzone
C’est quoi la route pour joindre 8.8.8.8 depuis R2 ?
Si c’est R1 et que tu précises pas l’ip source, ton Ping va venir de l’ip 
privée du FE de R2.
Donc...

David Ponzone



> Le 12 déc. 2019 à 15:31, Antoine DURAND  a écrit :
> 
> 
> Je viens de monter un lab pour mon histoire de deny/permit ! J'arrive enfin à 
> quelque chose qui me convient ! Je posterai ici la version finale pour ceux 
> qui sont interessés...
>  
> Par contre j'ai un problème avec l'utilisation iBGP que je ne m'explique pas.
> ISP-1 connecté sur R1
> ISP-2 connecté sur R2
>  
> Je préfère la sortie ISP-1 pour joindre 8.8.8.8 (local pref 200) via R1, sur 
> R2 je suis à 100.
> Depuis R1 je ping sans problème 8.8.8.8 mais pas possible depuis R2 SAUF si 
> je passe OFF R1 !!
>  
> Même chose pour toutes les IPs ayant une local pref 200 depuis R2 !
>  
> J'utilise pourtant bien une IP publique (lo0) et également next-hop-self + 
> update-source Loopback0 sur iBGP
>  
> Voici la conf :
>  
> R1 :
> interface Loopback0
>  ip address A.A.A.1 255.255.255.252
> !
> interface FastEthernet2/0
>  description link vers R2
>  ip address 10.0.0.1 255.255.255.252
>  duplex auto
>  speed auto
>  !
> !
> router bgp 65001
>  no synchronization
>  bgp router-id 10.0.0.1
>  bgp log-neighbor-changes
>  network A.A.A.0 mask 255.255.255.0
>  network B.B.B.0 mask 255.255.254.0
>  network C.C.C.0 mask 255.255.255.0
>  neighbor 10.0.0.2 remote-as 65001
>  neighbor 10.0.0.2 update-source Loopback0
>  neighbor 10.0.0.2 next-hop-self
>  neighbor 10.0.0.2 soft-reconfiguration inbound
> !
> ip route A.A.A.2 255.255.255.255 10.0.0.2
> !
> R2 :
> interface Loopback0
>  ip address A.A.A.2 255.255.255.252
> !
> interface FastEthernet2/0
>  description link vers R1
>  ip address 10.0.0.2 255.255.255.252
>  duplex auto
>  speed auto
>  !
> !
> router bgp 65001
>  no synchronization
>  bgp router-id 10.0.0.2
>  bgp log-neighbor-changes
>  network A.A.A.0 mask 255.255.255.0
>  network B.B.B.0 mask 255.255.254.0
>  network C.C.C.0 mask 255.255.255.0
>  neighbor 10.0.0.1 remote-as 65001
>  neighbor 10.0.0.1 update-source Loopback0
>  neighbor 10.0.0.1 next-hop-self
>  neighbor 10.0.0.1 soft-reconfiguration inbound
> !
> ip route A.A.A.1 255.255.255.255 10.0.0.1
> !
>  
> Je tourne en rond depuis hier sans trouver, une idée de quoi j'oubli ?

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


Re: RE: [FRnOG] [TECH] BGP best practice

2019-12-12 Par sujet Antoine DURAND
Je viens de monter un lab pour mon histoire de deny/permit ! J'arrive enfin à quelque chose qui me convient ! Je posterai ici la version finale pour ceux qui sont interessés...

 

Par contre j'ai un problème avec l'utilisation iBGP que je ne m'explique pas.

ISP-1 connecté sur R1

ISP-2 connecté sur R2

 

Je préfère la sortie ISP-1 pour joindre 8.8.8.8 (local pref 200) via R1, sur R2 je suis à 100.

Depuis R1 je ping sans problème 8.8.8.8 mais pas possible depuis R2 SAUF si je passe OFF R1 !!

 

Même chose pour toutes les IPs ayant une local pref 200 depuis R2 !

 

J'utilise pourtant bien une IP publique (lo0) et également next-hop-self + update-source Loopback0 sur iBGP

 

Voici la conf :

 


R1 :
interface Loopback0
 ip address A.A.A.1 255.255.255.252
!
interface FastEthernet2/0
 description link vers R2
 ip address 10.0.0.1 255.255.255.252
 duplex auto
 speed auto
 !
!
router bgp 65001
 no synchronization
 bgp router-id 10.0.0.1
 bgp log-neighbor-changes
 network A.A.A.0 mask 255.255.255.0
 network B.B.B.0 mask 255.255.254.0
 network C.C.C.0 mask 255.255.255.0
 neighbor 10.0.0.2 remote-as 65001
 neighbor 10.0.0.2 update-source Loopback0
 neighbor 10.0.0.2 next-hop-self
 neighbor 10.0.0.2 soft-reconfiguration inbound
!

ip route A.A.A.2 255.255.255.255 10.0.0.2

!

R2 :
interface Loopback0
 ip address A.A.A.2 255.255.255.252
!
interface FastEthernet2/0
 description link vers R1
 ip address 10.0.0.2 255.255.255.252
 duplex auto
 speed auto
 !
!
router bgp 65001
 no synchronization
 bgp router-id 10.0.0.2
 bgp log-neighbor-changes
 network A.A.A.0 mask 255.255.255.0
 network B.B.B.0 mask 255.255.254.0
 network C.C.C.0 mask 255.255.255.0
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 update-source Loopback0
 neighbor 10.0.0.1 next-hop-self
 neighbor 10.0.0.1 soft-reconfiguration inbound
!

ip route A.A.A.1 255.255.255.255 10.0.0.1

!

 

Je tourne en rond depuis hier sans trouver, une idée de quoi j'oubli ?




Re: [FRnOG] [TECH] Visio & partage d'écran

2019-12-12 Par sujet François Laperruque
Bonjour a tous,

jitsy est fourni par Renater pour tous les etablissements de recherche et ca 
marche impec. 
Je ne passe plus que par ça, au boulot...

-- FAI associatif [Viviers Fibre]
http://viviers-fibre.net
https://yunohost.viviers-fibre.net

11 décembre 2019 22:06 mail...@kaminot.xyz a écrit:

> +1 jitsi en prod sur nos serveurs fonctionne super avec toutes les
> fonctionnalites et est open-source (donc un plus)
> 
> on a plus de 100 utilisateurs dessus.
> 
> vincent
> 
> On 12/11/19 8:00 PM, Michel Py wrote:
> 
>>> merwan a écrit :
>>> Tu as essayé zoom ?
>> 
>> C'est ce qu'on utilise aussi, Skype business on évite comme la peste.
>> 
>>> Wallace a écrit :
>>> Je te conseille vivement JitSi https://meet.jit.si
>> 
>> Je louche vers cela, en effet.
>> 
>> Michel.
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org


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


Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?

2019-12-12 Par sujet Fabien DEDENON





Bonjour,


iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre iperf.he.net 
et ma machine. C'est
suffisamment haut pour ne pas poser de problème. Par curiosité, est-il possible 
d'identifier aux
alentours de quel hop le shaping serait appliqué ?

J'ai l'impression que ton problème de TCP shapé n'en est pas un, que c'est 
juste l'effet de la latence que tu mesures...
En effet, faire de l'iperf en TCP, c'est bon pour un LAN ou à la limite un WAN 
national.
Pour la longue distance, si tu veux mesurer une bande passante max, c'est 
forcément avec de l'UDP.


Exacte, aussi si tu veux rester en TCP pour charger un circuit a rtt 
long, multiplie le nombre de flows:


-P, --parallel  # number of parallel client streams to run

+


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


Re: [FRnOG] [TECH] Mikrotik et Multicast

2019-12-12 Par sujet David Ponzone
Pierre,

Oui, pardon, je sous-entendais un environnement où on sait qu’il n’y a rien de 
« sérieux » qui exploite le Multicast (clustering, VRRP, etc..).
Ton argument est valable, c’est peut-être ce qui explique ce choix généralisé 
chez les constructeurs.

> Le 12 déc. 2019 à 11:22, Pierre LANCASTRE  a 
> écrit :
> 
> Bonjour 
> 
> Pas que du bien, quand la partie querier/report est pas configurée / mal 
> gérée, ça casse pas mal de choses. Déjà vu ça avec des softs de clustering 
> 


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


Re: [FRnOG] [TECH] Mikrotik et Multicast

2019-12-12 Par sujet Pierre LANCASTRE
Bonjour

Pas que du bien, quand la partie querier/report est pas configurée / mal
gérée, ça casse pas mal de choses. Déjà vu ça avec des softs de clustering

++

Pierre

Le jeu. 12 déc. 2019 à 10:49, David Ponzone  a
écrit :

> Oui tout à fait, mais j’avais pas anticipé une merde pareil sur le LAN :)
>
> D’ailleurs, je comprends pas pourquoi l’IGMP snooping est (quasi)
> systématiquement désactivé par défaut sur les switch, alors qu’à priori ça
> peut faire que du bien  non ?
>
> > Le 12 déc. 2019 à 10:11, Thierry Chich  a
> écrit :
> >
> >
> >
> >> -Message d'origine-
> >> De : frnog-requ...@frnog.org  De la part de
> >> David Ponzone
> >> Envoyé : jeudi 12 décembre 2019 09:48
> >> À : Hugues Voiturier 
> >> Cc : FRnOG 
> >> Objet : Re: [FRnOG] [TECH] Mikrotik et Multicast
> >>
> >> Yep, le mettre à no sur le/les ports egress, ça aide, merci!
> >>
> >> Je vais activer l’IGMP snooping aussi, ça va aider aussi.
> >
> >
> > J'y connais pas grand-chose, mais activer l'IGMP snooping , a priori,
> c'est vital ,sinon, le multicast c'est du broadcast.
> >>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


Re: [FRnOG] [TECH] Mikrotik et Multicast

2019-12-12 Par sujet David Ponzone
Oui tout à fait, mais j’avais pas anticipé une merde pareil sur le LAN :)

D’ailleurs, je comprends pas pourquoi l’IGMP snooping est (quasi) 
systématiquement désactivé par défaut sur les switch, alors qu’à priori ça peut 
faire que du bien  non ?

> Le 12 déc. 2019 à 10:11, Thierry Chich  a écrit 
> :
> 
> 
> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de
>> David Ponzone
>> Envoyé : jeudi 12 décembre 2019 09:48
>> À : Hugues Voiturier 
>> Cc : FRnOG 
>> Objet : Re: [FRnOG] [TECH] Mikrotik et Multicast
>> 
>> Yep, le mettre à no sur le/les ports egress, ça aide, merci!
>> 
>> Je vais activer l’IGMP snooping aussi, ça va aider aussi.
> 
> 
> J'y connais pas grand-chose, mais activer l'IGMP snooping , a priori, c'est 
> vital ,sinon, le multicast c'est du broadcast.
>> 


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


Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?

2019-12-12 Par sujet Philippe Bourcier
Bonjour,

> iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre 
> iperf.he.net et ma machine. C'est
> suffisamment haut pour ne pas poser de problème. Par curiosité, est-il 
> possible d'identifier aux
> alentours de quel hop le shaping serait appliqué ?

J'ai l'impression que ton problème de TCP shapé n'en est pas un, que c'est 
juste l'effet de la latence que tu mesures...
En effet, faire de l'iperf en TCP, c'est bon pour un LAN ou à la limite un WAN 
national.
Pour la longue distance, si tu veux mesurer une bande passante max, c'est 
forcément avec de l'UDP.


Cordialement,
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/philippebourcier


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


Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?

2019-12-12 Par sujet Raphael Mazelier



On 12/12/2019 10:19, Frederic Dumas wrote:



C'est une question de curiosité, pas un problème réel dans le cas 
présent.



En général le rtt (et donc la vitesse de la lumière), et le loss sont 
une bonne indication du débit théorique que tu peux atteindre en TCP ,;)


--

Raphael Mazelier


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


[FRnOG] Re: [TECH] TCP shape depuis les US - Identifier l'origine ?

2019-12-12 Par sujet Stephane Bortzmeyer
On Thu, Dec 12, 2019 at 10:19:09AM +0100,
 Frederic Dumas  wrote 
 a message of 65 lines which said:

> Existe-t-il un outil publiquement accessible du style des sondes
> Atlas, non pas pour regarder les annonces BGP, mais pour tester les
> débits depuis différents points de l'internet?

[Les capacités, pas les débits.]

Je ne crois pas qu'il puisse exister un tel outil : ce serait trop
tentant de l'utiliser pour des attaques par déni de service. (C'est
bien pour cela que les sondes Atlas ne font du HTTP que vers les
ancres.)




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


[FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?

2019-12-12 Par sujet Frederic Dumas



Bonjour,

iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre 
iperf.he.net et ma machine. C'est suffisamment haut pour ne pas poser de 
problème. Par curiosité, est-il possible d'identifier aux alentours de 
quel hop le shaping serait appliqué ?


D'après le looking glass de HE, les paquets allant de la Californie vers 
l'Europe ne traversent que deux AS: HE et celui de mon FAI (UPC). Ça ne 
nous laisse pas beaucoup de coupables.


Sans sondes le long du chemin, je ne vois pas comment en savoir plus. 
Existe-t-il un outil publiquement accessible du style des sondes Atlas, 
non pas pour regarder les annonces BGP, mais pour tester les débits 
depuis différents points de l'internet? Je préfère poser la question que 
de conclure trop vite.



C'est une question de curiosité, pas un problème réel dans le cas présent.

Bonne journée.



$ iperf3 -t30 -O5 -p5201 -c iperf.he.net -R
Connecting to host iperf.he.net, port 5201
Reverse mode, remote host iperf.he.net is sending

[SNIP]

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-30.00  sec   472 MBytes   132 Mbits/sec0 sender
[  4]   0.00-30.00  sec   473 MBytes   132 Mbits/sec receiver



$ iperf3 -t30 -O5 -p5201 -c iperf.he.net -R -P2
Connecting to host iperf.he.net, port 5201
Reverse mode, remote host iperf.he.net is sending

[SNIP]

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-30.00  sec   456 MBytes   128 Mbits/sec0 sender
[  4]   0.00-30.00  sec   457 MBytes   128 Mbits/sec receiver
[  6]   0.00-30.00  sec   456 MBytes   128 Mbits/sec0 sender
[  6]   0.00-30.00  sec   457 MBytes   128 Mbits/sec receiver
[SUM]   0.00-30.00  sec   912 MBytes   255 Mbits/sec0 sender
[SUM]   0.00-30.00  sec   914 MBytes   256 Mbits/sec receiver



--
Frederic Dumas
f.du...@ellis.siteparc.fr




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


RE: [FRnOG] [TECH] Mikrotik et Multicast

2019-12-12 Par sujet Thierry Chich



> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> David Ponzone
> Envoyé : jeudi 12 décembre 2019 09:48
> À : Hugues Voiturier 
> Cc : FRnOG 
> Objet : Re: [FRnOG] [TECH] Mikrotik et Multicast
> 
> Yep, le mettre à no sur le/les ports egress, ça aide, merci!
> 
> Je vais activer l’IGMP snooping aussi, ça va aider aussi.


J'y connais pas grand-chose, mais activer l'IGMP snooping , a priori, c'est 
vital ,sinon, le multicast c'est du broadcast.
> 
> > Le 11 déc. 2019 à 23:33, Hugues Voiturier  a
> écrit :
> >
> > Tu as essayé de décocher “Unknown Multicast Flood” dans ton interface
> dans l’onglet Bridge / Port ?
> > Ça coupe tout le multicast chez moi…
> > Hugues
> > AS57199 - AS50628
> >
> >> On 11 Dec 2019, at 23:09, David Ponzone  > wrote:
> >>
> >> Le challenge de la nuit: filtrer un flux multicast qui entre sur le port
> ethernet (membre d’un bridge) d’un ROUTEUR Mikrotik.
> >>
> >> Moi je dis: impossible.
> >> J’ai essayé au niveau du firewall ip (mais c’est normal que ça marche pas,
> j’avais pas activé use-ip-firewall) et au niveau du bridge filter:
> >>
> >> /interface bridge filter
> >> add action=drop chain=input in-interface=ether8 packet-type=multicast
> >>
> >> Ca donne:
> >>
> >> /interface bridge filter print stats
> >> Flags: X - disabled, I - invalid, D - dynamic
> >> #   CHAINACTION BYTES 
> >> PACKETS
> >> 0   inputdrop  8155389475 
> >> 7791558
> >>
> >> Ca semble dropper mais le flux est toujours là en out sur l’autre port du
> bridgeU
> >>
> >> J’ai essayé:
> >>
> >> /interface bridge filter
> >> add action=drop chain=input in-bridge=bridge packet-type=multicast
> >>
> >> Pas mieux.
> >>
> >> Globalement, Google semble confirmer que c’est pas possible, mais je
> trouve ça incroyable.
> >>
> >> Quand j’aurais réussi à bloquer, je chercherai d’où ce vient ce flux alors
> qu’il va vers un switch qui le réplique vers des téléphones Yealink, donc à
> priori pas des clients Multicast….
> >>
> >> Note du troll: il y a de plus en plus de « prestataires » qui font mumuse
> avec des trucs multicast sans rien y comprendre et c’est inquiétant. Moi j’y
> comprends rien, et j’essaie pas de jouer avec.
> >>
> >>
> >>
> >> ---
> >> 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] Mikrotik et Multicast

2019-12-12 Par sujet David Ponzone
Yep, le mettre à no sur le/les ports egress, ça aide, merci!

Je vais activer l’IGMP snooping aussi, ça va aider aussi.

> Le 11 déc. 2019 à 23:33, Hugues Voiturier  a écrit 
> :
> 
> Tu as essayé de décocher “Unknown Multicast Flood” dans ton interface dans 
> l’onglet Bridge / Port ?
> Ça coupe tout le multicast chez moi… 
> Hugues
> AS57199 - AS50628
> 
>> On 11 Dec 2019, at 23:09, David Ponzone > > wrote:
>> 
>> Le challenge de la nuit: filtrer un flux multicast qui entre sur le port 
>> ethernet (membre d’un bridge) d’un ROUTEUR Mikrotik.
>> 
>> Moi je dis: impossible.
>> J’ai essayé au niveau du firewall ip (mais c’est normal que ça marche pas, 
>> j’avais pas activé use-ip-firewall) et au niveau du bridge filter:
>> 
>> /interface bridge filter
>> add action=drop chain=input in-interface=ether8 packet-type=multicast
>> 
>> Ca donne:
>> 
>> /interface bridge filter print stats
>> Flags: X - disabled, I - invalid, D - dynamic
>> #   CHAINACTION BYTES 
>> PACKETS
>> 0   inputdrop  8155389475 
>> 7791558
>> 
>> Ca semble dropper mais le flux est toujours là en out sur l’autre port du 
>> bridgeU
>> 
>> J’ai essayé:
>> 
>> /interface bridge filter
>> add action=drop chain=input in-bridge=bridge packet-type=multicast
>> 
>> Pas mieux.
>> 
>> Globalement, Google semble confirmer que c’est pas possible, mais je trouve 
>> ça incroyable.
>> 
>> Quand j’aurais réussi à bloquer, je chercherai d’où ce vient ce flux alors 
>> qu’il va vers un switch qui le réplique vers des téléphones Yealink, donc à 
>> priori pas des clients Multicast….
>> 
>> Note du troll: il y a de plus en plus de « prestataires » qui font mumuse 
>> avec des trucs multicast sans rien y comprendre et c’est inquiétant. Moi j’y 
>> comprends rien, et j’essaie pas de jouer avec.
>> 
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/ 
> 


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


Re: [FRnOG] [TECH] Mikrotik et Multicast

2019-12-12 Par sujet David Ponzone
Ah bien essayé, mais c’est pas le cas.
L’IPBX est même pas sur site :)


> Le 12 déc. 2019 à 09:12, Oliver varenne  a écrit :
> 
>> Quand j’aurais réussi à bloquer, je chercherai d’où ce vient ce flux alors
>> qu’il va vers un switch qui le réplique vers des téléphones Yealink, donc à
>> priori pas des clients Multicast….
> 
> Les téléphones SIP modernes (Yealink, Fanvil, Htek, Grandstream) font 
> tous du multicast
> Le truc le plus courant est le SIP plug n play
> Les téléphone s'abonnent au 224.0.1.75
> Quand un IPBX est compatible avec ça, il utilise cela pour distribuer les 
> adresses d'auto provisionning.
> 
> Donc désactiver cette fonction dans les téléphone sera peut-être un premier 
> truc à faire.
> 
> 
> 
> 
> 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
>> David Ponzone
>> Envoyé : mercredi 11 décembre 2019 23:09
>> À : FRnOG 
>> Objet : [FRnOG] [TECH] Mikrotik et Multicast
>> 
>> Le challenge de la nuit: filtrer un flux multicast qui entre sur le port
>> ethernet (membre d’un bridge) d’un ROUTEUR Mikrotik.
>> 
>> Moi je dis: impossible.
>> J’ai essayé au niveau du firewall ip (mais c’est normal que ça marche
>> pas, j’avais pas activé use-ip-firewall) et au niveau du bridge filter:
>> 
>> /interface bridge filter
>> add action=drop chain=input in-interface=ether8 packet-type=multicast
>> 
>> Ca donne:
>> 
>> /interface bridge filter print stats
>> Flags: X - disabled, I - invalid, D - dynamic
>> #   CHAINACTION BYTES 
>> PACKETS
>> 0   inputdrop  8155389475 
>> 7791558
>> 
>> Ca semble dropper mais le flux est toujours là en out sur l’autre port du
>> bridge.
>> 
>> J’ai essayé:
>> 
>> /interface bridge filter
>> add action=drop chain=input in-bridge=bridge packet-type=multicast
>> 
>> Pas mieux.
>> 
>> Globalement, Google semble confirmer que c’est pas possible, mais je
>> trouve ça incroyable.
>> 
>> Quand j’aurais réussi à bloquer, je chercherai d’où ce vient ce flux alors
>> qu’il va vers un switch qui le réplique vers des téléphones Yealink, donc à
>> priori pas des clients Multicast….
>> 
>> Note du troll: il y a de plus en plus de « prestataires » qui font mumuse
>> avec des trucs multicast sans rien y comprendre et c’est inquiétant. Moi
>> j’y comprends rien, et j’essaie pas de jouer avec.
>> 
>> 
>> 
>> ---
>> 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] Mikrotik et Multicast

2019-12-12 Par sujet David Ponzone
Vu le profil du client, je le sens pas.
Ca doit être une caméra IP qui multicast ce qu’elle filme (ce qui me semble 
dénuer d’intérêt, sauf pour regarder en live le flux sur plusieurs TV).

D’ailleurs, j’ai trouvé d’autres victimes:

https://fr.coredump.biz/questions/49374642/cant-capture-multicast-packets-with-python
 


L’adresse MAC source est exactement la même chez moi: Taifatec_00:60:01

C’est legit ça ?

Bon j’ai trouvé, c’est une saloperie de HDMI-extender-over-IP:
https://blog.danman.eu/reverse-engineering-lenkeng-hdmi-over-ip-extender/ 


La boite taiwaianse qui fait le SoC (Taifatech) semble ne plus exister (en tout 
cas, plus de site web, les liens vers la doc marchent plus).


> Le 12 déc. 2019 à 08:08, Xavier Beaudouin  a écrit :
> 
> Hello David,
> 
> J'y connais rien mikrotik mais...
> 
>> Note du troll: il y a de plus en plus de « prestataires » qui font mumuse 
>> avec
>> des trucs multicast sans rien y comprendre et c’est inquiétant. Moi j’y
>> comprends rien, et j’essaie pas de jouer avec.
> 
> Je pense que ça viens du fait que VxLAN peux être transmit en multicast et vu 
> que 
> certains trucs sont en train de l'implem par défaut, ca joue dans tous les 
> sens.
> 
> Après quand on ne sais pas comment mcast joue on y touche pas (ou on demande 
> a 
> des personnes qui savent)...
> 
> Courage car bcp de device se font exploser le CPU avec du mcast (surtout le 
> Dense Mode...aka je bourrine et je flode)...
> 
> Xavier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


RE: [FRnOG] [TECH] Mikrotik et Multicast

2019-12-12 Par sujet Oliver varenne
> Quand j’aurais réussi à bloquer, je chercherai d’où ce vient ce flux alors
> qu’il va vers un switch qui le réplique vers des téléphones Yealink, donc à
> priori pas des clients Multicast….

Les téléphones SIP modernes (Yealink, Fanvil, Htek, Grandstream) font tous 
du multicast
Le truc le plus courant est le SIP plug n play
Les téléphone s'abonnent au 224.0.1.75
Quand un IPBX est compatible avec ça, il utilise cela pour distribuer les 
adresses d'auto provisionning.

Donc désactiver cette fonction dans les téléphone sera peut-être un premier 
truc à faire.




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
> David Ponzone
> Envoyé : mercredi 11 décembre 2019 23:09
> À : FRnOG 
> Objet : [FRnOG] [TECH] Mikrotik et Multicast
> 
> Le challenge de la nuit: filtrer un flux multicast qui entre sur le port
> ethernet (membre d’un bridge) d’un ROUTEUR Mikrotik.
> 
> Moi je dis: impossible.
> J’ai essayé au niveau du firewall ip (mais c’est normal que ça marche
> pas, j’avais pas activé use-ip-firewall) et au niveau du bridge filter:
> 
> /interface bridge filter
> add action=drop chain=input in-interface=ether8 packet-type=multicast
> 
> Ca donne:
> 
> /interface bridge filter print stats
> Flags: X - disabled, I - invalid, D - dynamic
>  #   CHAINACTION BYTES 
> PACKETS
>  0   inputdrop  8155389475 
> 7791558
> 
> Ca semble dropper mais le flux est toujours là en out sur l’autre port du
> bridge.
> 
> J’ai essayé:
> 
> /interface bridge filter
> add action=drop chain=input in-bridge=bridge packet-type=multicast
> 
> Pas mieux.
> 
> Globalement, Google semble confirmer que c’est pas possible, mais je
> trouve ça incroyable.
> 
> Quand j’aurais réussi à bloquer, je chercherai d’où ce vient ce flux alors
> qu’il va vers un switch qui le réplique vers des téléphones Yealink, donc à
> priori pas des clients Multicast….
> 
> Note du troll: il y a de plus en plus de « prestataires » qui font mumuse
> avec des trucs multicast sans rien y comprendre et c’est inquiétant. Moi
> j’y comprends rien, et j’essaie pas de jouer avec.
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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