En dehors de ce que vous avez réalisé "hors process", une chose que @Babou_o préconise doit à minima être réalisée pour obtenir que votre bâtiment soit reconnu avec le bon nombre de prises.
Il ne s'agit pas simplement de sommes à payer mais bien d'informer l'OI de la présence du bon nombre d'EL (Equivalent Logement) pour le bâtiment.
Je dirais déclarer le bâtiment comme si vous étiez un promoteur, donc avec l'obligation de câbler (ou faire câbler) le bâtiment, puis de déclarer le bâtiment câblé à l'OI.
Réussir à avoir 2 routes optiques supplémentaires ne serait pour moi qu'un "bricolage", qui ne consistera qu'à mieux sauter à la demande suivante.
Mais ce n'est n'est que mon avis d'observateur, l'ami @Babou_o étant lui un professionnel des télécoms intervenant sur le site depuis un "certain temps"...Bonne journée

Si on veut régénérer les chaînes d'auth, c'est probablement le plus pragmatique. Je suis de ton avis: modifier les chaînes d'auth en milieu de bail n'est pas une bonne idée.

Bonjour

Cela fonctionnerait (de changer les chaine en milieu de bail) mais la logique du DHCP est de garder les mêmes identifiant sur la session.

Il est mieux (mais pas impératif) de garder les info d'auth cohérente sur les deux stack sur la durée de la session dans le BNG. Mais là aussi ce n'est pas impératif dans l'implémentation actuelle.

Pour rappel, une session BNG est ouverte à la monté du premier stack v4 ou v6.
Et est fermée à la cloture (RELEASE ou DECO par timer) du dernier stack.
Entre l'ouverture et la fermeture du contexte BNG, on peut avoir autant de START/STOP des stack v4 ou v6 à la condition que l'un des deux reste connecté.
Le BNG considère qu'un client est "vivant" tant que l'un au moins des stack v4 ou v6 est en vie.
C'est le comportement de 3 des 4 fournisseurs de BNG, dont celui que l'on utilise chez Orange. Le dernier est un peu différent mais je ne me souviens plus du détail.

LeVieux

Certains avaient migré vers les réseaux mobiles pour anticiper la fin du cuivre (et payer moins cher). A voir si c'était 2G seulement ou 2G/3G ou 2G/3G/4G ...

Ce serait quand même très étonnant de migrer pour anticiper la fin du cuivre, et de choisir une techno annoncée également comme en fin de vie...

Bonjour,

Pourriez vous compléter votre profil avec votre numéro client disponible sur une des facture Bbox.

Merci

L'expression est malformée. Lire le premier paragraphe de Simple Rule Management.

Première expression : VLAN HEADER EXPRESSION

vlan id 832

Seconde expression incomplète : IPV6 HEADER EXPRESSION

ip6

Comment sélectionner en fonction du protocole encapsulé dans un paquet IPv6 ? Voir « Rappel IPv6 » ci-après.

Troisième expression : UDP HEADER EXPRESSION

udp dport 547

Analyse

Ce que l'on veut c'est sélectionner les paquets IPv6.

vlan type ip6

Attention : l'expression vlan type est surchargée. Voir « Ambivalence de l'expression vlan type ».

Rappel IPv6

Il faut utiliser l'expression meta l4proto en IPv6 pour correspondre au protocole encapsulé.

nft describe meta l4proto | grep icmp
        icmp                            1
        ipv6-icmp                       58

On peut utiliser l'expression abrégée icmpv6 type <data type>.

If you specifically want to match on the ICMPv6 type, then nftables creates an implicit meta l4proto dependency that is not shown, therefore, there is no need for being verbose in your notation, ie.

Code: [Sélectionner]

% nft add rule filter input icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
Hyperlien : Matching IPv6 headers

Ambivalence de l'expression vlan type

vlan type 8021ad vlan type 8021q vlan type ip6 counter

Cette expression représente explicitement une trame VLAN 802.1ad et une trame 802.1Q (enchaînement QinQ).

vlan type ip6 counter

Cette expression représente implicitement une trame VLAN 802.1q.

L'ambivalence apparaît dans la signification du type EtherType.

09:18

Finalement, il semblerait que mon interprétation soit fausse. J'ai essayé dans des espaces de nommages. nftables transforme la règle en :

table netdev test_qinq {
        chain ingress {
                type filter hook ingress device "veth_recv" priority filter; policy accept;
                ether type 8021q vlan type 8021ad vlan type 8021q vlan type ip6 counter packets 0 bytes 0 meta nftrace set 1
        }
}

09:31

Je crois que j'ai compris.

- VLAN support:

   # payload statement
   ip saddr 10.1.1.1 icmp type echo-request vlan id set 321

   # payload expression (QinQ matching)
   ether type 8021ad vlan id 10 vlan type 8021q vlan id 100 vlan type ip accept

Hyperlien : https://lwn.net/Articles/982283/

$ nft describe vlan type
payload expression, datatype ether_type (Ethernet protocol) (basetype integer), 16 bits

pre-defined symbolic constants (in hexadecimal):
        ip                              0x0800
        arp                             0x0806
        ip6                             0x86dd
        8021q                           0x8100
        8021ad                          0x88a8
        vlan                            0x8100

$ nft describe ether_type
datatype ether_type (Ethernet protocol) (basetype integer), 16 bits

pre-defined symbolic constants (in hexadecimal):
        ip                              0x0008
        arp                             0x0608
        ip6                             0xdd86
        8021q                           0x0081
        8021ad                          0xa888
        vlan                            0x0081

Donc, 8021ad ne devrait pas être utilisé dans l'expression vlan type mais uniquement dans l'expression ether type.