Gelöst: Onlinegaming Verbindungsabbruch wenn das Fallback Gateway ausfällt

[mrk45k]

Hallo zusammen,

ich habe ein kleines Problem.
Wenn meine Fallbackleittung (LTE) ausfällt fliege ich aus sämtlichen online game sessions raus die gerade aktiv sind.

Das komische ist dabei das meine Hauptleitung (DSL) nicht gestört ist zu dem Zeitpunkt.
Das ganze ist reproduzierbar in dem ich den Fallbackrouter neustarte.
Das ganze habe ich aber vor ein paar Monaten getestet und das Phänomen scheint seit der neusten OPNsense Version zu sein.

Beide Gateways sind als WAN Gruppe angelegt  DSL hat Priority 10. LTE Priority 254.
Das Umswitchen und zurückfallen funktioniert tadellos.
Nur leider passiert irgend etwas wenn die Fallbackleitung gestört ist.

OPNsense ist:
OPNsense 21.1.8_1-amd64
FreeBSD 12.1-RELEASE-p19-HBSD
OpenSSL 1.1.1k 25 Mar 2021

Hat einer einen Ansatz/Idee was das sein könnte?
Was ich probieren könnte?


Gruß Karsten

Code: [Select]

            ,~~~~~~~~,                ,~~~~~~~~,
   { Internet }              { Internet }
    '~~~:~~~~'               '~~~~:~~~'
            :                          :
            : 140/40 Mbits             : 21/11 Mbits
            : DSL                      : LTE
            : IPv4+IPv6                : IPv4
            :                          :            Gateway 1: 192.168.2.0/24
      .-----+-----.              .-----+-----.      Gateway 2: 192.168.21.0/24
      | Gateway 1 |              | Gateway 2 |      Vlan_1:   172.29.1.0/24  (Null)
      | FB7590    |              | FB6820v3  |      Vlan_11:  172.29.11.0/24 (Network)
      '#----+-----'              '-----+-----'      Vlan_16:  172.29.16.0/24 (WPA3)
       §    |                          |            Vlan_21:  172.29.21.0/24 (Main/Media)
  ,~~~~#    |                          |            Vlan_80:  172.29.80.0/24 (DMZ)
 { DECT }   '----------,   ,-----------'            Vlan_90:  172.29.90.0/24 (Guest/IoT)
 { VoIP }              |   | Fallback               Vlan_100: 172.29.100.0/24(Ulla)
  '~~~~'         .-----+---+-----.                  OpenVPN_1:     10.11.0.0/24
                 | OPNsense      |                  OpenVPN_2:     10.11.1.0/24
         | Qotom i56200u |                  Wireguard:     10.11.2.0/24
                 | -[OpenVPN_1]  |                  RPi_OpenVPN:   10.8.7.0/24
                 | -[OpenVPN_2]  |                  RPi_Wireguard: 10.8.9.0/24
                 | -[Wireguard]  |
                 '-------#-------'
                         #
                         # LAGG (vlan:1,11,16,21,80,90,100)
                         #
                  .------#-----.                           
     ,~~+~~,      | PoE-Switch |                           ,~~~~+~~~~,
    { AP's  }-----+ HPE 1920S  +-------+-------------------{ Ulla's AP }
     '~~#~~'      '------------'      |                    '~~~~#~~~~'
§                              |                         §
§(vlan:11,16,21,90)            |(vlan:11,21,80,90)       §(vlan:100)
§                              |                         §
 .------#--------.             .-------+-------.         .-------#-------.
 | Cameras       |         | Consoles      |         | Mediaplayers  |
 | Laptops       |             | RPi's         |         | Laptops       |
 | Mediaplayers  |             | Switchs       |         | Mobilephones  |
 | Mobilephones  |             | NAS           |         '---------------'
 | Rollershutters|             | Mediaplayers  |
 | Powersockets  |             | TV's          |
 | etc.          |             | Cameras       |
 '---------------'             | etc.          |
                               '---------------'


[mrk45k]

Hat hier keiner eine Idee?

Laut den Reporting ist kein großartiger Traffic auf dem Fallback Gateway. Zumindest wie ich das so ersehe.
Und es fliegen alle Rechner raus aus den Onlinegaming sessions, nicht nur einer.
Deshalb muss es, meiner Meinung nach, übergeordnet an OPNsense liegen.

Das Ganze passiert auch wenn das Monitoring auf die Moitoring IP (google DNS 8.8.8. fehlerhaft ist.
Also die eigentliche Verbindung noch läuft aber Paketverluste vorhanden sind beim Monitoring.

Ich habe keine " Sticky Connections" aktiviert. Weil mein LTE nicht soviel (50GB Trafficlimit) Daten hat.
Und da im Falle des Fallbacks schon eine gute Menge an Daten anfällt. Weil meist Abends die Hauptverbindung schwächelt und wir viel streamen zu dem Zeitpunkt. Und dann summiert sich das ganze ganz schnell da erstmal wieder gepuffert wird. Videostreams laufen somit aber durch (mit artefaktbildung, daran erkenne ich das dann meist). In dem oben genannten Fall werden logischerweise auch alle Onlinegamesessions abgebrochen. Da ist es aber auch verständlich. Was ich nicht verstehe ist wieso ich aus den Sessions fliege wenn das Fallback Gateway fehlerhaft ist, obwophl dieses eigentlich garnicht meine Verbindung zum Server ist.

[chemlud]

Schuß in's Blaue:

https://forum.opnsense.org/index.php?topic=23668.msg113078#msg113078

?

[mrk45k]

Jepp, das war ein sehr guter Schuß ins "Blaue"!

Ich hatte es heute Morgen, nach ein wenig Überdenken, so gelöst das Ich nicht den Google DNS als Monitoring IP nehme. Sondern standard das Gateway.
Denn eigentlich ist die Leitung ja nur zur Not, und wenn diese ausfällt und die Hauptleitung auch weg ist. Dann ist es mal so. Ohne Internet.
Bei einem Neustart des Routers sind(waren) die Onlinesessionabbrüche aber immer noch vorhanden.
Das werde ich auch so belassen, da es ja nicht schadet.

Jetzt, mit dem "Disable State Killing on Gateway Failure" enabled kann ich den Router auch Neustarten ohne raus zufliegen!

Warum hat das ganze den vorher Funktioniert? Ist mir aber eigentlich egal da es gelöst ist!

[chemlud]

Wenn du Francos Antworten weiter unten in dem Fred liest, wird es vielleicht "klarer" (oder unklarer?), wie sich das historisch entwickelt hat. Richtig verstanden habe ich es nicht und auch nicht, warum es ein Nachteil sein kann.

[mrk45k]

So wie ich das verstehe wurde die Variabelenabfrage umgeschrieben von...

isset = variabele ist vorhanden und gesetzt (ungesetzet bei nicht vorhanden!)

..auf..

!empty = variabele ist aufjedenfall vorhanden und beschrieben. Ob gesetzt oder ungesetzt wird im bedarf dann später überprüft.

Und da scheint wohl was im PHP anders interpretiert zu werden bei diversen versionsständen.