Ankündigung

Einklappen
Keine Ankündigung bisher.

Homeserver / IP-Router Pakete über Layer 2 Bridge routen

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Homeserver / IP-Router Pakete über Layer 2 Bridge routen

    Hallo Community,
    sorry, falls dieses Problem hier etwas doof beschrieben ist, aber ich bin ITler bzw . Netzwerker und habe von KNX bzw. KNXnet/IP nicht so die Ahnung, brauche aber Hilfe da wir nicht mehr weiter kommen auf IT Seite.

    Folgendes Problem haben wir bei einem Kunden.
    Der Kunde hat einen Gira Homeserver der einen Gira IP Router lokal im Netz hat und einen weiteren an einem anderen Standort.

    Wir haben dort eine Astaro Firewall im Einsatz mit einem VPN Device von Astaro welches RED heist. Dieses Device macht einen Layer 2 VPN Tunnel auf den wir in das Haupt Netzwerk gebridged haben.

    Dies bedeutet nun das wir z.B. den Homeserver auf der 192.168.1.90 haben, den dort lokalen IP Router auf 192.168.1.91 haben und den entfernten IP Router auf der 192.168.1.92 haben.

    Wir können pingen, Daten austauschen etc.
    Also Netzwerkseitig ist alles prima.

    Der Elektrobetrieb sieht auch alle KNX/EIB Kommunikation in seiner Software wenn er in der Aussenstelle ist, sowohl die aus dem Hauptgeschäft wie die aus der Aussenstelle.

    Jetzt kommt das suspekte.
    Wir können den IP Router in der Aussenstelle über den Homeserver erreichen und schalten, aber alle Telegramme die zurück zum Homeserver müssten kommen nicht an.

    Wir haben den Fall nun Wochen lang analysiert und sehen die Multicast Pakete auf UDP Port 3671 den IP Router verlassen und dann sind diese weg.

    Astaro hat das mit uns nun analysiert und wir sind zu dem Entschluss gekommen das es eigentlich nur an der TTL liegen kann.
    Der Gira Homeserver sendet mit einer TTL von 16, der IP Router von Gira mit einer TTL von 1.
    Ergo wird das Paket verworfen noch bevor es den Endpunkt erreicht, wir haben immerhin die Hardware VPN Box, DSL Router, Internet, DSL Router und Firewall dazwischen, TTL 1 ist hierfür zu wenig.

    Laut Gira kann man das allerdings nicht ändern.

    Klingt das mit der TTL plausibel?
    Gibt es hier eine Lösung?

    Wir haben eben das Problem das Thermometer, Uhr etc. keine Multicasts zum Homeserver bekommt und dieser auch nie den Status der Gruppen mitbekommt, da die Quittungen bzw. Pakete fehlen.
    Wie gesagt, schalten können wir, nur kommt das ACK Telegramm nicht zurück.

    Wir sind sehr dankbar für jegliches Feedback, dieses Problem hat uns nun schon Wochen an Arbeit verursacht.

    Vielen lieben Dank vorab!

    #2
    Zitat von ALTEMO Beitrag anzeigen
    Klingt das mit der TTL plausibel?
    Also wenn die TTL schon beim Senden auf 1 steht, ist es logisch, das dieses Paket nicht über Routergrenzen hinweg geht.
    Da jeder Router am TTL den Wert 1 abzieht und bei 0 ist dann vorbei.
    Was ich nicht genau verstanden habe.

    Der Gira-Server sendet Pakete mit TTL=1?
    --
    Gruß
    Lothar

    Kommentar


      #3
      Zitat von ALTEMO Beitrag anzeigen
      Klingt das mit der TTL plausibel?
      Gibt es hier eine Lösung?
      Plausibel klingt es aber da musss Astaro dann nachbessern wenn sie das Paket nicht weiterleiten

      TTL ist ein Layer 3 IP Feature und hat den Layer 2 VPN Tunnel nicht zu interessieren. Der muss das Paket weiterleiten.

      Eine andere Quelle von Multicast Problemen auf Layer 2 kann IGMP snooping sein wenn IGMP (wie im Fall von vielen KNX/IP Router) nicht verwendet wird.

      Da die Kommunikation in eine Richtung aber funktioniert ist es eher Unwahrscheinlich dass hier das Problem liegt aber man sollte es auch nicht ausschliessen.

      Gruss,
      Gaston

      Kommentar


        #4
        Hallo,
        wir sehen das Multicast Paket durch den Tunnel laufen, es "stirbt" aber dann auf der Firewall bevor es auf das interne LAN geroutet wird.

        Rein technisch ist das für TTL 1 absolut plausibel.

        Ich verstehe nicht das man die TTL der Telegramme vom Gira IP Router nicht hoch setzen kann!?

        Kommentar


          #5
          Zitat von ALTEMO Beitrag anzeigen
          Rein technisch ist das für TTL 1 absolut plausibel.
          Plausibel beudeutet nicht richtig ! Es ist plausibel dass der Router bei TTL=1 hier einen Fehler macht, ja. Dennoch muss er es weiterleiten.

          Zu sagen dass das Verhalten der Routers/Firewall bei TTL=1 richtig ist, ist falsch

          Ich verstehe nicht das man die TTL der Telegramme vom Gira IP Router nicht hoch setzen kann!?
          Ein TTL von 1 ist absolut legal und bedeutet dass das Telegram nicht geroutet werden soll. Natürlich wäre es besser wenn man dies parametrieren könnte.

          Dennoch liegt der Fehler in diesem Fall, wie gesagt, nicht beim KNX/IP-Router.

          Gruss,
          Gaston

          Kommentar

          Lädt...
          X