Re: [FRnOG] [TECH] Single Pair Ethernet

2024-03-12 Par sujet Philippe Bourcier 
Re,

>> J'ai acheté pour la maison 1 adaptateur coaxial vers RJ45 sur Amazon 
>> (https://amzn.to/3TzI1Tf).
> 
> Tu ne vas pas aller très loin avec ça… ça sert exclusivement à pouvoir tester 
> la continuité de
> câbles coax avec un testeur équipé de prises RJ et pas magiquement 
> transformer 4 paires de cuivre
> en un coax…
> 
> ++ ic

Les fabricants de ROV (robots sous-marins) utilisent des ombiliques en coax et 
ils mettent du VDSL aux 2 bouts pour pouvoir remonter quelques flux de caméra 
et le command-control, le tout sur plus de 1.5km sans gros soucis... Par contre 
c'est pas donné (mais le ROV non plus).

Pour du particulier, le CPL ou les petits routeurs Wifi (client) to Ethernet 
font très bien l'affaire...


Cordialement,
--
Philippe Bourcier
https://twitter.com/irukanji_invest
https://www.linkedin.com/in/philippebourcier/


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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

2024-03-12 Par sujet Jérôme Berthier via frnog 

Le 12/03/2024 à 10:53, Lionel Giraudeau-Bocquet via frnog a écrit :
- trouver le moyen de récupérer le numéro du vlan en provenance de la 
MAC de la carte IPMI (et je suis certain que le switch a l'info 
quelque part, je ne sais juste pas comment lui faire cracher le morceau) 


Utiliser la fonction "Packet capture" intégrée au switch 3650 ?

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/37e/consolidated_guide/b_37e_consolidated_3650_cg/b_37e_consolidated_3650_cg_chapter_0110001.html

--
Jérôme Berthier


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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

2024-03-12 Par sujet David Ponzone 


> Le 12 mars 2024 à 15:26, Thierry Chich  a écrit 
> :
> 
> 
>> - peut-on faire une règle sur le port 11 qui dit que tout paquet qui arrive 
>> de cette MAC se voit attribuer le vlan 1
> Ben soit je comprends pas, soit c'est access vlan 1, mais c'est à coté du 
> sujet.
>> - tout paquet à destination de la MAC se voit attribuer le vlan XXX
> Ca peut se faire sur le switch grace aux systèmes mac-vlan , mais ça me 
> semble être un contresens. Ton problème, c'est qu'un paquet est émis depuis 
> ton ipmi avec un id de vlan 802.1Q, et tu ne peux rien y faire, par 
> définition. Ce qu'il faudrait, c'est un système qui détaggue automatiquement 
> ton paquet, mais ça, je ne vois pas comment le faire simplement.
>> 


Oui, détagger un VLAN inconnu, ça va être compliqué.
Par contre, tu peux faire un dot1q-tunnel pour mettre le paquet dans un outer 
VLAN X de ton choix, et donc le ressortir sur le port de ton choix (qui doit 
être en access untag X).
Je sais pas si ça peut aider mais on sait jamais.

David


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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

2024-03-12 Par sujet Thierry Chich 

Bonjour

Le 12/03/2024 à 10:53, Lionel Giraudeau-Bocquet via frnog a écrit :

Bonjour à tous,

Membre de FDN j'ai déjà posé cette question sur une liste sympa 
interne et il m'a été conseillé de venir poser ma question ici (merci 
tout de même !).


Voici le problème que je n'arrive pas à résoudre :
J'ai récupéré plusieurs lames (ayant une carte IPMI qui est intégrée à 
la carte mère) qui ont été installées dans un chassis avec d'autres 
que j'avais déjà.
Le panneau de contrôle du châssis me permet de faire des power on/off 
et récupérer les adresses MAC des cartes Ethernet et IPMI.
J'ai mis du temps à comprendre pourquoi les cartes IPMI ne demandaient 
pas d'adresse au serveur DHCP sur le réseau : ces cartes ont été 
configurées avec une adresse IP fixe dans un VLAN au pif (== que je ne 
connais pas)

Elles ne causent donc pas avec le vlan natif Cisco (vlan 1).

Je m'en suis sorti, à distance et avec de la chance, car les lames 
tentent de booter en PXE avant d'essayer leur disque. J'ai donc 
configurer le serveur PXE pour leur envoyer une image de dépannage sur 
laquelle elles ont booté et j'ai pu faire un "ipmitool lan set 1 vlan 
id off". Dans la seconde les cartes IPMI obtiennent leur adresse IP.


Belle histoire, mais ce n'est pas fini : l'une des lames ne parvient 
pas à démarrer (soit elle boot sur son disque interne automatiquement 
et se retrouve donc avec une adresse IP fixe que je ne connais pas, 
soit elle joue aux dames, soit elle est coincée au boot dans le Bios 
ou autre, soit la carte mère est tout simplement morte ).
Pour parvenir à savoir ce qu'il se passe je suis obligé de passer par 
la carte IPMI (pas de port pour brancher un écran et encore moins un 
clavier).


La lame est connectée (via le switch du chassis qui ne fait que 
transmettre les paquets sans toucher aux ID vlan) au port Gi1/0/11 
d'un Cisco, et le serveur DHCP sur le port Gi1/0/6.
Les ports Gi1/0/[1-20] et Gi1/1/[1-24] (c'est une stack de deux 
switchs) sont dans le vlan 1, les 4 derniers du premier switch 
(Gi1/0/[21-24]) sont dans le vlan 2. Les deux vlans ne communiquent 
pas, il y a juste une machine qui a une patte sur ce vlan 1 privé et 
l'autre sur un réseau auquel j'ai accès à distance.


Dans un monde idéal, je cherche à ce que, temporairement, carte IPMI 
et serveur DHCP se causent pour que la première ait une adresse IP et 
que du deuxième je parvienne à lancer un ipmitool (je connais user et 
mot de passe) pour virer ce vlan dont je ne connais pas le numéro.


Je vois ça "simplement" comme ça :
- trouver le moyen de récupérer le numéro du vlan en provenance de la 
MAC de la carte IPMI (et je suis certain que le switch a l'info 
quelque part, je ne sais juste pas comment lui faire cracher le morceau)


Comme cela a été dit, le plus simple, c'est d'écouter sur le port avec 
le bon vieux tcpdump -e. Soit directement - mais là tu ne peux pas 
visiblement, soit en utilisant du port monitorirng pour renvoyer tout ce 
qui est émis sur le port sur lequel le ipmi est branché vers un autre 
port (là où tu as un serveur pour écouter).


- peut-on faire une règle sur le port 11 qui dit que tout paquet qui 
arrive de cette MAC se voit attribuer le vlan 1
Ben soit je comprends pas, soit c'est access vlan 1, mais c'est à coté 
du sujet.

- tout paquet à destination de la MAC se voit attribuer le vlan XXX
Ca peut se faire sur le switch grace aux systèmes mac-vlan , mais ça me 
semble être un contresens. Ton problème, c'est qu'un paquet est émis 
depuis ton ipmi avec un id de vlan 802.1Q, et tu ne peux rien y faire, 
par définition. Ce qu'il faudrait, c'est un système qui détaggue 
automatiquement ton paquet, mais ça, je ne vois pas comment le faire 
simplement.



p://www.frnog.org/

--

Thierry





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

Re: [FRnOG] [TECH] Single Pair Ethernet

2024-03-12 Par sujet ic 
io,

> On 12 Mar 2024, at 10:47, Vincent Duvernet  wrote:
> 
> J'ai acheté pour la maison 1 adaptateur coaxial vers RJ45 sur Amazon 
> (https://amzn.to/3TzI1Tf).

Tu ne vas pas aller très loin avec ça… ça sert exclusivement à pouvoir tester 
la continuité de câbles coax avec un testeur équipé de prises RJ et pas 
magiquement transformer 4 paires de cuivre en un coax…

++ ic


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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

2024-03-12 Par sujet David Ponzone 
Ok mais elles ont pas la même MAC les lames donc tu peux séparer dans Wireshark.
Après, si tu as pas les MAC des lames, ça devient compliqué :)
Et à distance en plus!

David

> Le 12 mars 2024 à 11:30, Lionel Giraudeau-Bocquet  a 
> écrit :
> 
>> J’ai raté un truc peut-être, j’ai lu en diagonale, mais pourquoi tu mets pas 
>> un Wireshark à la sortie de la carte pour voir ce qu’elle raconte (IP, vlan, 
>> etc…) ?
> 
> Le 12/03/2024 à 11:24, David Ponzone a écrit :
> C'est une lame dans un chassis. Il n'y a qu'un seul port Ethernet sur ce 
> dernier et les autres lames sont utilisées.
> Mais oui, si j'avais facilement accès au matériel (parce qu'en plus tout ça 
> se passe loin de chez moi) ça serait envisageable.
> Maintenant ça me donne une idée, car dans le chassis il y a un switch 
> Broadcom qu'on peut interroger. Peut-être que lui a plus d'infos sur ce 
> fameux Vlan ... Je vais creuser.


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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

2024-03-12 Par sujet Lionel Giraudeau-Bocquet via frnog 

J’ai raté un truc peut-être, j’ai lu en diagonale, mais pourquoi tu mets pas un 
Wireshark à la sortie de la carte pour voir ce qu’elle raconte (IP, vlan, etc…) 
?



Le 12/03/2024 à 11:24, David Ponzone a écrit :
C'est une lame dans un chassis. Il n'y a qu'un seul port Ethernet sur ce 
dernier et les autres lames sont utilisées.
Mais oui, si j'avais facilement accès au matériel (parce qu'en plus tout 
ça se passe loin de chez moi) ça serait envisageable.
Maintenant ça me donne une idée, car dans le chassis il y a un switch 
Broadcom qu'on peut interroger. Peut-être que lui a plus d'infos sur ce 
fameux Vlan ... Je vais creuser.



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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

2024-03-12 Par sujet Lionel Giraudeau-Bocquet via frnog 

Le 12/03/2024 à 10:53, Lionel Giraudeau-Bocquet via frnog a écrit :

Bonjour à tous,

...
Dans un monde idéal, je cherche à ce que, temporairement, carte IPMI 
et serveur DHCP se causent pour que la première ait une adresse IP et 
que du deuxième je parvienne à lancer un ipmitool (je connais user et 
mot de passe) pour virer ce vlan dont je ne connais pas le numéro.


Je vois ça "simplement" comme ça :
- trouver le moyen de récupérer le numéro du vlan en provenance de la 
MAC de la carte IPMI (et je suis certain que le switch a l'info 
quelque part, je ne sais juste pas comment lui faire cracher le morceau)


Sur le port Gi1/0/11 tu met un vlan isolé que tu propage jusqu'à ta 
machine qui a 2 pattes, tu fais un tcpdump sur ce vlan avec -e pour 
qu'il te montre le vlan utilisé par la lame lorsqu'elle fera ces 
requêtes DHCP.
-e c'est pour montrer le détail du layer 2 et notamment les vlan 
utilisés (même si le 1er vlan est encapsulé dans un 2ème (q-in-q)).



- peut-on faire une règle sur le port 11 qui dit que tout paquet qui 
arrive de cette MAC se voit attribuer le vlan 1

- tout paquet à destination de la MAC se voit attribuer le vlan XXX


Je ne connais pas de matériel qui sait faire ça.


Jérôme



Le 12/03/2024 à 11:20, Jérôme Marteaux a écrit :

Ca rejoint ce qu'écrivait Dominique "Domi" Rousseau sur Bistro@FDN.
J'ai moyen d'avoir une autre machine que je pourrais passer sur ce 
fameux VLAN mystère, donc je vais faire ça (en espérant qu'à la fin tout 
ce bruit ait servi à quelque chose).


Merci beaucoup,
Lionel


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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

2024-03-12 Par sujet David Ponzone 
J’ai raté un truc peut-être, j’ai lu en diagonale, mais pourquoi tu mets pas un 
Wireshark à la sortie de la carte pour voir ce qu’elle raconte (IP, vlan, etc…) 
?

> Le 12 mars 2024 à 10:53, Lionel Giraudeau-Bocquet via frnog  
> a écrit :
> 
> Bonjour à tous,
> 
> Membre de FDN j'ai déjà posé cette question sur une liste sympa interne et il 
> m'a été conseillé de venir poser ma question ici (merci tout de même !).
> 
> Voici le problème que je n'arrive pas à résoudre :
> J'ai récupéré plusieurs lames (ayant une carte IPMI qui est intégrée à la 
> carte mère) qui ont été installées dans un chassis avec d'autres que j'avais 
> déjà.
> Le panneau de contrôle du châssis me permet de faire des power on/off et 
> récupérer les adresses MAC des cartes Ethernet et IPMI.
> J'ai mis du temps à comprendre pourquoi les cartes IPMI ne demandaient pas 
> d'adresse au serveur DHCP sur le réseau : ces cartes ont été configurées avec 
> une adresse IP fixe dans un VLAN au pif (== que je ne connais pas)
> Elles ne causent donc pas avec le vlan natif Cisco (vlan 1).
> 
> Je m'en suis sorti, à distance et avec de la chance, car les lames tentent de 
> booter en PXE avant d'essayer leur disque. J'ai donc configurer le serveur 
> PXE pour leur envoyer une image de dépannage sur laquelle elles ont booté et 
> j'ai pu faire un "ipmitool lan set 1 vlan id off". Dans la seconde les cartes 
> IPMI obtiennent leur adresse IP.
> 
> Belle histoire, mais ce n'est pas fini : l'une des lames ne parvient pas à 
> démarrer (soit elle boot sur son disque interne automatiquement et se 
> retrouve donc avec une adresse IP fixe que je ne connais pas, soit elle joue 
> aux dames, soit elle est coincée au boot dans le Bios ou autre, soit la carte 
> mère est tout simplement morte ).
> Pour parvenir à savoir ce qu'il se passe je suis obligé de passer par la 
> carte IPMI (pas de port pour brancher un écran et encore moins un clavier).
> 
> La lame est connectée (via le switch du chassis qui ne fait que transmettre 
> les paquets sans toucher aux ID vlan) au port Gi1/0/11 d'un Cisco, et le 
> serveur DHCP sur le port Gi1/0/6.
> Les ports Gi1/0/[1-20] et Gi1/1/[1-24] (c'est une stack de deux switchs) sont 
> dans le vlan 1, les 4 derniers du premier switch (Gi1/0/[21-24]) sont dans le 
> vlan 2. Les deux vlans ne communiquent pas, il y a juste une machine qui a 
> une patte sur ce vlan 1 privé et l'autre sur un réseau auquel j'ai accès à 
> distance.
> 
> Dans un monde idéal, je cherche à ce que, temporairement, carte IPMI et 
> serveur DHCP se causent pour que la première ait une adresse IP et que du 
> deuxième je parvienne à lancer un ipmitool (je connais user et mot de passe) 
> pour virer ce vlan dont je ne connais pas le numéro.
> 
> Je vois ça "simplement" comme ça :
> - trouver le moyen de récupérer le numéro du vlan en provenance de la MAC de 
> la carte IPMI (et je suis certain que le switch a l'info quelque part, je ne 
> sais juste pas comment lui faire cracher le morceau)
> - peut-on faire une règle sur le port 11 qui dit que tout paquet qui arrive 
> de cette MAC se voit attribuer le vlan 1
> - tout paquet à destination de la MAC se voit attribuer le vlan XXX
> 
> => une fois les échanges DHCP faits, je peux passer la commande ipmitool qui 
> va bien
> 
> - on remet la config du Cisco dans son état initiale
> 
> 
> Mais comment faire tout ça ?
> Si quelqu'un a des idées je suis tout ouï !
> (voir même toutes les commandes à passer, parce qu'à part des shut/no shut 
> sur des interfaces, je ne connais pas grand chose d'autre ...)
> 
> Un peu d'info de version, au cas où :
> 2 * cisco WS-C3650-24TD
> Même version :
> Cisco IOS Software, IOS-XE Software, Catalyst L3 Switch Software 
> (CAT3K_CAA-UNIVERSALK9-M), Version 03.07.03E RELEASE SOFTWARE (fc3)
> 
> Merci d'avance à vous,
> Lionel
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

2024-03-12 Par sujet Jérôme Marteaux 

Le 12/03/2024 à 10:53, Lionel Giraudeau-Bocquet via frnog a écrit :

Bonjour à tous,

Membre de FDN j'ai déjà posé cette question sur une liste sympa interne 
et il m'a été conseillé de venir poser ma question ici (merci tout de 
même !).


Voici le problème que je n'arrive pas à résoudre :
J'ai récupéré plusieurs lames (ayant une carte IPMI qui est intégrée à 
la carte mère) qui ont été installées dans un chassis avec d'autres que 
j'avais déjà.
Le panneau de contrôle du châssis me permet de faire des power on/off et 
récupérer les adresses MAC des cartes Ethernet et IPMI.
J'ai mis du temps à comprendre pourquoi les cartes IPMI ne demandaient 
pas d'adresse au serveur DHCP sur le réseau : ces cartes ont été 
configurées avec une adresse IP fixe dans un VLAN au pif (== que je ne 
connais pas)

Elles ne causent donc pas avec le vlan natif Cisco (vlan 1).

Je m'en suis sorti, à distance et avec de la chance, car les lames 
tentent de booter en PXE avant d'essayer leur disque. J'ai donc 
configurer le serveur PXE pour leur envoyer une image de dépannage sur 
laquelle elles ont booté et j'ai pu faire un "ipmitool lan set 1 vlan id 
off". Dans la seconde les cartes IPMI obtiennent leur adresse IP.


Belle histoire, mais ce n'est pas fini : l'une des lames ne parvient pas 
à démarrer (soit elle boot sur son disque interne automatiquement et se 
retrouve donc avec une adresse IP fixe que je ne connais pas, soit elle 
joue aux dames, soit elle est coincée au boot dans le Bios ou autre, 
soit la carte mère est tout simplement morte ).
Pour parvenir à savoir ce qu'il se passe je suis obligé de passer par la 
carte IPMI (pas de port pour brancher un écran et encore moins un clavier).


La lame est connectée (via le switch du chassis qui ne fait que 
transmettre les paquets sans toucher aux ID vlan) au port Gi1/0/11 d'un 
Cisco, et le serveur DHCP sur le port Gi1/0/6.
Les ports Gi1/0/[1-20] et Gi1/1/[1-24] (c'est une stack de deux switchs) 
sont dans le vlan 1, les 4 derniers du premier switch (Gi1/0/[21-24]) 
sont dans le vlan 2. Les deux vlans ne communiquent pas, il y a juste 
une machine qui a une patte sur ce vlan 1 privé et l'autre sur un réseau 
auquel j'ai accès à distance.


Dans un monde idéal, je cherche à ce que, temporairement, carte IPMI et 
serveur DHCP se causent pour que la première ait une adresse IP et que 
du deuxième je parvienne à lancer un ipmitool (je connais user et mot de 
passe) pour virer ce vlan dont je ne connais pas le numéro.


Je vois ça "simplement" comme ça :
- trouver le moyen de récupérer le numéro du vlan en provenance de la 
MAC de la carte IPMI (et je suis certain que le switch a l'info quelque 
part, je ne sais juste pas comment lui faire cracher le morceau)


Sur le port Gi1/0/11 tu met un vlan isolé que tu propage jusqu'à ta 
machine qui a 2 pattes, tu fais un tcpdump sur ce vlan avec -e pour 
qu'il te montre le vlan utilisé par la lame lorsqu'elle fera ces 
requêtes DHCP.
-e c'est pour montrer le détail du layer 2 et notamment les vlan 
utilisés (même si le 1er vlan est encapsulé dans un 2ème (q-in-q)).



- peut-on faire une règle sur le port 11 qui dit que tout paquet qui 
arrive de cette MAC se voit attribuer le vlan 1

- tout paquet à destination de la MAC se voit attribuer le vlan XXX


Je ne connais pas de matériel qui sait faire ça.


Jérôme

--
Jérôme Marteaux


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

[FRnOG] [TECH] Configuration VPN sur Cisco

2024-03-12 Par sujet Lionel Giraudeau-Bocquet via frnog 

Bonjour à tous,

Membre de FDN j'ai déjà posé cette question sur une liste sympa interne 
et il m'a été conseillé de venir poser ma question ici (merci tout de 
même !).


Voici le problème que je n'arrive pas à résoudre :
J'ai récupéré plusieurs lames (ayant une carte IPMI qui est intégrée à 
la carte mère) qui ont été installées dans un chassis avec d'autres que 
j'avais déjà.
Le panneau de contrôle du châssis me permet de faire des power on/off et 
récupérer les adresses MAC des cartes Ethernet et IPMI.
J'ai mis du temps à comprendre pourquoi les cartes IPMI ne demandaient 
pas d'adresse au serveur DHCP sur le réseau : ces cartes ont été 
configurées avec une adresse IP fixe dans un VLAN au pif (== que je ne 
connais pas)

Elles ne causent donc pas avec le vlan natif Cisco (vlan 1).

Je m'en suis sorti, à distance et avec de la chance, car les lames 
tentent de booter en PXE avant d'essayer leur disque. J'ai donc 
configurer le serveur PXE pour leur envoyer une image de dépannage sur 
laquelle elles ont booté et j'ai pu faire un "ipmitool lan set 1 vlan id 
off". Dans la seconde les cartes IPMI obtiennent leur adresse IP.


Belle histoire, mais ce n'est pas fini : l'une des lames ne parvient pas 
à démarrer (soit elle boot sur son disque interne automatiquement et se 
retrouve donc avec une adresse IP fixe que je ne connais pas, soit elle 
joue aux dames, soit elle est coincée au boot dans le Bios ou autre, 
soit la carte mère est tout simplement morte ).
Pour parvenir à savoir ce qu'il se passe je suis obligé de passer par la 
carte IPMI (pas de port pour brancher un écran et encore moins un clavier).


La lame est connectée (via le switch du chassis qui ne fait que 
transmettre les paquets sans toucher aux ID vlan) au port Gi1/0/11 d'un 
Cisco, et le serveur DHCP sur le port Gi1/0/6.
Les ports Gi1/0/[1-20] et Gi1/1/[1-24] (c'est une stack de deux switchs) 
sont dans le vlan 1, les 4 derniers du premier switch (Gi1/0/[21-24]) 
sont dans le vlan 2. Les deux vlans ne communiquent pas, il y a juste 
une machine qui a une patte sur ce vlan 1 privé et l'autre sur un réseau 
auquel j'ai accès à distance.


Dans un monde idéal, je cherche à ce que, temporairement, carte IPMI et 
serveur DHCP se causent pour que la première ait une adresse IP et que 
du deuxième je parvienne à lancer un ipmitool (je connais user et mot de 
passe) pour virer ce vlan dont je ne connais pas le numéro.


Je vois ça "simplement" comme ça :
- trouver le moyen de récupérer le numéro du vlan en provenance de la 
MAC de la carte IPMI (et je suis certain que le switch a l'info quelque 
part, je ne sais juste pas comment lui faire cracher le morceau)
- peut-on faire une règle sur le port 11 qui dit que tout paquet qui 
arrive de cette MAC se voit attribuer le vlan 1

- tout paquet à destination de la MAC se voit attribuer le vlan XXX

=> une fois les échanges DHCP faits, je peux passer la commande ipmitool 
qui va bien


- on remet la config du Cisco dans son état initiale


Mais comment faire tout ça ?
Si quelqu'un a des idées je suis tout ouï !
(voir même toutes les commandes à passer, parce qu'à part des shut/no 
shut sur des interfaces, je ne connais pas grand chose d'autre ...)


Un peu d'info de version, au cas où :
2 * cisco WS-C3650-24TD
Même version :
Cisco IOS Software, IOS-XE Software, Catalyst L3 Switch Software 
(CAT3K_CAA-UNIVERSALK9-M), Version 03.07.03E RELEASE SOFTWARE (fc3)


Merci d'avance à vous,
Lionel


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

RE: [FRnOG] [TECH] Single Pair Ethernet

2024-03-12 Par sujet Vincent Duvernet 
Yop,

Ah, c'est un sujet qui m'intéresse.
J'ai acheté pour la maison 1 adaptateur coaxial vers RJ45 sur Amazon 
(https://amzn.to/3TzI1Tf).
L'objectif étant de récupérer l'usage coaxial devenu obsolète par l'IPTV afin 
de pouvoir relier 2 parties de la maison où il n'y a qu'un seul câble ethernet.
J'aurais pu séparer mon câble en 2x4 fils mais je limite mon débit à 100 Mbps 
ce qui est moins que ma fibre.
Pourquoi récupérer alors une 2ème ligne même à 10 Mbps ? pour le téléphone de 
la box Orange. Les murs sont épais, c'est compliqué de garder le signal. Donc 
comme ça, Tel1 sur la box pour le 1er tel et Tel2, bah pour le Tel2.
(Alors oui Orange dit que c'est pas conforme de faire comme cela avec 1 seule 
ligne mais ça fonctionne depuis des années).

L'autre méthode consiste à utiliser un boitier actif comme celui-ci 
(https://amzn.to/496RTZf) en prenant bien soin d'acheter à côté les transfo 
secteurs pour la France qui ne sont pas compris.
J'en ai acheté mais pas encore installé. Ça veut dire ajouter un boitier qui 
fait de la lumière, qui consomme de l'élec' mais aussi qu'il faut placer dans 
les coffrets VDI résidentiels qui ne sont pas tellement adaptés à ce genre 
d'appareils (déjà que mettre un switch manageable Gigabit...).

Quid du 10 Mbps, j'ai l'impression aussi que certains matériels réseaux actifs 
n'acceptent plus d'être raccordé à du matos en 10 Mbps, ils veulent 100 minimum.

Vincent

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Dominique 
Rousseau
Envoyé : lundi 11 mars 2024 09:33
À : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Single Pair Ethernet

Le Fri, Mar 08, 2024 at 07:36:38PM +0100, Fabien Sirjean 
[fsirj...@eddie.fdn.fr] a écrit:
> Bonjour la liste,
> 
> J'ai récemment entendu parler pour la première fois de Single Pair 
> Ethernet (10BASE-T1S / 10BASE-T1L), dont les specs ont l'air 
> prometteuses (notamment en environnement industriel) :
> 
>  - 10 Mbps sur une seule paire de cuivre, avec des standards en cours 
> de travail pour monter à 10G voire plus ?
>  - Distance jusqu'à 1 km
>  - PoE (ou plutôt PoDL) jusqu'à 50W
> 
> Alors, poudre verte ou bien véritable intérêt ? Des retours 
> d'expérience en la matière ?

Sans les 50W, c'est ce que le réseau téléphonique fait depuis longtemps, non ? 
pour l'alimentation des combinés, et le débit de 10Mbps en *DSL.
Donc pourquoi pas une normalisation IEEE d'un truc plus "ethernet".

Les standards pour aller plus loin auront surement des contraintes conséquentes 
sur le cablage, et ils feraient sans doute mieux de réfléchir à des connecteurs 
combinant de l'optique et du cuivre pour l'alimentation...


--
Dominique Rousseau
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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


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