Auteur Sujet: Remplacer ONT SFR (Lu 351819 fois)

moray · « **Réponse #1356 le:** 21 février 2026 à 18:57:12 »

Citation de: G8U5 le 20 février 2026 à 16:25:27

Pour l'auto-negociation, tous les routeurs ne supportent pas le 2.5gbs.

Et voila, c'est ca le problème... aprés un peu de recherche j'ai découvert que le mikrotik RB5009 n'aime pas trop le module FS ONU-34-20BI car son SFP+ supporte 10Gbit et pas 2.5Gbit.
J'ai essayé de forcer le link à 1Gbit mais ca ne semble pas marcher. Le "sfp-tx-fault" est toujour "yes" (comme montré en bas). Le MA5671A semble etre plus compatible, je pense je vais le prendre avec un media converter au cas où.
Dommage car je voulais éviter d'utiliser un boitier externe...

Code: [Sélectionner]

[admin@MikroTik] > /interface ethernet monitor sfp-sfpplus1 once
                        ;;; fiber                                                                    
                      name: sfp-sfpplus1                                                             
                    status: no-link                                                                  
          auto-negotiation: done                                                                     
                 supported: 10M-baseT-half                                                           
                            10M-baseT-full                                                           
                            100M-baseT-half                                                          
                            100M-baseT-full                                                          
                            1G-baseT-half                                                            
                            1G-baseT-full                                                            
                            1G-baseX                                                                 
                            2.5G-baseT                                                               
                            2.5G-baseX                                                               
                            5G-baseT                                                                 
                            10G-baseT                                                                
                            10G-baseSR-LR                                                            
                            10G-baseCR                                                               
               advertising:                                                                          
  link-partner-advertising:                                                                          
        sfp-module-present: yes                                                                      
               sfp-rx-loss: no                                                                       
              sfp-tx-fault: yes                                                                      
                  sfp-type: SFP/SFP+/SFP28/SFP56                                                     
        sfp-connector-type: SC                                                                       
              sfp-encoding: nrz                                                                      
        sfp-link-length-sm: 40km                                                                     
           sfp-vendor-name: Lantiq                                                                   
    sfp-vendor-part-number: Falcon SFP                                                               
       sfp-vendor-revision: 0                                                                        
         sfp-vendor-serial: PTINXXXXXXX                                                             
    sfp-manufacturing-date: 14-01-01                                                                 
            sfp-wavelength: 1312.55nm                                                                
           sfp-temperature: 26C                                                                      
        sfp-supply-voltage: 3.363V                                                                   
       sfp-tx-bias-current: 6mA                                                                      
              sfp-tx-power: -40dBm                                                                   
              sfp-rx-power: -16.252dBm                                                               
           eeprom-checksum: good

rooot · « **Réponse #1357 le:** 21 février 2026 à 19:28:52 »

Citation de: moray le 21 février 2026 à 18:57:12

j'ai découvert que le mikrotik RB5009 n'aime pas trop le module FS ONU-34-20BI car son SFP+ supporte 10Gbit et pas 2.5Gbit.

Le RB5009 supporte bien 2.5Gbps sur son SFP+, il faut mettre ton RouterOS a jour.
https://forum.mikrotik.com/t/it-is-hoped-that-2-5gbps-support-can-be-added-to-the-sfp-of-rb5009/157554/10

moray · « **Réponse #1358 le:** 21 février 2026 à 22:04:19 »

OK, encore quelque progrès sur ce problème...

C'est vrais, le lien 2.5G sur le ONU FS semble effectivement marcher, et le sfp-tx-fault je l'ai fixé (la solution est dans la page hack-gpon.org pour la stick FS).
Le problème maintenant est avec le DHCP et SFR. Alors, je peux assurer que avec l'ont altice tout marche parfaitement. Le vendor-class-identifier est correctement configuré. Le DHCP sur interface ethernet prends l'adresse correctement (J'ai un IP publique, pas de CG-NAT).

Sur le mikrotik si je fais un "sniff" sur l'interface sfp je vois le traffique dhcp entre le router et SFR, mais je recois les responses sur une VLAN 0:6 (log en bas) et donc le client dhcp ne sais pas quoi faire et reste in "searching". J'ai fait dejà plusieurs essayes en créant des vlan mais sans succès... je m'arrete la pour l'instant, mais si quelqu'un a une idée...

ChatGPT/Claude parlent de VLAN QinQ et j'ai essayé de faire une config pour gèrer ca mais je n'arrive pas a la faire marcher. Je vais poster aussi sue les forums mikrotik...

Code: [Sélectionner]

[admin@MikroTik] > /tool sniffer quick interface=sfp-sfpplus1 
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, VLAN, SRC-ADDRESS, DST-ADDRESS
INTERFACE     TIME   NUM  DIR  SRC-MAC            DST-MAC            VLAN  SRC-ADDRESS              DST-ADDRESS                
sfp-sfpplus1  1.103    1  ->   6C:61:F4:0B:AA:XX  FF:FF:FF:FF:FF:FF        0.0.0.0:68 (bootpc)      255.255.255.255:67 (bootps)
sfp-sfpplus1  1.175    2  <-   68:AB:09:76:BB:YY  FF:FF:FF:FF:FF:FF  0:6   93.31.207.1:67 (bootps)  255.255.255.255:68 (bootpc)
sfp-sfpplus1  1.175    3  <-   68:AB:09:76:BB:YY  FF:FF:FF:FF:FF:FF  0:6   93.31.207.1:67 (bootps)  255.255.255.255:68 (bootpc)
sfp-sfpplus1  4.607    4  ->   6C:61:F4:0B:AA:XX  FF:FF:FF:FF:FF:FF        0.0.0.0:68 (bootpc)      255.255.255.255:67 (bootps)
sfp-sfpplus1  4.686    5  <-   68:AB:09:76:BB:YY  FF:FF:FF:FF:FF:FF  0:6   93.31.207.1:67 (bootps)  255.255.255.255:68 (bootpc)
sfp-sfpplus1  4.687    6  <-   68:AB:09:76:BB:YY  FF:FF:FF:FF:FF:FF  0:6   93.31.207.1:67 (bootps)  255.255.255.255:68 (bootpc)
sfp-sfpplus1  7.955    7  ->   6C:61:F4:0B:AA:XX  FF:FF:FF:FF:FF:FF        0.0.0.0:68 (bootpc)      255.255.255.255:67 (bootps)
sfp-sfpplus1  8.014    8  <-   68:AB:09:76:BB:YY  FF:FF:FF:FF:FF:FF  0:6   93.31.207.1:67 (bootps)  255.255.255.255:68 (bootpc)
sfp-sfpplus1  8.021    9  <-   68:AB:09:76:BB:YY  FF:FF:FF:FF:FF:FF  0:6   93.31.207.1:67 (bootps)  255.255.255.255:68 (bootpc)
sfp-sfpplus1  9.487   10  ->   6C:61:F4:0B:AA:XX  FF:FF:FF:FF:FF:FF        0.0.0.0:68 (bootpc)      255.255.255.255:67 (bootps)
sfp-sfpplus1  9.559   11  <-   68:AB:09:76:BB:YY  FF:FF:FF:FF:FF:FF  0:6   93.31.207.1:67 (bootps)  255.255.255.255:68 (bootpc)
sfp-sfpplus1  9.559   12  <-   68:AB:09:76:BB:YY  FF:FF:FF:FF:FF:FF  0:6   93.31.207.1:67 (bootps)  255.255.255.255:68 (bootpc)

Paul · « **Réponse #1359 le:** 23 février 2026 à 17:07:33 »

C'est la notation VLAN:PCP, donc il ne s'agit pas de QinQ, ce serait étonnant, et l'IA a pioché dans le pifomètre. Le trafic reçu est sur le VLAN 0 (donc pas de VLAN) avec une CoS 6. Ce qui est bizarre, c'est que personne ici ne semblait avoir remonté jusqu'ici qu'SFR utilisait une CoS 6 pour le trafic DHCP.

Il attend peut-être une réponse avec le même marquage, ce qu'il faudrait faire avec :

Code: [Sélectionner]

add comment="DHCP traffic" new-vlan-priority=6 ports=sfp-sfpplus1 protocol=udp dst-port=67 src-port=68 switch=switch1

moray · « **Réponse #1360 le:** **Hier** à 17:57:47 »

Citation de: Paul le 23 février 2026 à 17:07:33

C'est la notation VLAN:PCP, donc il ne s'agit pas de QinQ, ce serait étonnant, et l'IA a pioché dans le pifomètre. Le trafic reçu est sur le VLAN 0 (donc pas de VLAN) avec une CoS 6. Ce qui est bizarre, c'est que personne ici ne semblait avoir remonté jusqu'ici qu'SFR utilisait une CoS 6 pour le trafic DHCP.

Merci. J'imagine la commande complete etait :

Code: [Sélectionner]

/interface ethernet switch rule
add comment="DHCP traffic" new-vlan-priority=6 ports=sfp-sfpplus1 protocol=udp dst-port=67 src-port=68 switch=switch1

Par contre ca ne marche pas dans mon cas car "new-vlan-priority not supported for this switch".

Je ne sais pas pourquoi ma config est si capricieuse... comme j'ai dit dans un message precedent j'avais une config qui marchait avant. La seule chose que je peux imaginer est que ils ont peut etre passé mon abonnement sur quelque chose pour entreprises, car je l'avais passé sous ma boite.

Paul · « **Réponse #1361 le:** **Hier** à 21:32:42 »

En effet, se placer dans la bonne arborescence, c'est mieux. Je découvre en même temps que c'est pas si simple, alors que l'ASIC de commutation (88E6393X) du RB5009 est très capable, il ne peut pas modifier le PCP :

Citer

new-vlan-priority (integer: 0..7) | Changes the VLAN priority field (priority code point, the property only applies to Atheros8327, QCA8337 and Atheros8316 switch chips)

Donc soit tu utilises les filtres bridge :

Code: [Sélectionner]

/interface bridge filter
add action=set-priority chain=output src-port=68 dst-port=67 ip-protocol=udp mac-protocol=ip new-priority=6 out-interface=sfp-sfpplus1 passthrough=yes

Soit tu utilises le pare-feu :

Code: [Sélectionner]

/ip firewall mangle
add action=set-priority chain=output src-port=68 dst-port=67 protocol=udp new-priority=6 out-interface=sfp-sfpplus1

Soit tu ajoutes un CRS305, sur lequel la commande fonctionnera entre l'ONT et le routeur.

Teste avec une des 2 premières méthodes, si ça fonctionne, la 3e est préférable parce que c'est la seule qui décharge le CPU du routeur du marquage supplémentaire.

moray · « **Réponse #1362 le:** **Hier** à 21:55:56 »

Ca y est, j'ai trouvé grace à une réponse sur le forum mikrotik. La solution est de mettre l'interface sfp-sfpplus1 sur le bridge (configuré pour faire du vlan filtering), ajouter une vlan et mettre le client dhcp sur cette vlan. Le bridge va enlever les tag des paquets.

Dans ma configuration j'avais deja le bridge avec des vlan et le vlasn filtering activé, j'ai donc ajouté le port sfp-sfpplus1.
En suite j'ai crée une vlan (1000), je l'ai ajouté dans la liste des interfaces WAN (que j'utilise pour les configs comme firewall etc.), mis le PVID du port sfp-sfpplus1 sur le bridge à 1000 et activé l'option "Frame Types" sur "admit only untagged and priority tagged"
En suite le client dhcp est à configurer sur l'interface vlan1000 est ca prend l'adresse IP.

Avant de faire ca j'ai aussi branché mon ancien router SOFOS sur opnsense qui a une cage SFP et j'ai aussi vérifié que en effet ca marchait bien.

Edit: la manip avec la chaine firewall mangle était aussi suggéré par chatgpt, mais ca n'a pas marché.