RE: [FRnOG] [TECH] Soft notification de maintenance par mail

[Sébastien 65]

Hello David 

Staytus est pas mal utilisé, je l'ai déjà "parcouru".

Quand tu as des maintenances ou tu dois changer des équipements de cœur ou de 
collecte l'impact n'est pas négligeable !
Tu as toujours des utilisateurs qui veulent tout savoir, même pour du FTTH à 
pas cher...

C'est pour cela que je souhaite pouvoir créer des catégories/groupes pour 
pouvoir faire du sélectif en fonction de la maintenance.
En y réfléchissant il peut aussi y avoir un second intérêt pour de la 
notification en cas d'incident sur une techno précise.

Sébastien



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

[FRnOG] [TECH] Soft notification de maintenance par mail

[Sébastien 65]

Bonjour à tous,

Je recherche des retours d'expérience et conseil sur l'utilisation d'une appli 
Web (Open-Source de préférence) permettant de faire la notification mail lors 
de maintenance.
Je suis également à l'écoute si un module de notification par SMS existe, mais 
cela n'est pas la priorité !

Le besoin est de pouvoir faire des notifications auprès des usagers par type 
d'intervention. Par exemple je voudrais pouvoir faire une rubrique 
FTTH,FTTB,xDSL, etc.. sur laquelle je peux ensuite ajouter un groupe 
d'utilisateur à notifier.

Par exemple dans le cas d'une maintenance sur du FTTH, je souhaite pouvoir 
envoyer un mail à tous les clients rattachés à ce groupe.

Quesqu'il existe de simple et efficasse pour gérer ce type de sujet ?

Merci !

Sébastien

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

RE: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[Sébastien 65]

Hello Paul, David,

@David
>Je te demande si le 7200 est donné par le serveur.

Oui, cela provient du serveur DHCP du côté de l'opérateur de collecte (FTTH 
AXIONE) sur lequel je n'ai absolument pas la main.
Baisser le timer à une époque lointaine avait présenté quelque problème...

@Paul
tu peux ecrire la meme chose differemment : faire ton ip nat inside sur tout 
sauf ca ?

Je n'ai pas essayé car je pars du principe qu'avec les 2 règles ci-dessous, 
cela doit neutraliser le forward pour qu'il reste sur son interface et pas vers 
le firewall...
ip nat inside source static udp X.X.X.X 67 interface GigabitEthernet8 67
ip nat inside source static udp X.X.X.X 68 interface GigabitEthernet8 68

Par exemple si j'utilise ip nat inside source static tcp X.X.X.X 22 interface 
GigabitEthernet8 22 le flux reste bien sur l'interface WAN et ne va pas vers le 
firewall ! Pourquoi toutes les règles ne sont pas traitées de la même façon, 
c'est ce qui m'interpelle 

Sébastien

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

RE: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[Sébastien 65]

7200s => DHCP Addresses leased from a server (show dhcp lease)

Je n'ai pas essayé 1800s, mais une valeur plus haute que 7200s sans succès.

Sur Google j'ai trouvé des problématiques identiques par exemple ici 
https://community.cisco.com/t5/routing/interface-being-restarted-by-dhcp-1841/td-p/2359494
 ou par ici 
https://blog.ipspace.net/2009/09/expired-dhcp-lease-bounces-interface.html il y 
a une référence comme mon cas d'utilisation dans un commentaire plus bas.

>Le cisco avec ce ip nat inside, il arrive à pinger l’extérieur ?
Non, le ping ne peut pas passer car le retour est forcé vers le firewall via ip 
nat inside.
Le Cisco envoi bien le ping mais cela rentrera vers le firewall qui lui ne sait 
pas et va droper car il n'est pas l'initiateur/source du ping.

Pour que le ping fonctionne il faut faire une ACL avec une IP autre en Loopback 
ou avoir un subnet d'interco/mgmt. C'est une autre histoire.

De : David Ponzone 
Envoyé : mercredi 31 mai 2023 17:44
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

7200, c’est quoi ? Le lease-time par défaut du serveur DHCP ?
Si tu forces à 1800 de ton côté, ça aide pas ?

Jamais entendu parler d’un automatisme de ce genre chez Cisco à cause d’un ip 
nat inside, mais je fais jamais ça.
Je renvoie que les ports 1024-6535, 443 et 500.

Le cisco avec ce ip nat inside, il arrive à pinger l’extérieur ?

Le 31 mai 2023 à 17:23, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

David,

Pas si évident que ça  Comme j'ai dit dans le mail précédent le problème n'est 
présent qu'avec l'utilisation du 'ip nat inside' pour pousser le flux du WAN 
vers un autre équipement (équipement local type firewall connecté derrière le 
CISCO).

De base la configuration du DHCP lease est de 7200s, dès que la commande 'ip 
nat inside ...' est présente dans le routeur bin toutes les 2H j'ai droit à :

May 30 23:29:34.302: %DHCP-5-RESTART: Interface GigabitEthernet8 is being 
restarted by DHCP

May 30 23:29:36.302: %LINK-5-CHANGED: Interface GigabitEthernet8, changed state 
to administratively down
May 30 23:29:37.302: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet8, changed state to down
May 30 23:29:39.330: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed state 
to down
May 30 23:29:42.938: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed state 
to up
May 30 23:29:43.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet8, changed state to up
May 30 23:29:46.522: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet8 
assigned DHCP address X.X.X.X, mask 255.255.255.0, hostname 892FSP-X

Sur le même principe de l'interface WAN en mode DHCP, j'ai des routeurs sur 
lesquels le 'ip nat inside' n'est pas utilisé, magie ou pas aucun problème sur 
le DOWN/UP du port WAN.
J'ai un routeur qui a reboot il y a 2 jours, le show log indique la récup de 
l'adresse DHCP le 29/05 et depuis rien de plus dans les logs... Pourtant même 
serveur DHCP en face.


Sébastien


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 31 mai 2023 16:14
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

Seb,

Hmm dans mon monde à moi, le DHCP renew est à l’initiative du client, sauf si 
le serveur implémente FORCERENEW, et que le Cisco l’honore.
Donc tu devrais pas avoir de problème si tu forces un lease plus court sur le 
Cisco avec « ip dhcp client lease 0 0 5 » ou un truc du genre.

> Le 31 mai 2023 à 15:52, Sébastien 65 
> mailto:sebastien...@live.fr>> a écrit :
>
> Bonjour à tous,
>
> Sur des routeurs CISCO (88X/89X/etc...) ayant le port WAN en mode DHCP et 
> utilisant la règle 'ip nat inside source static ip-lan-du-firewall 
> ip-wan-loopback extendable' lors de la fin du lease DHCP l'IOS fait tomber le 
> port WAN (Down/Up)...
>
> La commande 'ip nat inside source X X extendable' remplie bien la fonction 
> car tout ce qui arrive sur le port WAN est automatiquement renvoyé sur l'IP 
> indiquée. Aucun problème à ce niveau.
>
> Le problème est que dès que la renégo du DHCP arrive, la requête est 
> transférée sur l'équipement ip-lan-firewall et pas sur l'interface WAN du 
> CISCO. La conséquence est que l'IOS fait tomber le port UP/DOWN pour pouvoir 
> récupérer "enfin" une IP sur son interface WAN.
>
> J'ai essayé de forcer les requêtes provenant du serveur DHCP à rester sur 
> l'interface WAN (ici GE8) mais sans succès :
> ip nat inside source static udp X.X.X.X 67 interface GigabitEthernet8 67
> ip nat inside source static udp X.X.X.X 68 interface GigabitEthernet8 68
>
> Le phénomène est que toutes les 2H le port WAN GE8 fait DOWN/UP. La 
> modification du lease n'est 

RE: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[Sébastien 65]

David,

Pas si évident que ça  Comme j'ai dit dans le mail précédent le problème n'est 
présent qu'avec l'utilisation du 'ip nat inside' pour pousser le flux du WAN 
vers un autre équipement (équipement local type firewall connecté derrière le 
CISCO).

De base la configuration du DHCP lease est de 7200s, dès que la commande 'ip 
nat inside ...' est présente dans le routeur bin toutes les 2H j'ai droit à :

May 30 23:29:34.302: %DHCP-5-RESTART: Interface GigabitEthernet8 is being 
restarted by DHCP

May 30 23:29:36.302: %LINK-5-CHANGED: Interface GigabitEthernet8, changed state 
to administratively down
May 30 23:29:37.302: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet8, changed state to down
May 30 23:29:39.330: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed state 
to down
May 30 23:29:42.938: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed state 
to up
May 30 23:29:43.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet8, changed state to up
May 30 23:29:46.522: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet8 
assigned DHCP address X.X.X.X, mask 255.255.255.0, hostname 892FSP-X

Sur le même principe de l'interface WAN en mode DHCP, j'ai des routeurs sur 
lesquels le 'ip nat inside' n'est pas utilisé, magie ou pas aucun problème sur 
le DOWN/UP du port WAN.
J'ai un routeur qui a reboot il y a 2 jours, le show log indique la récup de 
l'adresse DHCP le 29/05 et depuis rien de plus dans les logs... Pourtant même 
serveur DHCP en face.


Sébastien


De : David Ponzone 
Envoyé : mercredi 31 mai 2023 16:14
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

Seb,

Hmm dans mon monde à moi, le DHCP renew est à l’initiative du client, sauf si 
le serveur implémente FORCERENEW, et que le Cisco l’honore.
Donc tu devrais pas avoir de problème si tu forces un lease plus court sur le 
Cisco avec « ip dhcp client lease 0 0 5 » ou un truc du genre.

> Le 31 mai 2023 à 15:52, Sébastien 65  a écrit :
>
> Bonjour à tous,
>
> Sur des routeurs CISCO (88X/89X/etc...) ayant le port WAN en mode DHCP et 
> utilisant la règle 'ip nat inside source static ip-lan-du-firewall 
> ip-wan-loopback extendable' lors de la fin du lease DHCP l'IOS fait tomber le 
> port WAN (Down/Up)...
>
> La commande 'ip nat inside source X X extendable' remplie bien la fonction 
> car tout ce qui arrive sur le port WAN est automatiquement renvoyé sur l'IP 
> indiquée. Aucun problème à ce niveau.
>
> Le problème est que dès que la renégo du DHCP arrive, la requête est 
> transférée sur l'équipement ip-lan-firewall et pas sur l'interface WAN du 
> CISCO. La conséquence est que l'IOS fait tomber le port UP/DOWN pour pouvoir 
> récupérer "enfin" une IP sur son interface WAN.
>
> J'ai essayé de forcer les requêtes provenant du serveur DHCP à rester sur 
> l'interface WAN (ici GE8) mais sans succès :
> ip nat inside source static udp X.X.X.X 67 interface GigabitEthernet8 67
> ip nat inside source static udp X.X.X.X 68 interface GigabitEthernet8 68
>
> Le phénomène est que toutes les 2H le port WAN GE8 fait DOWN/UP. La 
> modification du lease n'est pas la solution car cela reporte uniquement le 
> problème sans le résoudre...
>
> Est-ce que quelqu'un connait le phénomène et la solution ?
>
> Merci 
>
> Sébastien
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[Sébastien 65]

Bonjour à tous,

Sur des routeurs CISCO (88X/89X/etc...) ayant le port WAN en mode DHCP et 
utilisant la règle 'ip nat inside source static ip-lan-du-firewall 
ip-wan-loopback extendable' lors de la fin du lease DHCP l'IOS fait tomber le 
port WAN (Down/Up)...

La commande 'ip nat inside source X X extendable' remplie bien la fonction car 
tout ce qui arrive sur le port WAN est automatiquement renvoyé sur l'IP 
indiquée. Aucun problème à ce niveau.

Le problème est que dès que la renégo du DHCP arrive, la requête est transférée 
sur l'équipement ip-lan-firewall et pas sur l'interface WAN du CISCO. La 
conséquence est que l'IOS fait tomber le port UP/DOWN pour pouvoir récupérer 
"enfin" une IP sur son interface WAN.

J'ai essayé de forcer les requêtes provenant du serveur DHCP à rester sur 
l'interface WAN (ici GE8) mais sans succès :
ip nat inside source static udp X.X.X.X 67 interface GigabitEthernet8 67
ip nat inside source static udp X.X.X.X 68 interface GigabitEthernet8 68

Le phénomène est que toutes les 2H le port WAN GE8 fait DOWN/UP. La 
modification du lease n'est pas la solution car cela reporte uniquement le 
problème sans le résoudre...

Est-ce que quelqu'un connait le phénomène et la solution ?

Merci 

Sébastien




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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Bonsoir,

Nous avons enfin réussi à faire fonctionner le MTU  SFR a réalisé quelques 
updates de conf et PE durant ces derniers jours/semaines sur la DSP.

Maintenant je monte bien à 1492 sur le CPE client 

ping 1.1.1.1 size 1492 df-bit fonctionne ENFIN (contre 1462 avant) ! Ou autre 
chose bien entendu...

Il faut bien utiliser un MTU de 2000 sur l'interface de collecte et sur les 2 
VLANs de livraison 1998 et 1999. En gros les STAS de SFR génériques sont 
correctes pour les DSP.

Merci à tous ceux qui ont participé au débug.

@+




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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Merci David pour l'info ! Je vais essayer aussi pour voir.

Je ne connais pas cette commande je vais me rencarder sur la doc CISCO.

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Salut Christophe,

Non, problème toujours présent ! En cours d'analyse côté SFR...

De mon côté je suis avec un MTU 9000 de bout en bout, pour faire simple conf de 
dernière "chance"...

Sébastien

De : Christophe LUCAS 
Envoyé : vendredi 17 février 2023 12:19
À : Sébastien 65 
Cc : Jérôme Marteaux ; frnog 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Salut,

Est-ce que ton problème s'est réglé ?

Pour obtenir 1500 côté usager :
 - RFC2516 + RFC4638 (PPPoE Max-Payload) avec 8 octects de plus sur ta wan 
physique pour PPP + PPPoE (6+2) ;
 - Avoir une MTU alignée avec SFR entre ton PE qui fait du BGP avec SFR > 1548 ;
 - Avoir ta MTU > 1548 sur ton propre réseau pour transporter l'overhead du 
tunnel L2TP (40 octets) jusqu'à ton LNS ;

Bonne journée,
Christophe


- Mail original -
De: "Sébastien 65" 
À: "Jérôme Marteaux" , "frnog" 
Envoyé: Mercredi 15 Février 2023 11:46:52
Objet: RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

>As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant ton 
>ping ICMP ?
Rapidement mais rien qui me choque... Que je ping depuis le CPE vers la 
Loopback du LNS ou inversement j'ai un mtu = 0 en debug icmp...

Si je ping le CPE depuis le LNS en indiquant le size 1460 j'ai bien le len à 
1460 sur le debug ICMP du CPE.

*Feb 15 10:34:36.926: IP: s=IP-CPE (local), d=IP-LNS (Dialer0), len 1460, 
sending
*Feb 15 10:34:36.926: ICMP type=0, code=0
*Feb 15 10:34:36.926: IP: s=IP-CPE (local), d=IP-LNS (Dialer0), len 1460, 
output feature
*Feb 15 10:34:36.926: ICMP type=0, code=0, Post-routing NAT Outside(26), 
rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

>Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce cas tu 
>ne devrais pas être le seul impacté. 1 seul lien impacté ?
C'est notre première liaison de livrée localement sur cette porte...

Je viens enfin d'avoir le support, le sujet est en cours de traitement.
En plus du problème MTU j'avais indiqué un gros problème de latence qui vient 
de m'être confirmé par le support SFR ! On va avancer...
Etant a première vue l'un des premiers opérateurs locaux à avoir activé la 
porte j'ai l'impression qu'un de mes confrères rencontre +/- les mêmes 
soucis... Donc ça va avancer plus rapidement car je ne suis plus le seul !

Sébastien

De : frnog-requ...@frnog.org  de la part de Jérôme 
Marteaux 
Envoyé : mercredi 15 février 2023 10:57
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Le 15/02/2023 à 10:47, Sébastien 65 a écrit :
>> Si tu as toujours des problèmes pour faire passer des paquets plus gros que 
>> 1460 tu as un problème de fragmentation quelque part.
>> 1460 + 20 octets IP + 8 octets UDP + 12 octets L2TP = 1500.
> Entièrement d'accord ! Mais qui est le coupable 
>
>> Donc soit chez SFR soit chez toi.
>> Tu peux déjà regarder l'interface qui fait face à la porte SFR, y-a-t'il des 
>> "giants" dans show interface xxx ?
> Je viens de re-regarder, je n'ai pas de giants sur l'interface connectée 
> directement à l'équipement de collecte SFR et sur l'équipement qui est 
> connecté au LNS !
> J'avais check cela quand j'avais passé tout le monde à MTU 9000 pour voir.

As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant
ton ping ICMP ? (debug ip icmp, monitor capture, sh ip traf, debug l2tp
packet)

>
> C'est pour cela que je pense vraiment que c'est un équipement de SFR qui me 
> bouffe la MTU !
>

Ca me semblerait étonnant, car dans les 2 cas (MTU à 1500 et MTU plus
haute) tu devrais recevoir les paquets.
Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce
cas tu ne devrais pas être le seul impacté. 1 seul lien impacté ?


--
Jérôme Marteaux


---
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] Valeur MTU PPPOE FTTH

[Sébastien 65]

>As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant ton 
>ping ICMP ?
Rapidement mais rien qui me choque... Que je ping depuis le CPE vers la 
Loopback du LNS ou inversement j'ai un mtu = 0 en debug icmp...

Si je ping le CPE depuis le LNS en indiquant le size 1460 j'ai bien le len à 
1460 sur le debug ICMP du CPE.

*Feb 15 10:34:36.926: IP: s=IP-CPE (local), d=IP-LNS (Dialer0), len 1460, 
sending
*Feb 15 10:34:36.926: ICMP type=0, code=0
*Feb 15 10:34:36.926: IP: s=IP-CPE (local), d=IP-LNS (Dialer0), len 1460, 
output feature
*Feb 15 10:34:36.926: ICMP type=0, code=0, Post-routing NAT Outside(26), 
rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

>Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce cas tu 
>ne devrais pas être le seul impacté. 1 seul lien impacté ?
C'est notre première liaison de livrée localement sur cette porte...

Je viens enfin d'avoir le support, le sujet est en cours de traitement.
En plus du problème MTU j'avais indiqué un gros problème de latence qui vient 
de m'être confirmé par le support SFR ! On va avancer...
Etant a première vue l'un des premiers opérateurs locaux à avoir activé la 
porte j'ai l'impression qu'un de mes confrères rencontre +/- les mêmes 
soucis... Donc ça va avancer plus rapidement car je ne suis plus le seul !

Sébastien

De : frnog-requ...@frnog.org  de la part de Jérôme 
Marteaux 
Envoyé : mercredi 15 février 2023 10:57
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Le 15/02/2023 à 10:47, Sébastien 65 a écrit :
>> Si tu as toujours des problèmes pour faire passer des paquets plus gros que 
>> 1460 tu as un problème de fragmentation quelque part.
>> 1460 + 20 octets IP + 8 octets UDP + 12 octets L2TP = 1500.
> Entièrement d'accord ! Mais qui est le coupable 
>
>> Donc soit chez SFR soit chez toi.
>> Tu peux déjà regarder l'interface qui fait face à la porte SFR, y-a-t'il des 
>> "giants" dans show interface xxx ?
> Je viens de re-regarder, je n'ai pas de giants sur l'interface connectée 
> directement à l'équipement de collecte SFR et sur l'équipement qui est 
> connecté au LNS !
> J'avais check cela quand j'avais passé tout le monde à MTU 9000 pour voir.

As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant
ton ping ICMP ? (debug ip icmp, monitor capture, sh ip traf, debug l2tp
packet)

>
> C'est pour cela que je pense vraiment que c'est un équipement de SFR qui me 
> bouffe la MTU !
>

Ca me semblerait étonnant, car dans les 2 cas (MTU à 1500 et MTU plus
haute) tu devrais recevoir les paquets.
Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce
cas tu ne devrais pas être le seul impacté. 1 seul lien impacté ?


--
Jérôme Marteaux


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

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

>Si tu as toujours des problèmes pour faire passer des paquets plus gros que 
>1460 tu as un problème de fragmentation quelque part.
>1460 + 20 octets IP + 8 octets UDP + 12 octets L2TP = 1500.
Entièrement d'accord ! Mais qui est le coupable 

>Donc soit chez SFR soit chez toi.
>Tu peux déjà regarder l'interface qui fait face à la porte SFR, y-a-t'il des 
>"giants" dans show interface xxx ?
Je viens de re-regarder, je n'ai pas de giants sur l'interface connectée 
directement à l'équipement de collecte SFR et sur l'équipement qui est connecté 
au LNS !
J'avais check cela quand j'avais passé tout le monde à MTU 9000 pour voir.

C'est pour cela que je pense vraiment que c'est un équipement de SFR qui me 
bouffe la MTU !

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Le MTU sur l'interface vi2 est de 1492 comme pour le Dialer0.

CPE#sh interface vi2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Description: *** PPPoE lns_FTTH SFR ***
  MTU 1492 bytes, BW 56 Kbit/sec, DLY 2 usec,
 reliability 255/255, txload 18/255, rxload 18/255
  Encapsulation PPP, LCP Open

>As-tu bien toute la négo ppp dans ton debug ?
Oui j'ai collé toute la nego PPP qui trace MTU/MRU sur le CPE.

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

@Jérôme Marteaux
>Donc là ça s'accorde sur 1514 en MTU. Et en vrai tu as combien ?
Le CPE ne peut jamais dépasser 1460 avec un ping size (même en pinguant l'IP de 
la Loopback LNS).
Comme indiqué dans un précédent message sur la nego PPP du LNS il indique à 
chaque fois "PPP: Reducing MTU to peer's MRU" mais rien côté CPE...

@Steeve BEAUVAIS
>Pour moi c'est normal que cela ne fonctionne pas à 1492 à cause du L2TP de 
>l'OI.
En fait j'ai envie de dire que cela n'est pas normal que je ne dépasse pas les 
1460... Je peux me tromper !

Je n'ai toujours pas le retour de SFR sur le sujet au bout de 15J c'est 
fabuleux !!
Par contre quand je consulte les STAS IP Access SFR - en me disant que cela 
sera simmilaire sur leur DSP (?) je vois :

*sur accès FTTH
On utilise PPPoE et par défaut la MTU est 1492.
Si on veut une taille du paquet IP de 1500 octets, il faut utiliser sur le CPE 
d’extrémité le tag PPPoE max-payload en le mettant à la valeur 1500. 
L'interface Ethernet WAN du CPE doit avoir une MTU d'au moins de 1512 octets. 
La LNS doit être configurée correctement (négociation MRU).

J'ai eu quelques retours en OFF m'indiquant que pour eux il est possible 
d'aller bien au dela de 1460...

Je vais aller chercher dans mes cartons poussiéreux un bon C7301 et faire le 
test à la place de l'ASR-1001, sérieux :p
D'ailleurs si quelqu'un a dans ces archives c7301-boot-mz.152-4.M11.bin et 
C7301_RMFUR.srec.123-4r.T4 je suis prenneur ;)

Sébastien



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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Bonjour à tous,

OK Steeve je suis d'accord il n'est pas possible de modifier le MTU sur le 
Dialer. Je l'avais indiqué dans une réponse précédente c'est pour cela que 
j'étais plutôt sur la Loopback/Vi-Template du LNS...

@Jérôme Marteaux<mailto:jer...@dedwen.info> Voici le ppp nego sur le CPE :

*Feb 14 15:59:17.435: Vi2 PPP: Using dialer call direction
*Feb 14 15:59:17.435: Vi2 PPP: Treating connection as a callout
*Feb 14 15:59:17.435: Vi2 PPP: Session handle[7719] Session id[14]
*Feb 14 15:59:17.435: Vi2 LCP: Event[OPEN] State[Initial to Starting]
*Feb 14 15:59:17.435: Vi2 PPP: No remote authentication for call-out
*Feb 14 15:59:17.435: Vi2 LCP: O CONFREQ [Starting] id 1 len 14
*Feb 14 15:59:17.435: Vi2 LCP:MRU 1492 (0x010405D4)
*Feb 14 15:59:17.435: Vi2 LCP:MagicNumber 0x7D1CD9B7 (0x05067D1CD9B7)
*Feb 14 15:59:17.435: Vi2 LCP: Event[UP] State[Starting to REQsent]
*Feb 14 15:59:17.435: Vi2 LCP: I CONFREQ [REQsent] id 1 len 38
*Feb 14 15:59:17.435: Vi2 LCP:MRU 1514 (0x010405EA)
*Feb 14 15:59:17.435: Vi2 LCP:AuthProto CHAP (0x0305C22305)
*Feb 14 15:59:17.435: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
*Feb 14 15:59:17.435: Vi2 LCP:MRRU 1524 (0x110405F4)
*Feb 14 15:59:17.435: Vi2 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
*Feb 14 15:59:17.435: Vi2 LCP: O CONFREJ [REQsent] id 1 len 8
*Feb 14 15:59:17.435: Vi2 LCP:MRRU 1524 (0x110405F4)
*Feb 14 15:59:17.435: Vi2 LCP: Event[Receive ConfReq-] State[REQsent to REQsent]
*Feb 14 15:59:17.455: Vi2 LCP: I CONFACK [REQsent] id 1 len 14
*Feb 14 15:59:17.455: Vi2 LCP:MRU 1492 (0x010405D4)
*Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x7D1CD9B7 (0x05067D1CD9B7)
*Feb 14 15:59:17.455: Vi2 LCP: Event[Receive ConfAck] State[REQsent to ACKrcvd]
*Feb 14 15:59:17.455: Vi2 LCP: I CONFREQ [ACKrcvd] id 2 len 34
*Feb 14 15:59:17.455: Vi2 LCP:MRU 1514 (0x010405EA)
*Feb 14 15:59:17.455: Vi2 LCP:AuthProto CHAP (0x0305C22305)
*Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
*Feb 14 15:59:17.455: Vi2 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
*Feb 14 15:59:17.455: Vi2 LCP: O CONFACK [ACKrcvd] id 2 len 34
*Feb 14 15:59:17.455: Vi2 LCP:MRU 1514 (0x010405EA)
*Feb 14 15:59:17.455: Vi2 LCP:AuthProto CHAP (0x0305C22305)
*Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
*Feb 14 15:59:17.455: Vi2 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
*Feb 14 15:59:17.455: Vi2 LCP: Event[Receive ConfReq+] State[ACKrcvd to Open]
*Feb 14 15:59:17.487: Vi2 PPP: Phase is AUTHENTICATING, by the peer
*Feb 14 15:59:17.487: Vi2 LCP: State is Open


De : frnog-requ...@frnog.org  de la part de Jérôme 
Marteaux 
Envoyé : lundi 13 février 2023 21:23
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Le 10/02/2023 à 13:24, Sébastien 65 a écrit :
> Sur le CPE j'ai le MRU à 1492 et MRRU à 1524 comme sur le LNS, sauf que je 
> n'ai aucune indication de type Reducing MTU sur le CPE.
>
> J'ai l'impression que sur la chaine SFR il y a un équipement qui fait 
> n'importe quoi et me bouffe mon MTU !
>

Et que dit un debug ppp nego sur le CPE ?

--
Jérôme Marteaux


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

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Salut Steeve,

>Sur un cisco le MTU max que tu peux mettre sur un dialer est égale au MTU de 
>l'interface physique ou logique associé.
L'interface logique associée dans la virtual-template est une loopback, donc le 
MTU est de 1514.

Le MTU du Dialer devrait être bien supérieure à 1452, ce qui n'est pas le cas...

Sébastien

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Fabien,

J'avais même essayé avec MTU 9000 sur le LNS et même chose sur l'équipement de 
collecte qui récupère l'infra FTTH SFR afin d'être sur que la réduction MTU ne 
soit pas faite par un de mes équipements !

Cela ne change strictement rien côté CPE... Le debug sur le LNS indique 
toujours  PPP: Reducing MTU to peer's MRU

Sébastien

De : frnog-requ...@frnog.org  de la part de Fabien H 

Envoyé : vendredi 10 février 2023 18:37
À : Liste FRnoG 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Peut-être vérifier sur ton LNS que ton interface de Collecte opérateur ait
bien un MTU à minimum 2000 ?

Le ven. 10 févr. 2023 à 13:25, Sébastien 65  a écrit :

> Sur le CPE j'ai le MRU à 1492 et MRRU à 1524 comme sur le LNS, sauf que je
> n'ai aucune indication de type Reducing MTU sur le CPE.
>
> J'ai l'impression que sur la chaine SFR il y a un équipement qui fait
> n'importe quoi et me bouffe mon MTU !
>
> ---
> 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] Valeur MTU PPPOE FTTH

[Sébastien 65]

Sur le CPE j'ai le MRU à 1492 et MRRU à 1524 comme sur le LNS, sauf que je n'ai 
aucune indication de type Reducing MTU sur le CPE.

J'ai l'impression que sur la chaine SFR il y a un équipement qui fait n'importe 
quoi et me bouffe mon MTU !

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

>Déjà un bon point ! Mais dans l'autre sens (SFR->toi) c'est pas garanti.
En modifiant le vpdn/virtual-template j'ai bien la MRU qui passe de 1464 à 1524 
avec un message de reducing MTU que je n'avais pas avant sur le LNS :

Feb 10 12:35:44.717: Vi2.1 CHAP: O SUCCESS id 2 len 4
Feb 10 12:35:44.717: Vi2.1 PPP: Reducing MTU to peer's MRU
Feb 10 12:35:44.717: Vi2.1 PPP: Phase is UP


Par contre sur le CPE je ne peux toujours pas aller au-delà de 1460.



De : frnog-requ...@frnog.org  de la part de Jérôme 
Marteaux 
Envoyé : vendredi 10 février 2023 11:22
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Le 10/02/2023 à 11:08, Sébastien 65 a écrit :
>> C'est bien sur cet équipement (LNS ?) que ça coince, celui-ci dit qu'il fait 
>> au mieux 1464.
> Le debug indiqué est bien sur notre LNS. Je ne comprends pas justement 
> pourquoi il MTU à 1464 ?!
>

C'est à cause de ip mtu adjust dans ton vpdn sans ip mtu dans la
virtual-template:

Automatically Adjusting the IP MTU
You can also enable automatic adjustment of the IP MTU. This feature
allows the router to automatically adjust the IP MTU on the
virtual-access interface to compensate for the size of the L2TP header
and the MTU of the egress interface.

Note: The IP MTU is only adjusted automatically if there is no IP MTU
manually configured on the virtual-template interface (using the option
in the previous section).

https://www.cisco.com/c/en/us/support/docs/dial-access/virtual-private-dialup-network-vpdn/24320-l2tp-mtu-tuning.html

Supprime tout ce qui est relatif à la mtu dans le vpdn et met ppp mtu
adaptive dans la virtual-template.

>> Donc ton interco avec SFR est à 1500. Côté SFR est-ce bien aussi à 1500
> Mon interco est bien à 1500 ! Côté SFR j'attends d'avoir un retour j'ai 
> ouvert un ticket sans réponse depuis 1 semaine sur le sujet...
>
> Etant sur une nouvelle DSP il n'y a pas de STAS pour le moment, donc 
> clairement tu pars à l'aveugle...
>
> J'ai regardé les STAS de SFR FTTH ils indiquent que :
>
> # Entre le CPE sur le site du client final et le LNS du client Opérateur
> - On utilise PPPoE et par défaut la MTU est 1492.
> -Si on veut une taille du paquet IP de 1500 octets, il faut utiliser sur le 
> CPE d’extrémité le tag PPPoE max-payload en le mettant à la valeur 1500.
> -L'interface Ethernet WAN du CPE doit avoir une MTU d'au moins de 1512 
> octets. La LNS doit être configurée correctement (négociation MRU).
>
> # Sur les Portes de Livraison
> -La MTU entre les équipements Opérateur et le NTU de SFR devra être de 2000 
> octets en émission et en réception,

Si SFR respecte ^^ alors la MTU de la porte de collecte est à 2000.

> -Les équipements Opérateur ne devront pas envoyer des paquets L2TP fragmentés 
> vers SFR.
>
> J'aimerais que le support de la DSP me confirme cela...
>
>> Ré-essaye 1501 sans df pour voir si ça fragmente bien.
> Oui ça fragmente bien, par ex un ping de 1600 sans df passera !

Déjà un bon point ! Mais dans l'autre sens (SFR->toi) c'est pas garanti.

--
Jérôme Marteaux



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

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

>C'est bien sur cet équipement (LNS ?) que ça coince, celui-ci dit qu'il fait 
>au mieux 1464.
Le debug indiqué est bien sur notre LNS. Je ne comprends pas justement pourquoi 
il MTU à 1464 ?!

>Donc ton interco avec SFR est à 1500. Côté SFR est-ce bien aussi à 1500
Mon interco est bien à 1500 ! Côté SFR j'attends d'avoir un retour j'ai ouvert 
un ticket sans réponse depuis 1 semaine sur le sujet...

Etant sur une nouvelle DSP il n'y a pas de STAS pour le moment, donc clairement 
tu pars à l'aveugle...

J'ai regardé les STAS de SFR FTTH ils indiquent que :

# Entre le CPE sur le site du client final et le LNS du client Opérateur
- On utilise PPPoE et par défaut la MTU est 1492.
-Si on veut une taille du paquet IP de 1500 octets, il faut utiliser sur le CPE 
d’extrémité le tag PPPoE max-payload en le mettant à la valeur 1500.
-L'interface Ethernet WAN du CPE doit avoir une MTU d'au moins de 1512 octets. 
La LNS doit être configurée correctement (négociation MRU).

# Sur les Portes de Livraison
-La MTU entre les équipements Opérateur et le NTU de SFR devra être de 2000 
octets en émission et en réception,
-Les équipements Opérateur ne devront pas envoyer des paquets L2TP fragmentés 
vers SFR.

J'aimerais que le support de la DSP me confirme cela...

>Ré-essaye 1501 sans df pour voir si ça fragmente bien.
Oui ça fragmente bien, par ex un ping de 1600 sans df passera !

Sébastien

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Bonjour Jérôme,

>Pour moi mtu et ip mtu veulent dire la même chose sur un dialer (mtu ne 
>devrait pas exister car dialer n'est pas une interface physique).
mtu 1492 est automatique, je ne le configure pas moi-même c'est le routeur qui 
se rajoute cette commande.
D'ailleurs, il n'est jamais possible de supprimer ou d'augmenter la mtu d'un 
dialer ppp :

CPE(config)#int dialer 0
CPE(config-if)#mtu 1500
 MAX allowed PPPOE MTU[1492] is set as MTU
CPE(config-if)#no mtu 1492
 MAX allowed PPPOE MTU[1492] is set as MTU

>Pour voir ce que chacun dit tu peux faire un debug ppp nego pour savoir qui 
>annonce quoi en MRU (entre ton CPE, l'OLT/BNG SFR et ton LNS)
Justement c'est ici que je ne comprends pas pourquoi la MRU ne dépasse jamais 
1492 // 1464, un output :

Feb 08 07:03:16.714: PPP: Alloc Context [9713814]
Feb 08 07:03:16.714: ppp31 PPP: Phase is ESTABLISHING
Feb 08 07:03:16.714: ppp31 LCP: Event[OPEN] State[Initial to Starting]
Feb 08 07:03:16.714: ppp31 LCP: O CONFREQ [Starting] id 1 len 38
Feb 08 07:03:16.714: ppp31 LCP:MRU 1464 (0x010405B8)
Feb 08 07:03:16.714: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:16.714: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:16.714: ppp31 LCP:MRRU 1524 (0x110405F4)
Feb 08 07:03:16.714: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:16.714: ppp31 LCP: Event[UP] State[Starting to REQsent]
Feb 08 07:03:16.998: ppp31 LCP: I CONFREQ [REQsent] id 1 len 14
Feb 08 07:03:16.998: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:16.998: ppp31 LCP:MagicNumber 0x67B01CAC (0x050667B01CAC)
Feb 08 07:03:16.998: ppp31 LCP: O CONFACK [REQsent] id 1 len 14
Feb 08 07:03:16.998: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:16.998: ppp31 LCP:MagicNumber 0x67B01CAC (0x050667B01CAC)
Feb 08 07:03:16.998: ppp31 LCP: Event[Receive ConfReq+] State[REQsent to 
ACKsent]
Feb 08 07:03:16.998: ppp31 LCP: I CONFREJ [ACKsent] id 1 len 8
Feb 08 07:03:16.998: ppp31 LCP:MRRU 1524 (0x110405F4)
Feb 08 07:03:16.998: ppp31 LCP: O CONFREQ [ACKsent] id 2 len 34
Feb 08 07:03:16.998: ppp31 LCP:MRU 1464 (0x010405B8)
Feb 08 07:03:16.998: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:16.998: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:16.998: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:16.998: ppp31 LCP: Event[Receive ConfNak/Rej] State[ACKsent to 
ACKsent]
Feb 08 07:03:17.306: ppp31 LCP: I CONFNAK [ACKsent] id 2 len 8
Feb 08 07:03:17.306: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:17.306: ppp31 LCP: O CONFREQ [ACKsent] id 3 len 34
Feb 08 07:03:17.306: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:17.306: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:17.306: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:17.306: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:17.306: ppp31 LCP: Event[Receive ConfNak/Rej] State[ACKsent to 
ACKsent]
Feb 08 07:03:17.618: ppp31 LCP: I CONFACK [ACKsent] id 3 len 34
Feb 08 07:03:17.618: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:17.618: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:17.618: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:17.618: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:17.618: ppp31 LCP: Event[Receive ConfAck] State[ACKsent to Open]
Feb 08 07:03:17.646: ppp31 PPP: Phase is AUTHENTICATING, by this end
Feb 08 07:03:17.646: ppp31 CHAP: O CHALLENGE id 2 len 33 from "lns-FTTH"
Feb 08 07:03:17.646: ppp31 LCP: State is Open

>Regarde show l2tp tunnel, prend l'IP d'un OLT/BNG SFR au hasard et essaye de 
>le pinger en df pour voir si déjà tu as bien 1500 octets,
Je peux pinger une IP du BNG SFR depuis le LNS avec 1500 mais pas en 1501 (size 
150x df-bit)

Sébastien

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

>Tu veux dire que le paquet de 1462 passe puis ensuite ne passe plus ?
C'est bien ça !

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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Nop pas du tout David ! C'est un réflexe le 8.8.8.8

Tu me crois ou pas (délirant) :

CPE#ping 152.199.23.71 size 1462 df-bit source dial0
Type escape sequence to abort.
Sending 5, 1462-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
Packet sent with a source address of
Packet sent with the DF bit set
!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/47/64 ms
CPE#ping 152.199.23.71 size 1463 df-bit source dial0
Type escape sequence to abort.
Sending 5, 1463-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
Packet sent with a source address of
Packet sent with the DF bit set
.
Success rate is 0 percent (0/5)
CPE#ping 152.199.23.71 size 1463 df-bit source dial0
Type escape sequence to abort.
Sending 5, 1463-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
Packet sent with a source address of
Packet sent with the DF bit set
.
Success rate is 0 percent (0/5)
CPE#ping 152.199.23.71 size 1462 df-bit source dial0
Type escape sequence to abort.
Sending 5, 1462-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
Packet sent with a source address of
Packet sent with the DF bit set
.
Success rate is 0 percent (0/5)




De : David Ponzone 
Envoyé : mercredi 8 février 2023 17:08
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Et oui, je t’ai prévenu et tu m’as pris à la légère :)

Quand tu fais un ping 1462 vers 8.8.8.8, tu envoies ça dans le payload:

Data (1462 bytes)

Et tu reçois ça en réponse:

Data (68 bytes)

Donc l’ICMP REPLY était bien plus petit que ta limite de MTU LNS->CPE.

Ceci dit, tu sembles avoir un MTU asymétrique et ça mérite de s’y pencher, mais 
bon avec SFR, tu auras difficilement quelqu’un qui tient la route en face pour 
discuter de ça.

Pour 152.199.23.71, tu es sûr de ton coup ?
Je ne vois pas la même asymétrie de l’ICMP REPLY.

Le 8 févr. 2023 à 16:59, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Le ping size 1462 passe vers 8.8.8.8/152.199.23.71 mais pas vers 
1.1.1.1/208.67.222.222/212.82.100.150, pour eux il faut un size à 1460.

Je ne peux pas dire encore l'impact car il s'agit du premier lien livré 
localement sur cette DSP !
Mais quand je regarde les STAS de SFR il est bien indiqué MTU 1492 par défaut 
en PPPoE d'où mon interrogation 


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 16:18
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Et ça passe à 1462 et pas plus ?
C’est bizarre, mais bon, ça fait depuis que j’ai commencé dans ce métier (1995) 
qu’on se prend la tête avec le MTU et les trucs bizarres.
Déjà si ça coupe à 1462, tu devrais mettre ça comme valeur dans ton 
Virtual-Template et dans ton CPE.

Tu as un impact client ou c’était par curiosité ?
Généralement, si les MTU de tes interfaces autorisent des paquets d’une taille 
qui sera droppée par le réseau, tu as/auras un impact client immédiat, puisque 
la fragmentation va faire des paquets trop gros.
D’où la réduction du MTU, ou l’utilisation du MSS (qui ne règle pas le problème 
pour ICMP et UDP).

Le 8 févr. 2023 à 11:32, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

L'interface Virtual-Access2.X a un MTU de 1464 !

Je suis en directe sur une collecte FTTH SFR Pro (DSP).

De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 11:24
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Cherche la Vi de ton lien (sh users | inc ), et fais un:
sh int ViX.Y

Tu vas avoir le MTU de la Vi.

Ca peut aussi venir de SFR ou de ton collecteur puisque je suppos que tu es pas 
en direct avec SFR.

Le 8 févr. 2023 à 11:17, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

David,

Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 

interface Virtual-Template1
 description SFR FTTH
 ip unnumbered Loopback10
 no ip redirects
 no ip proxy-arp
 ip verify unicast source reachable-via rx
 ppp ..
!

J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis le 
routeur CPE.

Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers d'autres 
destinations.


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 10:26
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans tu 
as:
mtu 1462
alors c’es

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Le ping size 1462 passe vers 8.8.8.8/152.199.23.71 mais pas vers 
1.1.1.1/208.67.222.222/212.82.100.150, pour eux il faut un size à 1460.

Je ne peux pas dire encore l'impact car il s'agit du premier lien livré 
localement sur cette DSP !
Mais quand je regarde les STAS de SFR il est bien indiqué MTU 1492 par défaut 
en PPPoE d'où mon interrogation 


De : David Ponzone 
Envoyé : mercredi 8 février 2023 16:18
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Et ça passe à 1462 et pas plus ?
C’est bizarre, mais bon, ça fait depuis que j’ai commencé dans ce métier (1995) 
qu’on se prend la tête avec le MTU et les trucs bizarres.
Déjà si ça coupe à 1462, tu devrais mettre ça comme valeur dans ton 
Virtual-Template et dans ton CPE.

Tu as un impact client ou c’était par curiosité ?
Généralement, si les MTU de tes interfaces autorisent des paquets d’une taille 
qui sera droppée par le réseau, tu as/auras un impact client immédiat, puisque 
la fragmentation va faire des paquets trop gros.
D’où la réduction du MTU, ou l’utilisation du MSS (qui ne règle pas le problème 
pour ICMP et UDP).

Le 8 févr. 2023 à 11:32, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

L'interface Virtual-Access2.X a un MTU de 1464 !

Je suis en directe sur une collecte FTTH SFR Pro (DSP).

De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 11:24
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Cherche la Vi de ton lien (sh users | inc ), et fais un:
sh int ViX.Y

Tu vas avoir le MTU de la Vi.

Ca peut aussi venir de SFR ou de ton collecteur puisque je suppos que tu es pas 
en direct avec SFR.

Le 8 févr. 2023 à 11:17, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

David,

Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 

interface Virtual-Template1
 description SFR FTTH
 ip unnumbered Loopback10
 no ip redirects
 no ip proxy-arp
 ip verify unicast source reachable-via rx
 ppp ..
!

J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis le 
routeur CPE.

Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers d'autres 
destinations.


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 10:26
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans tu 
as:
mtu 1462
alors c’est normal (c’est le retour qui bloque à 1462).

Conseil: évite de faire tes tests de ping avec 8.8.8.8, ils font des trucs 
bizarres sur ICMP…
Le mieux c’est de pinger l’autre endpoint donc l’IP de l’interface que tu as 
mises dans le Virtual-Template1

David

> Le 8 févr. 2023 à 09:50, Sébastien 65 
> mailto:sebastien...@live.fr>> a écrit :
>
> Bonjour,
>
>
> Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
> L2TP/PPPoE...
>
>
> Pour pouvoir surfer "correctement" sur internet je suis obligé de configurer 
> le Dialer du routeur client comme ceci :
>
>
> interface Dialer0
>
> encapsulation ppp
>
> mtu 1492
>
> ip mtu 1460
>
> ip tcp adjust-mss 1420
>
>
> Le Dialer0 est rattaché sur le VLAN d'accès 2900.
>
>
> Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…
>
>
> ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe depuis 
> le routeur.
>
>
> Côté LNS j’ai la configuration suivante :
>
>
> vpdn-group FTTH-SFR
>
> accept-dialin
>
>  protocol l2tp
>
>  virtual-template 1
>
> source-ip X.X.X.X
>
> local name LNS-FTTH
>
> lcp renegotiation always
>
> no l2tp tunnel authentication
>
> ip pmtu
>
> ip mtu adjust
>
> !
>
>
> Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?
>
>
> Merci !
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

L'interface Virtual-Access2.X a un MTU de 1464 !

Je suis en directe sur une collecte FTTH SFR Pro (DSP).

De : David Ponzone 
Envoyé : mercredi 8 février 2023 11:24
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Cherche la Vi de ton lien (sh users | inc ), et fais un:
sh int ViX.Y

Tu vas avoir le MTU de la Vi.

Ca peut aussi venir de SFR ou de ton collecteur puisque je suppos que tu es pas 
en direct avec SFR.

Le 8 févr. 2023 à 11:17, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

David,

Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 

interface Virtual-Template1
 description SFR FTTH
 ip unnumbered Loopback10
 no ip redirects
 no ip proxy-arp
 ip verify unicast source reachable-via rx
 ppp ..
!

J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis le 
routeur CPE.

Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers d'autres 
destinations.


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 10:26
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans tu 
as:
mtu 1462
alors c’est normal (c’est le retour qui bloque à 1462).

Conseil: évite de faire tes tests de ping avec 8.8.8.8, ils font des trucs 
bizarres sur ICMP…
Le mieux c’est de pinger l’autre endpoint donc l’IP de l’interface que tu as 
mises dans le Virtual-Template1

David

> Le 8 févr. 2023 à 09:50, Sébastien 65 
> mailto:sebastien...@live.fr>> a écrit :
>
> Bonjour,
>
>
> Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
> L2TP/PPPoE...
>
>
> Pour pouvoir surfer "correctement" sur internet je suis obligé de configurer 
> le Dialer du routeur client comme ceci :
>
>
> interface Dialer0
>
> encapsulation ppp
>
> mtu 1492
>
> ip mtu 1460
>
> ip tcp adjust-mss 1420
>
>
> Le Dialer0 est rattaché sur le VLAN d'accès 2900.
>
>
> Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…
>
>
> ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe depuis 
> le routeur.
>
>
> Côté LNS j’ai la configuration suivante :
>
>
> vpdn-group FTTH-SFR
>
> accept-dialin
>
>  protocol l2tp
>
>  virtual-template 1
>
> source-ip X.X.X.X
>
> local name LNS-FTTH
>
> lcp renegotiation always
>
> no l2tp tunnel authentication
>
> ip pmtu
>
> ip mtu adjust
>
> !
>
>
> Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?
>
>
> Merci !
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

David,

Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 

interface Virtual-Template1
 description SFR FTTH
 ip unnumbered Loopback10
 no ip redirects
 no ip proxy-arp
 ip verify unicast source reachable-via rx
 ppp ..
!

J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis le 
routeur CPE.

Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers d'autres 
destinations.


De : David Ponzone 
Envoyé : mercredi 8 février 2023 10:26
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans tu 
as:
mtu 1462
alors c’est normal (c’est le retour qui bloque à 1462).

Conseil: évite de faire tes tests de ping avec 8.8.8.8, ils font des trucs 
bizarres sur ICMP…
Le mieux c’est de pinger l’autre endpoint donc l’IP de l’interface que tu as 
mises dans le Virtual-Template1

David

> Le 8 févr. 2023 à 09:50, Sébastien 65  a écrit :
>
> Bonjour,
>
>
> Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
> L2TP/PPPoE...
>
>
> Pour pouvoir surfer "correctement" sur internet je suis obligé de configurer 
> le Dialer du routeur client comme ceci :
>
>
> interface Dialer0
>
> encapsulation ppp
>
> mtu 1492
>
> ip mtu 1460
>
> ip tcp adjust-mss 1420
>
>
> Le Dialer0 est rattaché sur le VLAN d'accès 2900.
>
>
> Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…
>
>
> ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe depuis 
> le routeur.
>
>
> Côté LNS j’ai la configuration suivante :
>
>
> vpdn-group FTTH-SFR
>
> accept-dialin
>
>  protocol l2tp
>
>  virtual-template 1
>
> source-ip X.X.X.X
>
> local name LNS-FTTH
>
> lcp renegotiation always
>
> no l2tp tunnel authentication
>
> ip pmtu
>
> ip mtu adjust
>
> !
>
>
> Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?
>
>
> Merci !
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Sébastien 65]

Bonjour,


Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
L2TP/PPPoE...


Pour pouvoir surfer "correctement" sur internet je suis obligé de configurer le 
Dialer du routeur client comme ceci :


interface Dialer0

 encapsulation ppp

 mtu 1492

 ip mtu 1460

 ip tcp adjust-mss 1420


Le Dialer0 est rattaché sur le VLAN d'accès 2900.


Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…


ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe depuis 
le routeur.


Côté LNS j’ai la configuration suivante :


vpdn-group FTTH-SFR

accept-dialin

  protocol l2tp

  virtual-template 1

 source-ip X.X.X.X

 local name LNS-FTTH

 lcp renegotiation always

 no l2tp tunnel authentication

 ip pmtu

 ip mtu adjust

!


Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?


Merci !


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

[FRnOG] [ALERT] Incident FTTH KOSC/SFR

[Sébastien 65]

Hello,

Est-ce qu'il y a des infos sur l'incident généralisé impactant grandement les 
FTTH sur les départements 64/65 via collecte KOSC et SFR ?

Le retour KOSC est "nous vous informons qu’un incident réseau est actuellement 
en cours. Des incidents impacts les sites NRA/NRO ."

Pas plus d'infos depuis les coupures des liaisons de ce matin après 11h !

Je suis preneur d'infos car 17h plus personne au bout des tickets...

Merci !

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

RE: [FRnOG] [TECH] Reboot switch via commande no police

[Sébastien 65]

Jérôme,

Voici la raison : Last reload reason: abort at PC 0x0

Le crashdump me fait mal à la tête mais le dernier event est bien la commande 
no police xxx rien d'autre !

Truc de malade +++, en port console je peux supprimer le no police xxx  le 
switch ne bronche pas !

Si je passe en SSH et que je supprime le no police xxx reboot direct du switch !



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

[FRnOG] [TECH] Reboot switch via commande no police

[Sébastien 65]

Hello,

Un truc marrant (en fait non ) sur un CISCO 4900M qui dispose d'un 
service-policy input/output intégrant une police dans la class class-default.

Si je supprime la police via "no police " le switch REBOOT ! Aucun message 
d'erreur...
Il revient sur la conf startup préalablement enregistrée avant la saisie de la 
commande no police.

J'ai essayé avec deux IOS et même combat 
cat4500e-entservicesk9-mz.152-4.E10.bin ET 
cat4500e-entservicesk9-mz.152-4.E10a.bin

Quelqu'un a t'il déjà vu cela ?

Sébastien

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

[FRnOG] [TECH] Gestion des CDR

[Sébastien 65]

Bonjour à tous,

Connaissez-vous un outil simple de gestion/compilation des CDR permettant de 
sortir des graphes/profil de consommation avec la possibilité d'utiliser des 
filtres (pays,fixe,mob,surtaxé,etc...) ?

Un de mes opérateurs Trunk SIP me donne des CDR sans interface de gestion, je 
dois moi-même traiter le "gros" fichier en filtrant par le nom du trunk client 
pour exporter les données individuellement pour chaque client.

Si une moulinette existe cela m'intéresse de pouvoir produire des profils de 
conso et également faciliter la préparation de la facturation.

Si possible open-source, mais pas fermé sur une appli payante.

Merci !

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

[FRnOG] [TECH] Choix antenne 4G extérieure omni

[Sébastien 65]

Bonjour la liste,

Que pouvez vous me conseiller comme antenne 4G extérieure omni ?

Cerise sur le gâteau, un fournisseur qui ne mettra pas 3 mois à la livrer...

Merci



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

[FRnOG] [BIZ] ASR-920-12CZ-A

[Sébastien 65]

Bonjour,

Un broker CISCO peut-t'il revenir vers moi concernant ASR-920-12CZ-A ?

Mes brokers actuels n'ont pas de stock rapide ou alors le prix ne sera pas 
celui de d'habitude...

Merci par avance de revenir vers moi en privé.

Sébastien

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

[FRnOG] [BIZ] Cisco ME 3800X

[Sébastien 65]

Bonjour,

Je recherche un broker qui pourrait me fournir du CISCO ME avec licence Metro 
IP Services.

Merci de bien vouloir revenir vers moi en PV.

Bonne journée à tous !

Sébastien

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

[FRnOG] [ALERT] KOSC FTTH down dans le sud-ouest

[Sébastien 65]

Bonjour la liste,

Est-ce que quelqu'un a des infos sur le problème réseau de KOSC ?

Nous avons eu des problèmes Lundi en mode yoyo avec le motif "anomalies fibres 
dans un Datacenter Toulousain" et aujourd'hui coupure franche avec comme raison 
: problème WDM !

J'ai cru comprendre aussi qu'il y a un impact réseau dans l'Est !

J'ai l'impression qu'il y a de plus en plus de laisser-aller chez eux...

Sébastien

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

[FRnOG] [TECH] Config CISCO 3G sur réseau EIT

[Sébastien 65]

Bonjour à tous,

Meilleurs voeux pour cette nouvelle année !

Qui parmi vous utilise des routeurs CISCO 3G (819G+7) sur le réseau carte SIM 
E.I.T avec qui je pourrais comparer une configuration ??

J'ai 3 cartes SIM qui me donne un résultat complétement différent, dont une ou 
je suis bridé en EDGE... Au bout d'un certain temps très variable la session 
tombe et ne remonte pas !
Le profile 1 de la SIM est attachée sur l'APN net26 sans aucune 
authentification. J'ai également essayé avec l'APN fnetnrj...

J'utilise le chat-script hspa  "" "AT!SCACT=1,1" TIMEOUT 60 "OK"

La configuration de l'interface Cel0 est la suivante :
!
interface Cellular0
 ip address negotiated
 ip nat outside
 ip virtual-reassembly in
 encapsulation slip
 dialer in-band
 dialer idle-timeout 0
 dialer string hspa
 dialer watch-group 1
 async mode interactive
 pulse-time 0
!
line 3
 script dialer hspa
 no exec
 rxspeed 2160
 txspeed 576
!

Afin de garder la connexion UP j'utilise watch-group 1 ainsi qu'un IP SLA qui 
ping toutes les 10 secondes 8.8.8.8 pour créer du trafic...

dialer watch-list 1 ip 5.6.7.8 0.0.0.0 => 2° TEST avec dialer watch-list 1 ip 
1.1.1.1 255.255.255.255
dialer watch-list 1 delay route-check initial 60
dialer watch-list 1 delay connect 1

Cela ne fonctionne pas mieux ;(

Une idée ?

Sébastien



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

RE: [FRnOG] [ALERT] Incident national chez AXIONE ...

[Sébastien 65]

Arf... Ne m'en parle même pas David ! Au prix que cela a couté (et que ça coute 
toujours !) c'est quand même déplorable d'avoir un maillage fait avec les 
pieds...

J'ai du mal à comprendre la logique du maillage réseau ici dans mon territoire 
! Par exemple sur un tronc de collecte FTTB, tu vas avoir quelques clients de 
UP et tous les autres DOWN.
Le plus amusant (si je peux dire ça hein ;( ), dans la même ville, deux clients 
espacés d'environ 500m = 1UP et 1 DOWN.


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

RE: [FRnOG] [ALERT] Incident national chez AXIONE ...

[Sébastien 65]

Idem chez nous ! Sur le pont depuis environ 17h...

Sur deux départements voisin 1 est quasi HS, l'autre semble SAFE !

Ils ne savent pas encore par où commencer ! Ça va piquer à mon avis...

Bon courage à eux car ils vont en avoir besoin, prévoir aussi du café car la 
nuit va être longue !

Sébastien

De : frnog-requ...@frnog.org  de la part de 
br...@skiwebcenter.fr 
Envoyé : jeudi 18 novembre 2021 18:36
À : Charles ENEL-REHEL 
Cc : frnog-al...@frnog.org ; frnog-requ...@frnog.org 

Objet : Re: [FRnOG] [ALERT] Incident national chez AXIONE ...


Pas d'impact chez nous, mais un message sur leur espace client.

Bon courage.




-


Bonjour,

Nous tenons à vous informer d'un incident survenu sur notre réseau.

Date de début : jeudi 18 novembre 2021 16:56:00 CET (UTC +0100)

Motif : Incident généralisé sur notre réseau

Information(s) supplémentaire(s):
Nous rencontrons actuellement un incident généralisé sur notre réseau
national. Nous savons qu'il y a beaucoup d'impact et notre escalade
technique investigue en ce moment sur la nature de l'incident afin de
trouver au plus vite une solution. Nous reviendrons vers vous dès que
nous aurons plus d'information sur les raisons de cet incident et sur un
délai de rétablissement.

Service(s) potentiellement impacté(s) :

Voir le texte cité

Veuillez nous excuser pour la gêne occasionnée, merci de votre
compréhension.

Cordialement,

Supervision AXIONE
Téléphone :
0811 65 05 18




Le 2021-11-18 18:23, Charles ENEL-REHEL a écrit :
> Holà !
>
> Pour info, incident général et national chez AXIONE depuis 16h56. Perte
> concomitante de milliers de sites, aléatoirement situés en France dans
> tous
> leurs réseaux. Merci Nokia !
>
> Beaucoup de trous dans la raquette mais pas tous par terre. Bon courage
> à
> eux car là, c'est chaud ;-)
>
> Charles.
>
> ---
> Liste de diffusion du FRnOG
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7Caf7bac3939314f1aeaf008d9aaba0e6a%7C84df9e7fe9f640afb435%7C1%7C0%7C637728538339772710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=uP5Ve008NnhS9bQRL93aELmWL8UJhit%2BePrmum2jFxE%3Dreserved=0


---
Liste de diffusion du FRnOG
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7Caf7bac3939314f1aeaf008d9aaba0e6a%7C84df9e7fe9f640afb435%7C1%7C0%7C637728538339772710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=uP5Ve008NnhS9bQRL93aELmWL8UJhit%2BePrmum2jFxE%3Dreserved=0

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

[TECH] RE: [TECH] RE: [FRnOG] [TECH] Par quel modèle remplacer les C891F-K9 [NAT]

[Sébastien 65]

David,

>Je dis ça, parce que sauf si tu as les moyens de mettre 1000€ dans un CPE 
>neuf, les appros en refurbished sur Cisco sont très variables en dispo et 
>prix, en fonction du modèle et de sa popularité.
Impensable de mettre autant sur un CPE  En refurb je n'ai pas trop de problème 
avec la panoplie de fournisseurs que j'ai à ma disposition... La série des 
8XX/9XX est relativement fréquente de plus je n'écoule pas 100 CPE par mois ! 
Cela dit j'aimerais bien ^^

>Après, je me mêle de ce qui me regarde pas mais homogénéité d’un parc veut 
>aussi dire être coincé par les roubignoles.
Je ne partage pas vraiment ton avis cette fois-ci !

Mais si cela peut te rassurer j'intègre aussi du Mikrotik sur une certaine 
catégorie de projet. Quand tu viens du monde Cisco c'est une autre philosophie 
et approche...
Le MKT marche pas trop mal en mode CPE basique avec IPv4 + IPv6 j'en suis ravi. 
Juste de gros problèmes avec les alimentations 24V qui lâchent à tour de bras 
!!!



De : David Ponzone 
Envoyé : lundi 8 novembre 2021 08:29
À : Sébastien 65 
Cc : Michel Py ; frnog-t...@frnog.org 

Objet : Re: [TECH] RE: [FRnOG] [TECH] Par quel modèle remplacer les C891F-K9 
[NAT]

C’est donc le moment de changer non ? :)
Je dis ça, parce que sauf si tu as les moyens de mettre 1000€ dans un CPE neuf, 
les appros en refurbished sur Cisco sont très variables en dispo et prix, en 
fonction du modèle et de sa popularité.
Tu cours donc toujours le risque d’être coincé un jour ou l’autre.
Après, je me mêle de ce qui me regarde pas mais homogénéité d’un parc veut 
aussi dire être coincé par les roubignoles.

Le 8 nov. 2021 à 08:17, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Salut David,

Homogénéité du parc, configuration et automatisation des process [CISCO] !


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : lundi 8 novembre 2021 07:39
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : Michel Py 
mailto:mic...@arneill-py.sacramento.ca.us>>;
 frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [TECH] RE: [FRnOG] [TECH] Par quel modèle remplacer les C891F-K9 
[NAT]

Sébastien,

Juste pour info, c’est quoi le truc qui te contraint à mettre du Cisco ?
IP SLA ou autre chose ?

> Le 8 nov. 2021 à 06:38, Sébastien 65 
> mailto:sebastien...@live.fr>> a écrit :
>
>> T'as regardé du coté du 931 ? J'ai pas trouvé grand-chose sur le débit, mais 
>> c'est plus récent dont a priori ça devrait pédaler un peu plus que le 891.
> Je n'ai jamais essayé cette version ! Pourquoi pas mais la datasheet n'est 
> pas trop bavarde...
> J'ai regardé sur l'Internet, je n'ai pas réussi à trouver le throughput over 
> NAT, on ne parle que des 250Mb en VPN !
>
>> Il y a les dieux du routage qui, sur les forums, confondent le débit IPSEC 
>> et le débit tout court :-(
> lol !
>
> Merci pour ton RETEX sur Untangle 
>
> ---
> Liste de diffusion du FRnOG
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7Cea14d50bf5084486d23c08d9a2827ce8%7C84df9e7fe9f640afb435%7C1%7C0%7C637719503581641657%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ToAB10aiS5bzQLwGb91nmTcJ6kceMvMw0UZn9jNC%2BWI%3Dreserved=0<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F=04%7C01%7C%7C3f2daa3258ad464c067308d9a2897e0b%7C84df9e7fe9f640afb435%7C1%7C0%7C637719533665187362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=pM7AsCJt%2F1wA6VL5OC9wBCZ8KZTxhU4TaqRVDvowTio%3D=0>



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

[TECH] RE: [TECH] RE: [FRnOG] [TECH] Par quel modèle remplacer les C891F-K9 [NAT]

[Sébastien 65]

Salut David,

Homogénéité du parc, configuration et automatisation des process [CISCO] !


De : David Ponzone 
Envoyé : lundi 8 novembre 2021 07:39
À : Sébastien 65 
Cc : Michel Py ; frnog-t...@frnog.org 

Objet : Re: [TECH] RE: [FRnOG] [TECH] Par quel modèle remplacer les C891F-K9 
[NAT]

Sébastien,

Juste pour info, c’est quoi le truc qui te contraint à mettre du Cisco ?
IP SLA ou autre chose ?

> Le 8 nov. 2021 à 06:38, Sébastien 65  a écrit :
>
>> T'as regardé du coté du 931 ? J'ai pas trouvé grand-chose sur le débit, mais 
>> c'est plus récent dont a priori ça devrait pédaler un peu plus que le 891.
> Je n'ai jamais essayé cette version ! Pourquoi pas mais la datasheet n'est 
> pas trop bavarde...
> J'ai regardé sur l'Internet, je n'ai pas réussi à trouver le throughput over 
> NAT, on ne parle que des 250Mb en VPN !
>
>> Il y a les dieux du routage qui, sur les forums, confondent le débit IPSEC 
>> et le débit tout court :-(
> lol !
>
> Merci pour ton RETEX sur Untangle 
>
> ---
> Liste de diffusion du FRnOG
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7Cea14d50bf5084486d23c08d9a2827ce8%7C84df9e7fe9f640afb435%7C1%7C0%7C637719503581641657%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ToAB10aiS5bzQLwGb91nmTcJ6kceMvMw0UZn9jNC%2BWI%3Dreserved=0


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

[TECH] RE: [FRnOG] [TECH] Par quel modèle remplacer les C891F-K9 [NAT]

[Sébastien 65]

>T'as regardé du coté du 931 ? J'ai pas trouvé grand-chose sur le débit, mais 
>c'est plus récent dont a priori ça devrait pédaler un peu plus que le 891.
Je n'ai jamais essayé cette version ! Pourquoi pas mais la datasheet n'est pas 
trop bavarde...
J'ai regardé sur l'Internet, je n'ai pas réussi à trouver le throughput over 
NAT, on ne parle que des 250Mb en VPN !

>Il y a les dieux du routage qui, sur les forums, confondent le débit IPSEC et 
>le débit tout court :-(
lol !

Merci pour ton RETEX sur Untangle 

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

[FRnOG] [TECH] Par quel modèle remplacer les C891F-K9 [NAT]

[Sébastien 65]

Bonjour à tous,

Je cherche un petit CPE CISCO capable de pouvoir encaisser au minimum 800Mb en 
mode NAT.
Je n'ai pas besoin des features BGP/EIGRP et/ou routage high level, juste du 
traditionnel : SSH/DHCP/NAT/IP SLA avec support de l'IPv6 LAN/WAN.

Je souhaite remplacer des C891F-K9 plafonnant aux alentours de 400Mb avec du 
NAT.

Il y a bien les C-4P mais cela reste encore assez haut en termes de prix...

J'ai besoin d'un CPE dans les mêmes dimensions que les C891 ou C car facile 
à caser un peu partout...

Vous pouvez me conseillez quoi comme bécane (je vais privilégier le mode 
REFURB) ?

Bonne journée !

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

RE: [FRnOG] [MISC] Contact peering IELO-LIAZO

[Sébastien 65]

Merci pour les retours ! C'est maintenant OK j'ai le contact 

Sébastien

De : David Ponzone 
Envoyé : jeudi 14 octobre 2021 09:25
À : Sébastien 65 
Cc : Frnog misc 
Objet : Re: [FRnOG] [MISC] Contact peering IELO-LIAZO

https://www.peeringdb.com/asn/29075<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.peeringdb.com%2Fasn%2F29075=04%7C01%7C%7C4d17a2ed16b545ffbb6d08d98ee3cc88%7C84df9e7fe9f640afb435%7C1%7C0%7C637697931298939145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=j%2BCYsia58I04MFbVyV%2BWvGwU1%2BSzsHoccPg5S0upuz8%3D=0>

Le 14 oct. 2021 à 08:56, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Bonjour à tous,

Est-ce que l'un ou l'une d'entre vous dispose d'un contact tél/mail afin de 
pouvoir toucher le NOC/PEERING ?

Je ne peux plus consulter 
http://www.as-ielo.net/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.as-ielo.net%2F=04%7C01%7C%7C4d17a2ed16b545ffbb6d08d98ee3cc88%7C84df9e7fe9f640afb435%7C1%7C0%7C637697931298949143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tFNlYdFSXhYSXQwIzK0vDIyfQLlNBl3ZEAfP5XsNAp4%3D=0>
 ou 
http://as29075.net/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fas29075.net%2F=04%7C01%7C%7C4d17a2ed16b545ffbb6d08d98ee3cc88%7C84df9e7fe9f640afb435%7C1%7C0%7C637697931298959137%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=DXDTznj0ZqpF8a3DAhU9L2Yr7wcyWXgtbqu%2Blbm6SyE%3D=0>
 car les deux sites ne sont plus fonctionnels !

J'ai passé un mail sur pe...@ielo.net<mailto:pe...@ielo.net> il y a une 
semaine, aucune réponse...

Merci pour vos retours en PV.

Bonne journée !

---
Liste de diffusion du FRnOG
http://www.frnog.org/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F=04%7C01%7C%7C4d17a2ed16b545ffbb6d08d98ee3cc88%7C84df9e7fe9f640afb435%7C1%7C0%7C637697931298969125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=md1OOBVA%2FTLTylHopx3C0SjMKYUWRQTgrQGUXPimTbQ%3D=0>


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

[FRnOG] [MISC] Contact peering IELO-LIAZO

[Sébastien 65]

Bonjour à tous,

Est-ce que l'un ou l'une d'entre vous dispose d'un contact tél/mail afin de 
pouvoir toucher le NOC/PEERING ?

Je ne peux plus consulter http://www.as-ielo.net/ ou http://as29075.net/ car 
les deux sites ne sont plus fonctionnels !

J'ai passé un mail sur pe...@ielo.net il y a une semaine, aucune réponse...

Merci pour vos retours en PV.

Bonne journée !

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

RE: [FRnOG] [TECH] RAD ou pas RAD sur CELAN Orange ?

[Sébastien 65]

Merci pour vos retours.

Les STAS ne sont pas hyper documentées sur cette partie... Il figure bien le 
fait de pouvoir commander une liaison avec ou sans EAS mais aucune indication 
s'il faut appliquer une configuration spécifique lorsqu'il n'y a pas d'EAS.

Il n'est pas non plus précisé s'il est possible d'enlever l'EAS en cours de 
route !

Au-delà d'un débit d'un Giga, l'EAS est obligatoire d'après ma lecture.

Sébastien

De : Michel Merle 
Envoyé : dimanche 13 juin 2021 19:12
À : Steeve BEAUVAIS - Société Serinya Telecom 

Cc : Romain BAFFERT ; David Ponzone 
; Sébastien 65 ; frnog-tech 

Objet : Re: [FRnOG] [TECH] RAD ou pas RAD sur CELAN Orange ?

L’intérêt principal est si tu ne veux pas avoir d’équipement AC sur le site de 
livraison du CELAN : en supprimant l’EAS, tu fais ta cuisine en DC. Plus besoin 
d’onduleur alimenté en AC, qui charge des batteries DC puis en cas de panne 
refaire du AC qui rentre dans l’EAS pour etre transformé en, je vous le donne 
en mille, DC.

On fait comme cela sur certains sites qu’on veut full-DC, et sur les Raisecom 
on rajoute une alim DC dans le slot prévu à cet effet.

mM
> On 13 Jun 2021, at 18:45, Steeve BEAUVAIS - Société Serinya Telecom 
>  wrote:
>
> J'ai vu sur une conf Orange qu'ils utilisaient le VLAN 4092 pour manager.
>
> Cordialement,
>
> Steeve Beauvais
>
> Le dim. 13 juin 2021 à 01:59, Romain BAFFERT  a
> écrit :
>
>> Ça se défend ! Et du coup, ces EAS sont sûrement managés par orange, il y
>> aurait donc un vlan qui traîne dans un coin ?
>> Le 13 juin 2021 à 06:11 +0700, Steeve BEAUVAIS - Société Serinya Telecom <
>> steeve.beauv...@serinyatelecom.fr>, a écrit :
>>
>> Salut,
>>
>> En effet, avec ou sans EAS rien ne change sur la conf du CPE.
>>
>> Pour ma part, je fais livrer mes CEE et CELAN cuivre sans EAS. Par contre,
>> les optiques je les fais avec EAS uniquement pour délimiter clairement le
>> périmètre notamment sur l'allumage. Je préfère laisser la responsabilité de
>> l'allumage (donc le module SFP) à Orange et me livrer le service sur une
>> interface RJ45.
>>
>> Et comme le dit David c'est gratuit :)
>>
>> Cordialement,
>>
>> Steeve Beauvais
>>
>> Le sam. 12 juin 2021 à 13:59, David Ponzone  a
>> écrit :
>>
>>
>> Le 12 juin 2021 à 11:10, Charles ENEL-REHEL 
>>
>> a écrit :
>>
>>
>> Au demeurant, ORANGE est (à ma connaissance) le seul opérateur de gros à
>> proposer de la collecte Ethernet / FttO sans obliger un NTE. Franchement
>> appréciable. Chez tous les autres, tu te tapes obligatoirement la mise en
>> oeuvre d'un NTE chez ton client, tantôt RAD, tantôt ADVA, tantôt CIENA,
>>
>> ...
>>
>> selon l'opérateur.
>>
>>
>> Ou encore Raisecom.
>> Ou le pire: un simple switch Huawei 24 ports chez SFR/CLink….
>>
>> Bref, moi je suis partagé: en CELAN cuivre pas de RAD, mais en CELAN
>> optique, j’ai pas encore vu d’intérêt puisqu’il est gratuit.
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7C6973216fd9ef4db08d6f08d92e8e707c%7C84df9e7fe9f640afb435%7C1%7C0%7C637592011566361570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=EmdlMx%2FPHJwCre8jkJpZzkMIZap1aJFvHizTBQEiP4k%3Dreserved=0
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7C6973216fd9ef4db08d6f08d92e8e707c%7C84df9e7fe9f640afb435%7C1%7C0%7C637592011566361570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=EmdlMx%2FPHJwCre8jkJpZzkMIZap1aJFvHizTBQEiP4k%3Dreserved=0
>>
>>
>
> ---
> Liste de diffusion du FRnOG
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7C6973216fd9ef4db08d6f08d92e8e707c%7C84df9e7fe9f640afb435%7C1%7C0%7C637592011566361570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=EmdlMx%2FPHJwCre8jkJpZzkMIZap1aJFvHizTBQEiP4k%3Dreserved=0


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

[FRnOG] [TECH] RAD ou pas RAD sur CELAN Orange ?

[Sébastien 65]

Hello,

Sur vos liaisons en fibre CELAN Orange, installez-vous le RAD ?

J'ai l'impression qu'il est possible de ne pas l'installer et de brancher la 
fibre directement sur notre équipement ?

Je n'arrive pas à savoir s'il faut appliquer une QoS quelconque avec Tag du 
numéro de VLAN déclaré sur la porte en sortie de cette liaison pour que cela 
fonctionne.

J'utilise des CPE CISCO, l'idée est de n'avoir qu'un seul équipement de 
terminaison. Surtout de pouvoir gérer l'urgence si le RAD tombe en panne... 
Plus simple de remplacer notre CPE encore plus rapidement qu'un remplacement 
RAD Orange par leurs tech.

Vos avis sur la question et votre feedback sont les bienvenus :)

Bon week-end !

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

RE: [FRnOG] [BIZ] Boitier SIP flash

[Sébastien 65]

Merci à tous pour les retours !

Je n'ai pas envie de bricoler ou d'utiliser de l'ATA même si ça peut répondre 
au final... J'ai vraiment besoin d'un truc simple.

D'après vos réponses je n'ai pas trop le choix !! Rapide simple et efficace => 
ALGO (vraiment ultra cher pour ce type de produit)

Sébastien

De : frnog-requ...@frnog.org  de la part de Mickael 
MONSIEUR 
Envoyé : mardi 8 juin 2021 17:28
À : Richard Klein 
Cc : Stéphane Rivière ; FRench Network Operators Group 

Objet : Re: [FRnOG] [BIZ] Boitier SIP flash

Le mar. 8 juin 2021 à 15:04, Richard Klein  a écrit :
>
> Bonjour,
>
> Prendre un boîtier ATA et concevoir sur la RJ11 un circuits de détection de
> sonnerie
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fsearch%3Fq%3Dpstn%2Bring%2Bvoltage%2Bdetector%2Bschematic%26oq%3Dpstn%2Bring%2Bvoltage%2Bdetector%2Bschematic%26aqs%3Dchrome..69i57.1278j0j4%26client%3Dms-android-oneplus-rvo3%26sourceid%3Dchrome-mobile%26ie%3DUTF-8data=04%7C01%7C%7Cf02972ff060c4942e7c908d92a922c5a%7C84df9e7fe9f640afb435%7C1%7C0%7C637587629568224560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=T5Ai8W03U3%2By1Vu5zordmoAayCmNuLSR9rLfNOAck7Q%3Dreserved=0
> Ajouter le boîtier ATA dans un ring group en plus des postes qui devront
> sonner .
> Et voilà
> Richard

J'utilise un convertisseur SIP ATA avec ceci:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.velleman.eu%2Fproducts%2Fview%2F%3Fid%3D371944data=04%7C01%7C%7Cf02972ff060c4942e7c908d92a922c5a%7C84df9e7fe9f640afb435%7C1%7C0%7C637587629568224560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RQRonVkzX9uD5NatuAHexm1l7Sy4KhYzb7W%2FsFZq9Xw%3Dreserved=0

>
> Le mar. 8 juin 2021 à 14:45, Stéphane Rivière  a écrit :
>
> > Le 08/06/2021 à 14:33, Rémy Vallereau a écrit :
> > > Bonjour,
> > >
> > > Il me semble que Stentofon peut ajouter une lumière/flash aux
> > > interphones/bornes d'appel.
> >
> > Sinon, prendre un tel SIP à "2 balles" chez alibaba et monter une chtite
> > interface branchée sur le HP ou la led témoin... Genre une diode et un
> > ptit condo pour intégrer, un ampli en comparateur pour déclencher et un
> > transibule de puissance pour coller le relais qui allume la loupiote !
> >
> > Perso, je pense pas que ça vaille le coup, mais le tout emballé dans une
> > boite de dérivation, ça peut être le projet d'une journée de week-end :)
> >
> > Surtout si t’arrive à facturer le truc très cher ! Car même à 50% des
> > ALGO, ça restera lucratif :>> N'oublies pas mes 10% pour l'idée !
> >
> > --
> > Be Seeing You
> > Number Six
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7Cf02972ff060c4942e7c908d92a922c5a%7C84df9e7fe9f640afb435%7C1%7C0%7C637587629568224560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vYVrn6%2B7S70QdH%2BdSTYlU8%2BttM5k3YwYTXI0ubySFME%3Dreserved=0
> >
>
> ---
> Liste de diffusion du FRnOG
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7Cf02972ff060c4942e7c908d92a922c5a%7C84df9e7fe9f640afb435%7C1%7C0%7C637587629568224560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vYVrn6%2B7S70QdH%2BdSTYlU8%2BttM5k3YwYTXI0ubySFME%3Dreserved=0


---
Liste de diffusion du FRnOG
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7Cf02972ff060c4942e7c908d92a922c5a%7C84df9e7fe9f640afb435%7C1%7C0%7C637587629568224560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vYVrn6%2B7S70QdH%2BdSTYlU8%2BttM5k3YwYTXI0ubySFME%3Dreserved=0

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

[FRnOG] [BIZ] Boitier SIP flash

[Sébastien 65]

Bonjour,

Un peu hors sujet mais... Branché sur un switch avec le protocole IP + SIP 
toussa toussa

Je suis à la recherche d'un voyant d'avertissement SIP qui flash lorsqu'un 
appel arrive.
Un produit basique fixé sur un mur et que l'on branche sur le réseau en lui 
configurant un compte SIP tous simplement !
Utile par exemple en atelier lorsque la sonnerie du téléphone n'est pas audible 
à cause du bruit des machines...

Je connais la gamme ALGO 8128, mais c'est vraiment hors de prix...

Quelqu'un peut-il m'aiguiller vers un autre produit ?

Merci

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

[TECH] Re : [FRnOG] [TECH] DDoS sur ZAYO ce matin ?

[Sébastien 65]

D'accord merci Samuel pour la confirmation !

À voir maintenant s'il y aura une communication de notre transitaire sur ce 
point...


De : Samuel Gaiani-Porquet 
Envoyé : jeudi 3 juin 2021 19:12
À : frnog@frnog.org ; Sébastien 65 ; 
frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] DDoS sur ZAYO ce matin ?

Hello,

Je confirme qu'on a relevé des perturbations suspectent sur ces horaires ce 
matin (impossibilité de communiquer avec certains services de Microsoft) , du 
même type qu'il y a quelques jours où ils s'étaient visiblement déjà pris un 
gros ddos.

J'ai ouïe dire qu'ils prévoyaient une maintenance à terme pour se prémunir plus 
efficacement

A suivre

Le 3 juin 2021 17:39:32 GMT+02:00, "Sébastien 65"  a 
écrit :

Bonjour,

Avez-vous constaté ce matin (de 8h30 à 9h20) un problème sur le transitaire 
ZAYO pour ceux qui l'utilise ?
J'ai cru comprendre à une attaque DDoS, je n'ai pas plus d'info ni 
communication de la part de notre transitaire utilisant ZAYO...

Bonne soirée 

Sébastien

Liste de diffusion du FRnOG
http://www.frnog.org/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F=04%7C01%7C%7C57847795840a4162db8608d926b2d5a4%7C84df9e7fe9f640afb435%7C1%7C0%7C637583371786887803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=fdW7MUEJxEUs8a%2BEurskrZk0z4ea2PIiuHeh65%2B6gfs%3D=0>

--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

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

[FRnOG] [TECH] DDoS sur ZAYO ce matin ?

[Sébastien 65]

Bonjour,

Avez-vous constaté ce matin (de 8h30 à 9h20) un problème sur le transitaire 
ZAYO pour ceux qui l'utilise ?
J'ai cru comprendre à une attaque DDoS, je n'ai pas plus d'info ni 
communication de la part de notre transitaire utilisant ZAYO...

Bonne soirée 

Sébastien

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

[FRnOG] [TECH] Re : Limitation du nombre port sur 3750X-24 avec carte NM-10G ??

[Sébastien 65]

Enlever no negociation auto sur l'équipement en face... pas de limitation sur 
le nombre de ports d'un 24S, uniquement celle liée à la combinaison 
simultanément des ports 1Gb et 10Gb de la carte NM.

Désolé pour le bruit de fond !

De : frnog-requ...@frnog.org  de la part de Sébastien 
65 
Envoyé : lundi 12 avril 2021 19:31
À : frnog-t...@frnog.org 
Objet : [FRnOG] [TECH] Limitation du nombre port sur 3750X-24 avec carte NM-10G 
??

Bonsoir,

J'ai un phénomène ultra bizarre qui me laisse penser à une limitation sur le 
nombre de ports 1Gb utilisable sur un 3750X-24S avec une carte C3KX-NM-10G.

Si je banche quelque chose sur le port G1 de la carte le port ne monte pas, par 
contre sur le port G4 aucun problème. Même constat sur un second switch 
3750X-24 avec une autre carte C3KX-NM-10G !!!

J'ai testé les deux cartes sur un autre switch 3750X-12S et aucun problème avec 
le port G1...

Est-ce qu'il y a une limitation du nombre de port Gb 

Merci .



---
Liste de diffusion du FRnOG
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7C3f13ad58b60f421ca5c908d8fdd8e9c0%7C84df9e7fe9f640afb435%7C1%7C0%7C637538455355821839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6klFTfD9omUYU%2B3dhvim%2BgP1FnLEnMFLoRdLxKrvTGU%3Dreserved=0

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

[FRnOG] [TECH] Limitation du nombre port sur 3750X-24 avec carte NM-10G ??

[Sébastien 65]

Bonsoir,

J'ai un phénomène ultra bizarre qui me laisse penser à une limitation sur le 
nombre de ports 1Gb utilisable sur un 3750X-24S avec une carte C3KX-NM-10G.

Si je banche quelque chose sur le port G1 de la carte le port ne monte pas, par 
contre sur le port G4 aucun problème. Même constat sur un second switch 
3750X-24 avec une autre carte C3KX-NM-10G !!!

J'ai testé les deux cartes sur un autre switch 3750X-12S et aucun problème avec 
le port G1...

Est-ce qu'il y a une limitation du nombre de port Gb 

Merci .



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

[FRnOG] [TECH] Boot super long sur ASR 1002

[Sébastien 65]

Bonjour à tous,

J'ai une paire d'ASR 1002 que je trouve extrêmement long à démarrer (+ de 4 
minutes) !

System image file is 
"bootflash:asr1000rp1-adventerprisek9.03.16.10.S.155-3.S10-ext.b"

Chassis type: ASR1002

Slot  TypeState Insert time (ago)
- --- - -
0 ASR1002-SIP10   ok00:12:05
 0/0  4XGE-BUILT-IN   ok00:07:44
 0/1  SPA-8X1GE-V2ok00:07:44
R0ASR1002-RP1 ok, active00:12:05
F0ASR1000-ESP10   ok, active00:12:05
P0ASR1002-PWR-AC  ok00:09:43
P1ASR1002-PWR-AC  ps, fail  00:09:43

Slot  CPLD VersionFirmware Version
- --- ---
0 0712020216.3(2r)
R00801101716.3(2r)
F00709140116.3(2r)


J'ai également deux messages qui me font penser que cela n'est pas normal, mais 
je n'arrive pas à en déterminer la cause :

Image validated
==> %IOSXEBOOT-4-BOOT_ACTIVITY_LONG_TIME: (rp/0): tdl_boot_time_resolve took: 
107 seconds, expected max time 30 seconds
Mar 29 15:28:47.161 R0/0: %PMAN-3-PROC_EMPTY_EXEC_FILE: Empty executable used 
for process vman

*Mar 29 15:30:09.549: %SPA_OIR-6-ONLINECARD: SPA (4XGE-BUILT-IN) online in 
subslot 0/0
*Mar 29 15:30:11.052: %SPA_OIR-6-ONLINECARD: SPA (SPA-8X1GE-V2) online in 
subslot 0/1
==> *Mar 29 15:30:12.867: %SYS-6-BOOTTIME: Time taken to reboot after reload =  
405 seconds

Êtes-vous dans le même cas que moi ??

Merci !

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

RE: [FRnOG] [TECH] Supervision latence et traceroute tout en un

[Sébastien 65]

Oui ce n'est pas libre mais exactement ce que je cherche 

Par contre le prix woua ça pique !!! En plus Solarwinds en ce moment n'est pas 
en pleine forme... Sunburst !!!

De : frnog-requ...@frnog.org  de la part de Denis 
Fondras 
Envoyé : vendredi 12 mars 2021 08:43
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Supervision latence et traceroute tout en un

Le Fri, Mar 12, 2021 at 07:06:20AM +, Sébastien 65 a écrit :
> Bonjour à tous,
>
> Existe-t-il un outil avec une interface web permettant de visualiser la 
> latence et le chemin emprunté pour joindre une destination ?
>
> Je cherche une interface capable de me donner la variation sur la latence 
> ainsi que le changement de chemin.
>
> J'utilise SmokePing mais je n'ai pas l'historique du chemin utilisé (style 
> traceroute).
>
> Une idée d'un produit si possible open-source ?
>

Sapuspalibre :
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.solarwinds.com%2Ffr%2Fnetwork-performance-monitor%2Fuse-cases%2Fnetpathdata=04%7C01%7C%7Cc462d6d8765a46894b5c08d8e52aa7c0%7C84df9e7fe9f640afb435%7C1%7C0%7C637511318646510668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=dpx7wYftx%2FqVVIPpGojUWlEFYxofQ1uG4Uv%2B3hTrUMw%3Dreserved=0

Mais ca fonctionne bien :po


---
Liste de diffusion du FRnOG
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7Cc462d6d8765a46894b5c08d8e52aa7c0%7C84df9e7fe9f640afb435%7C1%7C0%7C637511318646510668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oqpZ8PKW7x01InGYXomONEA%2FmHWeFo2LngA3qqFXQ%2FA%3Dreserved=0

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

RE: [FRnOG] [TECH] Supervision latence et traceroute tout en un

[Sébastien 65]

Bonjour Fabien,

A ma connaissance, il n'y a pas d'interface web pour MTR permettant de 
consulter l'historisation des résultats ?

J'ai besoin par exemple de pouvoir revenir en arrière sur une période donnée 
afin de voir la latence (vérif si dégradation ou pas) ainsi que de pouvoir 
croiser avec le chemin emprunté.



De : Fabien H 
Envoyé : vendredi 12 mars 2021 08:11
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Supervision latence et traceroute tout en un

Bonjour Sebastien,

mtr sous linux !

Ou éventuellement WinMTR sous Windows

Le ven. 12 mars 2021 à 08:08, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :
Bonjour à tous,

Existe-t-il un outil avec une interface web permettant de visualiser la latence 
et le chemin emprunté pour joindre une destination ?

Je cherche une interface capable de me donner la variation sur la latence ainsi 
que le changement de chemin.

J'utilise SmokePing mais je n'ai pas l'historique du chemin utilisé (style 
traceroute).

Une idée d'un produit si possible open-source ?

Bonne journée !

---
Liste de diffusion du FRnOG
http://www.frnog.org/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F=04%7C01%7C%7C637b87bf2bf743dab07008d8e52616d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637511299033607239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=K0vnb9mMu4U33R%2BqsDp4gGDLGHG91EVXBuaSyWNdOhc%3D=0>

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

[FRnOG] [TECH] Supervision latence et traceroute tout en un

[Sébastien 65]

Bonjour à tous,

Existe-t-il un outil avec une interface web permettant de visualiser la latence 
et le chemin emprunté pour joindre une destination ?

Je cherche une interface capable de me donner la variation sur la latence ainsi 
que le changement de chemin.

J'utilise SmokePing mais je n'ai pas l'historique du chemin utilisé (style 
traceroute).

Une idée d'un produit si possible open-source ?

Bonne journée !

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

[TECH] Re : [FRnOG][TECH] Soft pour gestion câblage

[Sébastien 65]

Merci à tous :)

Pour le moment toutes les réponses même en Off m'oriente vers Netbox. Je vais 
regarder ça.


De : Pascal Cabaud 
Envoyé : dimanche 7 février 2021 10:46
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Soft pour gestion câblage

Bonjour,

Netbox fait le job facilement tant qu’on ne cherche pas à gérer l’accès.

Il faut créer un device-type par fourreau (genre 36 mono...), mettre des 
rear-points, les connecter aux front-ports. Pour créer un fourreau, instancier 
le câble avec ces device-types dans chaque baie. Il ne reste plus qu’à 
documenter les connexions aux front-ports.

pc

--
Pascal Cabaud

> Le 7 févr. 2021 à 10:21, Sébastien 65  a écrit :
>
> Bonjour à tous,
>
> Est-ce que quelqu'un sait me dire s'il existe un logiciel de gestion de 
> câblage cuivre/fibre ?
>
> Pour le moment j'utilise Excel mais pas super pratique... J'ai besoin 
> d'identifier chaque extrémité+position d'un tiroir d'une armoire X vers Y.
>
> Vous répertoriez vos brassages/mmr avec quoi ?
>
> Merci
>
>
>
> ---
> Liste de diffusion du FRnOG
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7C87ae8e0edd104b33856308d8cb4d2f27%7C84df9e7fe9f640afb435%7C1%7C0%7C637482879641214959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=s3SKAnOZtog5NnhD50gCxUJlrTwc27c3q82rRcloKfQ%3Dreserved=0


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

[FRnOG] [TECH] Soft pour gestion câblage

[Sébastien 65]

Bonjour à tous,

Est-ce que quelqu'un sait me dire s'il existe un logiciel de gestion de câblage 
cuivre/fibre ?

Pour le moment j'utilise Excel mais pas super pratique... J'ai besoin 
d'identifier chaque extrémité+position d'un tiroir d'une armoire X vers Y.

Vous répertoriez vos brassages/mmr avec quoi ?

Merci



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

[FRnOG] [TECH] Sonde température et d'humidité IP (PoE)

[Sébastien 65]

Bonjour,

Je recherche une sonde de température et humidité version IP (avec PoE - pas de 
prise élec sur l'emplacement prévu) pour installer sur un mur d'une salle 
informatique.
La sonde doit être capable de nous envoyer à minima un email avec les valeurs 
lorsqu'un seuil est atteint...
Une interface Web doit être intégrée afin de pouvoir afficher les valeurs de la 
sonde.

Dans mon cas je dois installer deux sondes dans la pièce.

Quesque vous connaissez à un prix descend ? J'ai regardé rapidement, sur le net 
je trouve des sondes à 300€ je trouve cela démesuré !

=>Je connais la version Arduino/Raspberry mais je n'ai absolument pas le temps 
de m'y pencher dessus !

Merci !


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

Re: [FRnOG] [TECH] Appli monitoring switch/routeur Cisco

[Sébastien 65]

Je n'ai aucune idée du débit nécessaire pour un équipement, est-ce que vous 
savez qu'elle est la taille du flux lors d'une requête Snmp de Librenms ?

David quand tu dis tout poller, il n'est pas possible de choisir la ou les 
valeurs sonde à remontrer sans pour autant charger toute la lib ?


De : David Ponzone 
Envoyé : lundi 2 novembre 2020 15:58
À : Olivier Lange 
Cc : Sébastien 65 ; Michel Py 
; frnog-t...@frnog.org 

Objet : Re: [FRnOG] [TECH] Appli monitoring switch/routeur Cisco

Perso, un peu ras le bol de LibreNMS, sa mauvaise habitude de tout poller et 
ses upgrades foireux, donc j’ai commencé à jouer avec CheckMK et j’aime bien.

> Le 2 nov. 2020 à 15:55, Olivier Lange  a écrit :
>
> Salut,
>
> Pas utilisé sur du Catalayst (enfin, peut être mais pas sur...). Mais on
> l'avait mis sur de l'arista et du Cisco, et je l'utilise au quotidien sur
> du Mikrotik, et ca fait bien le travail. C'est propre, clean, et pas mal
> d'informations. Et ca te reviendra moins cher que les solutions full Cisco.
> Arès, dès le moment ou tes switchs sont capable de faire du SNMP, tu va
> pouvoir récupérer les informations.
>
> Olivier
>
> ---
> Liste de diffusion du FRnOG
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7C72beed2c4a59418d173308d87f3fc284%7C84df9e7fe9f640afb435%7C1%7C0%7C637399259099428154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=75zuwfYcLrB00XZQ5VBGOz4lqU4rSICRL2vT3D6nX%2FQ%3Dreserved=0

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

RE: [FRnOG] [TECH] Appli monitoring switch/routeur Cisco

[Sébastien 65]

Bonjour à tous,

Merci pour les premiers retours  !

@Michel Py<mailto:mic...@arneill-py.sacramento.ca.us>
>T'as besoin de quelque chose de beau à montrer aux huiles ?
Déjà on va commencer par nous les techs !

>Ah bon ? dans quel sens ? Je trouve que c'est pas trop pire.
Déjà je trouve qu'il y a trop de menu et de catégorie, c'est pas super 
intuitif/fluide de se repérer là-dedans...

>J'utilise LibreNMS aussi, je préfère mais avec le matos qui a un control-plane 
>en carton c'est pas toujours idéal.
Le besoin immédiat est de pouvoir intégrer des switchs 3750X facilement. La 
finalité sera également d'y greffer des 2960(S-X) et quelques 3750G...

Puisque tu utilises LibreNMS penses-tu que ça va merdouiller quelque part sur 
ces Catalyst ?

De : Michel Py 
Envoyé : lundi 2 novembre 2020 03:18
À : 'Sébastien 65' ; frnog-t...@frnog.org 

Objet : RE: [FRnOG] [TECH] Appli monitoring switch/routeur Cisco

> Sébastien 65 a écrit :
> Est-ce que quelqu'un utilise Cisco Prime Lan Management ici ? Le dashboard a 
> l'air sympathique :)

T'as besoin de quelque chose de beau à montrer aux huiles ?

> PRTG je le trouve vraiment trop usine à gaz !

Ah bon ? dans quel sens ? Je trouve que c'est pas trop pire. J'utilise LibreNMS 
aussi, je préfère mais avec le matos qui a un control-plane en carton c'est pas 
toujours idéal.

Michel.


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

[FRnOG] [TECH] Appli monitoring switch/routeur Cisco

[Sébastien 65]

Bonjour,

Est-ce que quelqu'un utilise Cisco Prime Lan Management ici ? Le dashboard a 
l'air sympathique :)

Je cherche une appli permettant d'avoir un dashboard type NOC avec la création 
de l'infra/lien entre les équipements afin de visualiser la topology du réseau 
(Snmp).

Avec des fonctions de type alarme/warning et de jolis graphiques sur le trafic 
et état d'occupation des différentes liaisons.

Appli à installer localement, soit en mode interface Web soit via un client 
sous Windows...

PRTG je le trouve vraiment trop usine à gaz !

Vous me renverez vers quelle solution ?

Merci



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

Re: [FRnOG] [TECH] ipv6 prefix-list avec route-map

[Sébastien 65]

Je connais Cymru, je l'avais mis en place il y a longtemps sur Quagga...

C'est pas plus mal non plus d'avoir une prefix-list que l'on maîtrise et sur 
laquelle il est facile d'agir :)



De : Michel Py 
Envoyé : lundi 26 octobre 2020 19:14
À : Sébastien 65 ; frnog-t...@frnog.org 

Objet : RE: [FRnOG] [TECH] ipv6 prefix-list avec route-map

> Sébastien 65 a écrit :
> En voulant actualiser ma prefix-list des Bogons IPV6 sur mes transits,

Pourquoi tu n'utilises pas le feed full-bogons de Team Cymru ?
https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/

Pas la peine de ré-inventer la roue quand quelqu'un se décarcasse déjà avec les 
MAJ.

Michel.

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

RE: [FRnOG] [TECH] ipv6 prefix-list avec route-map

[Sébastien 65]

Oui ça fonctionne, le préfixe 2001:DB8::/32 n'est plus présent :

route-map TRANSIT_ENTRANT_IPV6 deny 10
 description *** DENY routes with invalid AS numbers ***
 match as-path 100
!
route-map TRANSIT_ENTRANT_IPV6 deny 20
 match ipv6 address prefix-list MY-PREFIXE
!
route-map TRANSIT_ENTRANT_IPV6 deny 30
 match ipv6 address prefix-list BOGONS-IPV6
!
route-map TRANSIT_ENTRANT_IPV6 permit 40
 description *** PERMIT routes only for AS TRANSIT ***
 match as-path 10
!

Effectivement... Merci David

De : David Ponzone 
Envoyé : lundi 26 octobre 2020 10:55
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] ipv6 prefix-list avec route-map

Ben oui, avec ça tu autorises tout ce qui vient de 174, donc si les bogon 
viennent de là….
Essaie voir de mettre tous tes deny avant le permit.

Le 26 oct. 2020 à 10:46, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Le permit 20 filtre sur l'AS du Transitaire afin d'obtenir uniquement les 
réseaux provenant de l'AS174 et de tous les AS directement attachés sur 174

ip as-path access-list 10 permit ^174_
ip as-path access-list 10 deny .*

Penses-tu que l'erreur vient de la route-map 20 ?


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : lundi 26 octobre 2020 10:38
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] ipv6 prefix-list avec route-map


Je suis un peu ennuyé par ton permit 20 avant le deny 30.
Tu es sûr que l’as-path 10 ne match pas les routes que tu veux refuser avec 
BOGONS-IPV6 ?

> Le 26 oct. 2020 à 09:58, Sébastien 65 
> mailto:sebastien...@live.fr>> a écrit :
>
> Bonjour,
>
> En voulant actualiser ma prefix-list des Bogons IPV6 sur mes transits, je 
> test d'abord avec deux routeurs en interne, je n'arrive pas à filtrer par 
> exemple 2001:DB8::/32.
>
> Sur R1 j'envoi le préfixe 2001:DB8::/32 à R2.
>
> Sur R2 j'ai la configuration suivante :
>
> ipv6 prefix-list BOGONS-IPV6 description - Filtre Entrant IPV6 -
> ipv6 prefix-list BOGONS-IPV6 seq 5 permit ::/0
> ipv6 prefix-list BOGONS-IPV6 seq 10 permit ::/8 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 15 permit 100::/64 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 20 permit 2001::/32 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 25 permit 2001:2::/48 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 30 permit 2001:3::/32 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 35 permit 2001:10::/28 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 40 permit 2001:20::/28 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 45 permit 2001:DB8::/32 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 50 permit 2002::/16 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 55 permit 3FFE::/16 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 60 permit FC00::/7 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 65 permit FE00::/9 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 70 permit FE80::/10 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 75 permit FEC0::/10 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 80 permit FF00::/8 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 1000 deny ::/0 le 128
>
> route-map TRANSIT_ENTRANT_IPV6 deny 10
> description *** DENY routes with invalid AS numbers ***
> match as-path 100
> !
> route-map TRANSIT_ENTRANT_IPV6 permit 20
> description *** PERMIT routes only for AS TRANSIT ***
> match as-path 10
> !
> route-map TRANSIT_ENTRANT_IPV6 deny 30
> match ipv6 address prefix-list MY-PREFIXE
> !
> route-map TRANSIT_ENTRANT_IPV6 deny 40
> match ipv6 address prefix-list BOGONS-IPV6
> !
>
> La prefix-list doit bien être en PERMIT et la route-map en DENY ?
> J'ai plus ou moins la même chose en IPV4 et je n'ai pas de problème...
>
> Je merde ou ?
>
>
>
> ---
> Liste de diffusion du FRnOG
> https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7C5a67a6a794924b7bf3e208d87992eaa8%7C84df9e7fe9f640afb435%7C1%7C0%7C637393019185127222%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5t2ZEO%2F5bBSjlholZo7g1QttNF6jwrF6Apfkr9YrmXw%3Dreserved=0<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F=04%7C01%7C%7C7954d8d1cf2348515ed408d87995368c%7C84df9e7fe9f640afb435%7C1%7C0%7C637393029050412325%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=YVGqpKdZln1TTpRFDeSkq0aXiGco2dGHse2wkPGOYYU%3D=0>



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

RE: [FRnOG] [TECH] ipv6 prefix-list avec route-map

[Sébastien 65]

Le permit 20 filtre sur l'AS du Transitaire afin d'obtenir uniquement les 
réseaux provenant de l'AS174 et de tous les AS directement attachés sur 174

ip as-path access-list 10 permit ^174_
ip as-path access-list 10 deny .*

Penses-tu que l'erreur vient de la route-map 20 ?


De : David Ponzone 
Envoyé : lundi 26 octobre 2020 10:38
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] ipv6 prefix-list avec route-map


Je suis un peu ennuyé par ton permit 20 avant le deny 30.
Tu es sûr que l’as-path 10 ne match pas les routes que tu veux refuser avec 
BOGONS-IPV6 ?

> Le 26 oct. 2020 à 09:58, Sébastien 65  a écrit :
>
> Bonjour,
>
> En voulant actualiser ma prefix-list des Bogons IPV6 sur mes transits, je 
> test d'abord avec deux routeurs en interne, je n'arrive pas à filtrer par 
> exemple 2001:DB8::/32.
>
> Sur R1 j'envoi le préfixe 2001:DB8::/32 à R2.
>
> Sur R2 j'ai la configuration suivante :
>
> ipv6 prefix-list BOGONS-IPV6 description - Filtre Entrant IPV6 -
> ipv6 prefix-list BOGONS-IPV6 seq 5 permit ::/0
> ipv6 prefix-list BOGONS-IPV6 seq 10 permit ::/8 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 15 permit 100::/64 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 20 permit 2001::/32 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 25 permit 2001:2::/48 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 30 permit 2001:3::/32 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 35 permit 2001:10::/28 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 40 permit 2001:20::/28 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 45 permit 2001:DB8::/32 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 50 permit 2002::/16 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 55 permit 3FFE::/16 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 60 permit FC00::/7 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 65 permit FE00::/9 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 70 permit FE80::/10 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 75 permit FEC0::/10 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 80 permit FF00::/8 le 128
> ipv6 prefix-list BOGONS-IPV6 seq 1000 deny ::/0 le 128
>
> route-map TRANSIT_ENTRANT_IPV6 deny 10
> description *** DENY routes with invalid AS numbers ***
> match as-path 100
> !
> route-map TRANSIT_ENTRANT_IPV6 permit 20
> description *** PERMIT routes only for AS TRANSIT ***
> match as-path 10
> !
> route-map TRANSIT_ENTRANT_IPV6 deny 30
> match ipv6 address prefix-list MY-PREFIXE
> !
> route-map TRANSIT_ENTRANT_IPV6 deny 40
> match ipv6 address prefix-list BOGONS-IPV6
> !
>
> La prefix-list doit bien être en PERMIT et la route-map en DENY ?
> J'ai plus ou moins la même chose en IPV4 et je n'ai pas de problème...
>
> Je merde ou ?
>
>
>
> ---
> Liste de diffusion du FRnOG
> https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7C5a67a6a794924b7bf3e208d87992eaa8%7C84df9e7fe9f640afb435%7C1%7C0%7C637393019185127222%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5t2ZEO%2F5bBSjlholZo7g1QttNF6jwrF6Apfkr9YrmXw%3Dreserved=0


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

[FRnOG] [TECH] ipv6 prefix-list avec route-map

[Sébastien 65]

Bonjour,

En voulant actualiser ma prefix-list des Bogons IPV6 sur mes transits, je test 
d'abord avec deux routeurs en interne, je n'arrive pas à filtrer par exemple 
2001:DB8::/32.

Sur R1 j'envoi le préfixe 2001:DB8::/32 à R2.

Sur R2 j'ai la configuration suivante :

ipv6 prefix-list BOGONS-IPV6 description - Filtre Entrant IPV6 -
ipv6 prefix-list BOGONS-IPV6 seq 5 permit ::/0
ipv6 prefix-list BOGONS-IPV6 seq 10 permit ::/8 le 128
ipv6 prefix-list BOGONS-IPV6 seq 15 permit 100::/64 le 128
ipv6 prefix-list BOGONS-IPV6 seq 20 permit 2001::/32 le 128
ipv6 prefix-list BOGONS-IPV6 seq 25 permit 2001:2::/48 le 128
ipv6 prefix-list BOGONS-IPV6 seq 30 permit 2001:3::/32 le 128
ipv6 prefix-list BOGONS-IPV6 seq 35 permit 2001:10::/28 le 128
ipv6 prefix-list BOGONS-IPV6 seq 40 permit 2001:20::/28 le 128
ipv6 prefix-list BOGONS-IPV6 seq 45 permit 2001:DB8::/32 le 128
ipv6 prefix-list BOGONS-IPV6 seq 50 permit 2002::/16 le 128
ipv6 prefix-list BOGONS-IPV6 seq 55 permit 3FFE::/16 le 128
ipv6 prefix-list BOGONS-IPV6 seq 60 permit FC00::/7 le 128
ipv6 prefix-list BOGONS-IPV6 seq 65 permit FE00::/9 le 128
ipv6 prefix-list BOGONS-IPV6 seq 70 permit FE80::/10 le 128
ipv6 prefix-list BOGONS-IPV6 seq 75 permit FEC0::/10 le 128
ipv6 prefix-list BOGONS-IPV6 seq 80 permit FF00::/8 le 128
ipv6 prefix-list BOGONS-IPV6 seq 1000 deny ::/0 le 128

route-map TRANSIT_ENTRANT_IPV6 deny 10
 description *** DENY routes with invalid AS numbers ***
 match as-path 100
!
route-map TRANSIT_ENTRANT_IPV6 permit 20
 description *** PERMIT routes only for AS TRANSIT ***
 match as-path 10
!
route-map TRANSIT_ENTRANT_IPV6 deny 30
 match ipv6 address prefix-list MY-PREFIXE
!
route-map TRANSIT_ENTRANT_IPV6 deny 40
 match ipv6 address prefix-list BOGONS-IPV6
!

La prefix-list doit bien être en PERMIT et la route-map en DENY ?
J'ai plus ou moins la même chose en IPV4 et je n'ai pas de problème...

Je merde ou ?



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

RE: [FRnOG] [TECH] Amateur de RF pour meilleur rapport signal/bruit (SNR) ?

[Sébastien 65]

>Tu n'as donc pas testé par toi-même.
Bien sûr que si !! J'ai à minima 4 AF avec ça 

Cela me fait penser que je peux faire un test d'enlever les RFArmor sur un 
couple d'AF afin de voir si le comportement est +/- identique !

>As-tu testé la terre radio ...
Heu non ! Peux-tu STP m'expliquer comment on fait cela ?


De : Stéphane Rivière 
Envoyé : dimanche 6 septembre 2020 19:31
À : Sébastien 65 ; frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Amateur de RF pour meilleur rapport signal/bruit 
(SNR) ?


>>Ce blindage additionnel a t-il déjà montré son efficacité sur d'autres 
>>liaisons ?
> RFArmor en écoule des milliers, donc je présume que cela doit être très
> efficace ! J'avais échangé avec un WISP qui m'indiquait ne plus monter
> un équipement sans cela !!

Tu n'as donc pas testé par toi-même.

>>Instinctivement, un blindage à l'arrache, ça peut te ramener un max de bruit, 
>>donc une perte de débit.
> Oui, mais je ne m'explique pas trop le truc car pas compliqué quand même
> d'installer un morceau d'alu au cul de l'électronique...

Oui, alors, ça, j'aurais des tonnes d'anecdotes de truc "pas compliqués"
en blindages et accrochages (couplages indésirables) HF finalement ultra
tordus...

Peut-être c'est un défaut de blindage ou de serrage d'un câble ou d'une
sma... qui transforme ce "blindage" en perturbateur... As-tu testé la
terre radio (est-elle vraiment à la terre, quelle est sa résistance, le
bruit peut venir aussi de la terre, même si tu as spécifié que ça ne
change rien connectée ou pas - ce qui est louche en soit).

>>Par rapport au bilan de liaison, 103 Mbps est :
> Très bien, débit attendu pour cette longueur de liaison radio.

Mon opinion, et les shadoks (ou gibis) approuveraient : s'il n'y a pas
de problème, c'est qu'il n'y a pas de question.

Laisse le matos tel qu'il est d'origine puisqu'il fait le job aux perfs
attendues.


* Généralités

L'alu étant ce qu'il est, les fréquences en question étaient ce qu'elles
sont... On est pas dans des fréquences ordinaires (au sens simples à
blinder). On est à un niveau qu'on appelle chez nous de "la plomberie".
Généralement, si on mets de l'alu, c'est soit qu'il y a de l'épaisseur
pour la rigidité mécanique... soit qu'il y a beaucoup de vis ou de
soudures pour l'étanchéité radioélectrique (équipotentialité).

Il est aussi possible que la boite en alu réalise un couplage entre
plusieurs parties internes de l'ubiquiti, juste séparées par une paroi
et non pas un blindage intégral ou un couplage entre deux lignes
d'accord internes réalisées directement sur le circuit, etc... là je
donne des exemples, pas plus.

Si tu veux, à ce niveau industriel et à ces fréquences, ubiquiti (ce ne
sont pas des cloches mais forcément de bons kadors) vont faire ce qu'il
faut, et ils vont aussi certifier leur compatibilité électromagnétique
et pas question de sortir 5000 bestioles de l'usine avec un défaut au
niveau HF qui va faire sortir la FCC de ses gonds et envoyer le tout à
la poubelle avec une amende à faire peur aux chiens.

C'est mon opinion de base, sans avoir fait de mesures sur la bête, ni
avoir regardé l'agencement interne ni constaté la qualité de blindage
interne. Ce sont juste des indications.

Ces fréquences, c'est pas de la cibi (11m de longueur d'onde soit 2,75m
de quart d'onde), c'est un truc (je suppose en 5.8, j'utilise pas les
air-fiber) d'environ 5cm de longueur d'onde. Tout ce qui va faire plus
d'un quart d'onde (12mm et quelques) est une porte ouverte, un couplage
possible, un ennui potentiel... Et il y a une multitude de fréquences
intermédiaires dans ta bestiole. Un petit trou dans un blindage est une
fuite HF

L'énergie HF étant concentrée sur une distance très courte à ces
fréquences, on est sur des champs où le moindre détail compte _et_ des
blindages _très calculés_ question fabrication. Ca peut être de l'alu,
du cuivre, de l'argent (du cuivre argenté, l'effet de surface fait le
reste). Deplus ces circuits n'étant jamais isolé, les fils entrent et
sortent, il faut découpler ces signaux aussi.


Si un jour t'as la fin de l'histoire, je suis preneur :)

--
Be Seeing You
Number Six


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

RE: [FRnOG] [TECH] Amateur de RF pour meilleur rapport signal/bruit (SNR) ?

[Sébastien 65]

>Ces bidules ne seraient-ils pas déjà blindés d'origine par une couche 
>demétallisation sur la façe intérieure ? T'en a démonté un pour voir ?
C'est un capotage en alu, voici le lien du produit avec la description sur la 
matière utilisée : https://rfarmor.com/uds5g30-s45.html
[https://rfarmor.com/media/catalog/product/cache/68157f00e79998ce616a550d05fa16d5/u/d/uds5g30-s45.png]
UDS5G30-S45
Fits the following Ubiquiti antennas:AF-5G30-S45RD-5G30-LWAF-2G24-S45Works with 
the following radios:Rocket M5 / M2Rocket Titanium M5 / M2Rocket AC LiteRocket 
AC airPRISIMairFIBER 2/5 X Made from powder coated white aluminum and install 
in minutes.NOTE: Radio/Antenna NOT included.
rfarmor.com
>Ce blindage additionnel a t-il déjà montré son efficacité sur d'autres 
>liaisons ?
RFArmor en écoule des milliers, donc je présume que cela doit être très 
efficace ! J'avais échangé avec un WISP qui m'indiquait ne plus monter un 
équipement sans cela !!

>Instinctivement, un blindage à l'arrache, ça peut te ramener un max de bruit, 
>donc une perte de débit.
Oui, mais je ne m'explique pas trop le truc car pas compliqué quand même 
d'installer un morceau d'alu au cul de l'électronique...

>Par rapport au bilan de liaison, 103 Mbps est :
Très bien, débit attendu pour cette longueur de liaison radio.


De : frnog-requ...@frnog.org  de la part de Stéphane 
Rivière 
Envoyé : dimanche 6 septembre 2020 13:34
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Amateur de RF pour meilleur rapport signal/bruit 
(SNR) ?

> Qui est calé sur cette partie pour m'aider à comprendre le phénomène ?

Ces bidules ne seraient-ils pas déjà blindés d'origine par une couche de
métallisation sur la façe intérieure ? T'en a démonté un pour voir ?

Ce blindage additionnel a t-il déjà montré son efficacité sur d'autres
liaisons ?

Instinctivement, un blindage à l'arrache, ça peut te ramener un max de
bruit, donc une perte de débit.

> En effet dès lors que j'installe le système anti RF le débit s'écroule sur 
> mes équipements (Je passe de 103Mb à 64Mb).

Par rapport au bilan de liaison, 103 Mbps est :
- dans la moyenne attendue
- plutôt mauvais ?


--
Be Seeing You
Number Six


---
Liste de diffusion du FRnOG
https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7Cfbe93889434d42206ab608d85258db7f%7C84df9e7fe9f640afb435%7C1%7C0%7C63734985212183sdata=5W%2FIStIZZQoGMqvlkbBujHdalsJHkx1OLDz4rxfNZWo%3Dreserved=0

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

[FRnOG] [TECH] Amateur de RF pour meilleur rapport signal/bruit (SNR) ?

[Sébastien 65]

Bonjour la liste,

Je fais face à un gros problème que je ne m'explique pas sur l'utilisation d'un 
blindage radio sur du matériel AirFiber 5 XHD.

Qui est calé sur cette partie pour m'aider à comprendre le phénomène ?

En effet dès lors que j'installe le système anti RF le débit s'écroule sur mes 
équipements (Je passe de 103Mb à 64Mb).
Le système anti RF (kits RFArmor) permet de réduire le bruit de fond en 
fournissant un signal plus propre permettant d’avoir un débit plus élevé et 
plus stable - ici c'est tout le contraire !!!

J'ai vérifié aussi du côté de la masse, bien connecté sur les AF. Même en 
déconnectant la masse cela reste identique...

Voici le lien d'un test de débit entre deux équipements lorsque on 
enlève/installe le RFArmor : https://i.ibb.co/jg4tfWy/dav.jpg
[https://i.ibb.co/jg4tfWy/dav.jpg]

Est-ce que parmi vous il y a des personnes qui utilisent des RFArmor sur de 
l'Ubiquiti ?

Sébastien


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

[FRnOG] [BIZ] RE: Recherche consultant expert Ubiquiti

[Sébastien 65]

Bonjour à tous,

Merci pour tous vos retours en PV. Désolé de ne pas avoir pris le temps de 
répondre plus rapidement à vos questions.

La question principale concerne l'utilisation de AirLINK avec l'outil 
d'alignement des AF5-XHD. Je n'arrive pas à comprendre les valeurs de AirLINK 
rapportées aux valeurs d'alignements des AF

Je suis contraint d'utiliser une méthode fastidieuse (boussole/GPS/réglage 
approximatif) pour accrocher un signal pour ensuite affiner le pointage. Donc 
je suis perplexe sur l'usage de l'outil/valeur AirLINK (?) !
L'outil d'ALIGNEMENT des AF5-XHD n'est pas non plus très clair à mon goût...

Je me demande si le TILT AirLINK ne devrait pas correspondre à ANTENNA 
ELEVATION du AF5 et non pas à ANTENNA TILT. Une inversion des libellés ??? 
C'est quoi la vraie correspondance ???

Par exemple AirLINK indique les valeurs suivantes Heading / Tilt pour une 
distance de 16Km entre les deux AF :
Point bas : 214° / 0.55°
Point haut : 34° / -0.69°

Voici le lien de la comparaison/alignement des AF qui ne correspond absolument 
pas aux valeurs AirLINK !!!

https://i.ibb.co/ByyCTR1/AF5.png
[https://i.ibb.co/ByyCTR1/AF5.png]
Sébastien


De : Sébastien 65
Envoyé : mercredi 2 septembre 2020 17:04
À : frnog-...@frnog.org 
Objet : Recherche consultant expert Ubiquiti

Bonjour la liste,

Je recherche un consultant expert UBIQUITI (AirMax/AirFiber).

Est-ce qu'il y a quelqu'un dans la liste ou une personne que vous conseilleriez 
?

Plus d'info sur le besoin en PV.

Merci

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

[FRnOG] [BIZ] Recherche consultant expert Ubiquiti

[Sébastien 65]

Bonjour la liste,

Je recherche un consultant expert UBIQUITI (AirMax/AirFiber).

Est-ce qu'il y a quelqu'un dans la liste ou une personne que vous conseilleriez 
?

Plus d'info sur le besoin en PV.

Merci

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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Bonjour,

>Si on peut passer les ports du switch en L3, je ne vois pas ou il y aurait un 
>PB
Sauf erreur de ma part, il n'est pas possible de passer un port en L3 (no 
switchport) car les fonctions dot1q-tunnel ne seront pas possible...



De : frnog-requ...@frnog.org  de la part de L-C FABRE 

Envoyé : lundi 17 août 2020 16:39
À : Vincent Bernat 
Cc : Michel Py ; frnog 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

Yo,
j’arrive après la guerre mais 3 semaines sans Net c’étais juste trop bon pour 
que je l’interrompe :-)

Je précise que je suis ignare en Cisco et que c’est visiblement un sujet 
Cisco-ish.
Comme j’ai vu passer une réponse à base de Mikrotik, je me permets ce mail.

Si on peut passer les ports du switch en L3, je ne vois pas ou il y aurait un PB
Genre « no switchport » et après on injecte le trafic à partir de là
Connecter deux ports de « routeur » ça ne pose pas de PB (mais je ne connais 
pas le 3750)

En outre, sur ce que j’utilise (Huawei CE) je confirme que les mac sont 
associés par VLan, VRF, VPN, VxLan.

Pour ma culture, qu’elle serait la façon académique de le faire chez Cisco ?

Et pour mon plaisir, où trouve t'on le générateur de signature K :-)

> Le 15 août 2020 à 09:40, Vincent Bernat  a écrit :
>
> ❦ 15 août 2020 07:13 +00, Michel Py:
>
>>> Je pointais juste le fait que l'explication de comment la CAM fonctionne 
>>> n'est pas bonne depuis 20 ans.
>>
>> Excellente remarque, j'avais en effet pris quelques raccourcis dans 
>> l'histoire.
>>
>>> Perso, jamais fait de Q-in-Q
>>
>> As-tu déjà mis un câble en boucle entre 2 ports sur le même switch?
>
> Oui (entre deux VRF dans mon cas). Je ne vois pas le rapport avec les
> carottes. Je réitère donc : je souligne juste que ton explication était
> fausse (depuis 20 ans). Comme c'était a priori la seule base
> scientifique pour expliquer pourquoi c'est une mauvaise idée, j'ai fait
> la remarque. Je n'y connais rien en Q-in-Q et donc je n'ai pas d'avis
> sur le fait que ce soit ou non une bonne idée dans le cas présenté.
> --
> Write clearly - don't be too clever.
>- The Elements of Programming Style (Kernighan & Plauger)
>
>
> ---
> 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] Q-in-Q Cisco sur CELAN

[Sébastien 65]

David,

Je ne suis pas sur de comprendre le fait de rajouter un 3750 ?

De : David Ponzone 
Envoyé : vendredi 14 août 2020 10:47
À : Sébastien 65 
Cc : Radu-Adrian Feurdean ; frnog@frnog.org 

Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

Ajoute un 3x50, t’en as pour 400-500€

David Ponzone



> Le 14 août 2020 à 10:31, Sébastien 65  a écrit :
>
> Bonjour à tous,
>
> J'ai bien pris en compte vos différentes remarques sur le no GO et je vous en 
> remercie ! Je ne vais donc pas jouer avec le feu...
> Même si bon nombre de retour m'indique que cela fonctionne !!!
>
> Je préfère dormir sur mes deux oreilles, je n'ai pas pour habitude de faire 
> de la bricole. Je vais regarder du côté des Nexus si cela peut être fait.

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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Bonjour à tous,

J'ai bien pris en compte vos différentes remarques sur le no GO et je vous en 
remercie ! Je ne vais donc pas jouer avec le feu...
Même si bon nombre de retour m'indique que cela fonctionne !!!

Je préfère dormir sur mes deux oreilles, je n'ai pas pour habitude de faire de 
la bricole. Je vais regarder du côté des Nexus si cela peut être fait.

Donc je repars de zéro et dois replancher sur le sujet...

De : frnog-requ...@frnog.org  de la part de 
Radu-Adrian Feurdean 
Envoyé : vendredi 14 août 2020 10:01
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

On Fri, Aug 14, 2020, at 05:28, Michel Py wrote:
> Le machin qui consiste à mettre un cable entre 2 ports sur le même
> switch, c'est contraire à la logique. Continue, le jour ou çà va te

Si tu utilises le switch en tant que "switch" (fr: commutateur ethernet), oui, 
c'est au minimum problematique. Ca semble etre le cas de Sebastien.

Si par contre tu utilises le switch en tant que "multiplexeur" ethernet/802.1q 
ca peut etre assez "safe". Peut-etre pas avec un 3750, mais il y a des 
equipements avec lesquels c'est completement safe. On peut ocasionellement 
trouver des trucs comme ca das les "multiplexeurs ethernet" connectes derriere 
des routeurs. Ah, et sur un vrai routeur, connecter 2 ports entre eux ca ne 
pose aucun probleme.

Mais encore un fois, dans le cas present on parle d'un switch initialement 
prevu pour de la bureautique (3750 -> campus networks)

D'un cote, j'ai envie de dire "vas-y ! la concurrence locale va t'etre 
reconnaissante (le jour ou ca va foirer)".
D'un autre cote, ces bidouilles (et leurs consequences) tache encore plus 
l'image des petits operateurs (locaux ou pas), qui meritent mieux que ca.


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

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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Merci Thierry pour ton retour.

C'est quand même difficile de trancher entre le OUI c'est OK ça va gazer et NON 
tu fais une boulette...
J'ai eu des retours sur des personnes qui ont +/- la même config sur du 3750 
sans problématique particulière.

De mon côté la mise en place est passée du premier coup entre les deux switchs 
(c3750e-universalk9-mz.152-4.E10)!

J'aimerais vraiment avoir un retour sur du 3750X sur lequel cela ne fonctionne 
pas ! Peut-être l'IOS qui, à un moment peut faire merder le montage, car côté 
802.1q je ne vois pas spécialement de problématique sur l'usage

Sébastien


De : Thierry Chich 
Envoyé : mercredi 12 août 2020 18:23
À : Michel Py 
Cc : Sébastien 65 ; David Ponzone 
; frnog 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

Je confirme que c’est dangereux. Je l’ai eu fait, et ça a très bien marché. Et 
je l’ai eu refait, et ça a bien foiré. Pourtant, du strict point de vue 802.1q, 
c’est dans les clous. Mais on est jamais à l’abri d’un STP qui fonctionne pas 
comme on le pense (et dieu sait que c’est quasiment une caractéristique du STP 
- ne pas fonctionner comme on pense), ou d’un reparametrage innocent qui va 
tout exploser. Le fait est que jamais je ne tenterais cette opération à 
distance, sans avoir le switch sous la main.
C’est un signe que c’est pas hyper sécurisé comme opération.


Thierry

> Le 9 août 2020 à 22:17, Michel Py  a 
> écrit :
>
> 
>>> Michel Py a écrit :
>>> C'est super dangereux. Avec un 3750X çà peut marcher, mais il y a plein de 
>>> modèles
>> de switch qui vont péter les plombs avec cette config.
>
>> Sébastien 65 a écrit :
>> Avant de me lancer j'ai quand même pris le temps de fouiller sur Google et
>> il s'avère que cette technique est "couramment" utilisée. Pour le même 
>> besoin,
>> j'ai vu ça sur du Cisco 3750,3550, HPE 5800
>
> Ce qui ne veut pas dire que c'est robuste ou sain. STP, c'est facile à 
> planter; tu fragilises la situation. Au moindre problème ou bug, le cable 
> entre 2 ports du même switch, comme c'est pas une config courante, çà va 
> devenir un paratonnerre à emmerdes, surtout en cas d'autres problèmes ou de 
> reboot.
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C5d74c70593de45797f7608d83edbfe07%7C84df9e7fe9f640afb435%7C1%7C0%7C637328461856722825sdata=Xl7GW5YWIyd62tbPqKcw%2F7Q2wpayiiK2bmRuSHfN9i0%3Dreserved=0


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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Michel,

>C'est super dangereux. Avec un 3750X çà peut marcher, mais il y a plein de 
>modèles de switch qui vont péter les plombs avec cette config.
Avant de me lancer j'ai quand même pris le temps de fouiller sur Google et il 
s'avère que cette technique est "couramment" utilisée.
Pour le même besoin, j'ai vu ça sur du Cisco 3750,3550, HPE 5800





De : Michel Py 
Envoyé : samedi 8 août 2020 18:09
À : 'Sébastien 65' ; David Ponzone 
; frnog 
Objet : RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

> Sébastien 65 a écrit :
> Juste pour faire un retour rapide. Je suis resté avec les 3750X et pas eu 
> besoin
> de rajouter un switch, mais l'idée est certainement à creuser !! La technique 
> consiste de
> faire une boucle sur les deux switch de chaque côté afin d'injecter le VLAN 
> 50 sur le 105.

C'est super dangereux. Avec un 3750X çà peut marcher, mais il y a plein de 
modèles de switch qui vont péter les plombs avec cette config.

Michel.


=> system mtu 1504 sur les 2 switch

port 1 :
switchport access vlan 105
 switchport mode dot1q-tunnel
 no cdp enable
 l2protocol-tunnel cdp
 l2protocol-tunnel stp

et sur le port 2 :
switchport trunk allowed vlan 50
 switchport trunk encapsulation dot1q
 switchport mode trunk

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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Sale oui et non... C'est une méthode, certes qui me déroute un peu sur "la 
boucle contrôlée" mais qui a le mérite de fonctionner !
De plus je me retrouve avec le VLAN de management pleinement fonctionnel sur 
les 2 switch.

Maintenant je comprends mieux pourquoi quand je passe dans certaines baies 
opérateurs, le fait qu'il y ait un patch entre deux ports sur le même 
équipement 


De : David Ponzone 
Envoyé : samedi 8 août 2020 10:25
À : Sébastien 65 
Cc : frnog 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

Certes, mais que c’est sale :)

Le 8 août 2020 à 10:18, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Bonjour,

Juste pour faire un retour rapide. Je suis resté avec les 3750X et pas eu 
besoin de rajouter un switch, mais l'idée est certainement à creuser !!

La technique consiste de faire une boucle sur les deux switch de chaque côté 
afin d'injecter le VLAN 50 sur le 105.


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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Bonjour,

Juste pour faire un retour rapide. Je suis resté avec les 3750X et pas eu 
besoin de rajouter un switch, mais l'idée est certainement à creuser !!

La technique consiste de faire une boucle sur les deux switch de chaque côté 
afin d'injecter le VLAN 50 sur le 105.

=> system mtu 1504 sur les 2 switch


port 1 :
switchport access vlan 105
 switchport mode dot1q-tunnel
 no cdp enable
 l2protocol-tunnel cdp
 l2protocol-tunnel stp

et sur le port 2 :
switchport trunk allowed vlan 50
 switchport trunk encapsulation dot1q
 switchport mode trunk

Bon week-end !

De : frnog-requ...@frnog.org  de la part de David 
Ponzone 
Envoyé : mardi 28 juillet 2020 11:41
À : frnog 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

Et aussi ta volonté d’utiliser le VLAN 50 sur le switch qui te sert à la 
collecte.
Sépare les usages, ça ira mieux.
Au pire tu ajoutes un autre switch pour exploiter le VLAN 50 et tu le fais 
arriver sur le switch CELAN par un port dot1q-tunnel aussi.
Au prix en broke de ce type de switch, c pas la fin du monde.

> On Tue, Jul 28, 2020, at 09:19, Sébastien 65 wrote:
>> Si Q-in-Q n'est pas la solution, quesqu'il me reste comme solution ?
>
> Ce n'est pas la solution a remettre en cause, mais l'outil (l'equipement).
>
>
> ---
> Liste de diffusion du FRnOG
> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C32d7e7a4241447ead74308d832da7ec6%7C84df9e7fe9f640afb435%7C1%7C0%7C637315261290349465sdata=FbIixFsQWIUo2AIcd435D6hKUuESuELooidyXLU%2F7dM%3Dreserved=0


---
Liste de diffusion du FRnOG
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C32d7e7a4241447ead74308d832da7ec6%7C84df9e7fe9f640afb435%7C1%7C0%7C637315261290349465sdata=FbIixFsQWIUo2AIcd435D6hKUuESuELooidyXLU%2F7dM%3Dreserved=0

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

[FRnOG] [TECH] Upgrade ROMMON routeur CISCO

[Sébastien 65]

Bonjour à tous,

Est-ce que cela est problématique si la version d'un firmware n'est pas la même 
sur un ASR1004-RP2 concernant le Slot 0; R0 et F0 :

Slot  CPLD VersionFirmware Version
- --- ---
0 0911160115.3(3r)S
R01002190116.9(5r)
F00804110215.5(3r)S1

Un upgrade rom-monitor filename bootflash:asr1000-rommon.169_5r_SPA.pkg all ne 
change rien sauf m'affiche les messages suivants :

ROMMON upgrade complete.
To make the new ROMMON permanent, you must restart the RP.

Upgrade rom-monitor on Embedded-Service-Processor 0

Target copying rom-monitor image file
rsync: link_stat "rommon/mcp/FP/20G/latest.bin" (in rommon_upgrade_pub) failed: 
No such file or directory (2)
rsync error: some files could not be transferred (code 23) at 
/scratch/mcpre/release/BLD-V03_16_10_S_FC3/contrib/rsync/main.c(1392) 
[receiver=2.6.9]

Upgrade rom-monitor on SPA-Inter-Processor 0

Target copying rom-monitor image file
rsync: link_stat "rommon/mcp/CC/10G/latest.bin" (in rommon_upgrade_pub) failed: 
No such file or directory (2)
rsync error: some files could not be transferred (code 23) at 
/scratch/mcpre/release/BLD-V03_16_10_S_FC3/contrib/rsync/main.c(1392) 
[receiver=2.6.9]

Sébastien

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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

>Ce n'est pas ce qu'on comprend a partir de ton schema.
Le schéma est correct, une erreur de ma part sur la réponse à David...

>Autre chose, si tu veux faire du QinQ, il y a une interface d'entree (que dans 
>ton cas tu vois pas - c'est la porte CELAN), et une interface de sortie (cele 
>sur laquelle tu mets mode dot1q-tunnel pour enlever le tag 105).
Pour moi l'interface de sortie est l'interface fa0/2 du switch CELAN.

>Au moins sur ton equipement, qui est concu par le constructeur pour connecter 
>des PC dans un LAN d'entreprise, pas pour faire operateur.
J'ai pas trop compris le sens de ta prhase ?!

Si Q-in-Q n'est pas la solution, quesqu'il me reste comme solution ?

De : frnog-requ...@frnog.org  de la part de 
Radu-Adrian Feurdean 
Envoyé : mardi 28 juillet 2020 09:08
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

On Tue, Jul 28, 2020, at 08:56, Sébastien 65 wrote:
> Sur le switch CELAN, le port Fa0/1 est la livraison de la porte CELAN,
> donc je ne peux pas faire un Switchport access vlan 105

Ce n'est pas ce qu'on comprend a partir de ton schema.

Autre chose, si tu veux faire du QinQ, il y a une interface d'entree (que dans 
ton cas tu vois pas - c'est la porte CELAN), et une interface de sortie (cele 
sur laquelle tu mets mode dot1q-tunnel pour enlever le tag 105). Au moins sur 
ton equipement, qui est concu par le constructeur pour connecter des PC dans un 
LAN d'entreprise, pas pour faire operateur.


---
Liste de diffusion du FRnOG
https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C97576afb83ff414dbdad08d832c51428%7C84df9e7fe9f640afb435%7C1%7C0%7C637315169307025887sdata=VtTVHsTwsrUNHjX5eqGCM8N68bBqQKp2Zm%2FNeE8yYn4%3Dreserved=0

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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Je vais retourner faire la sieste !!! Non le Fa0/2 est bien la livraison, le 
schéma est correct...

Par contre j'ai besoin de pouvoir utiliser le vlan50 sur le switch CELAN ! 
Pourquoi celui-ci ne peux pas être utilisé ?

De : David Ponzone 
Envoyé : mardi 28 juillet 2020 09:01
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

Tu t’es planté sur ton schéma alors.

Le 28 juil. 2020 à 08:56, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Sur le switch CELAN, le port Fa0/1 est la livraison de la porte CELAN, donc je 
ne peux pas faire un Switchport access vlan 105



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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Sur le switch CELAN, le port Fa0/1 est la livraison de la porte CELAN, donc je 
ne peux pas faire un Switchport access vlan 105

De : David Ponzone 
Envoyé : mardi 28 juillet 2020 08:45
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

Oula y a quelques soucis:

Sur site distant:
int fa0/1
Switchport mode trunk
Switchport trunk encapsulation dot1q
Switchport native vlan 900
Switchport trunk allowed  50-53

Sur switch CELAN:
Int fa0/1
Switchport mode dot1q-tunnel
Switchport access vlan 105

Sur switch2:
Int fa0/2
Switchport mode trunk
Switchport trunk encapsulation dot1q
Switchport native vlan 900
Switchport trunk allowed  50-53

Attention: si ça marche :), le VLAN 50 est pas exploitable sur le switch CELAN.


Le 28 juil. 2020 à 08:29, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Je viens de faire un test cela ne communique pas avec les autres VLANS sauf le 
VLAN 105...

Par exemple ici j'essaye d'utiliser le VLAN50 sur le site distant (management 
des switchs)...

Un schéma du lab sera plus parlant : 
https://i.ibb.co/t4zNDSB/qinq.jpg<https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.ibb.co%2Ft4zNDSB%2Fqinq.jpg=02%7C01%7C%7Cfd03457996a842f2219108d832c1df78%7C84df9e7fe9f640afb435%7C1%7C0%7C637315155735722036=WceJ38LTirCW9EOhqk9HDFEXMGRuHykhTTnMVJrm4XA%3D=0>
[https://i.ibb.co/t4zNDSB/qinq.jpg]



De : frnog-requ...@frnog.org<mailto:frnog-requ...@frnog.org> 
mailto:frnog-requ...@frnog.org>> de la part de 
Sébastien 65 mailto:sebastien...@live.fr>>
Envoyé : lundi 27 juillet 2020 18:03
À : David Ponzone mailto:david.ponz...@gmail.com>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

Ca me va mieux comme ça oui !


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : lundi 27 juillet 2020 17:55
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

:)


Tu mets ça sur le port trunk qui va vers ton autre switch (interne).
Ca indique à ton switch que si un paquet arrive de ce port, il doit pusher 105 
en outer-VLAN, et l’inverse quand il envoie un paquet sur ce port.


Le 27 juil. 2020 à 17:53, Sébastien 65 
mailto:sebastien...@live.fr><mailto:sebastien...@live.fr>>
 a écrit :

J'ai raté un truc...

Sur le switch de collecte il faut que j'écrase la conf du port pour y mettre 
switchport access vlan 105 + dot1q-tunnel ?
Les autres services FTTO (100 à 104) dessus ne vont plus fonctionner non ?


---
Liste de diffusion du FRnOG
https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7Cb340739a3578431376c908d832469e63%7C84df9e7fe9f640afb435%7C1%7C0%7C637314626164540820sdata=NcX%2B74uQySzzOrcGtNqkVmiAyLly2b35JagRSHDu09I%3Dreserved=0<https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F=02%7C01%7C%7Cfd03457996a842f2219108d832c1df78%7C84df9e7fe9f640afb435%7C1%7C0%7C637315155735732026=bTAajvgIpZbbGChkLAB013oc9CXquRnqgXsC1LYxhk8%3D=0>


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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Je viens de faire un test cela ne communique pas avec les autres VLANS sauf le 
VLAN 105...

Par exemple ici j'essaye d'utiliser le VLAN50 sur le site distant (management 
des switchs)...

Un schéma du lab sera plus parlant : https://i.ibb.co/t4zNDSB/qinq.jpg
[https://i.ibb.co/t4zNDSB/qinq.jpg]



De : frnog-requ...@frnog.org  de la part de Sébastien 
65 
Envoyé : lundi 27 juillet 2020 18:03
À : David Ponzone 
Cc : frnog-t...@frnog.org 
Objet : RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

Ca me va mieux comme ça oui !


De : David Ponzone 
Envoyé : lundi 27 juillet 2020 17:55
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

:)


Tu mets ça sur le port trunk qui va vers ton autre switch (interne).
Ca indique à ton switch que si un paquet arrive de ce port, il doit pusher 105 
en outer-VLAN, et l’inverse quand il envoie un paquet sur ce port.


Le 27 juil. 2020 à 17:53, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

J'ai raté un truc...

Sur le switch de collecte il faut que j'écrase la conf du port pour y mettre 
switchport access vlan 105 + dot1q-tunnel ?
Les autres services FTTO (100 à 104) dessus ne vont plus fonctionner non ?


---
Liste de diffusion du FRnOG
https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7Cb340739a3578431376c908d832469e63%7C84df9e7fe9f640afb435%7C1%7C0%7C637314626164540820sdata=NcX%2B74uQySzzOrcGtNqkVmiAyLly2b35JagRSHDu09I%3Dreserved=0

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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Ca me va mieux comme ça oui !


De : David Ponzone 
Envoyé : lundi 27 juillet 2020 17:55
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

:)


Tu mets ça sur le port trunk qui va vers ton autre switch (interne).
Ca indique à ton switch que si un paquet arrive de ce port, il doit pusher 105 
en outer-VLAN, et l’inverse quand il envoie un paquet sur ce port.


Le 27 juil. 2020 à 17:53, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

J'ai raté un truc...

Sur le switch de collecte il faut que j'écrase la conf du port pour y mettre 
switchport access vlan 105 + dot1q-tunnel ?
Les autres services FTTO (100 à 104) dessus ne vont plus fonctionner non ?


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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

J'ai raté un truc...

Sur le switch de collecte il faut que j'écrase la conf du port pour y mettre 
switchport access vlan 105 + dot1q-tunnel ?
Les autres services FTTO (100 à 104) dessus ne vont plus fonctionner non ?

De : David Ponzone 
Envoyé : lundi 27 juillet 2020 17:41
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

Ok donc si ton trunk est pas en prod, tu peux essayer de le passer en 
dot1q-tunnel du côté switch de collecte seulement (mais toujours en trunk sur 
l’autre switch).
Si ton CELAN arrive sur le VLAN 105, ça donne:
 switchport access vlan 105
 switchport mode dot1q-tunnel

Le 27 juil. 2020 à 17:36, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

>Ils arrivent où sur ton switch tes VLANS 50/52/53/… ?
>Sur certains ports, ou c’est encore sur un autre switch ?

Ils arrivent via un autre switch. J'ai un trunk entre les deux switch par 
contre.


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

RE: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

>Ils arrivent où sur ton switch tes VLANS 50/52/53/… ?
>Sur certains ports, ou c’est encore sur un autre switch ?

Ils arrivent via un autre switch. J'ai un trunk entre les deux switch par 
contre.


De : David Ponzone 
Envoyé : lundi 27 juillet 2020 16:32
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN


Ils arrivent où sur ton switch tes VLANS 50/52/53/… ?
Sur certains ports, ou c’est encore sur un autre switch ?

Le plus simple serait que ton switch qui gère tes VLAN internes soit connecté à 
ce switch de collecte sur un port dot1q-tunnel dans le VLAN 
le-VLAN-de-ton-CELAN.
Ainsi ton switch de collecte envoie/reçoit vers ton switch « interne » , il va 
ajouter/retirer le VLAN de ton CELAN comme outer-VLAN.

Mais il y a probablement d’autres confs possibles.

> Le 27 juil. 2020 à 15:35, Sébastien 65  a écrit :
>
> Bonjour,
>
> Je suis en train de regarder s'il va être possible de faire passer plusieurs 
> VLAN au travers d'une connexion FTTO Orange livrée sur notre porte CELAN.
>
> J'ai un site technique distant qui doit avoir accès nativement à certains de 
> nos VLANS (50,52,53...) de notre infra. Le site distant sera équipé d'un 
> Catalyst 3750X derrière le RAD.
>
> Est-ce que le Q-in-Q est une bonne approche sachant que notre porte de 
> collecte CELAN arrive sur du Catalyst 3750X avec une config du type :
>
> interface GigabitEthernet1/0/3
> description :: Porte collecte CELAN ::
> switchport trunk allowed vlan 100-105
> switchport trunk encapsulation dot1q
> switchport trunk native vlan 900
> switchport mode trunk
> switchport nonegotiate
> speed nonegotiate
> no cdp enable
> !
>
> Je vais devoir activer system mtu 1504 sur le switch de la porte CELAN et du 
> switch distant ??
> Sur le switch de collecte il faut passer le port de la porte en switchport 
> mode dot1q-tunnel ??
>
> Sébastien
>
>
> ---
> Liste de diffusion du FRnOG
> https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7Cc2b82cd9febc4066134d08d83239f4d0%7C84df9e7fe9f640afb435%7C1%7C0%7C637314571778057684sdata=wANkrXoxTD%2BrC4SU5gDmIYiiFifZN352gr7p4Hw35Yk%3Dreserved=0


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

[FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Sébastien 65]

Bonjour,

Je suis en train de regarder s'il va être possible de faire passer plusieurs 
VLAN au travers d'une connexion FTTO Orange livrée sur notre porte CELAN.

J'ai un site technique distant qui doit avoir accès nativement à certains de 
nos VLANS (50,52,53...) de notre infra. Le site distant sera équipé d'un 
Catalyst 3750X derrière le RAD.

Est-ce que le Q-in-Q est une bonne approche sachant que notre porte de collecte 
CELAN arrive sur du Catalyst 3750X avec une config du type :

interface GigabitEthernet1/0/3
 description :: Porte collecte CELAN ::
 switchport trunk allowed vlan 100-105
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 900
 switchport mode trunk
 switchport nonegotiate
 speed nonegotiate
 no cdp enable
!

Je vais devoir activer system mtu 1504 sur le switch de la porte CELAN et du 
switch distant ??
Sur le switch de collecte il faut passer le port de la porte en switchport mode 
dot1q-tunnel ??

Sébastien


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

RE: [FRnOG] [TECH] Choix de routeur en 2020

[Sébastien 65]

>T’appelles 6Wind et tu leur demandes si ça marche OSPFv3 chez eux, et voilà.
Oui j'avais l'intention mais... La CLI ne ressemble plus à IOS sur ce que j'ai 
pu regarder et elle diffère de la conf BGP/OSPF de Quagga si j'ai bien lu.

Je suis pénible je le sais... IOS reste notre référence, pour le moment pas 
possible de prendre du temps pour aller sur une autre CLI !

De : David Ponzone 
Envoyé : lundi 6 juillet 2020 19:34
À : Sébastien 65 
Cc : Michel Py ; Duchet Rémy 
; frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Choix de routeur en 2020

T’appelles 6Wind et tu leur demandes si ça marche OSPFv3 chez eux, et voilà.

Le 6 juil. 2020 à 19:32, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

>Ah si tu fais du propriétaire, je m’incline :)
Nan sans rire

J'étais vraiment chaud pour passer sur FRR mais le fait de ne pas pouvoir 
utiliser OSPF en v6 me pose un gros problème !
Voila pourquoi je regarde 1001-X 


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : lundi 6 juillet 2020 19:29
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : Michel Py 
mailto:mic...@arneill-py.sacramento.ca.us>>;
 Duchet Rémy mailto:r...@duchet.eu>>; 
frnog@frnog.org<mailto:frnog@frnog.org> 
mailto:frnog@frnog.org>>
Objet : Re: [FRnOG] [TECH] Choix de routeur en 2020

Ah si tu fais du propriétaire, je m’incline :)

Le 6 juil. 2020 à 19:23, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Parceque 1U + gère BGP,EIGRP & GLBP, etc...

Prix refurb pas déconnant donc cela permet de faire un easy spare ! ET le gros 
avantage pour moi est de garder la CLI made Cisco...


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

RE: [FRnOG] [TECH] Choix de routeur en 2020

[Sébastien 65]

>Ah si tu fais du propriétaire, je m’incline :)
Nan sans rire

J'étais vraiment chaud pour passer sur FRR mais le fait de ne pas pouvoir 
utiliser OSPF en v6 me pose un gros problème !
Voila pourquoi je regarde 1001-X 


De : David Ponzone 
Envoyé : lundi 6 juillet 2020 19:29
À : Sébastien 65 
Cc : Michel Py ; Duchet Rémy 
; frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Choix de routeur en 2020

Ah si tu fais du propriétaire, je m’incline :)

Le 6 juil. 2020 à 19:23, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Parceque 1U + gère BGP,EIGRP & GLBP, etc...

Prix refurb pas déconnant donc cela permet de faire un easy spare ! ET le gros 
avantage pour moi est de garder la CLI made Cisco...


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

RE: [FRnOG] [TECH] Choix de routeur en 2020

[Sébastien 65]

Parceque 1U + gère BGP,EIGRP & GLBP, etc...

Prix refurb pas déconnant donc cela permet de faire un easy spare ! ET le gros 
avantage pour moi est de garder la CLI made Cisco...



De : David Ponzone 
Envoyé : lundi 6 juillet 2020 19:14
À : Sébastien 65 
Cc : Michel Py ; Duchet Rémy 
; frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Choix de routeur en 2020

Mais pourquoi tu veux t’emmerder avec du 1001-X comme routeur de transit ?
Tu vas rapidement arriver à la limite, et la seule solution ça sera 
remplacement complet des 2 (parce que tu en as 2 bien entendu).
Comme routeur de collecte/aggrégation de liens, quand il est au taquet, t’en 
mets un autre. Et le jour où tu en as marre de gérer 3 ASR de 1U, tu en mets 1 
seul de 3/4U à la place.
Sinon y a le 1001-HX mais il est encore cher…

Le 6 juil. 2020 à 18:23, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

> Ils mettent une route-map qui ne prend pas les /24, seulement les /23 et plus 
> court, et une route par défaut sur un de leurs transits.
Ok donc vraiment pas top comme manière de faire...

>Tout dépend du timing, mais le 1001 c'est quand même bien limité; ce que je 
>voulais dire c'est que çà me semble pas être un bon investissement.
Puisque tu connais bien les 1001, j'ai bien conscience que le 1001 simple n'est 
pas à prendre, par contre un 1001-X 16Gb de RAM (Advanced Enterprise Service) 
tu valides ?

Je n'ai pas de recul sur le 1001-X, mais combien il supporte de full table sans 
faire du route-map et sans route par défaut comme cité plus haut ?

De : Michel Py 
mailto:mic...@arneill-py.sacramento.ca.us>>
Envoyé : lundi 6 juillet 2020 18:07
À : 'David Ponzone' mailto:david.ponz...@gmail.com>>
Cc : Sébastien 65 mailto:sebastien...@live.fr>>; Duchet 
Rémy mailto:r...@duchet.eu>>; 
frnog@frnog.org<mailto:frnog@frnog.org> 
mailto:frnog@frnog.org>>
Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020

> Sébastien 65 a écrit :
> Sur le datasheet je viens de lire que le 1001 supporte 1 000 000 de routes 
> IPv4, aujourd'hui
> c'est trop court ! Je suis curieux de savoir comment font les personnes 
> aujourd'hui ?

Ils mettent une route-map qui ne prend pas les /24, seulement les /23 et plus 
court, et une route par défaut sur un de leurs transits.


> David Ponzone a écrit :
> Chez toi un 9001 c’est à peine plus cher qu’un 1001-X  ?
> Faut que je fasse un A/R avec une grosse grosse valise :)

Cà dépend des modèles; un 1001 de base avec 1G c'est pratiquement gratuit et 
pour de bonnes raisons, mais quand tu commences à taper dans le 1001-X avec 10G 
et la license et tout çà reste cher pour ce que c'est. A ma connaissance il n'y 
a pas de 40G, et 1 seul slot. Tu l'installes aujourd'hui faut déjà penser à le 
remplacer. Le 9001 çà douille, mais çà arrive avec 4x 10G au départ, faut 
allonger plusieurs K€ de plus mais au moins tu le gardes quelques temps et le 
jour ou tu as besoin de 40G tu peux.

Tout dépend du timing, mais le 1001 c'est quand même bien limité; ce que je 
voulais dire c'est que çà me semble pas être un bon investissement.

Michel.


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

RE: [FRnOG] [TECH] Choix de routeur en 2020

[Sébastien 65]

> Ils mettent une route-map qui ne prend pas les /24, seulement les /23 et plus 
> court, et une route par défaut sur un de leurs transits.
Ok donc vraiment pas top comme manière de faire...

>Tout dépend du timing, mais le 1001 c'est quand même bien limité; ce que je 
>voulais dire c'est que çà me semble pas être un bon investissement.
Puisque tu connais bien les 1001, j'ai bien conscience que le 1001 simple n'est 
pas à prendre, par contre un 1001-X 16Gb de RAM (Advanced Enterprise Service) 
tu valides ?

Je n'ai pas de recul sur le 1001-X, mais combien il supporte de full table sans 
faire du route-map et sans route par défaut comme cité plus haut ?

De : Michel Py 
Envoyé : lundi 6 juillet 2020 18:07
À : 'David Ponzone' 
Cc : Sébastien 65 ; Duchet Rémy ; 
frnog@frnog.org 
Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020

> Sébastien 65 a écrit :
> Sur le datasheet je viens de lire que le 1001 supporte 1 000 000 de routes 
> IPv4, aujourd'hui
> c'est trop court ! Je suis curieux de savoir comment font les personnes 
> aujourd'hui ?

Ils mettent une route-map qui ne prend pas les /24, seulement les /23 et plus 
court, et une route par défaut sur un de leurs transits.


> David Ponzone a écrit :
> Chez toi un 9001 c’est à peine plus cher qu’un 1001-X  ?
> Faut que je fasse un A/R avec une grosse grosse valise :)

Cà dépend des modèles; un 1001 de base avec 1G c'est pratiquement gratuit et 
pour de bonnes raisons, mais quand tu commences à taper dans le 1001-X avec 10G 
et la license et tout çà reste cher pour ce que c'est. A ma connaissance il n'y 
a pas de 40G, et 1 seul slot. Tu l'installes aujourd'hui faut déjà penser à le 
remplacer. Le 9001 çà douille, mais çà arrive avec 4x 10G au départ, faut 
allonger plusieurs K€ de plus mais au moins tu le gardes quelques temps et le 
jour ou tu as besoin de 40G tu peux.

Tout dépend du timing, mais le 1001 c'est quand même bien limité; ce que je 
voulais dire c'est que çà me semble pas être un bon investissement.

Michel.


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

RE: [FRnOG] [TECH] Choix de routeur en 2020

[Sébastien 65]

Le 1001 a bonne presse, j'en vois quelques uns encore en full prod

Sur le datasheet je viens de lire que le 1001 supporte 1 000 000 de routes 
IPv4, aujourd'hui c'est trop court ! Je suis curieux de savoir comment font les 
personnes aujourd'hui ?
Un 1001-X supporte 3 500 000 routes IPv4 avec 16Gb de Ram...

Par contre le prix du 1001-X ou d'un 9001 n'est vraiment pas le même...

De : Michel Py 
Envoyé : lundi 6 juillet 2020 03:26
À : 'Sébastien 65' ; Duchet Rémy ; 
frnog@frnog.org 
Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020

> Sébastien 65 a écrit :
> Du coup, combien de full view IPv4 /IPv6 sur un ASR1001 avec
> 8Gb de RAM est-il capable de gérer ? 3 ou 4 full maximum ?


L'ASR 1001 je ne fais plus. Si c'est pas un 1001-X çà ne tient pas, en en 
regardant le prix en broke, je passe directement à l'ASR 9001. Un ASR1001, au 
jour d'aujourd'hui faut me payer pour que je le mette en prod. Si il est en 
prod depuis des lustres c'était un bon routeur, mais la fin de vie est arrivée.

Michel.

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

Re: [FRnOG] [TECH] Choix de routeur en 2020

[Sébastien 65]

Oui Michel ! FRR n'intègre pas IPv6 sur Eigrp... J'ai voulu tester hier, pas de 
problème pour IPv4 mais lorsque j'ai voulu passer du côté obscur avec ipv6 
router eigrp X j'ai pris un gros STOP !

Bien dommage et un peu déçu de FRR pour le coup ;(

Du coup, combien de full view IPv4 /IPv6 sur un ASR1001 avec 8Gb de RAM est-il 
capable de gérer ? 3 ou 4 full maximum ?

Je crois que ASR1001 est capable de passer à 16Gb de RAM, donc certainement 
plus de full view en perspective ?

De : Michel Py 
Envoyé : samedi 4 juillet 2020 00:19
À : 'Sébastien 65' ; Duchet Rémy ; 
frnog@frnog.org 
Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020

> Sébastien 65 a écrit :
> Concernant le bug OSPF, n'est-il pas possible d'utiliser EIGRP avec FRR pour 
> exclure OSPF ?

Justement un des trucs qui m'avaient intéressé avec FRR c'est qu'ils on 
implémenté EIGRP, je suis un fan.

> Je ne sais pas si quelqu'un a du recul sur l'utilisation EIGRP avec FRR...

Comme d'ab IPv6 est la dernière roue...
https://github.com/FRRouting/frr/issues/6108

Michel.


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

RE: [FRnOG] [TECH] Choix de routeur en 2020

[Sébastien 65]

Re,

Concernant le bug OSPF, n'est-il pas possible d'utiliser EIGRP avec FRR pour 
exclure OSPF ?

Je ne sais pas si quelqu'un a du recul sur l'utilisation EIGRP avec FRR...

De : frnog-requ...@frnog.org  de la part de Duchet 
Rémy 
Envoyé : jeudi 2 juillet 2020 08:09
À : Emmanuel DECAEN ; frnog@frnog.org 

Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020


> Avec FRR, la partie BGP me convient très bien, malheureusement la partie OSPF 
> avec IPv6 pose vraiment problème.

Perso, FRR ne fonctionnait pas en BGP sur un Bond Linux en 2x10Gbps.

Rémy

---
Liste de diffusion du FRnOG
https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C16315b0720844e21857808d81e4e9374%7C84df9e7fe9f640afb435%7C1%7C0%7C637292670111418232sdata=RfmLk37iU%2BrcEXcKh3RVBZVL9o7El7J3RomcPcW%2FHrU%3Dreserved=0

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

RE: [FRnOG] [TECH] Choix de routeur en 2020

[Sébastien 65]

Ok d'accord ! Tu m'as cassé ma journée Rémy :p


De : Duchet Rémy 
Envoyé : jeudi 2 juillet 2020 08:54
À : Sébastien 65 ; Emmanuel DECAEN 
; frnog@frnog.org 
Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020


On n’a pas testé sur Quagga.

On a bascule sur Bird, et tout fonctionne sans soucis.



Rémy



From: Sébastien 65 
Sent: Thursday, 2 July 2020 08:39
To: Duchet Rémy ; Emmanuel DECAEN ; 
frnog@frnog.org
Subject: RE: [FRnOG] [TECH] Choix de routeur en 2020



Ha m***e !!!



C'est chaud quand même que le support FRR ne bouge pas la correction...



J'allais planifier le changement vers du FRR... Est-ce que le bug est également 
présent sur Quagga ?



De : Duchet Rémy mailto:r...@duchet.eu>>
Envoyé : jeudi 2 juillet 2020 08:35
À : Sébastien 65 mailto:sebastien...@live.fr>>; Emmanuel 
DECAEN mailto:emmanuel.dec...@xsalto.com>>; 
frnog@frnog.org<mailto:frnog@frnog.org> 
mailto:frnog@frnog.org>>
Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020



La session BGP ne montait pas correctement, et était reset dès qu’une route 
était envoyé par un Peer.

Et pas de problème en IPv4, uniquement en IPv6..

J’ai demandé ici, et chez FFR (forum) aucune solution.

Du coup, on est passé sur du Bird. (et 0 problèmes avec la même config 
hardware).



Rémy



From: Sébastien 65 mailto:sebastien...@live.fr>>
Sent: Thursday, 2 July 2020 08:25
To: Duchet Rémy mailto:r...@duchet.eu>>; Emmanuel DECAEN 
mailto:emmanuel.dec...@xsalto.com>>; 
frnog@frnog.org<mailto:frnog@frnog.org>
Subject: RE: [FRnOG] [TECH] Choix de routeur en 2020



Rémy,



Quel est exactement le problème avec OSPF en IPv6 avec FRR ?



De : frnog-requ...@frnog.org<mailto:frnog-requ...@frnog.org> 
mailto:frnog-requ...@frnog.org>> de la part de Duchet 
Rémy mailto:r...@duchet.eu>>
Envoyé : jeudi 2 juillet 2020 08:09
À : Emmanuel DECAEN 
mailto:emmanuel.dec...@xsalto.com>>; 
frnog@frnog.org<mailto:frnog@frnog.org> 
mailto:frnog@frnog.org>>
Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020



> Avec FRR, la partie BGP me convient très bien, malheureusement la partie OSPF 
> avec IPv6 pose vraiment problème.

Perso, FRR ne fonctionnait pas en BGP sur un Bond Linux en 2x10Gbps.

Rémy

---
Liste de diffusion du FRnOG
https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C16315b0720844e21857808d81e4e9374%7C84df9e7fe9f640afb435%7C1%7C0%7C637292670111418232sdata=RfmLk37iU%2BrcEXcKh3RVBZVL9o7El7J3RomcPcW%2FHrU%3Dreserved=0<https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F=02%7C01%7C%7C7ddefafa7a0c4899768d08d81e54ca86%7C84df9e7fe9f640afb435%7C1%7C0%7C637292696801606117=snfLGqghfjjUb%2BpSz6VME3847ESTs5T2cwjPc0xX9Hk%3D=0>

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

RE: [FRnOG] [TECH] Choix de routeur en 2020

[Sébastien 65]

Ha m***e !!!

C'est chaud quand même que le support FRR ne bouge pas la correction...

J'allais planifier le changement vers du FRR... Est-ce que le bug est également 
présent sur Quagga ?

De : Duchet Rémy 
Envoyé : jeudi 2 juillet 2020 08:35
À : Sébastien 65 ; Emmanuel DECAEN 
; frnog@frnog.org 
Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020


La session BGP ne montait pas correctement, et était reset dès qu’une route 
était envoyé par un Peer.

Et pas de problème en IPv4, uniquement en IPv6..

J’ai demandé ici, et chez FFR (forum) aucune solution.

Du coup, on est passé sur du Bird. (et 0 problèmes avec la même config 
hardware).



Rémy



From: Sébastien 65 
Sent: Thursday, 2 July 2020 08:25
To: Duchet Rémy ; Emmanuel DECAEN ; 
frnog@frnog.org
Subject: RE: [FRnOG] [TECH] Choix de routeur en 2020



Rémy,



Quel est exactement le problème avec OSPF en IPv6 avec FRR ?



De : frnog-requ...@frnog.org<mailto:frnog-requ...@frnog.org> 
mailto:frnog-requ...@frnog.org>> de la part de Duchet 
Rémy mailto:r...@duchet.eu>>
Envoyé : jeudi 2 juillet 2020 08:09
À : Emmanuel DECAEN 
mailto:emmanuel.dec...@xsalto.com>>; 
frnog@frnog.org<mailto:frnog@frnog.org> 
mailto:frnog@frnog.org>>
Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020



> Avec FRR, la partie BGP me convient très bien, malheureusement la partie OSPF 
> avec IPv6 pose vraiment problème.

Perso, FRR ne fonctionnait pas en BGP sur un Bond Linux en 2x10Gbps.

Rémy

---
Liste de diffusion du FRnOG
https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C16315b0720844e21857808d81e4e9374%7C84df9e7fe9f640afb435%7C1%7C0%7C637292670111418232sdata=RfmLk37iU%2BrcEXcKh3RVBZVL9o7El7J3RomcPcW%2FHrU%3Dreserved=0<https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F=02%7C01%7C%7C9c776d2e925d4680c75508d81e521928%7C84df9e7fe9f640afb435%7C1%7C0%7C637292685235119624=eXIHk59Tj75G9cugf%2Fnw1pqQBuxhmTKrgEO8S2YAYF4%3D=0>

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

RE: [FRnOG] [TECH] Choix de routeur en 2020

[Sébastien 65]

Rémy,

Quel est exactement le problème avec OSPF en IPv6 avec FRR ?

De : frnog-requ...@frnog.org  de la part de Duchet 
Rémy 
Envoyé : jeudi 2 juillet 2020 08:09
À : Emmanuel DECAEN ; frnog@frnog.org 

Objet : RE: [FRnOG] [TECH] Choix de routeur en 2020


> Avec FRR, la partie BGP me convient très bien, malheureusement la partie OSPF 
> avec IPv6 pose vraiment problème.

Perso, FRR ne fonctionnait pas en BGP sur un Bond Linux en 2x10Gbps.

Rémy

---
Liste de diffusion du FRnOG
https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C16315b0720844e21857808d81e4e9374%7C84df9e7fe9f640afb435%7C1%7C0%7C637292670111418232sdata=RfmLk37iU%2BrcEXcKh3RVBZVL9o7El7J3RomcPcW%2FHrU%3Dreserved=0

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

[TECH] Re: [FRnOG] [TECH] Méthode pour tirage fibre dans bâtiment

[Sébastien 65]

On ne peut rien te cacher David !

La solution 2 me paraît la plus viable et simple sauf que je n'ai aucune idée 
du type d'armoire à utiliser pour faire la jointure entre l'intérieur/extérieur 
pour rentrer tout cela !

Une fois dans l'intérieur pas de pb car chemin de câble jusqu'à notre local 
technique...

Le truc bloquant pour moi est d'avoir la bonne armoire qui sera placée au 
dessus de la chambre de raccordement !

De : David Ponzone 
Envoyé : dimanche 31 mai 2020 10:34
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Méthode pour tirage fibre dans bâtiment


Le 31/05/2020 à 09:19, Sébastien 65 a écrit :
> Bonjour la liste,
>
> Question technique concernant la manière de rentrer plusieurs fibres (GCBLO 
> et autre opérateur) de l'extérieur vers l'intérieur d'un bâtiment ancien.
>
> J'ai un bâtiment sur lequel à l'époque le Télécom n'était pas prévu (aucun 
> fourreau...), les murs ont une grande épaisseur avec des fondations de 
> malade. Il n'est pas envisageable de passer "sous terre" pour pénetrer notre 
> bâtiment...
>
> 2 solutions :
> - Passage par le toit avec chemin de câble posé sur mur extérieur puis 
> passage en comble pour avoir un cheminement jusqu'à notre local technique 
> situé au milieu du bâtiment,
> - Perçage du mur extérieur au dessus de la chambre Télécom pour faire la 
> liaison extérieure/intérieure jusqu'au local technique (beaucoup plus simple 
> à réaliser).
>
> Une chambre Télécom pourra être installée à l'extérieur du bâtiment contre le 
> mur extérieur pour envisager une des 2 solutions ci-dessus.
>
> Quelle est la bonne méthode selon vous ?

Si tu hésites, c’est que la solution 2 te pose un problème non ?



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

[FRnOG] [TECH] Méthode pour tirage fibre dans bâtiment

[Sébastien 65]

Bonjour la liste,

Question technique concernant la manière de rentrer plusieurs fibres (GCBLO et 
autre opérateur) de l'extérieur vers l'intérieur d'un bâtiment ancien.

J'ai un bâtiment sur lequel à l'époque le Télécom n'était pas prévu (aucun 
fourreau...), les murs ont une grande épaisseur avec des fondations de malade. 
Il n'est pas envisageable de passer "sous terre" pour pénetrer notre bâtiment...

2 solutions :
- Passage par le toit avec chemin de câble posé sur mur extérieur puis passage 
en comble pour avoir un cheminement jusqu'à notre local technique situé au 
milieu du bâtiment,
- Perçage du mur extérieur au dessus de la chambre Télécom pour faire la 
liaison extérieure/intérieure jusqu'au local technique (beaucoup plus simple à 
réaliser).

Une chambre Télécom pourra être installée à l'extérieur du bâtiment contre le 
mur extérieur pour envisager une des 2 solutions ci-dessus.

Quelle est la bonne méthode selon vous ?

Bon week-end à vous !



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

RE: [FRnOG] [TECH] SW_DAI-4-PACKET_RATE_EXCEEDED CISCO

[Sébastien 65]

Salut Jérôme,

>Tu sécurises quoi via ce port Gi0/1 ?
Valider que les @MAC/IP d'un VLAN sont bien celle qui doivent discuter avec le 
routeur !

>Juste vérifier les correspondances MAC-IP via l'inspection DHCP snooping en 
>parallèle ?
Oui, j'ai des access-list ARP qui autorise sur un VLAN un couple d'@ IP/MAC. Je 
n'ai pas de service DHCP qui tourne sur ce réseau.
!
arp access-list VLAN_101_ARP
 permit ip host 10.0.1.1 mac host cc2d.e0b2.6f1c
 permit ip host 10.0.1.2 mac host 7c69.f617.8e82
!

>Je ne connais pas de méthode officielle mais je tenterai un doublement de 
>valeur jusqu'à que le défaut ne revienne plus.
C'est quitte ou double et j'aime pas du tout... Tu vas être tranquille pendant 
un certain temps et le jours ou il y aura plus de monde ça va merder et hop 
port down !

Bonne soirée !

De : frnog-requ...@frnog.org  de la part de Jérôme 
BERTHIER via frnog 
Envoyé : lundi 25 mai 2020 09:51
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] SW_DAI-4-PACKET_RATE_EXCEEDED CISCO

Salut,

Le 21/05/2020 à 08:50, Sébastien 65 a écrit :
> Bonjour à tous,
>
> Sur un switch j'ai activé Dynamic ARP Inspection, je me retrouve de temps en 
> temps le port UPLINK en err-disable state.
>
> Le port Gi0/1 est connecté en cascade sur différent switch du LAN qui n'ont 
> pas de mécanisme DAI.


Du coup, la logique m'échappe.

Le spoofing peut avoir lieu sur n'importe quel switch aval dans ce cas.

Tu sécurises quoi via ce port Gi0/1 ? Juste vérifier les correspondances
MAC-IP via l'inspection DHCP snooping en parallèle ?

En théorie, les ports vers d'autres devices (attendus exécutant DAI)
sont à l'état trust donc il n'y a pas d'inspection (donc pas de rate
limiting nécessaire).


> Le switch qui passe en err-disable est ensuite banché sur le routeur, le 
> switch me permet de faire du "ménage" AVANT de passer sur le routeur...
>
> J'utilise ip arp inspection validate src-mac dst-mac ip + ip arp inspection 
> filter
>
> *Mar  3 14:53:28.473: %SW_DAI-4-PACKET_RATE_EXCEEDED: 18 packets received in 
> 16 milliseconds on Gi0/1.
> *Mar  3 14:53:28.473: %PM-4-ERR_DISABLE: arp-inspection error detected on 
> Gi0/1, putting Gi0/1 in err-disable state
> *Mar  3 14:53:29.513: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
> GigabitEthernet0/1, changed state to down
> *Mar  3 14:53:30.553: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed 
> state to down
>
> En regardant un peux les valeurs par défaut, je constate que CISCO  fixe ip 
> arp inspection limit rate à 15 pps.
>
> Je ne sais pas comment définir cette valeur à part de faire au pifomètre ou 
> d'utiliser ip arp inspection limit none sur Gi0/1...
>
> Si quelqu'un peut m'expliquer la méthode je suis preneur 


Je ne connais pas de méthode officielle mais je tenterai un doublement
de valeur jusqu'à que le défaut ne revienne plus.

Ou alors plus fin, tu captures le trafic pour te faire une idée du seuil
atteint mais bon, comme tous les seuils, ça va forcément devenir faux au
bout d'un moment...


Bonne journée


>
> Merci
>
>
>
> ---
> Liste de diffusion du FRnOG
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7Cc4625a445bd64bc1ef3008d8008087ab%7C84df9e7fe9f640afb435%7C1%7C0%7C637259899310184386sdata=V3fmq%2FhXshiALZ6phOVljy81cqWZeJapXnKv4%2B14Vcw%3Dreserved=0


--
Jérôme BERTHIER


---
Liste de diffusion du FRnOG
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7Cc4625a445bd64bc1ef3008d8008087ab%7C84df9e7fe9f640afb435%7C1%7C0%7C637259899310184386sdata=V3fmq%2FhXshiALZ6phOVljy81cqWZeJapXnKv4%2B14Vcw%3Dreserved=0

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

[FRnOG] [TECH] SW_DAI-4-PACKET_RATE_EXCEEDED CISCO

[Sébastien 65]

Bonjour à tous,

Sur un switch j'ai activé Dynamic ARP Inspection, je me retrouve de temps en 
temps le port UPLINK en err-disable state.

Le port Gi0/1 est connecté en cascade sur différent switch du LAN qui n'ont pas 
de mécanisme DAI.
Le switch qui passe en err-disable est ensuite banché sur le routeur, le switch 
me permet de faire du "ménage" AVANT de passer sur le routeur...

J'utilise ip arp inspection validate src-mac dst-mac ip + ip arp inspection 
filter

*Mar  3 14:53:28.473: %SW_DAI-4-PACKET_RATE_EXCEEDED: 18 packets received in 16 
milliseconds on Gi0/1.
*Mar  3 14:53:28.473: %PM-4-ERR_DISABLE: arp-inspection error detected on 
Gi0/1, putting Gi0/1 in err-disable state
*Mar  3 14:53:29.513: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet0/1, changed state to down
*Mar  3 14:53:30.553: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed 
state to down

En regardant un peux les valeurs par défaut, je constate que CISCO  fixe ip arp 
inspection limit rate à 15 pps.

Je ne sais pas comment définir cette valeur à part de faire au pifomètre ou 
d'utiliser ip arp inspection limit none sur Gi0/1...

Si quelqu'un peut m'expliquer la méthode je suis preneur 

Merci



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