Aufschaukelnder Traffic von WAN zu sich selbst

[Patrick M. Hausen]

Ich würde bei einem fest zugewiesenen e.g. /56 vom Provider immer alle internen Interfaces statisch konfigurieren.

dead:beef:dead:be<VLAN ID>::1/64 benutze ich. 8 Bit - 1-255 - reicht für meine VLANs. 🙂

[meyergru]

Das Problem ist hier wahrscheinlich nicht "Track Interface" vs. "statische Konfiguration" auf den LAN-Interfaces, sondern, dass der Zugang beim Telekom-Business immer noch über PPPoE kommt. Und der /56er Präfix wird dort per DHCPv6 geholt, was offenbar nebenbei dazu führt, dass /56 auf lo0 kommt.

Du hast aber Recht: man könnte das WAN auch mit einer statischen IPv6 versehen und gucken, ob die fehlerhafte Route dann verschwindet. Und dann eben die lokalen Interfaces auch statisch.

[Patrick M. Hausen]

Und der /56er Präfix wird dort per DHCPv6 geholt, was offenbar nebenbei dazu führt, dass /56 auf lo0 kommt.

Ist bei mir aber auch so:

dead:beef:deaf:be00::/56              link#6                        USB             lo0

Und so eine Route ist ja sinnvoll. Das ist ja ein Summary, also jeder longer match überschreibt das. Und wenn man mit OSPF oder BGP irgendwas weiterverteilt, ist es gut, wenn das eigene Prefix stabil an irgendeinem nicht physischen Interface anliegt.

Ich kann noch nicht ganz folgen, wie das zu Problemen führen soll. Die Route ist wie schon geschrieben ja maximal *un*spezifisch.

Gruß
Patrick

[meyergru]

Das Problem liegt nicht bei der reinen Routenauswahl, sondern in den Host-Routen und der lo0-Bindung:

Routen auf lo0

Jede Adresse, die OPNsense auf lo0 ,,als Alias" einträgt, bekommt so eine lo0-Route.

Das sagt: diese einzelne Adresse gehört zu mir selbst.
- Pakete an diese IP werden niemals weitergeleitet, sondern lokal verarbeitet.
- Wenn so ein Alias zufällig im Prefix-Bereich der Clients liegt, sehen Clients ein Gateway, das eigentlich gar kein echtes Ziel ist.

/56 auf lo0

Das ist noch gefährlicher. Die Route bedeutet: ich selbst (lo0) bin zuständig für das ganze /56.
Das widerspricht der normalen Logik, wo nur die jeweils delegierten /64s auf den physischen Interfaces on-link sind.
- Für Adressen aus dem /56, die keiner /64-Route zugeordnet sind, greift diese lo0-Route.
- Der Kernel behandelt sie als ,,lokal", statt sie sauber als unreachable/off-link zu markieren.
- Ergebnis: Neighbor Discovery läuft ins Leere, Forwarding wird inkonsistent, manche Pakete landen trotzdem auf Default, weil die Adressauflösung auf dem gewählten Interface fehlschlägt.

Ich glaube auch, dass diese zusätzlichen lo0-Einträge so lange unproblematisch sind, wie sie auf nicht überlappende Präfixe angewendet werden.

Aber warten wir doch ab, was passiert, wenn @SarpeTronic die Route löscht - benötigt wird sie sicher nicht. Ich habe das bei mir getan und sie fehlt offenbar nicht, aber wie gesagt, ich habe das Problem aus verschiedenen Gründen nicht...

[Patrick M. Hausen]

Aber das ist eine *blackhole* Route. Siehe die Flags. Jedes Paket, das über diese Route weitergeleitet wird, wird verworfen.

Und das kann ja nur passieren für Ziele aus meinem /56, für die ich kein "more specific" irgendwo habe. Und dann ist das richtig so. Ich soll die nicht zurück ins Internet schieben. Genau dafür sorgt so eine Route.

In IOS ist es best practice genau so eine Route für das gesamte eigene AS in Richtung Null0 anzulegen. Der Effekt ist derselbe.