Bien vérifier l'état du flag rp_filter sur l'interface de l'upstream (cela m'a fait perdre beaucoup de temps, parce que le multicast était filtré).

Bonsoir,

je rencontre toujours une réduction du débit, l'erl3 est en configuration DHCP ipv4 seulement avec maintenant un seul bridge (br1 vif840), le client dh3 patché et la livebox play/décodeur play (=3) sur eth2 (tel/tv). J'ai mis à jour toutes les options (merci zoc) et l'ensemble des services sont fonctionnels sans interruption depuis les changements chez Orange. Les débits moyens sont de 930/300 avec la Livebox sur l'ONT, ils tombent depuis 2-3 mois à 380/300 avec l'ONT sur l'erl3. Je viens de passer au firmware 1.10.8 sans amélioration. Les câbles sont en état et l'offload est toujours actif. La config a évolué sans aucun changement sur le vif 832.

Comment tester la fonctionnalité de l'offload?

Faut-il obligatoirement passer à la config sans bridge comme MikeTheFreeman? Ca ne m'arrange pas de perdre un port sur mon GS108T.

konki

@konki : les bridges ne sont pas offloadés mais même avec le bridge sur les interfaces du vlan 840 ça ne m'empêche pas d'attendre le 1 Gbps, le trafic multicast est négligeable (10-15 Mbps) donc peu d'impact sur le CPU.
Je pencherai pour une autre cause.

Sinon j'ai sniffé le trafic du décodeur TV connecté à la livebox, les igmp membership report viennent bien d'une adresse source dans le LAN par défaut de la livebox (192.168.1.X).
Donc soit c'est la livebox qui par défaut NAT l'adresse source, soit c'est un effet de bord provoqué parce qu'elle n'est pas directement connectée sur le WAN (supposition).

Demain je snifferai les igmp membership de la livebox lorsqu'elle est directement sur le WAN.
Si c'est bien un comportement par défaut de la livebox, rien ne m'empêchera de mettre le décodeur TV sur le même LAN que la livebox et ça réglera à la fois le soucis de bridge et de TV.

Je suis en 1.10.8, aucun soucis non plus. J'attends en peu pour la 2.X car les changes sont assez conséquents.

En cherchant des infos sur l'ip 100.64.0.1, je viens de trouver qu'il s'agissait en fait d'une ip réservée par iana pour certains usages opérateurs (IANA-Reserved IPv4 Prefix for Shared Address Space), donc il y a toutes les chances pour que ça soit un comportement par défaut de la livebox : https://tools.ietf.org/html/rfc6598
Donc en fait dans l'idéal, il faudrait aussi natter l'adresse source du décodeur pour les paquets igmp afin que son comportement se rapporte davantage de ce qui est attendu par Orange (même si sans nat, ça semble fonctionner).
Par contre mettre en place du nat pour un seul type de trafic, pas sûr que l'ERL offload cela. Sinon : configurer le dhcp server sur le range 100.64.0.0/10 mais ça aurait potentiellement d'autres effets de bord.

EDIT : je pense qu'il y a moyen de faire fonctionner igmp proxy en mettant une deuxième adresse dans le range 100.64.0.0/10 sur l'interface 2.840. Il aurait sa route vers 100.64.0.1 sans avoir à changer la routine de la livebox.

Donc tu as viré la livebox et n'utilise pas le téléphone, ce qui n'est pas mon cas.

EDIT : la tv sur la livebox fonctionne après avoir ajouté la deuxième adresse en 10.64.0.2/30 sur l'interface.
Maintenant je me demande si c'est pas mieux d'ajouter une route statique plutôt que d'avoir un subnet de ce genre.

Ça peut être pratique en terme de brassage selon la distribution de la maison.
Dans mon cas pour l'instant je souhaite uniquement avoir la livebox sur un port de l'ERL et que tous les services montent de façon transparente sur la livebox.

J'ai terminé tous les tests, pas d'autre choix que d'avoir une adresse (primary ou secondary) dans le subnet 100.64.0.0/10 sur l'interface eth2.840. La route statique/blackhole n'est pas prise en compte dans igmp-proxy.
Mais au final le résultat est là : net+tel+tv en dhcp et sans bridges
J'espère qu'Orange ne va pas faire des siennes maintenant.