Frühere Suchanfragen

Keine früheren Suchanfragen

Suchoptionen

Nur verfügbar, wenn angemeldet.
sueden.social ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Eine Community für alle, die sich dem Süden hingezogen fühlen. Wir können alles außer Hochdeutsch.

Verwaltet von:

Serverstatistik:

1,8 Tsd.
aktive Profile

sueden.social: ÜberStatusProfilverzeichnisDatenschutzerklärung

Mastodon: ÜberApp herunterladenTastenkombinationenQuellcode anzeigenv4.4.3

#switchdev

0 Beiträge0 Beteiligte0 Beiträge heute
T_X<p>So, a bunch of <a href="https://chaos.social/tags/multicast" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>multicast</span></a> fixes for <a href="https://chaos.social/tags/rtl83xx" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rtl83xx</span></a> / <a href="https://chaos.social/tags/OpenWrt" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenWrt</span></a> / Linux bridge / <a href="https://chaos.social/tags/switchdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>switchdev</span></a> / DSA patches are out now.</p><p>Fix 1: Already applied: <a href="https://github.com/openwrt/openwrt/pull/18733" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/openwrt/openwrt/pul</span><span class="invisible">l/18733</span></a><br>Fix 2: Pending: <a href="https://github.com/openwrt/openwrt/pull/18769" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/openwrt/openwrt/pul</span><span class="invisible">l/18769</span></a></p><p>And a slightly larger patchset here: <a href="https://github.com/openwrt/openwrt/pull/18780" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/openwrt/openwrt/pul</span><span class="invisible">l/18780</span></a></p>
T_X<p>I really think <a href="https://chaos.social/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a> kernel switch folks should make up their mind at some point if they think switch drivers should register handlers with <a href="https://chaos.social/tags/DSA" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DSA</span></a> or if they should implement a switch-case to check for various <a href="https://chaos.social/tags/switchdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>switchdev</span></a> events for the same stuff. One approach should be ditched.</p>
T_X<p>In the classic, non-DSA <a href="https://chaos.social/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a> bridge the philosophy so far is: No matter in what combination you enable/disable multicast_snooping+ multicast_querier: The bridge ensures you don't break any network protocol, it detects per protocol family if <a href="https://chaos.social/tags/multicast" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>multicast</span></a> snooping is applicable. That together with <a href="https://chaos.social/tags/RFC4541" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC4541</span></a> I think is the only way to regain trust for <a href="https://chaos.social/tags/IGMP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IGMP</span></a> / <a href="https://chaos.social/tags/MLD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MLD</span></a> snooping imo.<br>And now things like <a href="https://chaos.social/tags/DSA" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DSA</span></a> or <a href="https://chaos.social/tags/switchdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>switchdev</span></a> come along with non-foolproof solutions, diverging between each driver...</p>
T_X<p>...and even this mrouter exists <a href="https://chaos.social/tags/switchdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>switchdev</span></a> event is a quite incomplete approach. What if you multicast router somehow <a href="https://chaos.social/tags/IGMP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IGMP</span></a> / <a href="https://chaos.social/tags/MLD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MLD</span></a> querying disabled -&gt; would break any <a href="https://chaos.social/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a>, even if you're not using multicast routing. What if you only have an IGMP querier? Would notify an mrouter-exists, but there's no MLD querier, so again IPv6 would be broken...</p>
T_X<p>Neither <a href="https://chaos.social/tags/switchdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>switchdev</span></a> nor <a href="https://chaos.social/tags/DSA" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DSA</span></a> really check if an IGMP/MLD querier exists. So if you enable multicast snooping on these you currently also need to make sure to have an IGMP/MLD querier somewhere. Which is different to a classic Linux bridge, which will stop snooping optimizations if there is none, to avoid packet loss. Only for Marvell Prestera I found some mrouter-exists check via an according switchdev event. Which no other driver uses. And...</p>
T_X<p>Could it be that <a href="https://chaos.social/tags/switchdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>switchdev</span></a> vs. <a href="https://chaos.social/tags/DSA" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DSA</span></a> is a bit of a mess on <a href="https://chaos.social/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a>? I have the feeling I'm starting to get a better hang of their code, while trying to implement something in there. For instance: The Linux bridge notifies MDB additions through switchdev events. Either your switch driver can listen/react to them directly. But also DSA listens to them and can call a port_mdb_add handler which your driver registered with DSA. Some drivers are some DSA / switchdev hybrid...</p>
T_X<p>for the former case it is broken when you have devices/listeners with <a href="https://chaos.social/tags/IGMP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IGMP</span></a> v1/v2 or <a href="https://chaos.social/tags/MLD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MLD</span></a> v1, instead of IGMPv3 / MLDv2. The issue you'll then potentially run into is IGMP / MLD report suppression. The big thing which <a href="https://chaos.social/tags/RFC4541" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC4541</span></a> specifies an ugly workaround for... this whole report suppression has lead to so many hard to debug, subtle breakages for decades and now seems to continue with <a href="https://chaos.social/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a> <a href="https://chaos.social/tags/DSA" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DSA</span></a> / <a href="https://chaos.social/tags/switchdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>switchdev</span></a>...<br><a href="https://chaos.social/tags/multicast" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>multicast</span></a> <a href="https://chaos.social/tags/igmpsnooping" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>igmpsnooping</span></a> <a href="https://chaos.social/tags/mldsnooping" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mldsnooping</span></a></p>
T_X<p>and Jan's reply on the <a href="https://chaos.social/tags/OpenWrt" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenWrt</span></a> forum also lead me to this observation, that several <a href="https://chaos.social/tags/switchdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>switchdev</span></a> drivers seem to try to emulate a multicast router port by mirroring all known <a href="https://chaos.social/tags/multicast" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>multicast</span></a> listener entries onto these mc router ports... <a href="https://patchwork.ozlabs.org/project/openwrt/cover/20230303214846.410414-1-jan@3e8.eu/#3074983" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">patchwork.ozlabs.org/project/o</span><span class="invisible">penwrt/cover/20230303214846.410414-1-jan@3e8.eu/#3074983</span></a><br>Which makes me scream, this is broken in so many scenarios... like when you use multiple <a href="https://chaos.social/tags/IGMP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IGMP</span></a> / <a href="https://chaos.social/tags/MLD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MLD</span></a> snooping switches. Or if you don't have a listener for that group, only a sender, whose packets still need to go to multicast routers.</p>
T_X<p>Can anyone recommend any <a href="https://chaos.social/tags/switchdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>switchdev</span></a> capable switches? Doesn't have to be crazy fast, 1 Gbit/s ports would be fine. I'd mostly be interested in using it for <a href="https://chaos.social/tags/multicast" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>multicast</span></a>, so that the <a href="https://chaos.social/tags/IGMP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IGMP</span></a> / <a href="https://chaos.social/tags/MLD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MLD</span></a> snooping would be performed by the <a href="https://chaos.social/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a> bridge. Is there anything that would be affordable for a <a href="https://chaos.social/tags/hackspace" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>hackspace</span></a>?</p>
Joachim Wiberg<p>Been looking for a <a href="https://fosstodon.org/tags/Marvell" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Marvell</span></a> 88E6393X switch chipset equipped board to run our little NOS on. Older LinkStreet/SOHO variants are also of interest, but not too old. Newer Prestera based ones don’t have <a href="https://fosstodon.org/tags/linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>linux</span></a> <a href="https://fosstodon.org/tags/switchdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>switchdev</span></a> support so not interesting (unfortunately because the Ironman is quite impressive!)</p><p>So far I’ve only found MikroTik RB5009. Which is interesting but needs a bit of work to get going with, and is limited to their bootloader. </p><p>Any tips are interesting, please RT! 😊</p>
AngesagtLive-Feeds
Über