Ungewöhnlich langsame IP-Pings & schnelle Batman-Pings

Wir haben die seltsame Situation, dass bestimmte pings über mehrere Batman-Hops (sowohl IPv4 als auch IPv6) sehr viel langsamer sind, als man das von den Latenzen der einzelnen Hops her erwarten würde.

Konkret sieht der relevante Teil des Netzes so aus: Knoten X hängt über einen fastd-Tunnel an GW A. Außerdem ist noch der mgmt-Server über einen GRE-Tunnel mit GW A verbunden. Über beide Tunnel läuft dann Batman.

Wenn ich nun von A aus X anpinge, bekomme ich Latenzen von ca 50ms. Wenn ich von mgmt aus A anpinge, sind es <10ms. Wenn ich jedoch von mgmt aus X anpinge (also den Hop über A ausnutze), brauchen die Antworten mehr als 100ms. Das trifft sowohl für IPv4 als auch für IPv6 zu, und sowohl für Pings direkt zum Knoten als auch für Pings zu einem Client, der an dem Knoten hängt. (IPv4 direkt zum Knoten konnte ich nicht testen, da die Knoten keine v4-Adresse haben.) Der Batman ping ist jedoch wie erwartet in der Größenordnung von 60ms.
Das führt zu der absurden Situation, dass ein Ping an die öffentliche IPv6-Adresse von X, der dann über das Internet zum FFRL und von dort über das GW A zum Knoten geht, deutlich schneller ist als ein Ping im Freifunk-Intranet, der über Batman direkt zum GW A und dann zum Knoten X gehen sollte.

Kann es sein, dass Batman die IP pings irgendwie über eine völlig andere Route schickt als seine eigenen Pings? Natürlich gibt es hier ein paar Schleifen, sowohl mgmt als auch GW A sind zum Beispiel auch mit GW B verbunden – aber batctl tr sagt, die direkte Route würde verwendet; und selbst dieser zusätzliche Hop kann die Latenz eigentlich nicht erklären.

Hat jemand von euch sowas schon mal ein seinem Netz beobachtet? Gibt es irgendwelche Ideen, woran das liegen könnte oder was man da tun kann?